Enhancing the Security of the Internet of Things

The Internet has grown beyond a network of laptops, PCs, and large servers: it also connects millions of small embedded devices. This new trend is called the Internet of Things, or IoT in short, and it enables many new and exciting applications. At the same time, IoT also comes with a number of risks related to information security. The lack of security, however, cannot be tolerated in certain applications of IoT, including connected vehicles and smart factories. In those applications, security failures may lead to substantial physical damage or monetary loss. Therefore, one of the biggest challenges today, which hinders the application of IoT technologies in certain application areas, is the lack of security guarantees.

In the CrySyS Lab, one of our main research topic is the design and development of security enhancing technologies for IoT systems. We believe this will enable the use of IoT in a wider range of applications. However, securing IoT systems is challenging, because IoT devices have resource constraints and they may not be capable of running traditional security mechanisms. Another problem is that typical IoT systems contain a large number of those devices, which makes the management of security on them a serious practical issue. On the other hand, in typical application environments, IoT devices are not directly connected to the Internet, but they are using gateway devices. Gateways usually have more resources and they may be physically better protected, so they can perform security functions to protect themselves and they can monitor the operation of those simpler IoT devices that they serve. Therefore, placing IoT devices behind gateways and protecting the gateways from cyber attacks seems to be a technically feasible, scalable, and cost efficient approach to increase the security of IoT systems.

Gateways directly face the Internet and they may be subject to various attacks, so it is important to implement strong security mechanisms on them. The following is a list of mechanisms that we believe to be essential for securing the operation of IoT gateway devices:

• Hardware root of trust: While gateways can be physically better protected than IoT devices themselves, they are still not strongly tamper resistant, as providing real tamper resistance for the entire device would be too expensive. This means that attackers with physical access to the gateway can compomise it. Therefore, it is important that the gateway has at least some tamper resistant module inside that can withstand physical attacks and that can serve as a root of trust for other security functions listed below. Such a tamper resistant module can be used to store sensitive cyrptographic secrets (e.g., the private key used to authenticate the device) to which access is strictly controlled.
• Verified boot process: It must be ensured that after a reset, the gateway boots into a secure state. This can be achieved by digitally signing the software layers loaded during the boot process, and enforcing each layer to verify the digital signature on the next layer before it is loaded and executed. If verification fails, the boot process is halted. The public signature verification keys needed for this can be stored inside the software layers themsleves, as the signature on a software layer also protects the integrity of the key stored in it. The very first bootloader component must be stored in and executed from unmodifiable ROM memory and it must use a public signature verification key that is stored in physically write-protected memory (e.g., a one-time programmable memory where to key is written during device initialization in a secure environment) or whose protection can be traced backed to the hardware root of trust. All these mechanisms ensure that the code loaded and executed after reset cannot be modified on the gateway, not even if the gateway is compromised at run-time and executes malicious code.
• Security hardened firmware/OS: The firmware/OS running on the device must be hardened by disabling unused services and enabling available protection mechanisms that are optional and not used by default. Hardening reduces the attack surface and makes the gateway more resistant to typical known attacks.
• Trusted execution environment: It is desirable to execute sensitive security functions in a trusted execution environment (TEE), which we can better trust for behaving correctly and protecting sensitive secrets (e.g., shared symmetric keys and private signature generating keys) during computations than does the main firmware/OS itself. Such a TEE could be provided by a security co-processor to which sensitive operations can be delegated, but this approach may be too expensive in practice. A more cost efficient solution is a software based TEE with some hardware support such as ARM’s TrustZone technology.
• Run-time firmware/OS integrity monitoring: While the verified boot process ensures that the gateway boots into a known good state after reset, it does not prevent compromising the device at run-time by exploiting some software vulnerability. This may happen despite firmware/OS hardening, because hardening is just a best-effort approach, and it cannot eliminate the entire attack surface. Hence, it is useful to periodically check the integrity of the firmware/OS and identify malicious components, suspicious network connections, or any other anomaly that may indicate a run-time compromise. However, this integrity verification should not be performed by the firmware/OS itself, as it may be already compromised and the result of the check may not be reliable. Instead, integrity verification must be performed by a trusted application running in the TEE and having access to the entire memory of the firmware/OS. Yet, integrity verification itself is far from trivial, even if it executes in a trusted execution environment. The integrity verification code may extract the list of the currently running processes and compare that to a whitelist, or it can even check if the processes in memory have the right hash values and they did not contain any potentially malicious additional code. If a compromise is detected, the gateway can be forced to reboot and get back to a known good state.
• Remote attestation of state: Run-time integrity checking can be triggered by an on-board secure timer (or watchdog mechanism), or it can be invoked remotely by an operator. In the latter case, it may make sense to send a response to the caller informing him/her about the result of the integrity verification procedure. In order to avoid that a compromised device can falsify the response, it should be digitally signed. So essentially, the trusted integrity verification application running in the TEE can send a digitally singed attestation report that can be verified by anyone. The private signature generation key must be protected by the TEE and secure storage mechanisms traceable back to the hardware root of trust.
• Secure and fail-safe remote firmware/OS update: The immediate response to a run-time compromise could be rebooting the gateway, however, in the long run, the vulnerability that made the compromise possible should also be eliminated and a security patch or the entire fixed firmware/OS should be downloaded to and installed on the gateway. This requires a secured firmware/OS update process, which is also fail-safe, meaning that if something goes wrong and the new firmware/OS does not work correctly, there must be a way to revert to the old version, at least temporarily. In addition, the revert feature should not introduce the possibility of forcing the gateway to boot an old, potentially vulnerable version of the firmware/OS, when actually a newer version is available and functions correctly.

