Accurately attest the integrity of devices with DICE

With 20 billion connected devices expected to be in use by 2030, the increasingly digitised world requires more advanced technological innovations to combat the proliferation of cyber-attacks. With more Internet of Things (IoT) devices, there comes an added risk of systems being targeted and exploited for their vulnerabilities. As such, it is paramount for users to have devices that they trust so they will receive peace of mind that hackers will not be able to find gaps and weaknesses in their systems and exploit their data.

A Trusted Platform Module (TPM) goes some way in helping to overcome these issues, especially in complex architectures with challenging security, but the large proportion of devices across the world do not operate with a TPM. This is where Device Identifier Composition Engine (DICE) comes in – allowing for accurate measurement and attestation architecture to establish trust in all devices.

Providing device protection with DICE

The TCG DICE Work Group was formed to provide a solution for devices that don’t contain a TPM, but can also establish an added layer of device security in devices that do contain one. For those devices with a TPM present, it provides a root-of-trust for measurement (RTM) that can close critical front-end gaps in the infrastructure, which can help to establish safeguarding measures for devices. As well as keeping data safe, DICE can also be easily integrated into existing infrastructure, with the architecture being flexible and interoperable with existing security standards.

New specifications from the work group provide guidelines developers can use to establish cryptographically strong device identity, attest software, and embed security policy into new devices, whilst assisting in the safe deployment and verification of software updates, at near zero cost.

With DICE, boot and firmware layers within each system receive a unique key from the previous layer. This key or secret is built from the cryptographic combination of a layer’s secret and the measurement of the next layer. Should the system be maliciously exploited by a hacker, measurements will differ for any exploited layer. This means a successful exploitation of system software would result in different keys for that layer, meaning malicious code cannot access any protected data. In a DICE device, when malicious code is introduced, the device will automatically re-key and data is protected.

Piecing together the puzzle around attestation

Previous DICE specifications have outlined how devices can make authoritative statements in order to establish device identity, however, the most recent specification titled ‘Endorsement Architecture for Devices’ enables manufacturers to provide manifests and present endorsement values to verifiers in order to successfully complete the reconciliation process.

Attestation allows us to establish trust in devices by challenging that device to tell us things about itself, what version of software its running, its identity, what its manufacturer was etc. These are called ‘claims’ – a device makes claims as to its state, configuration, date, coding etc. These claims are provided from the device, which is sometimes referred to as the attester (the piece of hardware doing the attesting).

These claims are then passed to a verifier; the element that is going to take those claims and decide whether the device is trustworthy based on the data provided and the cryptographic evidence of the keys that it possesses. It decides if this device can be trusted or not. There is no way for the verifier on its own to prove these claims are accurate without some authoritative source for what good values are, or, for the public keys matching the private keys that the device wants to prove possession of. To do so, evidence must be compared to what we call ‘endorsements’, which are similar to claims from the device, but the difference is that the endorsements are certified and signed by the device manufacturers. It is then the verifier’s role to understand and reconcile the claims and endorsements, to provide said optimal protection within devices.

The new specification on ’Endorsement Architecture for Devices’ fills in the missing piece of the puzzle around attestation by providing information to manufacturers on how to provide manifests, and a method of presenting endorsement values to these verifiers so that the reconciliation and attestation claim verification process can be carried out effectively and securely.

Securing solutions for all devices

As TCG upholds its promise to enhance security and privacy on systems with a TPM whilst providing similar security and privacy foundations for systems without a TPM, the ’Endorsement Architecture for Devices’ specification pledges to help bolster IoT solutions for many commercial and industrial applications. The new specification is available now and can be found here.