5 Elements to a Secure Embedded System – Part #2 Root-of-Trust

In “5 Elements to a Secure Embedded System – Part 1 Hardware Based Isolation”, we started our discussion about the five essential elements required to beginning securing an embedded system. As you may recall, the five elements that every developer be looking to implement are:

The main focus last time was that the system needs to have hardware-based isolation to create secure and nonsecure execution environments. In today’s post, we will continue the discussion by discussing the Root-of-Trust.

Element #2 – Root-of-Trust

When we power-on an embedded system and begin the boot process, we want to ensure that our embedded system boots with legitimate software. The problem that many systems face is how to determine if the first code that runs on the device is in fact their code and legitimate. The system could be booting successfully, but what happens if some piece of malware is the first thing that runs, and the rest of the software is trusting that code? This is where a Root-of-Trust comes into play.

A Root-of-Trust is an immutable process or identity which is used as the first entity in a trust chain. No ancestor entity can provide a trustable attestation (in digest or otherwise) for the initial code and data state of the Root-of-Trust. To put this another way, a Root-of-Trust for an embedded developer is an unchangeable identity and minimal software set that is able to successfully authenticate itself and facilitate secure operations on the system.

There are several key points in the definition above that we should consider. First, an immutable process or identify is something that cannot be changed. This means that when we select a microcontroller for our product, we need to ensure that we will be able to permanently “burn-in” important information that would be used by the Root-of-Trust such as a company private key. Once in the microcontroller, we do not want this information to be changeable. Second, we want to be able to attest the system. This means that I can send the system an operation to perform which it will then use its private key to sign. With access to the public key, I can then verify the operation result and the identity of the device.

Establishing a Root-of-Trust can be a bit tricky. For example, if I take a standard microcontroller and decide that I am going to use a general fused area to establish my Root-of-Trust, I am very much relying on my manufacturer that they will not share my key information and that they will not put their own Root-of-Trust on the microcontroller! While this is probably okay in many instances, we’ve all heard the horror stories about manufacturers making extra copies of a device illegitimately or even copying the intellectual property and then building essentially cloned devices. We want our Root-of-Trust to be able to protect against activities such as this and who knows if one of their employees may have other uses or ideas for our product!   

In order to avoid these types of issues, we want to create a Root-of-Trust that is hardware based and if possible, we even want the Root-of-Trust to first be established by the microcontroller vendor that we are using. If the Root-of-Trust is established by the microcontroller vendor, the moment the microcontroller is shipped it already has an immutable Root-of-Trust that is able to attest to its identity and that it came from that manufacturer! This is particularly interesting because these solutions allow us to use an existing Root-of-Trust that is verifiable to then transfer our Root-of-Trust to the device. When we transfer the Root-of-Trust to our company, we are then able to provision the microcontroller with security policies and keys that describe how the system should behave!

Establishing that Root-of-Trust is then critical because it will burn in the security settings such as:

With these initial settings developers are then able to ensure that the first code they run on their system is secure, immutable and able to verify all the software that loads afterwards. This is absolutely critical to building a secure embedded system.

Conclusions

Establishing a Root-of-Trust is absolutely critical to an embedded system. The Root-of-Trust is used to validate all the additional pieces of software that load on the system and is the first foundational link in a Chain-of-Trust that successfully boots an embedded system. A Root-of-Trust should be hardware based and immutable. This ensures that the Root-of-Trust cannot be tampered with which then allows the system to detect if software loaded later can be trusted or not. Developers should be looking for microcontroller solutions that have a hardware-based Root-of-Trust built into them.

In the next part, we will discuss secure boot, what it is and what it means to developers.  

RELATED ARTICLES:

Jacob Beningo is an embedded software consultant who currently works with clients in more than a dozen countries to dramatically transform their businesses by improving product quality, cost and time to market. He has published more than 200 articles on embedded software development techniques, is a sought-after speaker and technical trainer, and holds three degrees which include a Masters of Engineering from the University of Michigan. Feel free to contact him at [email protected], at his website, and sign-up for his monthly Embedded Bytes Newsletter.