2025년 3월 27일부터 AOSP를 빌드하고 기여하려면 aosp-main
대신 android-latest-release
를 사용하는 것이 좋습니다. 자세한 내용은 AOSP 변경사항을 참고하세요.
기기 식별자 구성 엔진
컬렉션을 사용해 정리하기
내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.
기기 식별자 구성 엔진 (DICE)은 Android에 채택된 신뢰할 수 있는 컴퓨팅 그룹 (TCG) 사양입니다.
부팅 시퀀스 중에 로드된 각 펌웨어에 대해 변경 불가능한 강력한 암호화 ID 세트를 만듭니다. 이러한 ID를 사용하면 기기의 보안 상태를 원격으로 확인할 수 있으며, 이를 우회하려면 ROM을 손상시켜야 합니다.
DICE 파생 프로세스

그림 1. 간소화된 DICE 파생 프로세스
DICE 파생 프로세스를 사용하면 펌웨어 이미지를 변경할 때마다 해당 단계와 그 이후의 모든 단계에 대해 새로운 고유 식별자가 생성됩니다. 이는 로드된 각 펌웨어 단계가 다음 단계를 측정하고 인증하여 우회나 조작을 방지하는 고유한 ID와 연결된 키를 생성하기 때문입니다. 읽기 전용 메모리 (ROM)는 키 파생 함수 (KDF)를 사용하여 측정, 구성, 고유한 기기 비밀 (UDS)을 처리하여 다음 단계에 로드할 비밀을 파생합니다. 이 보안 비밀을 복합 기기 식별자 (CDI)라고 합니다.
0단계: 초기화
DICE 프로세스는 일반적으로 퓨즈인 변경 불가능한 데이터 뱅크에서 UDS를 로드하는 칩셋의 ROM으로 시작됩니다. 이 UDS는 칩 제조 프로세스 중에 암호화 방식으로 무작위 값으로 안전하게 프로비저닝됩니다. UDS를 읽은 후 ROM은 래치와 같은 공급업체 종속 하드웨어 잠금 메커니즘을 사용하여 다음 부팅까지 UDS 액세스를 잠급니다.
1단계: 초기 키 파생
ROM은 UDS를 키 파생 함수 (KDF)의 입력으로 사용하여 기기를 고유하게 식별하는 영구 비대칭 키 쌍을 생성합니다. 보안 부팅 사용 여부와 같은 부팅 환경에 관한 메타데이터를 포함하여 다음 펌웨어 단계를 측정합니다. 그런 다음 ROM은 KDF에서 UDS, 펌웨어 측정, 구성 데이터를 결합하여 첫 번째 CDI를 파생합니다. 이 CDI는 다음 단계에 비밀로 전달됩니다.
2~n단계: 재귀 키 파생
그런 다음 프로세스가 반복됩니다. 이후 모든 단계에서 이전 단계의 CDI가 새 KDF의 입력으로 사용됩니다. 이 KDF는 CDI와 다음 펌웨어 이미지의 해시를 사용하여 새 파생 CDI를 생성합니다. 각 단계는 자체 키 쌍을 생성하고 이를 사용하여 단계별 측정값과 기타 관련 메타데이터가 포함된 인증서에 서명합니다.
이 페이지에 나와 있는 콘텐츠와 코드 샘플에는 콘텐츠 라이선스에서 설명하는 라이선스가 적용됩니다. 자바 및 OpenJDK는 Oracle 및 Oracle 계열사의 상표 또는 등록 상표입니다.
최종 업데이트: 2025-07-27(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-07-27(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."]]