This is part three of a series. Read part two here. 

At a Sensors Expo 2018 workshop in San Jose, CA, with Embedded Computing Design, Trusted Computing Group (TCG) work group members presented information about TCG’s Trusted Platform Module (TPM) for network security, the DICE lightweight hardware root of trust and the Trusted Software Stack (TSS 2.0). Based on the presentations, a three-part series has been developed to cover those topics. The first part discussed the TPM for Network Security and the second installment addressed the Trusted Software Stack. This third and final part addresses TCG’s Device Identifier Composition Engine (DICE) lightweight root of trust applicable to systems and components, including sensors, with or without a TPM.

The Internet of Things (IoT) and other market segments are driving architectures and connectivity solutions with challenging power, security, resource and other constraints. For networked sensors, these constraints make an optimal security posture much more difficult to create and maintain.

As discussed in Part 1 and Part 2, the TPM with TSS 2.0 provides advanced security for many markets and applications. While the TPM provides a variety of security options, some applications, especially in IoT solutions, systems and components probably will not have a TPM or similar silicon-based capabilities due to cost, complexity and physical space constraints on the embedded microcontroller (MCU) or system on chip (SoC).

TCG’s solution for these restrictions is the Device Identifier Composition Engine (DICE), a new specification from the DICE Architectures Workgroup in the Trusted Computing Group. The specification defines foundational security for IoT at near zero cost. Simple hardware (HW) requirements make DICE adaptable to almost any system or component.

As one of the first companies to take advantage of the capabilities that DICE provides, Microsoft’s implementation of DICE is called Robust, Resilient, Recoverable IoT or RIoT. DICE and RIoT provide HW-based identity and attestation, and a foundation for sealing, data integrity, device recovery and secure updating.

In a DICE Architecture, device startup (boot) is layered. Beginning with a Unique Device Secret (UDS), secrets or keys are created that are unique to the device and each layer and configuration. This derivation method means that if different code or configuration is booted, secrets are different. If a vulnerability exists and a secret is disclosed, patching the code automatically re-keys the device.

As shown in Figure 1, power-on (reset) unconditionally starts the DICE. DICE has exclusive access to the UDS and each layer computes the secret for the next layer using a cryptographic one-way function (OWF). In this derivation chain, each layer must protect the secret it receives. The branch (red arrows) in Figure 1 illustrates the result of a code or configuration change. Updates provide a way to recover a device or component if bad code leaks a secret.

Figure 1: The DICE model (top row) and the impact of changes (red arrows).

DICE can be used as a foundation to enable many high-value scenarios. For example, DICE can be used for secure remote device recovery (Cyber Resilient Platform Initiative). It can recover unresponsive (i.e., p0wned, hung, etc.) devices at a greatly reduced cost since there is no need for physical device interaction.

Another example is supply chain management (“DICE for Components”). Several recent damaging cyber-attacks were the result of malware introduced in the supply chain. DICE attestation lets end-customers trust far less of the supply-chain and just the storage-subsystem or flash vendor.

In addition, the strong cryptographic identity, authenticity, licensing and many more trust aspects to make DICE an ideal attribute to establish a trusted sensor node.

Implementing the Required Trust Level

In a flexible security framework, one size does not fit all. DICE offers minimal silicon requirements and low barrier to entry – two key factors for networked sensing applications. At the same time, it provides a foundation for strong cryptographic HW-based device identity and attestation, data at rest protection (sealing) and secure device update and recovery. With public announcements already made by SoC, MCU, and flash memory suppliers and more on the way, the time is right for system designers to investigate how DICE can provide the improved security for sensors and other IoT connectivity nodes.

This three-part article has shown how sensing nodes in connected industrial applications can benefit from the increased security that computers, networks and storage segments have already implemented.

Additional resources about DICE and its implementation are available at https://trustedcomputinggroup.org/work-groups/dice-architectures/. Developer resources for trusted computing also are available at https://develop.trustedcomputinggroup.org.

Dennis Mattoon is a Principal Software Development Engineer, Microsoft Research. As one of the founding members of the Security and Privacy Research and Engineering team in MSR, Dennis and his team have spent the last 10 years focused on advancements in trusted computing and system security. His most recent work has been on the creation of the Device Identifier Composition Engine Specification and Architectures (TCG DiceArch), Robust and Resilient IoT (RIoT), and the Cyber-Resilient Platform Initiative. (https://aka.ms/Cyrep).