החל מ-27 במרץ 2025, מומלץ להשתמש ב-android-latest-release במקום ב-aosp-main כדי ליצור תרומות ל-AOSP. מידע נוסף זמין במאמר שינויים ב-AOSP.
יישומים של DICE
קל לארגן דפים בעזרת אוספים
אפשר לשמור ולסווג תוכן על סמך ההעדפות שלך.
Device Identifier Composition Engine (DICE) היא תכונה לאבטחת Android שמספקת אימות חזק ומשפרת את תקינות המכשיר על ידי יצירת זהות קריפטוגרפית ייחודית לכל מכשיר. DICE שימושי במיוחד ליצירת זהויות של מכשירים שאפשר להשתמש בהן בתרחישים שבהם נדרשים הוכחות חזקות לזהות ותקשורת מאובטחת.
Remote Key Provisioning (RKP)
יש כמה יתרונות עיקריים לשימוש ב-DICE ל-RKP.
צמצום שטח ההתקפה
DICE משפר את RKP על ידי הנחת בסיס האמון בבסיס המחשוב המהימן (TCB) הקטן ביותר שזמין במכשיר, בדרך כלל הצ'יפ עצמו, במקום בסביבת הביצועים המהימנה (TEE). כך מקטינים מאוד את שטח ההתקפה ומצמצמים את הסיכון לפריצה קבועה ל-RKP.
שחזור מפשרות ב-TEE
DICE מספק מנגנון לשחזור האמון במכשירים גם אם יש פשרות ב-TEE או ב-bootloader שעלולות להשפיע על התוקף של אימות המפתחות שנוצרים על ידי KeyMint.
בעבר, נקודות חולשה ב-TEE או ב-bootloader הובילו לביטול מלא של מפתחות האימות בכל המכשירים המושפעים, ללא דרך לשחזור האמון גם אם נקודות החולשה תוקנו. הסיבה לכך היא ש-TEE ביצע אימות מרחוק של קובץ האימג' של Android שנטען דרך Android Verified Boot, כך שלא ניתן היה להוכיח לצד מרוחק שהתיקונים הוחלו. כדי לטפל בבעיה הזו, DICE מאפשרת אימות מרחוק של מצב הקושחה הנוכחי, גם מחוץ ל-Android, וכך מאפשרת למכשירים המושפעים לשחזר את האמון.
אימות הדדי של סביבות מבודדות
כל דומיין של אפליקציה שבו תהליך DICE מסתיים מקבל זהות בצורת מפתח עם שרשרת אישורים שמגיעה עד ל-root of trust המשותף שמתקבל מה-ROM. תהליך ההסקה של DICE מתפצל לענפים שונים כאשר נתיבים שונים של טעינה מתעקלים, ויוצרים עץ של אישורים שכוללים את אותו שורש, ויוצרים תשתית של מפתח ציבורי (PKI) במכשיר.
ה-PKI הזה מאפשר לרכיבים במתחמים מאובטחים נפרדים לבצע אימות הדדי. דוגמה קונקרטית אחת היא Secretkeeper, שכבת הפשטה של חומרה (HAL) שמאפשרת למכונות וירטואליות בעלות הרשאות (pVM) לתקשר עם ה-TEE כדי לקבל סוד יציב שאפשר להשתמש בו לאחסון מאובטח של נתונים קבועים.
דוגמאות התוכן והקוד שבדף הזה כפופות לרישיונות המפורטים בקטע רישיון לתוכן. 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,["# 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."]]
