Secure Boot in Embedded Systems: The Foundation of Device Security

Timestamps:

• 2:46 – 3:21 | Introduction to the Speaker
• 3:22 – 4:25 | Overview of the Webinar Content
• 4:26 – 5:00 | Importance of Security in Embedded Systems
• 5:01 – 5:15 | Role of Secure Boot in Device Security
• 5:16 – 5:38 | How Secure Boot Works
• 5:39 – 6:26 | Extending the Root of Trust
• 6:27 – 6:38 | Establishing the Root of Trust with RSA
• 6:39 – 6:57 | Understanding Authentication and Integrity
• 6:58 – 7:11 | Example of RSA in Secure Boot
• 7:12 – 8:55 | How RSA Provides Authentication and Integrity
• 8:56 – 9:21 | Symmetric vs. Asymmetric Keys in Encryption
• 9:22 – 9:34 | Secure Key Storage in Secure Boot
• 9:35 – 11:32 | Methods of Secure Key Storage
• 11:33 – 11:57 | Key Revocation Process
• 11:58 – 12:38 | Securing AES Keys
• 12:39 – 14:47 | Examples of Secure Key Storage Mechanisms
• 14:48 – 18:00 | Case Study: STM32MP and i.MX8 Key Storage
• 18:01 – 19:46 | Implementing Secure Boot in Manufacturing and Device Boot
• 18:02 – 26:02 | Demonstrating the Importance of Secure Boot
• 26:03 – 26:31 | Demonstrating RSA Authentication
• 26:32 – 27:00 | Conclusion and Future Webinars

****

0:00 – 0:45 | Introduction

Welcome to today’s webinar on “Secure Boot in Embedded Systems: The Foundation of Device Security.” We’re excited to explore the essentials of Secure Boot and its role in protecting embedded systems from unauthorized access and tampering. Whether you’re an experienced engineer or new to the field, this session will provide best practices to help you enhance the security of your devices.

Before we begin, let’s go over some quick housekeeping items to ensure a smooth experience. We will have a Q&A session at the end of the presentation, so please submit your questions at any time during the webinar using the Q&A button on your control panel. If you encounter any technical issues or need assistance, just send a message through the chat, and our webinar admin team will be ready to help.

0:46 – 1:35 | About Fidus Systems

So, who is Fidus? Founded in 2001, Fidus Systems has grown into a nearly 200-person, all-North-American electronic system development and design services company. We serve various industries and markets with three locations across North America: Canada and Silicon Valley. We’ve been working with embedded systems and FPGAs since 2002, and it’s safe to say that 80% of our projects have included FPGA content. We’re most proud of our 95% customer return rate, a true testament to the quality and efficiency of our work in improving our customers’ time to market. We have a very strong partner ecosystem, being a gold partner with Altera and having extensive experience with other chip manufacturers like Lattice and NXP, to name a few.

1:36 – 2:18 | Fidus’ Partnerships and Expertise

Most recently, we were announced as Partner of the Year by AMD. In our first decade, Fidus did a ton of AMD/Xilinx-related work, and in 2011, they asked us to become their first-ever premier design services member in North America. To this day, we’ve been collaborating on opportunities, training together on the latest technologies such as Versal and their latest embedded Plus architectural series—all with the goal of helping our customers get their solutions to market as quickly and smoothly as possible. We also boast the largest team of AMD-certified engineers and professionals in North America.

2:19 – 2:45 | Comprehensive Service Offering

As a full-service electronic systems design firm, our engineers and professionals cover multiple service disciplines, including FPGA design, embedded software, hardware, signal and power integrity, ASIC RTL design, and verification. We help our customers by supplying these expert skill sets directly or by managing complete projects from start to finish.

2:46 – 3:21 | Introduction to the Speaker

And now, I’m pleased to introduce our speaker today, Dawson Thoreau—an experienced embedded software designer who has implemented Secure Boot in embedded Linux systems, specializing in BSP and low-level application development. Dawson has worked extensively with tools like PetaLinux and Yocto. His expertise spans both low-level kernel drivers and high-level applications, making his insights into Secure Boot particularly valuable for today’s discussion. Please join me in welcoming Dawson. Over to you.

