Protecting Automotive Systems With A Root Of Trust

As our cars become more connected and autonomous, we depend on them to entertain us, connect seamlessly to our phones (which carry substantial personal information), help keep us in our proper driving lane, and more. We expect that the electronics in the automobile will work as advertised. However, connected cars can have vulnerabilities to direct, over-the-air, or side-channel attacks, which can cause inconvenience if an entertainment system goes down, or put drivers in harm’s way if the hack affects critical functionality such as braking and steering.

For example, in late 2016, researchers were able to demonstrate one way that hackers can put people in harm’s way, by accessing a Tesla Model S car’s control system remotely. The vulnerability allowed the researchers to access and control the braking system, engine, sunroof, door locks, trunk, side-view mirrors, and more (Figure 1). The vulnerability was through the infotainment and WiFi connection where the researchers were able to attack it and use it to gain access to the car’s controller area network (CAN) bus. The researchers acted responsibility and reported the issue to Tesla. Tesla followed up by providing an over-the-air software update. But Tesla didn’t stop there — they also included a new measure to enforce a code signing policy for any new firmware installing into the CAN bus.

While Tesla did not publicize exactly how they implemented the security in their system, using a hardware Root of Trust in their SoC would give them a very strong security perimeter.

Figure 1: Example security attack on a connected car

Components of a hardware Root of Trust
A hardware Root of Trust can be defined by the four basic building blocks:

1. The protective hardware provides a trusted execution environment (TEE) for the privileged software to run.
2. At a minimum, it must perform one or more proven cryptographic functions like AES based.
3. A form of tamper protection must be present and available for the entire runtime.
4. A flexible, yet simple user interface that the host can interact with, through either the host CPU and/or a host controller toggling GPIOs.

To meet these criteria, a hardware Root of Trust will include a variety of components, starting with a security perimeter. The security perimeter defines what needs to be protected on the SoC. It can be implemented in various ways, including via a private bus that connects to the main bus through a gateway.

Next, a Root of Trust will have a secure CPU that runs secure software/firmware. The enablement for most of the security features supported in a hardware Root of Trust is defined by the software running on that CPU. The resources around the CPU will help facilitate the security and performance of these functions.

The third element of a Root of Trust is the runtime memory. When running software on the CPU, designers need to protect the runtime data required by the software, more explicitly, the STACK, HEAP and global data. This data will contain keys in plain-text and other sensitive information. It is critical to ensure tight security around this block.

Next comes tamper resistance, which is essential for a hardware Root of Trust. Code from the outside needs to be validated prior to running it on the secure CPU. This can be implemented in many ways, for example, using a dedicated ROM that can only be accessed by the hardware Root of Trust.

Although most cryptographic functions can be supported in software, cryptography typically uses fewer memory resources and runs faster with the use of hardware accelerators. With hardware cryptographic accelerators, you can maintain high performance while using a slower clock for the CPU, which saves power, uses less runtime memory, and therefore saves area in the SoC. This is critical for cost-sensitive applications that require a high level of performance for their security functions, such as automotive applications.

Hardware Roots of Trust require a True Random Number Generator (TRNG). This module will always produce a high level of entropy required for the various security functions. Secure, untampered access to this module is critical. Compromised access to a TRNG will result in security vulnerabilities for the many security functions.

For example, many protocols generate ephemeral information to secure the connection between the end points. The high entropy used to generate the ephemeral information reduces predictability, therefore safeguarding the information. By interfering with this process, you can increase the predictability, which in turn, increases the security vulnerability of the protocol.

Including a secure clock, or secure counter, is important for applications that require a reliable time measurement. Using a secure clock is only effective if the hardware Root of Trust has access to a clock source that cannot be tampered with. A common example of this type of clock is the secure real time clock (RTC), which is typically battery powered and runs at a relatively low clock rate. Applications can use this clock to manage any time-based rights policies, for example.

The last component of a hardware Root of Trust is secure storage. Secure access to persistent storage is essential for applications requiring a state knowledge. For example, an anti-rollback feature for devices can only truly be secure if the hardware Root of Trust has secure access to a non-volatile memory (NVM). It’s critical that the information cannot be tampered with, nor can the access to the information be tampered with.

Five functions of a hardware Root of Trust
At the heart of a hardware Root of Trust are the security functions it supports. These functions provide the facility while offering a strong protection for an SoC’s product lifecycle management, during all operation phases, such as power off, power up, run time operations and communications with external entities.

Secure monitoring can be available during power up and runtime operation of the SoC. It will ensure that the components as well as the interactions of the components of the SoC are functioning properly. For example, this feature can monitor the host instruction code while the Host CPU is executing. An attempt to insert malicious instruction will result in a notification from the hardware Root of Trust back to the host.

Secure validation/authentication is responsible for cryptographically verifying the validity of the code and/or data on the SoC. The verify operation must run as an atomic operation and a hardware Root of Trust can guarantee this. This is ideal for the power up phase and ensuring a proper boot processes. That said, it is also used during the runtime phase and with applications that require proper authentication of certificates, for example. Examples of the common cryptographic operations include RSA signature check and ECDSA.

Storage protection can provide a way to take plain-text data on the SoC and securely protect it using encryption and authentication. For device binding, the protection can use a device unique key (DUK) that can only be successfully read by the device having the DUK.

Secure communication is available after successfully completing an authentication and key exchange protocol. Secure communication typically uses an ephemeral symmetric session key for encryption and in other cases, an HMAC key for authentication. These keys (which also include the master ephemeral key from the protocol) are generated inside the hardware Root of Trust, and therefore are protected and secret from any on-chip attacks.

Key management keeps the secret key material inside the hardware Root of Trust. Only indirect access to these keys is allowed and managed by permissions and policies on the application layer. Assuming the privilege levels are correct, any importing of keys must be authenticated and any exporting of keys must be wrapped to ensure continued protection of the secret material. Example of common key management applications include hardware secure module (HSM) using a public key cryptography standard (PKCS)#11 interface application to manage the policies, permissions, and handling of keys.

Hardware Secure Module 
The DesignWare tRoot H5 Hardware Secure Module (HSM) is Synopsys’ highly secure hardware root of trust that enables connected devices to securely and uniquely identify and authenticate themselves to create secure channels for remote device management and service deployment. tRoot’s advanced design addresses complex threats by protecting the device when its powered down, at boot time, run time, and, during the communication with other devices or the cloud. tRoot consistently addresses security throughout the device’s lifecycle, offering SoC designers the most efficient combination of power, size and performance.

Figure 2: DesignWare tRoot H5 Hardware Secure Module with Root of Trust

The DesignWare tRoot H5 HSM offers a high level of security because the TEE is isolated in the hardware. The software running on the CPU defines the security features supported, enabling a high level of scalability and flexibility. Logic blocks such as the Secure Instruction Controller and Secure Data Controller offer the ability to build upon the security features down the road. The tRoot HSM supports multi-stage Secure Boot, Secure Update and Secure Debug, among other security features. In addition, it offers Key Management support which uses a PKCS#11 interface to help manage both static and ephemeral keys.

The tRoot HSM can be implemented in a system without the need to lock memory as it can share memory resource already available in the system. Its unique architecture can effectively adjust to future security requirements and standards, and enable personalization of features, services and environments to create business growth and monetization in many markets, including the exploding IoT market. tRoot supports a whole range of additional features, from remote device and feature activation, secure key provisioning and management to secure communication, and secure in-field firmware updates.