Using hardware secure modules to protect SoCs

The battle to protect electronic devices from misuse or compromise is intensifying, as electronics becomes more pervasive in our lives and the value of the information that can be extracted from such devices rises.

Many industries are reacting to this requirement for greater security by publishing security guidelines or establishing regulatory standards.

In the industrial sector, security is needed to ensure that machines work properly and keep doing so, to maintain profitability and to ensure safety.

In the automotive sector, the increasing use of on-vehicle computing is improving functionality but creating the potential for more vulnerabilities.

The entertainment industry uses security to protect its intellectual property, embracing technology such as DRM, HDCP, and DTCP-IP 2.0. If the implementation of any of these standards is insecure, it would enable mass IP theft that could, in turn, lead to serious liabilities.

Healthcare has critical security requirements, to protect user data and, with the increasing use of technologies such as pacemakers and insulin pumps, to protect users from potentially lethal malfunctions or even hacking.

Protecting security in an SoC means protecting the device in all states.

When it is off, the data and software image is at rest and so may need to be encrypted to ensure its confidentiality, and tamper protection to stop it being changed. This may entail the use of authentication, and a mechanism to bind data to a particular device so it cannot be shared.

Once the device is turned on, the software image and data is initialized and used to execute and program on the SoC. If you want to validate the image and data on the device, and to validate that the device is the right one, you’ll need some form of authentication. It is also important to ensure that the boot-up sequence, and the functions it calls, can be trusted.

Once the device is running, it needs to be checked continuously for potential threats, with secured communication and secure monitoring of any access points to the SoC.

It is also important to consider other security requirements, such as protecting a user’s identity, being able to show that software has not been tampered with, and securely handling in-field updates.

Perhaps more importantly than any of these individual functions, it is vital to build a flexible and secure approach to security that can adapt to evolving attacks.

The Root of Trust

Many of these security requirements can be met by running security functions in a secure enclave, or trusted execution environment (TEE), protected from the non-secure area of the SoC. TEEs are often enabled by the use of a hardware secure module (HSM).

An HSM provides a Root of Trust, which acts as the foundation of a chain of trust that spans from the SoC to the operating system, applications and, eventually, right up to external communications. A Root of Trust has to be implemented as an inviolable part of the SoC’s hardware, and should be unique to each device, so that the rest of the security architecture can know it is running on a particular piece of hardware.

The HSM can create a closed protection environment, running its own software on dedicated hardware, to handle activities such as running cryptographic operations or providing secure access to key material. HSMs can also be certified to various security standards such as FIPS 140-2 Level 4, common criteria EAL5+ and others.

A TEE relies on the Root of Trust and provides a secure area of the SoC to guarantee code and data protection. In this isolated environment, developers can keep secrets, such as cryptographic keys, away from non-secure areas. They can also execute critical functions that require integrity. This is one way to execute a trusted process. There must be communication between the secure side and non-secure side, which must be managed to reduce the risk of attacks.

Inside an HSM

An embedded HSM is protected by dedicated hardware that can run its own software. It needs a minimum of cryptographic functions, such as support for AES. It needs tamper protection. And it must have a user interface with which the host can interact.

An HSM has a perimeter that separates its secure functions (Figure 1) from the rest of the SoC. Within that perimeter will be a secure CPU running firmware or software. The CPU has resources, such as runtime memory to hold the stack, heap, etc. The memory holds keys in plain text, and has to be tightly secured.

Tamper resistance can be achieved in various ways, including using a dedicated ROM that can only be accessed by the HSM.

The HSM needs cryptographic accelerators, and true random number generators (TRNGs) that can produce the high level of entropy necessary to, for example, generate the ephemeral keys used in various security protocols.

An HSM also needs a secure clock, to enable applications that need an expiration time, such as time-limited access to a movie rental.

An HSM also needs secure, persistent storage, so that applications that need access to state information can use the contents of this storage knowing it has not been tampered with.

The functions of an HSM

An HSM can provide:

Secure monitoring during power-up and operation of the SoC, to ensure that the SoC is functioning properly. For example, it can monitor the host instruction code while the host CPU is executing it, so that the introduction of malicious instructions can be detected.

Secure validation and authentication, to ensure the validity of the code and the data on the SoC. This can be done through an authentication scheme such as an RSA or ECC signature check.

Storage protection, to take plain text in the SoC and securely encrypt it and authenticate it. The authentication and encryption can use a device-unique key, so it can also uniquely bind it to the devices.

Secure communication, to enable a secure channel between two endpoints.

Key management, to generate and manage keys.

SoC interactions with an HSM

Host devices that want to interact with an HSM embedded in an SoC can do it in two ways. The first is to go through the host CPU on the SoC, and the second is to go through a host controller on the SoC that can toggle the GPIOs. Each approach has different security implications. For example, malicious code running on the host CPU can watch the messages going in and out of the HSM, or an attacker can cause a host controller to manipulate the GPIOs in unexpected ways.

Ideally, the HSM will detect these attacks and notify the SoC.

Here are three scenarios in which the HSM plays a key role in protecting an SoC.

Secure boot

