Securing Internet of Things (IoT) devices is at the top of everyone’s list – or so it seems. Wherever you look there is a new story of more compromised devices that reminds everyone, once again, of the seriousness of the problem. There is also, it seems, a lot of confusion about how to properly secure such devices. Clearly, it cannot be accomplished with PC era practices. There is no antivirus (AV) software solution for IoT devices unless the device has a powerful processor and sufficient memory, which, of course, the vast majority do not. In the post-PC era, security practices must evolve as well.

Security in the post PC era must be foundational to the device and must be designed in. It needs to be done in such a way as to isolate and protect critical information, data, and code. It should also be designed and implemented with consideration given to the system in which the device will live.

But what exactly is foundational security?

Foundational security is not some abstract concept. Rather, it involves the implementation of specific technologies and processes such as a hardware root-of-trust, secure boot, hardware cryptography, the ability to authenticate other devices and applications, and trusted remediation. Of these, the secure boot process is perhaps the most critical.

Secure boot: Basics and benefits

Implementing a secure boot process is critical to device integrity throughout its lifecycle for the simple reason that a compromised boot process allows hackers to inject malware or entirely replace firmware, leaving the entirety of a connected system vulnerable. A secure boot process also makes other security features possible by providing a necessary degree of trust. Indeed, a secure boot process is critical to extending a root of trust throughout an entire system.

At its simplest, a secure boot process prevents the execution of unauthorized code at the time of device power up, and prevents the exposure of embedded boot code and software IP. A secure boot process can be accomplished in many different ways, including using digitally signed binaries, secure and trusted boot loaders, boot file encryption, and security microprocessors.

While most secure boot claims center around digitally signed boot files, unless those signatures are verifiable using some sort of an immutable root of trust, however, it is not secure. Here we do not intended to dive into the mechanics of secure boot, but rather layout the considerations that device designers must account for when implementing a secure boot process. These include:

• Protecting IP – Secure boot processes that do not protect a company’s intellectual property (code) offer no real business benefit. If properly implemented, however, software IP such as proprietary algorithms can be protected from hackers.
• Trusted remediation – The ability to safely remediate in case of device failure or compromise is a critical ability that relies on having a secure boot process that checks the validity of the firmware image being booted with a root of trust.
• Secure firmware update – Validating incoming payloads intended to replace existing firmware images is critical to maintaining device integrity throughout the system lifecycle. The source of the payload and the payload itself must be validated prior to being applied, and with a properly implemented secure boot process, failure to validate results in a safe rollback to a known verified image.
• Secure connectivity to cloud resources – A secure boot process ensures that the device is authenticated with the cloud each time it attempts a connection through the use of embedded keys and certificates.

Implementing secure boot with TrustZone and a TEE

ARM’s TrustZone technology is particularly well suited to support a secure boot process. If an application uses a device equipped with ARM TrustZone, from the recently released Cortex-M23 and -M33 microcontrollers (MCUs) through Cortex-A-class applications processors, the device contains two operating systems (OSs) – a Trusted Execution Environment (TEE), which is a secure OS that manages access to a secure enclave of the device, as well as a rich OS or rich execution environment (REE) that executes primary applications.

The TEE plays a critical role in the secure boot process in that the TEE boots after the initial ROM boot but before the REE. Indeed, the TEE can boot the REE as part of the boot sequence, and doing so allows the REE image to be verified so that remedial action can be taken, if necessary.

There are many resources available from ARM that illustrate the usefulness of TrustZone for IoT. Interest in TrustZone has steadily increased since ARM recently made the technology available to MCU-based devices through a set of extensions (more on this in the article, “Securing the edge with ARM TrustZone for v8-M”).

Secure boot: Strategy, not check box

To conclude, secure boot is essential to maintaining device integrity through the life of the device. What’s important is that device architects and application designers lay out all the security considerations prior to defining a secure boot process. Security, after all, is a strategy, not a check box.

Abhijeet Rane is Vice President of Marketing at Sequitur Labs Inc.

Sequitur Labs Inc.

www.sequiturlabs.com

@SequiturLabs

LinkedIn: www.linkedin.com/company/3567007

Facebook: www.facebook.com/sequiturlabs