Besides the essential security features described above, the following mechanisms could also be useful:

• Disk encryption: In order to protect the data permanently stored on the gateway device, its persistant memory can be encrypted with standard disk encryption tools. The key or passphrase needed to decrypt the that memory content can be supplied by a trusted application running in the TEE, which also takes care of the secure storage of the key/passphrase using mechanisms that are traceable back to the hardware root of trust.
• Secure communications/remote access: The gateway should be able to communicate securely with its operator. This is needed not only for data transmission but also for providing secure remote access to the device for configuration and management purposes. Secure communications can be implemented with cryptographic mechanisms. However, long-term secret passwords or private keys needed for authenticating the gateway to the operator when setting up a secure communication session should not appear in memory accessible to the potentially compromised firmware/OS. This means that those secrets must be stored in secure storage and the cryptographic operations that use them should be implemented by trusted applications executed in the TEE.

In the spring semester of 2018, in a set of student semester projects, we created proof-of-concept (PoC) implemenations for some of the essential security features (verified boot, OS hardening, run-time integrity verification) described above. We used a Raspberry Pi embedded computer as the IoT gateway platform in our pilots. This ARM based platform supports TrustZone technology and the OP-TEE trusted execution environment, which our implementations heavily rely on. At the same time, unfortunately, the Raspberry Pi does not have a hardware root of trust, so our PoC implementations are incomplete in this sense. Yet, creating these PoC implementations was still very useful as a learning process for us. Our plan is to port these implementations to other, more secure embedded platforms that also feature some hardware root of tust element.

While working on the PoC implementations, we realized that for many of the issues that we encountered during development, there is no easily usable documention available on the Web. Information can be found here and there on different forums and github repositories, but not in a single place and not in a comprehensive, easy-to-understand form. So we decided to share our know-how and experience by publishing a series of blog posts that one could follow in a step-by-step manner to repeat what we did. More specifically, our blog posts cover the following topics:

• OP-TEE default build and installation on the Raspberry Pi
• Using Buildroot to create custom Linux system images
• Verified boot on the Raspberry Pi
• OS hardening on the Raspberry Pi
• Enabling WiFi and converting the Raspberry Pi into a WiFi AP
• Kernel integrity monitoring on the Raspberry Pi

We hope these blog posts will be helpful to the community working on IoT security and, in particular, to those using the Raspberry Pi and aiming at making it a bit more secure than the baseline platform that one gets by default.