top of page

Hardware Root of Trust (RoT) - A Product Security Necessity?

Feb 21, 20242 min read



A Hardware Root of Trust (RoT) is like a bouncer outside a party.

The guests trying to get in are like system processes that want to run on the main processor.


But they can't run until the bouncer checks they have actually been invited!



RoT Responsibilities


  1. Powers up and runs first

  2. Holds other processing systems in reset

  3. Checks the integrity and authenticity of necessary firmware before releasing those processors to run

  4. Is a dedicated resource for cryptographic algorithms

  5. Has isolated secure memory for key storage

  6. Is the source of a True Random Number Generator (TRNG) or Pseudo Random Number Generator (PRNG)

  7. Has hardware acceleration for certain common security algorithms (RSA, AES, SHA, etc.)


An example Root of Trust can be seen on Tesla's Autopilot in the figure below.


Tesla Autopilot Turbo Architecture Die - see [1] below


As seen in the architecture above - there is a dedicated processing core called the 'Security System'. Its job is to be the Root of Trust for the entire autopilot system. It coordinates secure boot on the many subsystems shown in the Turbo Architecture.


Different Types of RoTs

  1. Hardware Security Modules (HSM) - a dedicated processing core responsible to be the system's RoT

  2. Trusted Execution Environment (TEE) - using the main core of a system that has a special security configuration. i.e. Arm TrustZone - where the core switches over into a secure processor (with hardware isolation) to perform security related processing. See [2].


Can a Root of Trust be bypassed? Yes, generally with advanced physical attacks a RoT can be bypassed. In [1], the researchers from Technical University Berlin used voltage glitching to bypass the Root CA check used to verify the rest of the system's authenticity.


Also it must be noted that a RoT will not prevent your system from being taken over through the Application layer from code it has already checked. If you have vulnerabilities in your App layer, then an OTA patch is the only way to fix that.


That being said, secure embedded systems for IoT, Aerospace, Robotics, and Automotive should base their system security off of an architecture that includes a hardware Root of Trust.


Many of the Systems on Chip (SoC) now include dedicated Arm cores that act as a Hardware Security Module (HSM) and the system RoT if the system integrator turns on the HSM.


There are complexities that arise out of using a hardware Root of Trust. This blog post will not go into all of the common pitfalls that an integrator may run into. But it is recommended to work with a Security Architect to design your system's secure boot process and other related security functions.


Thanks for reading this far - you may enter the 'RoT' party now. Try the hash - it is delicious.


Any questions - please comment below or on the LI post.





References


 
 

Comments

bottom of page