Hardware Root of Trust/Secure Boot Solutions

Developing secure systems is a pressing need in this era of heightened cyberattacks on computing systems. To help OEMs and component suppliers implement stronger security in these systems, the National Institutes of Standards and Technology (NIST) Special Publication 800-193: Platform Firmware Resiliency Guidelines are based on the following three principles:

• Protect: Ensure code and critical data are protected from changes, whether malicious or inadvertent
• Detect: Identify when code and critical data have been corrupted
• Recover: Provide a means to restore code and critical data to a known good state

Offering a variety of features to meet the requirements of complex and challenging computing applications, our MEC172x family of Embedded Controllers (ECs) provides hardware-based security to help you implement the NIST 800-193 guidelines in your application. Their secure boot (or root of trust) feature is executed using immutable code in the Boot ROM along with public/private key cryptography.      

This secure boot process meets the protection and detection requirements in the NIST Platform Firmware Resiliency Guidelines. All application code is authenticated using the public key before it is executed in the MEC172x device. The ECC Digital Signature Algorithm (ECDSA) is used to both authenticate the code and validate that it has not been corrupted, either by accident or maliciously. 

To meet the recovery requirements in the NIST Platform Firmware Resiliency Guidelines, two images of the MEC172x’s application code are stored in the SPI Flash (Tag0 and Tag1) to provide redundancy. At boot time, the MEC172x will first attempt to boot using Tag0. If this image has been corrupted, it will then attempt to boot using Tag1. Once the MEC172x has loaded the application code, it can then use its crypto algorithms and crypto hardware to extend the protection, detection and recovery requirements to the BIOS, Management Engine (ME) code and any other information stored in the SPI Flash.

Extending the root of trust to the system (BIOS and ME) code is accomplished by using the MEC172x’s crypto hardware to authenticate the system code with ECDSA or RSA-Digital Signature Algorithm (RSA-DSA) and validate that the system code has not been corrupted. If the MEC172x detects that the system code has been corrupted, the application code can recover the system to a state of integrity by using backup or golden images to restore the system.  

System Code Recovery

Depending on the system configuration, the MEC172x can recover the system to a known good state. Some configuration options are:

1. Master Attached Flash (MAF) with one SPI chip
2. MAF with two SPI chips
3. Shared Flash with one SPI chip
4. Shared Flash (MAF) with two SPI chips

In all these cases, if the normal Host and ME code are detected to be corrupted, the golden images are copied from the backup location to the normal location, and then the system is allowed to boot using the restored images. For this process to be secure, once the backup image is copied to the normal location, it is re-authenticated by the MEC172x before the system is allowed to boot.

MAF with one SPI chip: In this configuration for MAF, the SPI Flash is large enough to store the golden images of the Host and ME code along with the normal Host and ME code.

MAF with two SPI chips: In this configuration, the backup images are stored in a second Flash device that can only be accessed by the MEC172x.  This prevents any malicious code running on the host processor from accessing the second Flash device and corrupting the backup images.

Shared Flash with one SPI chip: In this configuration, the SPI Flash is large enough to store the golden images of the Host and ME code along with the normal Host and ME code.

Shared Flash (MAF) with two SPI chips: In this configuration, the backup images are stored in a second Flash device that can only be accessed by the MEC172x.  This prevents any malicious code running on the host processor from accessing the second Flash device and corrupting the backup images.

To meet the latest CNSA Suite requirements for Top Secret information, the MEC172x devices have implemented:

• Elliptic Curve Digital Signature Algorithm (ECDSA) using ECC-P384 (FIPS Pub 186-4)
• Secure Hash Algorithm (SHA) using SHA2-384 (FIPS Pub 180-4)
• Elliptic Curve Diffie-Hellman (ECDH) using P-384 (NIST SP800-56A)
• Advanced Encryption Standard (AES) using AES256 (FIPS Pub 197)

The MEC172x family implements the following features and capabilities to support NIST 800-193:

• Secure Root of Trust
  • Initial boot code is in immutable code (ROM)
  • All code is authenticated before execution
• Multiple Keys
  • Support for up to 32 public keys for a system
  • Critical for protecting a system if a private key used to sign the code is compromised
• Key Revocation
  • Used to revoke keys if the private key is compromised
    • Automatic key revocation
    • Manual key revocation
• Code Rollback Protection
  • Used to prevent earlier versions of code to run on a system once the code has been determined to contain a security hole
    • Automatic code rollback protection
    • Manual code rollback protection
• Platform ID
  • Used to confirm that the loaded mutable code is intended to run on the specific platform
• Physically Unclonable Function (PUF)
  • Used to generate device-specific key or secrets
  • Keys can be used to store device-specific data in a SPI Flash
  • Keys can be used to generate device-specific private/public key pairs
• Redundancy
  • Support for Multiple SPI Flash, which allows the system to recover even if one Flash device is fully erased
  • Multiple images so that backup copies of all images (backup and golden) are available
  • Independent duplicates of all critical information for root of trust Including:
    • Dual images
    • Dual configuration blocks
    • Dual key repositories
• Support for Large SPI Flash with 4-byte addressing
  • Provides adequate storage for duplicate and backup images
• Secure Update
  • All code updates are authenticated before use
• Device Identifier Composition Engine (DICE) technology
• Attestation
  • Performed by DICE to determine the trustworthiness of an embedded device.

There will be times when a secure code update must be implemented to update one or all the code images in the system. The normal recommendation is to allocate a section of the SPI Flash to hold the image so it can be authenticated before it is copied over as the main or backup image. This area can be referred to as the staged area or staged image. During the secure update, the updated image is copied to the staged area where the MEC172x will authenticate the image. Once the image has been authenticated, the MEC172x can then copy it to the active location and perform authentication again to make sure it was not corrupted during the copy procedure.

In some systems, the images may be so large that there is not enough area in the Flash device for the main image, backup image and staged image. In this case, the system can store the staged image in system DRAM. The MEC172x implements bus mastering on the eSPI bus, which allows the MEC172x to directly access large amounts of the system Flash. The MEC172x can read large blocks of DRAM in 4 KB increments and perform the authentication of the staged image. Once the staged image has passed authentication, it can be copied to the SPI Flash and authenticated again to ensure there were no errors introduced when copying the image to the Flash device.  

The same capabilities to protect, detect and recover can be accomplished with other Microchip ECs such as the CEC1712.  Visit the MEC172x product page and/or CEC1712 product page to learn more about using these devices in your next platform.