החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
מנוע הלחמה של מזהי המכשיר
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Device Identifier Composition Engine (DICE) הוא מפרט של Trusted Computing Group (TCG) שאומץ ב-Android.
הוא יוצר קבוצה של זהויות קריפטוגרפיות חזקות ואיתן לכל קטע של קושחת שמוטען במהלך רצף האתחול. הזהויות האלה מאפשרות אימות מרחוק של מצב האבטחה של המכשיר, וניתן לעקוף אותן רק על ידי פגיעה ב-ROM.
תהליך הפקת DICE
איור 1. תהליך פשוט יותר של הפקת נתוני DICE.
תהליך ההסקה של DICE מבטיח שכל שינוי בתמונת קושחה יביא למזהה ייחודי חדש לשלב הזה לכל שלב לאחר מכן. הסיבה לכך היא שכל שלב של קושחת הקצרום שנטען מודד ומאמת את השלב הבא, יוצר זהויות ייחודיות ומפתחות משויכים שמונעים עקיפה או פגיעה. זיכרון לקריאה בלבד (ROM) מעבד את המדידה, ההגדרה והסוד הייחודי של המכשיר (UDS) באמצעות פונקציית הפקת מפתחות (KDF) כדי להפיק את הסוד לטעינה של השלב הבא. הסוד הזה נקרא מזהה מכשיר מורכב (CDI).
שלב 0: אתחול
תהליך DICE מתחיל בטעינה של ה-UDS ממאגר של נתונים שלא ניתנים לשינוי, בדרך כלל רכיבי ניתוב (fuses), על ידי ה-ROM של הצ'יפסט. ה-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."]]
