Die Device Identifier Composition Engine (DICE) verbessert die Sicherheit von Android auf verschiedene Weise. Mit der zunehmenden Einbindung dieser Architektur werden weitere Anwendungsfälle entwickelt.
Remote Key Provisioning
Der ursprüngliche Anwendungsfall für DICE bestand darin, den Root of Trust für das Remote Key Provisioning-Protokoll (RKP) im kleinsten TCB zu verankern, das für den Chip verfügbar ist, also im ROM, und nicht im TEE. Dadurch wird die Angriffsfläche für eine dauerhafte Manipulation von RKP erheblich reduziert. Noch wichtiger ist, dass die Vertrauenswürdigkeit von Geräten nach Manipulationen in der TEE oder im Bootloader wiederhergestellt werden kann, die sich auf die Gültigkeit der von KeyMint generierten Schlüsselattestierungen auswirken könnten.
Bisher führten Sicherheitslücken im TEE oder Bootloader zum vollständigen Widerruf der Attestationsschlüssel für alle betroffenen Geräte. Selbst wenn die Sicherheitslücken geschlossen wurden, gab es keine Möglichkeit, das Vertrauen wiederherzustellen. Das lag daran, dass es nicht möglich war, einer externen Partei nachzuweisen, dass die Patches angewendet wurden, da die Remote-Überprüfung von der TEE über das Android-Image durchgeführt wurde, das über den verifizierten Android-Boot geladen wurde. DICE schließt diese Lücke durch die Möglichkeit, den aktuellen Status der außerhalb von Android geladenen Firmware aus der Ferne zu prüfen.
Gegenseitige Authentifizierung isolierter Umgebungen
Jede Anwendungsdomain, an der DICE endet, erhält eine Identität in Form eines Schlüssels mit einer Zertifikatskette, die bis zum gemeinsamen, vom ROM abgeleiteten Root of Trust reicht. Da sich der DICE-Ableitungsprozess durch die Aufteilung der Ladepfade verzweigt, wird eine Baumstruktur mit Zertifikaten mit demselben Stamm erstellt. Daher wird während des DICE-Vorgangs eine On-Device-PKI erstellt.
Die durch den DICE-Ableitungsprozess erstellte PKI bietet einen Mechanismus, mit dem sich Komponenten in separaten sicheren Enclaves gegenseitig authentifizieren können. Ein konkretes Beispiel hierfür ist SecretKeeper, eine Trusted HAL, mit der pVMs mit der TEE kommunizieren können, um ein stabiles Secret zu erhalten, das zum sicheren Speichern persistenter Daten verwendet werden kann.