自 2025 年 3 月 27 日起,我们建议您使用 android-latest-release
而非 aosp-main
构建 AOSP 并为其做出贡献。如需了解详情,请参阅 AOSP 的变更。
DICE 的应用
使用集合让一切井井有条
根据您的偏好保存内容并对其进行分类。
设备标识符组合引擎 (DICE) 是一项 Android 安全功能,可为每台设备创建唯一的加密身份,从而提供强大的认证并提高设备完整性。DICE 特别适合用于创建设备标识,这些标识可用于需要严格身份验证和安全通信的场景。
远程密钥配置 (RKP)
使用 DICE 进行远程密钥配置有以下几项主要优势。
尽可能缩小攻击面
DICE 通过将可信根置于设备上可用的最小 可信计算基 (TCB) 来增强 RKP,这些 TCB 通常是芯片本身,而不是可信执行环境 (TEE) 内)。这可以大大减少攻击面,并最大限度地降低 RKP 永久受损的风险。
从 TEE 入侵中恢复
DICE 提供了一种机制,即使 TEE 或引导加载程序遭到入侵(可能会影响 KeyMint 生成的密钥认证的有效性),也能恢复对设备的信任。
过去,可信执行环境 (TEE) 或引导加载程序中的漏洞会导致所有受影响设备的认证密钥完全失效,即使修补了漏洞,也无法恢复信任。这是因为 TEE 对通过 Android 启动时验证加载的 Android 映像执行了远程验证,因此无法向远程方证明已应用补丁。DICE 通过启用对当前固件状态进行远程验证来解决此问题,即使在 Android 之外,从而允许受影响的设备恢复信任。
隔离环境的相互身份验证
DICE 进程终止的每个应用网域都会以密钥的形式接收一个身份,密钥的证书链会延伸回由 ROM 派生的共享信任根。随着不同的加载路径出现分支,DICE 派生过程会分成不同的分支,形成一个共享相同根的证书树,并创建设备端公钥基础架构 (PKI)。
此 PKI 可让位于单独安全隔区中的组件相互进行身份验证。一个具体示例是 Secretkeeper,这是一种硬件抽象层 (HAL),可让特权虚拟机 (pVM) 与 TEE 通信以接收稳定的 Secret,该 Secret 可用于安全地存储永久性数据。
本页面上的内容和代码示例受内容许可部分所述许可的限制。Java 和 OpenJDK 是 Oracle 和/或其关联公司的注册商标。
最后更新时间 (UTC):2025-03-25。
[null,null,["最后更新时间 (UTC):2025-03-25。"],[],[],null,["# Applications of DICE\n\nThe [Device Identifier Composition\nEngine (DICE)](/docs/security/features/dice) is an Android security feature that provides strong attestation and improves\ndevice integrity by creating a unique cryptographic identity for each device. DICE is especially\nuseful for creating device identities that can be used in scenarios requiring strong proof of\nidentity and secure communications.\n\nRemote Key Provisioning (RKP)\n-----------------------------\n\n\nThere are several key benefits that come from using DICE for RKP.\n\n### Minimization of the attack surface\n\n\nDICE enhances RKP by grounding the root of trust in the smallest possible\n[trusted computing base (TCB)](https://en.wikipedia.org/wiki/Trusted_computing_base)\navailable on the device, usually the chip itself, rather than within the Trusted Execution\nEnvironment (TEE). This greatly reduces the attack surface and minimizes the risk of permanent RKP\ncompromise.\n\n### Recovery from TEE compromises\n\n\nDICE provides a mechanism to recover trust in devices even if there are compromises in the TEE or\nbootloader that could affect the validity of the key attestations generated by\n[KeyMint](/docs/security/features/keystore/attestation#attestation-extension).\n\n\nHistorically, vulnerabilities in the\n[TEE](https://en.wikipedia.org/wiki/Trusted_execution_environment)\nor [bootloader](/docs/core/architecture/bootloader) led to\nfull revocation of attestation keys for all affected devices, with no path to recover trust even\nif the vulnerabilities were patched. This was because the TEE performed remote verification over\nthe Android image being loaded through the\n[Android Verified Boot](/docs/security/features/verifiedboot),\nmaking it impossible to prove to a remote party that the patches had been applied. DICE addresses\nthis issue by enabling remote verification of current firmware state, even outside of Android,\nallowing affected devices to recover trust.\n\nMutual authentication of isolated environments\n----------------------------------------------\n\n\nEach application domain that the DICE process terminates in receives an identity in the form of a\nkey with a certificate chain extending back to the shared root of trust derived by the ROM. The\nDICE derivation process separates into different branches as different loading paths diverge,\nforming a tree of certificates that all share the same root and creating an on-device public key\ninfrastructure (PKI).\n\n\nThis PKI enables components in separate secure enclaves to mutually authenticate one another. One\nconcrete example is [Secretkeeper](https://android.googlesource.com/platform/system/secretkeeper/),\na [hardware abstraction layer (HAL)](/docs/core/architecture/hal)\nthat allows privileged virtual machines (pVMs) to communicate with the TEE to receive a stable\nsecret that can be used to securely store persistent data."]]