Gartner forecasts that there will be 20.8 billion connected devices worldwide by 2020. The growing number of connected devices in the Internet of Things (IoT) provides an opportunity for service providers to develop new streams of revenue. For end users, IoT has the potential to provide solutions that can dramatically enhance productivity and quality in security, health, education, and many other areas. To capitalize on this opportunity, service providers must deliver an optimal customer experience while ensuring absolute data protection, privacy, and user safety.
However, this large number of diverse devices will also increase network vulnerability, with many devices carrying the potential to become targets for hackers and denial-of-service attacks. IoT devices are often constrained in memory, storage, and compute resources. These limitations make it a challenge to support complex and evolving security algorithms, as these require higher processing power with low CPU cycles. Connected devices might also outlive encryption effectiveness.
In a February 2016 survey and report on The Future of Mobile Service Delivery, Jim Hodges, senior analyst for Heavy Reading, pointed out that the top security concern for service providers is outages caused by distributed denial-of-service (DDoS) and botnet attacks. This fear is followed by threats related to system integrity in which traffic is manipulated by external attackers while spoofing a user’s identity.
Three concepts are fundamental to IoT security: identity, authentication, and authorization. Identity is about naming and providing authorization to the client. Authentication means proving the identity of the client, and authorization refers to managing the rights that are given to the client. To further enable the collection of device data for real-time intelligence analysis, IoT communication protocols have to be agreed upon as well.
IoT message protocols should include the following high-level functions:
Today, the popular IoT message protocol of choice is MQTT (Message Queue Telemetry Transport). MQTT is used as a primary transport protocol across industry verticals, including manufacturing, shipping/asset tracking, energy, and connected homes. Companies including IBM, Microsoft, Amazon Web Services, and Facebook Messenger all use MQTT for fast message delivery and to save battery life on devices.
IoT protocols like MQTT are used for secure and reliable communication between devices. MQTT is based on Transmission Control Protocol (TCP) and can be secured with Transport Layer Security (TLS). The MQTT protocol has been designed with low compute and memory requirements that are optimized with much simpler and smaller packet size than HTTP for certain IoT applications.
MQTT was originally created in 1999 for remote sensors but has found a new life with various IoT applications based on a publish-and-subscribe model. Devices/sensors will “publish” data to an IoT platform (broker) and the IoT application will then “subscribe” to the data that is relevant to its use case. The publish-and-subscribed data is called “topic,” which can be organized in a hierarchical structure based on use cases and category of the data type. Connectivity and communications between the devices and its platform influence the load, control, and security required by each use case.
In order to keep the protocol as lightweight as possible for resource-constrained IoT devices, MQTT provides minimal security beyond TCP. MQTT only recommends that the TLS protocol be used for applications that require additional levels of authentication. As a result, MQTT communications that rely on TCP alone are unencrypted and susceptible to man-in-the-middle attacks.
The MQTT protocol carries a number of potential vulnerabilities. For example, open ports can be used to launch denial-of-service (DoS) attacks as well as buffer overflow attacks across networks and devices. Depending on the number of IoT devices connected and use cases supported, the complexity of “topic” structure can grow significantly and cause scalability issues. MQTT message payloads are encoded in binary, and corresponding application/device types must be able to interoperate. Another problem area is with MQTT message usernames and passwords, which are sent in clear text.
While not specifically part of the MQTT specification, it has become customary for IoT platform brokers to support client authentication with SSL/TLS client-side certificates. Transport encryption with SSL and TLS can protect data when implemented correctly. To protect against threats, sensitive data including user IDs, passwords, and any other types of credentials should always be encrypted.
The downside of using TLS, SSL, and other methods of encryption is that they can add significant overhead. However, techniques such as TLS session resumption can compensate for some of the connection costs of TLS. Hardware acceleration is another method for reducing the size penalty for encryption. For complex applications over constrained devices, an optimized encryption library can be very useful. When application code is large, an encryption library can reduce the processing memory and increase performance.
The architecture of MQTT depends on brokers being highly available. Using X.509 certificates for client authentication can save resources on the broker side when many clients try to use broker services—such as database lookups or web service calls. Combining MQTT with state-of-the-art security standards like TLS and using X.509 certificates can also help improve security and performance.
The IoT represents an important new business opportunity for service providers. Though securing the MQTT messaging protocol with TLS is an important security consideration, many other attack vectors can also be exploited. Service providers must ensure end-to-end security with tight authentication of devices, authorization, and network-enforced policy for access to communication paths. The encryption of data for safety and privacy is also critical to the revenue streams of service providers in delivering an optimal customer experience.