3:22 – 4:25 | Overview of the Webinar Content

Thanks, Alecia. Hi, everyone. I’m Dawson Thoreau, an embedded software designer here at Fidus Systems. This webinar will explore the principles and implementation of Secure Boot in embedded systems, highlighting its pivotal role as the software root of trust. Throughout the presentation, we will cover security in embedded systems, including the risks posed by physical access to hardware, the role that the root of trust plays in the overall context of security, an introduction to RSA and AES—the algorithms used to authenticate and encrypt components in Secure Boot, methods used to securely store keys for RSA and AES in Secure Boot, and finally, we will outline the steps required to implement Secure Boot in the manufacturing, build, and device boot process. We’ll also demonstrate the importance of Secure Boot functions by simulating attacks on systems with different levels of Secure Boot implementations.

4:26 – 5:00 | Importance of Security in Embedded Systems

In a world with bad actors, embedded systems are vulnerable targets since hardware is physically accessible. Key security goals for embedded systems include preventing the device from running software that is not created by the original equipment manufacturer (OEM), ensuring that software loaded on the device has not been modified by a third party, and protecting intellectual property and customer data on the device. In some cases, protecting customer data is required by law, for example, through GDPR in the EU and HIPAA in the US.

5:01 – 5:15 | Role of Secure Boot in Device Security

So, how is this achieved? By implementing a Secure Boot process that employs authentication to ensure that software was created by the OEM and encryption to ensure that customer data is protected at rest.

5:16 – 5:38 | How Secure Boot Works

Let’s walk through the boot process of a device running embedded Linux with Secure Boot enabled. When the device is powered on, Secure Boot is executed to perform authentication and integrity checks on the boot firmware. Since Secure Boot is the first secure component executed by the system, it is known as the root of trust. Through strategic authentication of subsequent boot components, the root of trust can be extended beyond Secure Boot.

5:39 – 6:26 | Extending the Root of Trust

For example, the second-stage bootloader, loaded by Secure Boot and executed, can authenticate and decrypt the Linux kernel. When the Linux kernel starts, it can provide authentication and integrity checks through kernel components such as dm-crypt and dm-verity. As a result, when a pivot root occurs, the root of trust extends into the Linux user space.

Without Secure Boot enabled, the system root of trust does not exist. Although Linux can be vulnerable to exploits in user space, the device becomes even more vulnerable to exploits performed during the boot process. Boot process vulnerabilities can give third parties access to the entire system by modifying the boot firmware or injecting code to undermine system integrity and disable or bypass crucial security features.

6:27 – 6:38 | Establishing the Root of Trust with RSA

How does Secure Boot establish the root of trust? Through a mechanism called RSA. RSA is an algorithm that performs authentication and integrity checks on data using digital signatures.

6:39 – 6:57 | Understanding Authentication and Integrity

But what are authentication and integrity? In the context of Secure Boot, authentication guarantees that the software booted during the secure boot process was generated by a specific entity, such as the OEM. Integrity guarantees that the software has not been modified since its creation.

6:58 – 7:11 | Example of RSA in Secure Boot

For example, say I created a bootloader for a system that uses RSA. RSA could prove that I was the one who created the software and that no one has modified it since its creation.

7:12 – 8:55 | How RSA Provides Authentication and Integrity

How does RSA provide this authentication and integrity check? Through digital signatures. Digital signatures are unique fingerprints generated by providing data to authenticate and a special key to the RSA algorithm. One important note about RSA in the context of Secure Boot is its use of asymmetric keys. Asymmetric keys mean that different keys are used to create the digital signature and authenticate it. Keys are generated as private and public key pairs. The private key and the data are given to the RSA algorithm to generate the digital signature. As the name suggests, private keys should never be shared to avoid impersonation.

