Hardware roots of trust for IoT security

By Mike Borza |  No Comments  |  Posted: July 29, 2016
Topics/Categories: Embedded - Architecture & Design, IP - Selection  |  Tags: , , ,  | Organizations:

IoT security is critical. Embedding a root of trust in hardware can provide the firm foundation necessary for a more secure IoT implementation.

IoT implementations are taking a variety of approaches to security, depending on whether they are closed or open systems and the type of application.

Closed systems with low-end devices, such as certain wearables, do not typically include high-value information and so have a relatively low security risk. A trusted execution environment (TEE), that is, a secure area of the SoC that guarantees code and data protection, working with a with a bare-metal OS offers the minimal security required by low-end, closed systems. Higher-end applications in closed systems, such as utility metering, have higher-value data and therefore are at greater risk of hacking. These systems are starting to embed a hardware root of trust to provide strong protection for the credentials and software of devices.

On the open systems side, devices such as Linux-based IoT gateways and hubs can use containerization to separate and deploy applications securely. High-end devices for use in open systems may have multiple processors and run multiple operating systems. These systems commonly use virtualization strategies, backed up by hardware that can enforce the separation between environments. All open systems require a TEE for more secure functionality.

Trusted execution environments and hardware roots of trust

For the most critical applications, a hardware root of trust can be an important building block for more secure IoT devices and network implementations.

Hardware TEEs protect their code and data even when powered off, offer safeguards at boot time that ensure that the operating environment has not been tampered with, and continuously monitor the system’s integrity when running. For the most critical applications, a hardware root of trust is an important building block in creating TEEs.

Two approaches to creating a trusted execution environment (Source: Synopsys)

Figure 1 Two approaches to creating a trusted execution environment (Source: Synopsys)

The implementation at left relies on separating the memory spaces of different applications from each other. This approach requires less hardware but offers less security and is less able to enforce the separation of execution environments.

The approach on the right uses an embedded hardware root of trust, in this case DesignWare tRoot from Synopsys, with associated security modules, cryptography cores, accelerators and associated apps and APIs. This offers the greatest separation between applications, with the security functions executing within the trusted environment on behalf of the applications processor, and separated from any non-trusted software.

Hardware roots of trust offer other advantages. They can help reduce the opportunities for successful physical attacks on a system, for example through JTAG ports, embedded debuggers, and decapsulation, or injecting noise into power supplies or I/O pins to force devices into an unknown state that leaves them vulnerable.

Defining a hardware root of trust

In designing the Synopsys tRoot embedded security module, Synopsys created IP that could be incorporated into an SoC and run without a ROM. Code can be stored in any unsecured non-volatile storage and the tRoot module’s firmware can be expanded despite its fixed physical implementation, because the module can securely share system memory with other devices on-chip.

The module is designed to withstand various forms of physical and logical attack. It meets the requirements for FIPS 140-2 certification, and is designed to resist side-channel analysis. It has self-test capability and runtime integrity assurance and provides secure bootstrap facilities for other devices on-chip. It will withstand attacks from other devices, and offers a full set of cryptographic operators.

Interaction with other on-chip subsystems is through a well-defined messaging interface that has been examined for its invulnerability to exploits.

The DesignWare tRoot provides a safe environment to create, store, and use secrets within the chip and on behalf of client applications running on host CPU(s). It supports features including:

  • secure boot and secure access controls
  • secure identification and authentication
  • firmware integrity assurance
  • secure storage for the rest of the chip
  • secure debug and test access control
  • runtime protection
  • secure field updates

These features can also be used to support cryptographic control of functionality upgrades in the field or to turn on features that may otherwise be dormant.

Block diagram of Synopsys’ tRoot (Source: Synopsys)

Figure 2 Block diagram of Synopsys’ tRoot (Source: Synopsys)

The heart of tRoot is a 32bit ARC EM CPU, with tightly coupled SRAM for working memory, and a message-based interface to the host. Different versions of firmware can be loaded as needed.

A secure instruction controller enables the use of external program memory, which is encrypted and authenticated and treated as read-only by tRoot. The microcontroller that implements the instruction controller runs from a cache designed to resist timing attacks, and to signal a tRoot exception if it senses tampering.

An optional secure data controller can provide read/write data access to shared dynamic memory over the system bus. This memory is encrypted and authenticated, enabling secure designs to use lower-cost DRAM instead of expensive private SRAM.

A key-management and secure-key port interface provides the ability to take the device’s unique key, derive a family of keys from it, so the derived keys can be used in other cryptographic modules or distributed securely around the chip without being exposed to software.

Other options include a true random number generator for use in the most secure applications, a public key accelerator, and a variety of security protocol accelerators to support encrypted communications at more than 1Gbit/s.

The system interface to the device is through a set of ports including a host port interface that provides the messaging interface to the host CPU(s). There is also a device identity (DID) interface, which can access any on-chip non-volatile memory used to hold a device’s unique key.

An entropy interface provides an external random number generator input. A GPIO interface is used to implement physical tamper detection and response capabilities, as well as features such as scan and JTAG port controls. Finally, a UART interface provides general-purpose I/O.

