Electronic systems play an essential role in our lives. Whether communicating via a smart phone or driving a car equipped with Advanced Driver Assistance Systems (ADAS), we rely on electronics to simplify, and even perform, our day-to-day tasks. These systems are prone to being hacked, and the fact that they are connected amplifies the threat. As trusted intelligence takes on critical activities, (e.g., personal medical monitoring), the consequences of cyberattack and sabotage grow to include bodily injury or even death. In this new reality, building electronic systems that are secure against such attacks is an imperative.

Secure booting is the foundation of building secure electronic systems. As process geometries for microcontrollers continue to shrink, on-board embedded Flash is gradually being replaced by external NOR Flash. This architectural evolution creates a larger attack surface via the exposed bus interface, cloning possibilities, and so on. One approach to address this increasing vulnerability is to design with Secure NOR Flash to secure storage and to help the MCU establish a secure chain of trust while booting.

Secure Boot – The Foundation of a Secure System

Every electronic system boots up when power is applied. For embedded systems, this is typically implemented by running boot code stored in a non-volatile storage. To enable secure booting, the system needs to establish a root-of-trust, boot from the original hardware storage, and boot using the original trusted boot code (see Figure 1).

1. Establish Root-of-Trust

When an MCU starts to boot, it must run from a trusted location. This is typically realized by a small internal ROM, or trusted embedded flash. This code must be immutable so that the system can trust it intrinsically. It serves as the base of the root-of-trust hierarchy. From here the system can extend the trust to the external storage by authenticating the hardware and validating the storage contents.

1. Asymmetric Key Algorithm.

To establish the root-of-trust, the ROM code often relies on a pre-stored key. If an asymmetric key algorithm is used, this key is often a public key. The MCU uses this public key to validate the signature of the second stage bootloader, which resides on an external flash device. The signature, stored with the actual bootloader, is a digest value of the bootloader and signed with the private key that is cryptographically paired with the public key. If the MCU successfully validates the bootloader signature using the public key and calculates the same digest value from the current bootloader, it can be sure the bootloader code has not been changed. In this way, the root-of-trust is established. This validated second-stage bootloader can now be securely executed.

2. Symmetric Key Algorithm

Typically, a symmetric key algorithm will execute slower than a symmetric algorithm. For this reason, in applications where boot time is critical, users often chose a symmetric key algorithm. With a symmetric key, the host MCU and external flash share the same secret key. This shared secret can be established ahead of time in a secure environment before field deployment (i.e., during manufacturing). Subsequently, the shared secret can be used to validate the second-stage bootloader quickly by using a key-based hash on the software.

Figure 1: Building the Root-of-Trust

2. Boot from the original hardware storage

Booting from the original hardware storage may not be a major concern if the entire boot code is stored on embedded flash inside the MCU. This is because it may be impossible to swap out the embedded flash without damaging the MCU host. However, as the industry is moving towards 22-nm MCUs, it is becoming more difficult to have embedded flash inside an MCU. Technology beyond 28nm may be forced to store the boot code in an external flash. Therefore, to boot securely, the host must consider if the external flash has been replaced.

To prevent hackers from cloning the hardware with the original memory contents, the host MCU can perform a pairing process with the boot storage device during manufacturing. After that, only this paired storage device can provide the boot code for booting. Therefore, a secure hardware identifier must be used on the device to provide such pairing capability. The identifier can be a very strong device ID that cannot be tampered with or cloneable. Therefore, the authentication process after the pairing can be based on such identifier.

3. Boot using the original, trusted boot code

After identifying the original hardware storage, the next step is to validate the boot code to ensure it has not been tampered with or modified. There are multiple ways to do this, each requiring different processing capabilities and offering corresponding levels of security.

1. Simple Protection

As with most traditional NOR flash, users can enable block or sector-based protection on the memory range where the boot code resides. Such protection prevents accidental writes too and erases from the protected region. There are no secure elements in simple protection, so this protect is weak against intentional attacks that alter the code. Hackers can easily issue commands to unprotect the region and modify the boot code. Even if the protection scheme includes a password, it can be hacked by sophisticated attacks since the password is static in nature.

