DICE stands for Device Identifier Composition Engine, and it is a security standard created by the Trusted Computing Group (TCG) which has been addressing security issues for years. TCG announced the establishment of DICE Architecture, or DICE Architecture Work Group to address the need for increased security in the Internet of Things (IoT) therefore targeting products such as MCUs and systems on a chip (SoCs).

DICE Architecture is a simple yet new security approach that doesn’t increase silicon requirements, and it can be implemented in the hardware of security products during manufacturing. DICE Architecture explores new security and privacy technologies applicable to systems and components where traditional Trusted Platform Modules (TPM) may be unfeasible in IoT applications due to limitations related with cost, power, physical space, etc.

How does it work?

DICE Architecture — with its hardware root of trust for measurement — works by organizing the boot into layers and creating secrets unique to each layer and configuration based on a Unique Device Secret (UDS) (Figure 1). When a different code or configuration is booted, at any point in the chain, the secrets will be different. Each software layer keeps the secret it receives completely confidential. If a vulnerability exists and a secret is disclosed, patching the code automatically and creates a new secret, effectively re-keying the device. In other words, when malware is present, the device is automatically re-keyed and secrets are protected.

What are the benefits?

With this new approach DICE Architecture provides a strong device identity, attestation of device firmware and security policy, and safe deployment and verification of software updates, which often are a source of malware and other attacks. Another benefit for device makers and vendors is that there is no requirement to retain or store databases of unique secrets.

What are the UDS properties?

1. UDS values must be uncorrelated and statistically unique.
2. The device MUST have a UDS that has at least the same security strength as used in the attestation process of the device.
3. When the attestation process is determined by software that is not under control of the device manufacturer, the size of the UDS should be at least 256 bits and should not be rewritable.
4. The UDS must not be used as an identity value by any other entity.

Who is using/supporting DICE Architecture?

Even though it is a new standard, it promises to help designers to create better IoT solutions. There are already some demo boards and products in the markets and, in the near future, we will see more implementations not only in the microcontroller market because DICE has the potential to help in bigger security scenarios for many commercial and industrial applications. Members of the TCG are already supporting the standard (i.e. Microchip, Micron, Microsoft Research, etc.)

One example is the recently announced CEC1702 (Figure 2) hardware cryptography-enabled microcontroller (MCU) from Microchip Technology. The MCU is a Microsoft Azure for IoT Certified device with DICE hardware capability, providing a simple way to add fundamental security to embedded products.

Also, Micron Technology and Microsoft announced a new IoT device management capability that leverages (DICE). Micron’s Authenta-based memory demonstrates how only trusted IoT devices with healthy software can gain access to the Microsoft Azure IoT cloud platform (Figure 3). The health and identity of an IoT device is verified in memory where critical code and data are typically stored.