Hardware roots of trust in use

Consider a possible SoC design for an IoT gateway, as shown in Figure 3:

Block diagram of an IoT gateway SoC (Source: Synopsys)

Figure 3 Block diagram of an IoT gateway SoC (Source: Synopsys)

This SoC has multiple interfaces and supports a variety of standards including, for example. Ethernet, USB, PCIe, Wi-Fi, Bluetooth low energy, ZigBee, and more. It may have multiple processor cores and on-chip SRAM.

Program storage is likely to be in off-chip Flash memory, whose contents are copied into SRAM or external DDR memory to run once the SoC is booted. The hardware root of trust protects the device’s unique key, and the keys and facilities that derive from it. It provides secure storage for the rest of the chip, and acts as an identification or authentication device for various protocols.

One critical part of building a secure IoT is enabling secure bootstrapping. The tRoot module enables this by using its secure instruction controller to authenticate any program code copied from Flash into working memory during boot. If the code successfully passes cryptographic authentication, tRoot will then start its execution.

DesignWare tRoot can also be used to control access to the debug and scan chains. This is achieved using a signed request from an authority to enable scan chain or debug access. The credentials can be set to allow, for example, a debug port to be turned on without giving access to the entire scan chain, or to enable secure access to all the testable devices on the chain.

The authentication protocol can run through the UART to an external device such as a debugging pod, or through the host port interface with firmware that’s running on the host device to enable access to tRoot.

The tRoot module enables multiple keys to be derived from a device unique key (Source: Synopsys)

Figure 4 The tRoot module enables multiple keys to be derived from a device unique key (Source: Synopsys)

Extensible secure storage uses the device unique key to create bindings between applications running in tRoot and the data that they use. The device ID interface is typically connected to nonvolatile memory and brings in a stored value that is used in a key-generation or key-derivation process to create a derived key from the device’s unique key. This process disconnects the value that is used by applications from the device unique key and from the value that is used as the key generating key. The key generating key produced by tRoot forms the basis of the rest of the key derivation chain used by applications within tRoot.

Trust and authentication models

Roots of trust are often applied to network services. The tRoot module can strongly protect the identity of devices that operate in the cloud and so enable them to be connected to services operating in data centers.

Various trust and authentication models are being used for the IoT. In local networks, the choice of wireless protocol determines the choice of identification and authentication protocols, but the emerging standard for IoT devices connected over the Internet is Transport Layer Security (TLS).

There are two common methods of authenticating users of a TLS service. The first uses a combination of user name and password, and the client authenticates to the server. A better approach is to use client certificate authentication, based on a public key infrastructure (PKI) trust model. This gives the opportunity to control access very tightly, provides strong proofs of identity of devices within an ‘island’ of IoT devices, and strong proofs between devices that they are part of the same PKI island.

It is likely that the IoT will emerge as multiple PKI islands, disconnected from each other, as manufacturers try to lock in customers in their ecosystem. ‘Transitive trust’ – the cross-signing of the root keys for different PKIs – will enable different PKI islands to be linked securely.

Cross-signing the root keys of different PKI islands uses ‘transitive trust’ to join PKIs (Source: Synopsys)

Figure 5 Cross-signing the root keys of different PKI islands uses ‘transitive trust’ to join PKIs (Source: Synopsys)

The advantage of cross-signing is that it means much less data needs to be moved around the network as ecosystems are merged, because you’re effectively extending the original roots of trust for each of the ecosystems across both ecosystems.

Another approach to security is the ‘web of trust’, an open protocol that is inexpensive to deploy, light on resources and of which there are good open-source implementations. Users control who they trust and can vouch for other users, and key distribution is open and web-based.

There are disadvantages to be overcome. The model is difficult to scale for automation, and there are not yet tools to automate the delegation of trust. The approach also lacks a good model for revocation, although this too is changing.

Conclusion

The IoT is evolving rapidly and so are the security threats within it. To meet these threats, we’re going to need aggregation nodes, such as hubs and gateways, that are able to adapt and respond to new threats. This means it will be essential for IoT devices and networks to support automatic over-the-air security updates. Embedded hardware roots of trust are especially appropriate for such devices, especially in high-bandwidth or high-throughput devices with ready access to energy.

Lower-cost IoT devices protecting lower value secrets and running off batteries will have to rely on firmware, or firmware and limited hardware, to provide (lesser) root of trust capabilities.

Author

Mike Borza has more than 20 years of leadership experience in security system and safety critical system engineering. He was founder and CTO of Elliptic Technologies, recently acquired by Synopsys, and has been an active contributor to the security task group of IEEE 802.1. Borza was an editor of the 802.1 AR secure device identifier standard, is a founder member of the prpl Foundation and co-chair of its security engineering group, and chairs the EEMBC IoT security benchmark working group.

Company info

Synopsys Corporate Headquarters
690 East Middlefield Road
Mountain View, CA 94043
(650) 584-5000
(800) 541-7737
 www.synopsys.com

Comments are closed.

PLATINUM SPONSORS

Synopsys Cadence Design Systems Siemens EDA
View All Sponsors