While traditional computing/IT systems now include robust practices and standards to best protect important enterprise devices on the network, the lack of these capabilities for Internet of Things (IoT) applications remains a primary deterrent for widespread adoption. According to a study by the Ponemon Institute, 2017 Study on Mobile and Internet of Things Application Security, 75 percent of respondents say the use of IoT apps increase security risk very significantly or significantly, with nearly the same amount very concerned about the use of insecure IoT apps. Despite the concern, less than half of respondents (44 percent) say their organization isn't taking any steps to prevent attacks.
For IoT device developers to enjoy a ready market and realize maximum growth, things need to change. Clearly, project designers need IoT applications that are as secure and robust as IT systems. In addition, with IT being an important stakeholder in the implementation of enterprise IoT solutions, adoption will increase as security improves and IoT devices better fit into the framework of these IT practices. Let’s look at what’s needed for IoT devices to securely fit into the enterprise framework.
Security requirements for enterprise IoT applications
IoT deployments often include the following architectural features to provide full security (see Figure 1):
- Use of multiple wireless protocols, including low-power sensor technologies, such as Bluetooth Smart, Thread, or Zigbee, all of which require gateways to access the public Internet or even the corporate intranet
- Carefully controlled access to the public Internet via a firewall
- Integration with public cloud services such as Microsoft Azure IoT Hub, AWS IoT and IBM Watson IoT, using highly scalable publish/subscribe protocols like Message Queue Telemetry Transport (MQTT)
Figure 1: IoT deployments include multiple protocols, controlled access to the public Internet and integration with public cloud services such as Microsoft Azure IoT Hub, AWS IoT and IBM Watson IoT. (Source: UbiquiOS Technology)
While the underlying connectivity technologies such as Wi-Fi and Bluetooth provide robust security at the link layer, these safety measures do not meet the security needs of an enterprise IoT application because the benefits exist only between the communicating wireless devices (e.g., between a Wi-Fi IoT end-point and the access point to which it is connected).
Enterprise IoT applications require true end-to-end security between the IoT end-point and the cloud server, preferably with a root of trust founded in secure hardware. The most important concerns, pictured in Figure 2, are typically:
- Authentication: Ensuring the end-point connects only to the proper server, and that the server accepts connections only from bona fide end-points
- Integrity: Ensuring all messages exchanged between the end-point and server are received accurately, and that any intentional (e.g., malicious) or unintentional (e.g., corruption) changes of a message while in-flight can be detected by the recipient
- Privacy: Ensuring no content of any message exchanged between the end-point and server is divulged to a third party
Figure 2: Enterprise IoT applications require true end-to-end security between the IoT end-point and the cloud server, with typical concerns including authentication, integrity and privacy. (Source: UbiquiOS Technology)
Clearly, there’s a gap between what IoT developers create and what IT architects need.
End-to-end security in the IP world
To ensure the same level of end-to-end security of the enterprise at the IoT level, Transport Layer Security (TLS) protocol is the first line of defense. With its origins in the Secure Sockets Layer (SSL) protocol developed by Netscape Communications, TLS provides state-of-the-art algorithms to secure a connection between two nodes and ensure that:
- The identity of the communicating parties can be authenticated using public key cryptography. This authentication can be made optional but is generally required for at least one of the parties (typically the server).
- The connection safeguards integrity because each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission.
- The connection is private because symmetric cryptography is used to encrypt the data transmitted. The keys for this symmetric encryption are generated uniquely for each connection and are based on a shared secret negotiated at the start of the session.
- The latest stable version of the protocol is TLS 1.2, defined by RFC 5246, with TLS 1.3 currently in draft status.
To provide the highest levels of security, TLS relies on asymmetric public key cryptography in which each communicating entity is assigned a unique and strong private key , and a mathematically related public key.
As its name suggests, the private key must be kept secure with its owner and not disclosed to any third party. The public key, on the other hand, may be made generally available, as it is practically impossible to use it to determine the private key.
Public key cryptosystems are structured to enable two primary operations:
- The public key may be used to verify that the holder of the corresponding private key signed a given message.
- The public key may be used to encrypt a message such that only the corresponding private key holder can decrypt it.
TLS builds on these functions to directly achieve the goals of authentication and ensure message integrity. Privacy is indirectly achieved by using communication under the protection of public key encryption to establish a shared secret that may then allow a more computationally efficient symmetric encryption scheme to protect subsequent communications.
With TLS securing the sender, the next step in closing the loop in providing full end-to-end security is protecting the receiving IoT end-point. For TLS to secure edge-to-cloud communications, developers need to consider the following:
- Secure storage of the private key in the IoT end-point, such that an attacker wishing to impersonate the device cannot retrieve it.
- Ensure the authenticity and validity of the public key certificate offered by a server to which the IoT end-point is attempting to connect.
As noted, private keys must remain known only to the IoT end-point to ensure the overall security of the system. If compromised, an attacker may use the private key to impersonate the IoT end-point, intercept communications, or gain increased surface or information for a potential attack on the cloud infrastructure.
While modern microcontrollers and architectures often implement mechanisms to protect non-volatile memory and incorporate cryptographic co-processing engines, such platforms can still be susceptible to discovery attacks using measurement of dynamic supply currents or analysis of electromagnetic emissions.
For applications with the highest security requirements, developers should choose a hardware secure element – a device built on tamper-resistant hardware that implements mechanisms to:
- Store the private key in a manner that makes it irretrievable by all practical means
- Perform the cryptographic operations necessary to sign and/or decrypt data using the private key
When combined with a secure, element-aware embedded IoT connectivity stack, key TLS protocol operations may be offloaded to the secure element, thereby providing the security benefits of a root of trust founded in tamper-resistant hardware (see Figure 3).
Figure 3: A secure stack comprises secure firmware built on tamper-resistant hardware. (Source: UbiquiOS Technology)
Establishing the Device on the Network
Due to the criticality of IoT solutions having a small footprint (e.g., lightbulb, sensor, etc.), IoT products typically have limited user interface and frequently need to be installed and commissioned by non-expert users. As a result, they must support a provisioning flow that is very simple to follow while still maintaining security of the overall system.
With the device identity and root of trust embedded within a hardware secure element in the IoT end-point, the primary role of the provisioning process is to enable the device with credentials and details for access to the wireless network and/or gateway by which it will access the Internet.
A common approach is to employ a smartphone or tablet application that presents a user-friendly interface to provision the device and link it with the appropriate cloud server and account. In this scenario, the IoT device may include an alternative wireless technology (that is, to the one that it uses to communicate with the cloud) providing an interoperable means to communicate with the provisioning smartphone or tablet.
For example, a Wi-Fi IoT product may additionally include a low-power, low-cost technology such as Bluetooth Smart. This technology provides a secure out-of-band pipe for provisioning, with excellent compatibility and usability on a broad range of smartphone and tablet platforms.
IoT implementations are a valuable tool in many applications for improving product features and capabilities. Unfortunately, many of these implementations are done with minimal resources and designers may be tempted not to address the critical nature of security.
But, in addition to the Samsung example shared in the sidebar, nearly every week, distributed denial-of-service (DDoS) or ransomware attacks such as the recent WannaCry cripple companies, compromising their ability to do business. Designing robust security into an IoT product whether a camera, thermostat or temperature sensor, is possible and should be part of every designer's criteria. Not only will the use of industry standard practices provide a high-level of protection and ease implementation in the field, it will provide the assurance needed for large enterprise level distributors to come onboard, resulting in a dramatic uptick in market growth.