2025 年 3 月 27 日より、AOSP のビルドとコントリビューションには aosp-main
ではなく android-latest-release
を使用することをおすすめします。詳細については、AOSP の変更をご覧ください。
デバイス識別子構成エンジン
コレクションでコンテンツを整理
必要に応じて、コンテンツの保存と分類を行います。
デバイス識別子構成エンジン(DICE)は、Android に採用されている Trusted Computing Group(TCG)仕様です。起動シーケンス中、読み込まれるファームウェアごとに強力で不変の暗号 ID のセットを生成します。これらの ID を使用してデバイスのセキュリティ ポスチャーをリモートで検証でき、これは ROM の侵害によってのみ回避できます。
DICE の導出プロセス

図 1. DICE の導出プロセスの概要
DICE の導出プロセスは、ファームウェアのイメージに対するいかなる変更でも、そのステージとそれ以降のすべてのステージに対して新しい固有識別子をもたらします。これは、読み込まれるファームウェアのステージごとに、次に生成される ID と回避または改ざんを防止する関連付けられている鍵を測定し、証明するためです。読み出し専用メモリ(ROM)は鍵の導出機能(KDF)を使用して測定、構成、固有デバイス シークレット(UDS)を処理し、次に読み込まれるステージのシークレットを導出します。このシークレットのことを、複合デバイス識別子(CDI)といいます。
ステージ 0: 初期化
DICE プロセスは、チップセットの ROM が不変のデータのバンク(通常はヒューズ)から UDS を読み込むと起動します。この UDS は、チップ製造プロセスにおいて暗号論的にランダムな値で安全にプロビジョニングされたものです。ROM は、UDS を読み取った後にベンダー依存ハードウェア ロック メカニズム(ラッチなど)を使用して、次回の起動まで UDS アクセスをロックします。
ステージ 1: 最初の鍵の導出
ROM は UDS を鍵導出関数(KDF)への入力として使用し、特定のデバイスを識別する永続的な非対称の鍵ペアを生成します。ROM は次のファームウェアのステージを測定します。これには、セキュアブートが有効かどうかなど起動環境に関するメタデータが含まれます。次に、ROM は KDF で UDS、ファームウェア測定、構成データを組み合わせて最初の CDI を導出し、この CDI はシークレットとして次のステージに渡されます。
ステージ 2 以降: 再帰的な鍵の導出
その後、このプロセスが繰り返されます。その後のすべてのステージで、前のステージからの CDI は新しい KDF の入力として機能します。この KDF は、CDI と次のファームウェア イメージのハッシュを使用して新しく導出された CDI を生成します。ステージごとに独自の鍵ペアが生成され、それを使用してステージ固有の測定値とその他の関連メタデータを含む証明書に署名します。
このページのコンテンツやコードサンプルは、コンテンツ ライセンスに記載のライセンスに従います。Java および OpenJDK は Oracle および関連会社の商標または登録商標です。
最終更新日 2025-04-02 UTC。
[[["わかりやすい","easyToUnderstand","thumb-up"],["問題の解決に役立った","solvedMyProblem","thumb-up"],["その他","otherUp","thumb-up"]],[["必要な情報がない","missingTheInformationINeed","thumb-down"],["複雑すぎる / 手順が多すぎる","tooComplicatedTooManySteps","thumb-down"],["最新ではない","outOfDate","thumb-down"],["翻訳に関する問題","translationIssue","thumb-down"],["サンプル / コードに問題がある","samplesCodeIssue","thumb-down"],["その他","otherDown","thumb-down"]],["最終更新日 2025-04-02 UTC。"],[],[],null,["# Device Identifier Composition Engine\n\nThe Device Identifier Composition Engine (DICE) is a\n[Trusted Computing Group (TCG) specification](https://trustedcomputinggroup.org/what-is-a-device-identifier-composition-engine-dice/)\nthat has been [adopted into Android](https://pigweed.googlesource.com/open-dice/+/refs/heads/android16-release/docs/android.md).\nIt creates a set of strong, immutable cryptographic identities for each piece of firmware loaded\nduring the boot sequence. These identities enable remote verification of a device's security\nposture, which can only be evaded by compromising the ROM.\n\nDICE derivation process\n-----------------------\n\n***Figure 1.** Simplified DICE derivation process.*\n\n\nThe DICE derivation process ensures that any change to any firmware image results in a new unique\nidentifier for that stage and every stage thereafter. This is because each loaded firmware stage\nmeasures and certifies the next, generating unique identities and associated keys that prevent\nbypassing or tampering. The [read-only memory (ROM)](https://en.wikipedia.org/wiki/Read-only_memory)\nprocesses the measurement, configuration, and unique device secret (UDS) with a key derivation\nfunction (KDF) to derive the secret for the next stage to be loaded. This secret is referred to as\na compound device identifier (CDI).\n\n### Stage 0: Initialization\n\n\nThe DICE process begins with the chipset's ROM loading the UDS from a bank of immutable data,\ntypically fuses. This UDS is securely provisioned with a cryptographically random value during the\nchip production process. After reading the UDS, the ROM uses a vendor-dependent hardware-locking\nmechanism such as a latch to lock UDS access until the next boot.\n\n### Stage 1: Initial key derivation\n\n\nThe ROM uses the UDS as input to a [key derivation function (KDF)](https://en.wikipedia.org/wiki/Key_derivation_function)\nto generate the permanent asymmetric key pair that uniquely identifies that device. It measures\nthe next firmware stage, including metadata about the boot environment such as whether secure boot\nis enabled. The ROM then combines the UDS, firmware measurement, and configuration data in the KDF\nto derive the first CDI, which is passed to the next stage as a secret.\n\n### Stage 2 to n: Recursive key derivation\n\n\nThe process then repeats. In all subsequent stages, the CDI from the previous stage serves as the\ninput for a new KDF. This KDF uses the CDI and the hash of the next firmware image to produce a\nnew derived CDI. Each stage generates its own key pair and uses it to sign a certificate\ncontaining stage-specific measurements and other associated metadata."]]