Thank you for taking the time to read our security blog. This is part three in a three-part series about secure boot. If you haven’t checked out the previous two articles they are Part 1 – Secure Boot Introduction and Part 2 – Secure Boot of MCU Devices. In our last installment, my colleague Mr. Yamanaka-san described secure boot on our RH850 MCU devices. In this blog, I will cover secure boot on our Arm®-based Renesas R-Car Gen 3 SoC devices.
Secure Boot on R-Car
System-on-chip (SoC) devices have more complex boot sequences than typical microcontroller devices. Secure boot ensures integrity and authenticity through the entire boot chain. The software can be optionally stored encrypted at rest to protect confidentiality.
Building a Chain of Trust
To provide a secure boot on R-Car, Renesas builds a chain of trust rooted in the hardware. The mask ROM and HBK (boot key hash) act as an immutable trust anchor. These cannot be altered in production. Throughout the boot chain, each part of the chain of trust is verified by the earlier (authorized) part. Chaining of elements allows all stages of verification to point back to the original root of trust, like links in a chain. The starting point of this verification process is the mask ROM of the R-Car. It is executed immediately after reset.
Key Takeaway: Renesas builds a chain of trust rooted in the hardware
- Mask ROM and HBK function as an immutable trust anchor, these cannot be altered
- Each part of the chain of trust is verified by the previous (authorized) part
- The starting point of this verification process is the mask ROM of the R-Car device as the “Root of Trust”
Preparing the Secure Boot Environment
In R-Car devices, secure boot starts with preparing the signing chain. Preconditions to the signing process include generating two RSA key pairs (the device root key pair and the secure boot key pair) and generating the device root public key hash (HBK). Each customer will have a unique root key controlled in their secure OT environment. Root and secure boot private keys must be stored securely to ensure overall system security. Once the key pairs are created, a Renesas supplied tool generates a cryptographic hash of the root public key. This public root key hash (HBK) is provided to Renesas and programmed into R-Car devices during manufacturing. The HBK is used in the secure boot chain to verify the integrity and authenticity of the root public key.
Signing Images
After the environment is prepared, the signing process can begin. Taking the root and secure boot key pairs and software image as inputs, the signing tool generates two certificates: 1) A root key certificate that contains the public root key and 2) The content certificate that contains the secure boot public key and image signature contents. The software image and certificates are programmed into the R-Car device memory. Only public keys are stored on the R-Car device.
Secure Boot on an R-Car Device
After reset release (1) the Secure Boot function is called (2). The Secure Boot function verifies the software using the root key and content certificates (3). The deployed software will only be executed by the device if the verification process is successful (4).
Here is an exploded version of the secure boot sequence.
Steps:
- Device reset released
- The device executes the mask ROM. If the device is in a security-enabled state, secure boot is executed.
- The mask ROM loads certificates and content from external flash
- The mask ROM parses the root key certificate and extracts the root key. The root key hash is calculated and compared to the known root key hash (HBK). If the key is correct, the system proceeds to the next step.
- The mask ROM calculates and compares the hash of the boot key found in the secure boot content certificate to the secure boot key hash found in the key certificate (verified in the previous step). If the check passes, the public key is used to verify the content certificate signature. If the content certificate is valid, the data in the content certificate is used to calculate the validity and integrity of the next boot stage. If everything checks out execution jumps to the next boot stage.
Steps:
- Subsequent boot stages can call into the mask ROM secure boot functions to validate later stage content. In this example, the IPL calls into the mask ROM API to verify applications 1-3. By calling the mask ROM API in later stages, the designer can take advantage of the hardware acceleration for the RSA signature check and SHA accelerator for hashing.
- The mask ROM verifies the content certificate is loads the next boot stage
- The IPL can validate every image or only a subset of images it loads. In this example application, 1-3 use the secure boot API while application 4 and 5 use another method.
- When the IPL is done loading and verifying content, it jumps to the next boot stage.
Conclusion:
SoCs have a longer boot chain than MCU devices. The secure boot logic in our R-Car devices allows the designer to take advantage of hardware acceleration of signature checks throughout the boot process. Renesas R-Car devices leverage hardware as the secure root of trust for building dependable, secure systems. Thank you for taking the time to learn more about secure boot on R-Car devices!