Achieving a Root of Trust with Secure Boot in Automotive RH850 and R-Car Devices – Part 2

RH850 Security Solution

Hi, I’m Satoshi Yamanaka, Principal Engineer for Automotive Security at Renesas. I’ve been on the security team at Renesas for 3 years. My division is responsible for automotive security, and we are in charge of customer support. We are glad to be able to convey the importance of automotive security to our customers through this blog. This blog article, part 2 in a three-part series, aims to give readers a basic understanding of what secure boot is and why it is needed.

There are 2 types of security IP on RH850 MCUs, ICU-S and ICU-M. In this blog article, we introduce how secure boot is realized on both types of devices.

Secure boot in ICU-S and ICU-M can be implemented based on HIS (now AUTOSAR) Secure Hardware Extension (SHE) specification. If you want more information about the SHE specification, please refer to AUTOSAR SHE (URL: Specification of Secure Hardware Extensions (autosar.org)). Everyone can get the SHE specification from the AUTOSAR SHE site.

Image

Image

Secure Boot Implementation Method Using ICU-S on RH850

ICU-S is an Intelligent Cryptographic Unit equivalent of EVITA light.

Security software works on the Main Processor Element (MainPE) in ICU-S MCUs. The MainPE can use hardware resources in the ICU-S module, such as cryptographic accelerators and secure key storage, through the special function register interface of the ICUS.

Image

ICU-S does not have a dedicated security-only CPU. Secure Boot runs from the non-secure CPU (PE1). To prevent tampering, the initial secure boot logic is stored in One Time Program (OTP) memory. The reset vector must point to this immutable of code to prevent tampering. Along with OTP, secure boot on ICUS devices uses the secure boot MAC key and secure boot MAC slots stored protected within the ICUS. In this strategy, the OTP memory and ICUS create the Root of Trust.

Method Summary:

• Hardware Root of Trust:
  • OTP flash memory and storage of keys protected in ICUS
• Tamper resistance:
  • MAC and MAC key are securely stored in the protected ICUS memory
• Cryptographic Algorithm
  • CMAC (NIST SP 800-38B)

Image

Staged secure boot example using ICUS on RH850:

1. After MCU reset, CPU (PE1) starts and runs the secure boot program located in OTP memory.
2. The secure boot program verifies the User Program A.
   • Secure boot program calculates the CMAC value from User Program A and Boot MAC key.
   • Secure boot program verifies the calculation result and “CMAC value of Program A”^(Note1).
3. If verification in step 2 passes, PE1 operates User Program A and verifies User Program B with help of the ICU-S.
   • Same as step 2 (Program A -> Program B).
4. If verification in step 3 passes, User program (Program B) is executed by PE1.

Note1: “CMAC value of Program A” can be registered on Secure Data Flash managed by ICU-S

Secure Boot Implementation Method Using ICU-M on RH850

ICU-M is the Renesas Intelligent Cryptographic Unit meeting the EVITA medium use case.

MCUs featuring ICU-M have a separate ICU-M processor called the Intelligence Cryptographic Unit Processor (ICUP). Security software runs entirely on the ICUP. ICUP has exclusive access to the hardware resources in the ICU-M, such as cryptographic accelerators and secure flash memory. Additionally, the ICUP can access some shared resources for communication with the Main Processor Element (MainPE).

Application software operating on the MainPE cannot directly access resources in ICU-M, such as cryptographic accelerators and secure flash. Therefore, the MainPE must request security services to ICUP through a defined communication interface. This interface is defined by the ICUM firmware design. MCUs featuring ICUM support inter processor communication through shared memory mailboxes as well as inter processor interrupts.

Image

On devices with ICUM, Secure Boot runs from the secure ICUP. The initial secure boot logic is stored in secure code storage accessible only ICU-M. The secure boot implementation verifies the application using a secure boot key stored within the protected ICUM data flash. The secure boot key and ICUM form the hardware “Root of Trust”. After reset, the ICUP starts first and performs secure boot of the application software. After verification, the ICUP releases other processor elements in the MCU from the reset state and starts operation. As mentioned earlier, hardware resources in ICU-M, such as cryptographic accelerators and secure flash memory, are exclusively accessed by the ICUP.

Method Summary:

• Hardware Root of Trust:
  ICU-M hardware. and Secure boot program on Secure Code Flash. (Attacker cannot change Secure boot program protected by ICU-M hardware)
• Tamper resistance:
  Boot MAC is stored in protected data flash only accessible to ICUM.
• Cryptographic Algorithms:
  • CMAC (NIST SP 800-38B)
  • RSA Digital Signature Algorithm

Image

Staged secure boot example using ICUM in RH850 MCU (symmetric algorithms)

1. ICUP is configured to be the boot processor after MCU reset.
2. User Program A is verified by Secure boot program in ICU-M.
   • Secure boot program calculates the CMAC value from User Program A and Boot MAC key.
   • Secure boot program verifies the calculation result and “CAMC value of Program A”.
3. If verification in step 2 passes, CPU(PE1) is started by ICUM (Security Software)
4. PE1 operates User Program A and verifies User Program B to use Secure software.
   • Same as step 2 (Program A -> Program B).
5. If verification in step 4 passes, User Program B is operated by PE1.

Image

Staged secure boot example using ICUM in RH850 MCU (asymmetric algorithms)

1. ICUP is configured to be the boot processor after MCU reset.
2. User Program A is verified by Secure boot program in ICU-M.
   • Secure boot program calculates the message digest(hash) from User Program A.
   • Secure boot program calculates the message digest from Signature of Program A and Public key.
   • Secure boot program verifies both message digest.
3. If verification in step 2 passes, CPU(PE1) is started by ICUM (Security Software)
4. PE1 operates User Program A and verifies User Program B to use Secure software.
   • Same as step 2 (Program A -> Program B).
5. If verification in step 4 passes, User Program B is operated by PE1.

Conclusion

In summary…

1. ICU-S and ICU-M can make “root of trust” and “chain of trust”.
2. Secure boot in ICU-S and ICU-M can be implemented based on AUTOSAR (SHE) HIS.
3. Secure boot in ICU-M can be implemented based on signature verification.

Keep an eye out for part three in our secure boot series where Phil Lapczynski-san will introduce secure boot concepts on our R-Car SoC devices.