The public key is then used to authenticate the digital signature and prove that the corresponding private key was used to create it. In Secure Boot, when an RSA key pair is generated, the private key is usually stored on a build or packaging server to create a digital signature of the boot firmware. The public key is then given to the device so that it can be used in the Secure Boot process to authenticate the digital signature created by the private key. If the boot firmware contains secrets or intellectual property, Secure Boot can leverage the AES algorithm to encrypt sensitive data located in the boot firmware.

Encryption is the process of scrambling data—in this case, using the AES algorithm—so that it can no longer be read without knowledge of a secret component. The secret component, in this case, is a symmetric key used to encrypt and decrypt data. Unlike RSA, AES leverages symmetric keys to increase the algorithm’s speed on large amounts of data.

8:56 – 9:21 | Symmetric vs. Asymmetric Keys in Encryption

Asymmetric keys mean that AES uses the same key to encrypt and decrypt the data. Since only one key is used for both encryption and decryption, if a third party gains access to the secret key, they can easily decrypt the data. This is why most Secure Boot implementations enable secure storage mechanisms for AES and RSA keys used in Secure Boot.

9:22 – 9:34 | Secure Key Storage in Secure Boot

Storing keys used for Secure Boot securely is crucial to ensuring a secure root of trust. Without secure storage for keys, the authentication and encryption performed by Secure Boot would be pointless.

9:35 – 11:32 | Methods of Secure Key Storage

Let’s explore the methods used by popular manufacturers to store RSA and AES keys in Secure Boot systems. Before discussing the general strategy for storing public keys in Secure Boot, let’s consider what kind of access an adversary may want to the public keys to exploit the system.

First, remember that RSA uses asymmetric keys. The device only needs to know the public key to validate the signature, so there’s no reason to store the private key on the device. Since the public key is not a secret, there’s also no reason to encrypt it. An adversary would likely want to change the public key to one of their own. This way, they could generate their own public and private key pair, generate a signature for their custom boot firmware, and then program the device with the boot firmware and their public key so that Secure Boot executes without a hitch.

It appears that we have just stumbled upon our main requirement for public key storage: public keys should be unchangeable after they are programmed to prevent them from being altered by a bad actor. As a countermeasure, manufacturers such as AMD and NXP use one-time programmable (OTP) eFuses to store public keys, similar to fuses in electrical circuits. Once these OTP eFuses are programmed, they can no longer be reprogrammed, making the Secure Boot RSA public key unchangeable. These public key eFuses are typically programmed during manufacturing to ensure the keys programmed in the fuses can be trusted.

Some of you may wonder what happens if there is a data breach or if I accidentally delete my RSA private key and can no longer create firmware for the public key on the device. Manufacturers typically mitigate this issue by including multiple OTP eFuses to store RSA public keys.

11:33 – 11:57 | Key Revocation Process

This process is called key revocation. In addition to OTP eFuses to store public keys, a second set of eFuses are used to indicate that keys are revoked and should no longer be considered valid. Device manufacturers implement varying numbers of public key eFuses. For example, AMD Zynq UltraScale+ MPSoC devices have two OTP eFuses for public keys, while i.MX8 devices have four, and STM32MP devices have eight.

11:58 – 12:38 | Securing AES Keys

For symmetric AES keys, the main vulnerability is unauthorized access to the key. Any entity that gains access to the key will have the capability to decrypt the boot firmware and potentially access sensitive data. Therefore, obfuscation or encryption is the most important factor when storing symmetric encryption keys on devices that use Secure Boot. Typically, there is a mechanism that, when provided with an encryption key, will encrypt it to be stored at rest, only to be retrieved by Secure Boot later.

12:39 – 14:47 | Examples of Secure Key Storage Mechanisms

For example, in this diagram, the encryption key is provided to the embedded system and stored in a secure storage mechanism, which encrypts the key at rest with a device-specific encryption key. Then, when Secure Boot executes, the key is retrieved from the secure storage mechanism, decrypted, and provided back to Secure Boot for decryption purposes.

In addition to the secure method for storing keys, some platforms, such as MPSoC, allow less secure AES key storage mechanisms. These mechanisms are typically used in less mission-critical applications or for development purposes to test the Secure Boot encryption workflow.

