What’s needed to securely fit IoT devices into the enterprise framework

June 12, 2017

Dean Armstrong-June 12, 2017

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.

Continue reading on page two >>


< Previous
Page 1 of 2
Next >

Loading comments...