Device Identifier Composition Engine (DICE) improves the security posture of Android in a number of different ways, with more use cases in development as the integration of this architecture expands.
Remote key provisioning
The original use case for DICE was to ground the root of trust for the remote key provisioning (RKP) protocol in the smallest TCB available for the chip, the ROM, instead of within the TEE. This greatly reduces the attack surface for permanent compromise of RKP. More importantly, it grants the ability to recover trust in devices after compromises in the TEE or bootloader that could affect the validity of the key attestations that KeyMint generates.
Historically, vulnerabilities in the TEE or bootloader led to full revocation of attestation keys for all affected devices, with no path to recover trust even if the vulnerabilites were patched. This was because it wasn't possible to prove to a remote party that the patches had been applied, as remote verification was performed by the TEE over the Android image being loaded through Android Verified Boot. DICE closes that gap by providing the ability to remotely verify the current state of the firmware loaded outside of Android.
Mutual authentication of isolated environments
Each application domain that DICE terminates in receives an identity in the form of a key with a certificate chain extending back to the shared root of trust derived by the ROM. Because the DICE derivation process branches as loading paths split, this creates a tree of certificates that share the same root. Thus, an on-device PKI is created during the DICE process.
The PKI created by the DICE derivation process creates a mechanism for components in separate secure enclaves to mutually authenticate each other. A concrete example of this is SecretKeeper, a Trusted HAL that allows pVMs to communicate with the TEE to receive a stable secret, which can be used to securely store persistent data.