Securing the IoT from the network layer to the application layer
Wouter van der Beek
Security in the Internet of Things (IoT) has become a critical requirement, with recent legislation mandating ‘reasonable security features.’ It is very clear that the cost of implementing security within the IoT is necessary, and far outweighs the cost of not doing so.
Security is built up in layers; the first layer needing to be secured is the hardware layer, the second is the network layer. In this article, the network layer referenced is the Thread network layer: a low-cost, low-energy, meshed IoT network.
However, the network is a mix of wireless and wired IP technologies, so there is also a need for application level security. This comes from the OCF application layer; a secure domain where all devices and clients can securely talk to each other, say, Wouter van der Beek, senior IoT architect, Cisco Systems and Technical Working Group chair, Open Connectivity Foundation and Bruno Johnson, CEO of Cascoda, a member of the Open Connectivity Foundation.
Hardware security
The constrained microcontroller requires features to protect it from malicious code and hardware-based snooping that would compromise security. Secure hardware protects the boot sequence of the microcontroller by validating its signature and protects memory and peripheral access to isolate critical parts of the code. This only allows access through a well-defined and trusted application programming interface (API). These features minimise the attack surface of connected devices, providing a secure foundation for the network and application.
Network security
The network layer needs to ensure that the data sent over the air cannot be altered and that devices that join the network are legitimate. In order to secure data over the air, Thread uses a network-wide key that employs symmetric key cryptography known as AES-CCM. AES-CCM appends a tag code to each message and encrypts it using this network-wide key. If the recipient has the key, it can decipher, verify the origin, and verify that the message was not corrupted in transit. Lastly, the key is periodically changed based on the existing key and a specific sequence counter in case it becomes compromised.
However, when a new device needs to join a network, it does not know the network-wide key and therefore needs to obtain it. This process is known as commissioning. Of course, the key cannot be transmitted without encryption, as it could be intercepted by an attacker. To overcome this problem, Thread commissioning uses a process known as Password-Authenticated Key Exchange (PAKE), which is part of the Datagram Transport Layer Security standard (DTLS).
PAKE uses a low-strength secret in conjunction with asymmetric cryptography to generate a high-strength secret between the two parties. The high-strength secret is used to encrypt the communication of the key from the Thread commissioner (e.g. smartphone connected to the Thread network) to the joining device.
Application security
Bruno Johnson
To ensure end-to-end security at the application layer, OCF provides solutions to transfer ownership from manufacturer to purchaser, or from one purchaser to the next. The first step in integration is to establish ownership of the device. For this purpose, OCF issues certificates and maintains a database for each certified device. At this stage, the device is provisioned with those credentials for establishing mutually-authenticated secure connections with other devices in the IoT secure domain, thanks to OCF Public Key Infrastructure (PKI).
The provisioning instructions are then given over a secure connection, encrypted by DTLS. The process starts with ownership transfer of the device and then provisioning the device, following a set of state transitions. It should be noted that OCF takes into account that during its lifecycle, a device may change ownership. Hence, OCF requires devices to implement a hardware reset to return to their initialisation state.
In addition to this onboarding process, OCF devices can be provisioned with varying levels of security. OCF provides a layered approach: role-based access control and manufacturer usage descriptions. The former addresses device security, while the latter adds an additional layer of protection from the network.
Implementation using constrained hardware
Implementing OCF-over-Thread on constrained hardware is a challenge due to the very limited code space, memory, and computing power of low-cost microcontrollers. As a result, it is necessary to take advantage of code reuse. The largest code savings comes from sharing the core cryptography library and mbedTLS, common to both stacks. This is possible because OCF and Thread are both built upon DTLS.
The execution of the core cryptography primitives for DTLS requires access to dedicated hardware for acceleration, which is far more time and power-efficient than pure software. Such hardware acceleration reduces the Thread commissioning time by several orders of magnitude – a significant speed increase to the most computationally-intensive task for which the microcontroller is responsible. Hence managing access to the hardware cryptography functionality for both stacks through the mbedTLS library is critically important.
Both OCF and Thread Group run open source projects for their respective specifications. These concrete implementations eliminate ambiguity for developers and forge interoperability.
Technologies that can work together from the application to the network layer form a best-in-class secure IoT platform that can be deployed today.
The authors are Wouter van der Beek, senior IoT architect, Cisco Systems and Technical Working Group chair, Open Connectivity Foundation & Bruno Johnson, CEO of Cascoda, a member of the Open Connectivity Foundation.
Comment on this article below or via Twitter @IoTGN