Unlike RSA, where platforms use similar methods for storing RSA keys, AES key storage can differ from platform to platform. For example, Zynq UltraScale+ devices offer three levels of security:

• Black Keys: The most secure, using a PUF (Physically Unclonable Function) as a secure storage mechanism. The PUF uses variations in the silicon to act as a key encryption key. The encrypted AES key can then be stored in non-volatile memory. The PUF is only accessible to the cryptographic engine to perform decryption using that encrypted key.
• Grey Keys: The second most secure type of key, which are technically only obfuscated. They encrypt the AES secure boot key using a family key. The family key is not unique per device but is instead unique per device family, meaning all devices in the same family use the same key to encrypt the Secure Boot AES key.
• Red Keys: The least secure method of storing Secure Boot AES keys. They are the plain text version of the key, typically stored in battery-backed RAM (BBRAM) or eFuses, making them immutable. Red keys are typically used during the development process to test the Secure Boot encryption mechanism.

14:48 – 18:00 | Case Study: STM32MP and i.MX8 Key Storage

For STM32MP devices, they use a device called the BSEC (Boot Secure Control). The BSEC, when provided with an AES key, derives unique information for that key and programs it into OTP eFuses. Secure Boot then uses this information, along with the boot loader information, to derive an AES key used to decrypt the boot firmware. Since the BSEC stores the unique information in OTP eFuses, the AES key cannot be changed after it has been programmed.

For i.MX8 devices, the Cryptographic Acceleration and Assurance Module (CAAM) is used. Like the PUF in MPSoC devices, this module encrypts the key with a device-unique key to be used for Secure Boot. Before choosing an i.MX8-based processor, it’s important to note that the device must include a CAAM module to decrypt the boot firmware during Secure Boot.

18:01 – 19:46 | Implementing Secure Boot in Manufacturing and Device Boot

With the knowledge of Secure Boot mechanisms (RSA and AES) and the methods used to securely store secrets, we can now go over where keys are generated and where they are used in the manufacturing, firmware packaging, and device boot processes. Prior to device manufacturing, typically all keys that will be used throughout the device’s life cycle are generated. This includes the symmetric AES key, which is given to the build server and programmed into the device’s secure AES key storage mechanism, as well as the asymmetric RSA key pair, where the private key is given to the build server and the public key is programmed into the device’s OTP eFuses.

When it’s time to generate the boot firmware, the build server encrypts the boot firmware using AES encryption and the symmetric key stored on the server. This encrypted boot firmware is then signed using RSA and the public key, generating signed and encrypted boot firmware, which can be programmed onto the device’s persistent memory. When the device is powered on, Secure Boot starts executing, reads the signed and encrypted boot firmware from persistent memory, and performs an authentication check using RSA and the public key stored in the OTP eFuses. If the authentication fails, the boot process is aborted. For devices that support multi-boot, such as MPSoC, it is possible to attempt to boot from the next multi-boot offset if the first image is invalid.

If the firmware authentication using RSA is successful, the encrypted boot firmware can be decrypted using AES and the symmetric key stored in the secure key storage mechanism, generating the plain-text version of the boot firmware. Secure Boot then hands off execution to the boot firmware.

18:02 – 26:02 | Demonstrating the Importance of Secure Boot

Finally, let’s demonstrate the importance of Secure Boot by generating three images:

1. An image using Secure Boot with encryption and authentication.
2. An image with authenticated Secure Boot only.
3. A non-Secure Boot image.

Inside the boot images, we will include a secret file and modify the boot firmware to show the authentication and integrity checks of the boot process.

First, let’s go over the three boot firmware images generated for this demonstration. These three boot firmware images were generated using the Bootgen utility for the Zynq UltraScale+ MPSoC device. The first boot.bin generated is an encrypted and signed boot.bin image that utilizes Secure Boot. The second is a signed-only Secure Boot image, meaning there’s no encryption. The last one is an unsecure boot.bin that does not employ any Secure Boot implementation. In addition to the regular firmware included inside these boot.bin files—like the first-stage bootloader and the U-Boot executable—I also included a file called secretfile.txt, which contains proprietary information. The contents of this file are “super-secret data 42.”