2. Checksum Validation

If a checksum has been calculated from the original boot code, it can be used in subsequent boot-ups to validate that the code has not been modified. This process must be done by the host; therefore, it requires that the host read the entire boot code from the boot device and calculate the checksum before it can start running with it. Note that the host cannot rely on the memory device to provide the checksum value because this could be modified during an attack.

3. Using Encryption to Store Boot Code

The encrypted boot code can be stored on the NOR flash with a secret key. There could be hardware inside the MCU to decrypt the data transparently while booting. As the boot code plain text is not exposed on the bus, eavesdropping is not possible. This method is secure as long as the secret key used for encryption is not compromised. However, if the encryption key is compromised, the content of the boot code on external flash must be re-flashed. This process can be tedious or even impossible to implement on devices already in the field.

4. Flash Device Assisted Validation

Instead of the MCU reading the entire boot loader to RAM for validation, the validation task can be offloaded to the NOR flash if the device provides such functionality. In a boot-time sensitive system, offloading the validation task can help the MCU to start executing the bootloader sooner. A watchdog timer can be used to reset the system in case of a failed validation. With this method, the MCU can start handling some urgent tasks while the flash device is validating the code. Of course, only non-secure functions can be run before the validation is completed. That means the host must implement a secure interrupt handler that can get the validation result from the NOR flash via an interrupt event.

 

Secure NOR Flash

Traditional NOR flash is capable of providing simple data protection, with or without a password. This makes it difficult to implement secure boot functionality using traditional NOR flash. Next-generation Secure NOR flash available from companies like Cypress integrates security functionality to enable more stronger levels secure boot.

1.  Device Identification Composite Engine (DICE)

DICE, specified by Trusted Computing Group (TCG), provides a method for deriving a strong and secure device ID based on a unique device secret for each device. With DICE on the device that stores the boot code, the system can establish a root-of-trust foundation when booting.

DICE builds upon a Unique Device Secret (UDS). The UDS is a truly random number on each of the devices without any association. The UDS is generated at the customer’s facility and stored in a secret location on the device where, once written, the UDS cannot be read. The device identity, provided by certificates, is derived from the UDS. Therefore, once an MCU is paired up with a particular flash device, it is impossible to clone a device containing the same UDS.

2. Secure Storage Regions

Secure NOR flash can be configured to have multiple independent secure regions within the device. Regions with different access levels can be used to store firmware or software that may require different security levels. Individual regions can also be configured as non-secure storage for general data. As the security level increases, the read throughput from the device decreases due to cryptographic measures. By providing various access levels, the user can decide the trade-off between performance and security for each part of the system.

If the firmware bootloader is stored in a region that is configured to require authentication, the user can be sure that the firmware has not been modified by any unauthorized parties. If the firmware consists of sensitive data that the user does not want to be exposed on the SPI bus, it can be stored in an encryption-required region so that only encrypted data will be transferred onto the bus.

3. Fast Secure Boot

Some applications, such as automotive systems, need to boot up securely in a timely fashion. In modern complex systems, boot code or application software can be so large that the MCU would require significant time to read and validate the software in its entirety. In such cases, Secure NOR flash can offload the MCU during booting to validate software stored on the device. This is achieved by storing shared secret information between the MCU and the device ahead of time. During the boot process, this shared secret can be validated quickly to ensure the originality of the device and the stored software. The device can also authenticate the software application code while the MCU starts handling some basic tasks. Therefore, the entire boot time can be shortened to satisfy the stringent requirements of automotive applications.

Modern electronic systems in automotive, industrial, and communications require highly secure flash memory storage. Designers face the challenge of building safe and secure systems that are resilient to cyber-attacks. Secure memory, such as Cypress serial and parallel NOR flash, implements security functions that enable external storage to support a fast and secure boot.

Zhi Feng is Senior Principal Applications Engineer in Cypress’ Flash group. He completed his Bachelor degree in EE from South China University of Technology, and his Master of Applied Science degree from University of Ottawa in Canada. He has been with Cypress for 15 years, working in the NOR and NAND memory fields.