Trusted Computing Group released on Tuesday the Device Identifier Composition Engine (DICE) Architecture for securing resource-constrained devices that make up the Internet of Things.
The DICE Architecture provides critical security and privacy benefits to IoT and embedded systems where traditional Trusted Platform Modules (TPM) may be impractical, while also enabling support for those devices with a TPM for additional security benefits.
Security capabilities this new approach enables include 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.
The DICE Architecture, with its hardware root of trust for measurement, breaks up the boot process into layers, and creates unique secrets and a measure of integrity for each layer. This means if malware is present, the device is automatically re-keyed and secrets are protected.
To make it simpler for device makers and vendors, there is no requirement to retain or store databases of unique secrets. The DICE Architecture integrates into existing infrastructure and is flexible and compatible with existing security standards.
Based on the Trusted Platform Architecture Hardware Requirements for a Device Identifier Composition Engine (DICE) draft specification, the work group is exploring new security and privacy technologies applicable to systems and components with or without a TPM.
The goal is to develop new approaches to enhancing security and privacy with minimal silicon requirements. Even simple computing capabilities combined with software techniques can establish a cryptographically strong device identity, attest software and security policy, and enable safe deployment and verification of software updates.
DICE works by breaking up boot into layers and creating secrets unique to each layer and configuration based on a Unique Device Secret (UDS). If 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 to itself. If a vulnerability exists and a secret is disclosed, patching the code automatically creates a new secret, re-keying the device.
Using a DICE Compound Device Identifier (CDI) as a basis for Device Identity, the solution involves basic assumptions for design constraints. For example, it assumes the Device Identity will be represented cryptographically as an asymmetric key pair so the public portion can be freely shared while the private portion remains secret. The private portion of this key is used to prove the device’s identity.
The benefit of limiting the number of assumptions is that it maximizes the set of Device Identity and Attestation scenarios that the reference supports.
While presuming DICE support in hardware, how the UDS is provisioned within a device is not specified – only that it has been provisioned. Also, since there is a clear advantage in relieving device manufacturers and vendors of the burden of maintaining secret databases of UDS values, this architecture presents a solution that does not require secret databases of UDS values.
Micron, Microsoft, STMicroelectronics and others actively involved in the work group are already supporting DiceArch so interested users can immediately start evaluating and even implementing it in their products and systems.