Now, let’s see if we can find this data inside these boot firmware images. In this example, we’re acting as a bad actor who has somehow gained access to the device and dumped the boot firmware from non-volatile storage.

First, let’s attempt to find the super-secret data inside the unsecure image. Using the XXD command, which dumps the contents of binary files, including the ASCII representation, and grep to search the output for the string “secret,” we’re able to find the plain-text version of our super-secret data. This means that anyone who has dumped the firmware now has access to our proprietary information.

Next, let’s try the same thing on the encrypted boot firmware. As you can see, nothing is output when we search for the string “secret” in the encrypted boot firmware. If we go to the same offset inside the encrypted boot firmware that usually contains the proprietary information in the unsecure boot firmware, we can see that there is only encrypted data in its place, meaning that we cannot read the original plaintext secret data from the file. The only way to revert this encrypted data back to the original proprietary information is by using AES and the symmetric key known only to Secure Boot on the device, as well as the build server. This demonstrates the importance of encryption for protecting proprietary information located inside the boot firmware.

Now, let’s take a look at why authentication and integrity checks are so important for the system, implemented through RSA and Secure Boot.

Here, I have a system booted using an unsecure version of the boot firmware—no RSA encryption or RSA authentication check. When the system begins booting, the first thing it prints is the “Xilinx Zynq MP First Stage Bootloader.” This is printed by the first-stage bootloader itself, contained in the boot.bin of the booted system. Let’s attempt to modify this string printed by the first-stage bootloader by changing the data contained inside the boot.bin.

First, let’s log into the system and navigate to the boot directory. PetaLinux automatically mounts the boot firmware location to the /boot directory. In this case, boot.bin is the boot firmware booted by the boot process. I’ve put together a script that will allow me to modify the boot.bin at a given offset with the value of my choosing.

26:03 – 26:31 | Demonstrating RSA Authentication

Let’s find the offset of the string that prints “Zynq MP First Stage Bootloader.” We can see that the string “Zynq MP First Stage Bootloader” is located at offset 123D0. I can use my script to modify the boot.bin with the value “Dawson was here” at this location. Now, if I search for my name instead of “Zynq MP,” we can see that “Dawson was here” is now the content at that offset.

Let’s reset the system and see how this affects the boot process. As expected, “Dawson was here” is now printed as part of the first-stage bootloader. This means that we successfully modified the data contained in the first-stage bootloader, and the system still booted as expected. This is because no Secure Boot authentication is enabled in this boot firmware.

Now, let’s log in and attempt to do the same thing with the authentication-enabled Secure Boot image. I have my authentication-enabled Secure Boot image located here. Let’s change the original boot.bin to the signed boot.bin again. If we look inside the boot.bin for the first-stage bootloader string, you’ll see that it’s changed back to its original value. Let’s modify it again to be my hacked value.

Now, if I reprint the contents of the boot.bin, we will see that it’s modified again to be my value, as we can see here. Let’s reset the system and see how this affects the boot process. I will click the power-on reset button of the device, and as you can see, nothing appears in the terminal. This is because the firmware attempted to be booted is secured, meaning that Secure Boot first performs an RSA authentication check on the first-stage bootloader. In this process, it detects that I have made a change to the bootloader without updating the digital signature.

Secure Boot then halts the boot process since it has detected an unauthorized change. This effectively blocks anyone from changing the boot firmware without access to the private key, which is only accessible on the build server. This ensures that the system will only run firmware generated by a trusted entity.

26:32 – 27:00 | Conclusion and Future Webinars

Although Secure Boot is a key component of system security, it is not the only component. In future webinars, we will cover other important elements of security in embedded systems, including extending the root of trust beyond Secure Boot using Trusted Platform Modules (TPMs) to hold secrets used later in the boot process, as well as secure firmware upgrades. With that, I would like to thank you all for your time, and I’ll hand the presentation back to Alecia.