ตั้งแต่วันที่ 27 มีนาคม 2025 เป็นต้นไป เราขอแนะนำให้ใช้ android-latest-release แทน aosp-main เพื่อสร้างและมีส่วนร่วมใน AOSP โปรดดูข้อมูลเพิ่มเติมที่หัวข้อการเปลี่ยนแปลงใน AOSP
เครื่องมือการคอมโพสิชันตัวระบุอุปกรณ์
จัดทุกอย่างให้เป็นระเบียบอยู่เสมอด้วยคอลเล็กชัน
บันทึกและจัดหมวดหมู่เนื้อหาตามค่ากำหนดของคุณ
Device Identifier Composition Engine (DICE) เป็นข้อกำหนดของกลุ่มการประมวลผลข้อมูลที่เชื่อถือได้ (TCG) ที่ได้รับการนำมาใช้ใน Android
โดยจะสร้างชุดข้อมูลระบุตัวตนในการเข้ารหัสที่มีประสิทธิภาพและแก้ไขไม่ได้สำหรับเฟิร์มแวร์แต่ละรายการที่โหลดในระหว่างลำดับการบูต ข้อมูลประจำตัวเหล่านี้ช่วยให้สามารถยืนยันสถานะความปลอดภัยของอุปกรณ์จากระยะไกลได้ ซึ่งจะหลบเลี่ยงได้ก็ต่อเมื่อมีการบุกรุก ROM เท่านั้น
กระบวนการสร้าง DICE
รูปที่ 1 กระบวนการดึงข้อมูล DICE ที่ง่ายขึ้น
กระบวนการดึงข้อมูล DICE ช่วยให้มั่นใจได้ว่าการเปลี่ยนแปลงรูปภาพเฟิร์มแวร์จะส่งผลให้มีตัวระบุที่ไม่ซ้ำกันใหม่สำหรับระยะนั้นและทุกระยะหลังจากนั้น เนื่องจากเฟิร์มแวร์แต่ละระยะที่โหลดจะวัดและรับรองระยะถัดไป เพื่อสร้างตัวตนที่ไม่ซ้ำกันและคีย์ที่เกี่ยวข้องซึ่งป้องกันการลักลอบใช้หรือแทรกแซง หน่วยความจําแบบอ่านอย่างเดียว (ROM) จะประมวลผลการวัดค่า การกําหนดค่า และข้อมูลลับที่ไม่ซ้ำกันของอุปกรณ์ (UDS) ด้วยฟังก์ชันการสร้างคีย์ (KDF) เพื่อดึงข้อมูลลับสําหรับการโหลดระยะถัดไป ข้อมูลลับนี้เรียกว่าตัวระบุอุปกรณ์แบบผสม (CDI)
ระยะที่ 0: เริ่มต้น
กระบวนการ DICE เริ่มต้นด้วย ROM ของชิปเซ็ตที่โหลด UDS จากกลุ่มข้อมูลที่แก้ไขไม่ได้ ซึ่งโดยปกติแล้วจะเป็นฟิวส์ UDS นี้ได้รับการจัดสรรอย่างปลอดภัยด้วยค่าแบบสุ่มที่เข้ารหัสระหว่างกระบวนการผลิตชิป หลังจากอ่าน UDS แล้ว ROM จะใช้กลไกการล็อกฮาร์ดแวร์ซึ่งขึ้นอยู่กับผู้ให้บริการ เช่น กลอนเดือยตาย เพื่อล็อกการเข้าถึง UDS จนกว่าจะบูตครั้งถัดไป
ระยะที่ 1: การสร้างคีย์เริ่มต้น
ROM ใช้ UDS เป็นอินพุตสำหรับฟังก์ชันการสร้างคีย์ (KDF) เพื่อสร้างคู่คีย์แบบไม่สมมาตรถาวรซึ่งระบุอุปกรณ์เครื่องนั้นๆ ได้อย่างไม่ซ้ำกัน โดยจะวัดเฟิร์มแวร์ระยะถัดไป รวมถึงข้อมูลเมตาเกี่ยวกับสภาพแวดล้อมการบูต เช่น การเปิดใช้การบูตอย่างปลอดภัยหรือไม่ จากนั้น ROM จะรวม UDS, การวัดเฟิร์มแวร์ และข้อมูลการกําหนดค่าใน KDF เพื่อดึงข้อมูล CDI รายการแรก ซึ่งจะส่งไปยังระยะถัดไปแบบลับ
ระยะที่ 2 ถึง n: การสร้างคีย์แบบย้อนกลับ
จากนั้นระบบจะทําขั้นตอนนี้ซ้ำ ในขั้นตอนต่อๆ ไปทั้งหมด CDI จากขั้นตอนก่อนหน้าจะทำหน้าที่เป็นอินพุตสําหรับ KDF ใหม่ KDF นี้ใช้ CDI และแฮชของอิมเมจเฟิร์มแวร์ถัดไปเพื่อสร้าง CDI ใหม่ที่ได้ แต่ละระยะจะสร้างคู่คีย์ของตนเองและใช้คู่คีย์ดังกล่าวเพื่อลงนามในใบรับรองที่มีข้อมูลการวัดเฉพาะระยะและข้อมูลเมตาอื่นๆ ที่เกี่ยวข้อง
ตัวอย่างเนื้อหาและโค้ดในหน้าเว็บนี้ขึ้นอยู่กับใบอนุญาตที่อธิบายไว้ในใบอนุญาตการใช้เนื้อหา Java และ OpenJDK เป็นเครื่องหมายการค้าหรือเครื่องหมายการค้าจดทะเบียนของ 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."]]
