Embedded devices have always been vulnerable to attack. What has changed in recent years is the ability of hackers to access those devices. The air gaps in networks that used to protect industrial controllers and similar devices have been filled in, thanks to the growth in the use of wireless networking to interconnect them. Wireless networks were introduced for increased convenience and flexibility, but they also provide an easy way for hackers to launch attacks. What is required are devices that are hardened against attacks, using a combination of techniques to support high security.
Key to security hardening is a set of fundamental building blocks that when used together, reject hacking attempts and maintain integrity. A wireless-enabled device needs to ensure that it can maintain control of its own code and data as well as support private communication with remote endpoints that can supply the necessary accreditation to be trusted.
An example of why authentication of devices is essential is the man-in-the-middle attack. This is an attack in which a hacker intercepts communications between two legitimate devices and eavesdrops on the conversation, and alters the packets they receive in order to gain access to a secret or entry to one or both of the devices. A common attack used against Wi-Fi-enabled devices is to create an access point that masquerades as a legitimate router that forwards manipulated data to the real access point and to the device itself. Using such techniques, the attacker may learn the access codes needed to perform a successful login, or they may inject false data or malware that causes a device to become faulty.
Protected conversations are therefore important, which points to the use of cryptography to make eavesdropping much more difficult for a would-be attacker. However, cryptography support greatly eases the job of creating secure devices.
At the center of each secure IoT device there needs to be a root of trust. This is a set of functions in the embedded device that can be fully trusted by the computer’s operating system and software. In today’s devices, the root of trust is guaranteed through the use of public key infrastructure (PKI) cryptography – a mechanism that makes it possible to check the authenticity of any device and the validity of its operations.
Today, PKI is critical to the successful exploitation of cryptography in a highly distributed environment. PKI is built around the creation of pairs of encryption keys that are asymmetric in use. One is a public key that can be distributed freely and be used to encrypt messages that are sent to the holder of the private key. The ability to transfer the public key without risk across public networks greatly improves the scalability of encryption-based security compared with symmetric-key systems.
Because symmetric systems use the same key for both encryption and decryption, the key must be kept secret at all times from unauthorized users. This makes it extremely difficult to deliver trusted keys to users as they must employ alternative, high trust channels to communicate in order to obtain the key.
Under PKI, only the holder of the private key can decrypt messages sent by holders of the public key. Therefore, the key must be kept secret. However, the protocols supported by PKI mean that there is never a need to send the private key to another user. All communication can be supported through the use of public keys and certificates digitally signed using the private key.
PKI transactions can be compute intensive, which can make it hard to implement in embedded systems. However, the use of dedicated coprocessors will alleviate the burden of processing the keys and encrypted data from the host processor. Such a coprocessor is found on the Texas Instruments SimpleLink CC3220 wireless microcontroller. The CC3220 solution combines a Wi-Fi transceiver, TCP/IP networking and crypto engines with a microprocessor based on the ARM® Cortex®-M4 MCU.
Figure 1: Block diagram of the CC3220.
The transport layer security (TLS) protocol used almost universally on the internet is based on PKI, guarding against eavesdropping and helping to prevent man-in-the-middle attacks. However, with a PKI core, it is possible to go beyond just message encryption and protection. The core can be used in combination with well-designed hardware features to build a root of trust for the embedded system that ensures the device can only run authorized code, and following from that, only talk to authorized devices elsewhere in the network.
The idea behind the root of trust is that only code that has been signed by a trusted party is allowed to run at boot time, and that the code cannot be changed except by that same trusted party. The crucial factor for the boot code is that it is digitally signed using PKI techniques, creating a hash value that is tied to the contents of the code itself. This signed process is typically performed by the device manufacturer who first obtains or generates a PKI-based digital certificate that is protected by the manufacturer’s private key. The digital certificate used for this process is typically derived from a root certificate that has been generated by a high-trust agency. The root certificate supports the generation of a tree of derived certificates that point to a core trusted entity – a chain of trust that is difficult for an attacker to compromise.
When loaded into the device and analyzed using the matching public key, the code signature needs to match the contents of the binary precisely. Any changes to the software will mark the hash as invalid, and the device should refuse to boot from that image. This helps prevent attacks that center on the manipulation of the stored image to insert malicious code.
The public code verification key needs to be stored in secure memory, along with the device’s own private key that it will use to generate trusted key pairs for communication with other devices. Such a facility is available on the CC3220. As well as secure storage for the code verification key and the local system’s private key, the device provides a trusted root certificate catalog that can be used to verify the authenticity of other digital signatures provided by the device manufacturer or service operator.
Code updates and other secure data that needs to be sent from a server can be verified using a similar procedure, outlined in Figure 2. First, the server generates a public/private key pair and delivers the public version to the device. This is used to generate a temporary key pair. The derived public key is transmitted to the application server. The encrypted file can be transmitted over an unsecure channel such as Wi-Fi and decrypted once on the device, where its signature can undergo a final authenticity check.
Figure 2: The process used to deliver secure content to the device.
Any unauthorized code or data updates can be rejected if the signatures do not match. Furthermore, the device is protected against attacks that involve interruption caused by a reset during the updating process. Potentially, a device with partially installed firmware could become vulnerable to attacks that take advantage of the software being in an indeterminate state when it reboots. On the CC3220, automatic rollback is triggered following a reset to ensure only fully installed and accredited firmware can run.
The CC3220 provides further tamper detection and protection features. Ideally, the root of trust uses PKI operations to extend the trusted zone out from itself to cover the other elements of the system, such as application code that is signed and checked before execution. However, there is the possibility of malicious code being introduced at the factory, or the need to run a variety of services involves the loading of untrusted code. Another scenario could be a hacker gaining physical access to the device and introducing their own code by direct manipulation of the memory bus. A security alert counter in the CC3220 tracks access violations, such as attempts to read or write files using an invalid or improper security token. When the system reaches the predefined limit of security alerts, the device is locked. To recover from the locked state, the device must be restored to its factory settings and codebase.
Figure 3: Security features of the CC3220.
The advantage of having a hardware crypto engine on a device such as the CC3220 is that the processor does not need to load potentially untrusted code to run the PKI algorithms before it can test the remainder of the boot software for provenance. The code for the cryptographic and secure functions is not only executed by a dedicated network processor that runs alongside the main Cortex-M4 core, it is stored in ROM so that it cannot be modified by an attacker – even one with physical access to the system.
Conclusion
The result is the basis for a highly secure wireless microcontroller that can deliver on the promise of the IoT as being a secure, safe but flexible environment for intelligent control. There are additional measures software developers need to take to avoid opening up security holes, but through the use of encryption and communication only with trusted parties, the probability of an attacker gaining access to the device is greatly reduced.