The primary function here is to authenticate the host code image, usually when the SoC is powering up.

One way to do this is for the secure boot feature to require a certificate that contains a public key used to verify the system code. Both data sets are in external flash. When the SoC powers up, the first block that becomes active is the HSM. One of the first things it does is to begin reading the data at a known memory location.

The HSM will first validate the certificate using a root public key that exists inside the security perimeter. This root public key has been preprogrammed. If the authentication succeeds, then it will extract the sign-in public key from the certificate.

We can take this a step further by building a multistage boot sequence. In this approach, instead of using one certificate, you can have a certificate chain consisting of the root certificate, one or more subordinate certificates and an entity certificate. Each certificate represents an owner, and the certificate above (the parent certificate) signs the certificate below. A chain of certificates is a representation of different owners.

In this example, the base certificate owns the base code and data, such as drivers for peripherals in your SoC. The base certificate signs the OS certificate which allows the OS code to run on the SoC.

Secure update

SoCs are always vulnerable when accepting information from the outside, and so in-field update strategies present a challenge: how do you trust the source?

One way forward is to look at all the possible points of vulnerability, starting with the communication port. Will the port be accessed over the air or by a direct connect? Whatever the method, the key issue is how information gets to the HSM. A secondary issue is to consider what happens if there’s an onboard attacker that can observe or change this information?

The way to address this issue is to use a good protocol, which will monitor the messages and ensure all the messages from each recipient are delivered correctly, eliminating any man-in-the-middle attack. The protocol to support the secure update should be based on identity, and should provide the ability to revoke any compromised identities.

Designers can also add a secure channel to transmit data, using encryption and authentication to ensure that the packet transmitted was received properly.

Secure debug

An SoC in a debug state is vulnerable to misuse, and so it is important to enable the state in a secure way. This demands authentication, which shows that the process trying to access the debug facilities is authorized to do so. It also demands integrity, because the authentication is only useful if you can guarantee that an attacker cannot manipulate the results of the authentication scheme.

Many vendors secure JTAG ports using simple approaches, such as an unchanging shared secret held by both sides. The secret is typically burned into the SoC so if it is revealed, it compromises the chip or even a family of chips that share the same secret.

The secure CPU in an HSM enables more sophisticated authentication schemes, using proprietary or standard protocols. As with secure update, designers also need to consider good communication platforms.

It is also important, when developing a secure debug strategy, to have a clear idea of how the secure debug state will be ended – by turning the device off, or in some other way – so that you don’t leave a gap in the SoC’s security defenses.

Considerations when integrating an HSM in your SoC

Designers need to consider four factors when choosing an HSM for integration into an SoC: performance objectives; flexibility and scalability necessary for the application; security risk profile; product cost; and cost of ownership of your product.

Performance

If the SoC needs to meet fixed timing requirements, the HSM must have the performance to do so. Working out the necessary performance will involve understanding the timing requirements, the type of cryptographic functions in use, the size of the key that you need to use and the size of the data that you need to validate. Other factors that will affect performance include memory latency, and bus speed.

Flexibility and scalability

If the product for which you are developing an SoC is likely to be part of a product road map, it makes sense to forecast the necessary on-chip resources to take into account future application requirements, such as the need to use longer keys to protect higher-value content in a media player.

Security risk profile

HSM can help SoC designers incorporate better security in their designs, but this may be of little practical value if they don’t understand all the vulnerable points in their system.

For example, attacking a content-protection protocol on a media player may enable it to fully authenticate with an upstream device, so that once authenticated, it can receive the protected content, decode it and put the unprotected content into a frame buffer from which it can be stolen.

Understanding these kind of risks is vital to the effective use of an HSM to implement security.

Product cost and ownership cost

Product cost will depend on the vulnerability of your design to security risks, and hence the level of security protection required. Some designers list and prioritize vulnerabilities by using a weighting scheme. For example, a designer may use features from an HSM to support critical functions such as secure boot, but be more relaxed about ephemeral key protection during a communications session.

Ownership cost is about the additional cost that an SoC vendor passes on to a customer to support a particular security feature in a product. For example, your security feature may affect the manufacturing flow by demanding that each device goes through a unique step to give it a unique key. The manufacturing challenge, therefore, is to provision each device uniquely, while protecting the source of keys from leakages.

The Synopsys offering

Synopsys has built a family of HSMs with Root of Trust, including the tRoot H5. This is our highest performance HSM, which offers the flexibility and scalability necessary for an SoC that is expected to have an extended lifecycle in multiple products.

It uses hardware acceleration that makes some operations, such as large cryptographic processes, 100 times faster than running them in software on a generic processor. This can enable function such as the fast boot-up times required by automotive manufacturers. The tRoot H5 also supports multi-stage secure boot, secure update, and secure debug.

The tRoot H5 HSM consists of a hardware RTL component that must be integrated into your SoC, firmware and host software. The host software is designed to be portable across most platforms and the firmware is easy to install and use. The third key tRoot component is a set of tools designed to ease specific parts of the development process, such as building the firmware, or programming a root key for secure debug.

Author

Andrew Elias is a senior security architect at Synopsys.

Company info