IoT applications require end-to-end security — from device to Cloud

Figure 1: Security must be guaranteed from the IoT device to the cloud. This means encryption over its chosen wireless protocol, which then connects to the gateway/edge device. This must then take the IoT device’s data on to a server in the cloud using security measures like TLS in the IP stack.

The Internet of Things is presenting us with myriad small devices that affect industry, medicine, sports, and banking, as well as our vehicles, and ultimately our daily lives. While their small size and convenience may be the initial attraction, their true value is only realized by their connection—via the Internet—to the “Cloud.”

This somewhat nebulous term has real significance because the data collected and used by IoT devices really only gains value when it can be analyzed, compared and processed with other data and acted on by sophisticated applications that cannot reside on a small device, but instead, depend on those devices connection to the wider world of the Internet. That means that the data the IoT devices send and the data they receive—along with control commands sent back from the cloud—is the most important commodity and the basis for their value.

That data must be protected from corruption, theft and unauthorized use. It is not enough to simply secure a wearable medical instrument, for example. The path of the data from that instrument to say, a router, and from that router to a local server on a private network and from there to an actual corporate or hospital data center in the Cloud must be protected along its entire path (Figure 1).

Security from IoT to Cloud

According to a study by the Ponemon Institute, 75 percent of respondents say the use of IoT applications significantly increases security risk, with nearly the same number being very concerned about the use of insecure IoT applications. Despite that concern, 44 percent of respondents say their organization isn’t taking any steps to prevent attacks. For IoT device developers to enjoy a ready market and realize maximum growth, something needs to change. In the IoT world, there are a number of wireless protocols that have been developed to meet the needs of various scenarios and application areas.

For example, a medical device monitoring heart rate and blood oxygen for a person engaged in normal day-to-day life might work very well using a Bluetooth link to a smartphone carried by the patient. In contrast, tracking an shipment container being trucked across country would need another form of wireless connectivity—hence the availability of different wireless options. These protocols include the more familiar ones like Wi-Fi, Thread and Bluetooth, but also others like LoRa, Sigfox and NB-IoT. While these protocols do provide security at the link layer, enabling devices to communicate securely with each other and with a web gateway device, they do not themselves address the issue of security beyond the IoT endpoint.

The connection from endpoint to Cloud must use the Internet Protocol—an IP stack—and the specific wireless protocol must interface with the stack and be able to maintain security all the way to the Cloud. This should ideally include a root of trust founded in secure hardware. The most important concerns for security are authenticity—assuring that the proper entities are actually the ones communicating, integrity—assuring the messages received are actually the same as those that were sent, and privacy—assuring that no content is divulged to a third party.

Figure 2: Device security is built on a hardware processor platform with built-in security mechanisms to establish a root of trust. The operating system level mechanisms built on that manage encryption/decryption and key management and interface to the IP stack, which carries that security out to the cloud.

Security from endpoint to Cloud

In the past, enterprises have relied on the Secure Sockets Layer (SSL) within the IP stack for secure communication. However, the more recent Transport Layer Security (TLS) protocol provides newer, state-of-the-art algorithms aimed at securing communications between an IoT endpoint such as a gateway device or another device connected directly to the Internet. It is specifically designed to meet the three requirements listed above (Figure 2). The first is to authenticate the identities of the communicating parties such that the end-point connects only to the proper server and that the server accepts connections only from authenticated end-points. This is done using public key cryptography and can be made optional, but it is generally required for at least one of the parties (typically the server). The connection must also safeguard integrity by ensuring all messages exchanged between end-point and server are received accurately.

The recipient must be able to detect intentional or unintentional changes or corruption to a message. To do this, each message transmitted includes a message integrity check using a message authentication code to prevent undetected loss or alteration of the data during transmission. Messages must also be kept private so that no content is divulged to a third party. 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. A common thread running through these TLS security features is asymmetric public key cryptography. Public key cryptography actually relies on a private key as well as a public key.

This works by assigning each communication device a unique and strong private key, which must be kept secure with its owner and not divulged to any third party. A mathematically related public key can be generally distributed because it is almost impossible to use it to discover the private key. The public key is used to encrypt a message so only its corresponding private key can decrypt it. Such public keys can therefore only be used to communicate with one specific device. The public key can also verify that the device holding the corresponding private key signed a given message.
Use secure hardware
A crucial requirement for secure communications is that an end point’s private key be reliably protected so that no attacker can retrieve it to impersonate the legitimate device. It is also necessary to ensure than an IoT end-point is able to verify the authenticity and validity of the public key certificate offered by the server to which it is attempting to connect. Given the importance of the private key in also verifying the identity of the server, it must be protected from access or compromise with tamper-resistant storage. The best way to securely store that private key is to use hardware with built-in security features, but not just any hardware.

Many modern microcontrollers implement mechanisms to protect non-volatile memory and incorporate cryptographic co-processing engines, but such platforms can still be susceptible to attacks using measurement of dynamic supply currents or analysis of electromagnetic emissions and cannot be considered reliably secure. For applications with the highest security requirements, developers should choose a hardware secure element – a device built on tamper-resistant hardware. It must be able to store the private key so that it is irretrievable by all practical means as well as perform the cryptographic operations necessary to sign and/or decrypt data using the private key.
Establishing the device on the network
IoT products typically have a small footprint, with many sold as consumer products that often need to be installed and commissioned by lay persons or non-experts. Therefore, the process of provisioning them must be straightforward and easy to follow without compromising the 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 provisioning process can—without compromising security—provision the device with credentials and details for access to the wireless network and/or gateway via which it will access the Internet.

Having the device identity and root of trust securely embedded in the hardware means that attackers cannot get at it and the user need not even be aware of it. The user need only follow a simple set of instructions to set up the device. One way this can be done by providing a separate user-friendly interface through a different wireless link such as Bluetooth Smart or Wi-Fi.

The user can then follow the instructions using a smartphone app, for example, to provision the device and link it to the appropriate cloud server and account. IoT implementations are a valuable tool in many applications for improving product features and capabilities. They often serve very specialized functions in support of larger cloud-based applications and are in turn dependent on those applications. This requires such devices to connect beyond their local network and on up to the cloud, and as a result, securing that connection is vital.

Thus, in addition to security for their local protocols, rigorous security is required for their connection to the greater Internet and their applications through the use of well-designed protocols that ensure end-to-end security. Only the strict establishment of connected secure elements from hardware-based root of trust through secure wireless protocols communicating with a compact and secure IP stack can assure security from the smallest distributed devices up to vital enterprise applications running in the cloud.