דף זה תורגם על ידי Cloud Translation API.

אימות זוגות של מפתחות שמגובים באמצעות חומרה באמצעות אימות (attestation) של מפתחות

אימות מפתח מאפשר לכם להיות בטוחים יותר שהמפתחות שבהם אתם משתמשים באפליקציה מאוחסנים במאגר מפתחות שמגובה בחומרה של המכשיר. בקטעים הבאים מוסבר איך מאמתים את המאפיינים של מפתחות שמגובים בחומרה ואיך מפרשים את נתוני התוספים של אישורי האימות.

הערה: לפני שמאמתים את המאפיינים של מפתחות מגובים בחומרה של מכשיר בסביבת ייצור, צריך לוודא שהמכשיר תומך באימות מפתחות ברמת החומרה. כדי לעשות זאת, צריך לוודא ששרשרת אישורי האימות מכילה אישור בסיס שחתום באמצעות מפתח הבסיס של Google לאימות, ושאלמנט attestationSecurityLevel במבנה הנתונים של תיאור המפתח מוגדר לרמת האבטחה TrustedEnvironment או לרמת האבטחה StrongBox.

בנוסף, חשוב לאמת את החתימות בשרשרת האישורים ולבדוק את רשימת סטטוס ביטול האישורים כדי לוודא שאף אחד מהמפתחות בשרשרת לא בוטל. אם לא כל האישורים תקפים והבסיס הוא מפתח הבסיס של Google, אל תסמכו על האישור באופן מלא.

אחזור ואימות של צמד מפתחות בגיבוי חומרה

במהלך אימות המפתח, מציינים את הכינוי של זוג מפתחות ומאחזרים את שרשרת האישורים שלו, שבה אפשר להשתמש כדי לאמת את המאפיינים של זוג המפתחות הזה.

אם המכשיר תומך באימות מפתח ברמת החומרה, אישור הבסיס בשרשרת הזו נחתם באמצעות מפתח בסיס לאימות שמוקצה בצורה מאובטחת למאגר המפתחות של המכשיר שמגובה בחומרה.

הערה: במכשירים שמופעלת בהם אימות מפתח ברמת החומרה, Android בגרסה 7.0 (רמת API‏ 24) ומעלה ו-Google Play Services, אישור הבסיס חתום באמצעות מפתח הבסיס של אימות Google. מוודאים שאישור הבסיס הזה מופיע ברשימה שבקטע אישורי בסיס.

כדי להטמיע אימות מפתח:

משתמשים בשיטה KeyStore של אובייקט getCertificateChain() כדי לקבל הפניה לשרשרת של אישורי X.509 שמשויכים למאגר המפתחות שמגובה בחומרה.
שולחים את האישורים לשרת נפרד שאתם סומכים עליו לצורך אימות.

זהירות: אל תבצעו את תהליך האימות הבא באותו מכשיר. אם מערכת Android במכשיר נפגעה, יכול להיות שתהליך האימות יאפשר גישה למשהו לא מהימן.
מקבלים הפניה לספריית הניתוח והאימות של שרשרת אישורי X.509 שהכי מתאימה לערכת הכלים שלכם. מוודאים שהאישור הציבורי של השורש מהימן ושהאישור הבא בשרשרת חתום על כל אישור.
בודקים את סטטוס הביטול של כל אישור כדי לוודא שאף אחד מהאישורים לא בוטל.
אופציונלי: בודקים את תוסף האישור של פרטי ההקצאה, שמופיע רק בשרשראות אישורים חדשות יותר.

מקבלים הפניה לספריית מנתח ה-CBOR שהכי מתאימה לערכת הכלים שלכם. מחפשים את האישור הכי קרוב לאישור הבסיס שמכיל את תוסף האישור של פרטי ההקצאה. משתמשים בכלי הניתוח כדי לחלץ מהאישור את נתוני התוסף של האישור של פרטי ההקצאה.

פרטים נוספים זמינים בקטע בנושא תוסף מידע על הקצאת הרשאות.
מקבלים הפניה לספריית מנתח ה-ASN.1 שהכי מתאימה לערכת הכלים שלכם. מחפשים את האישור הכי קרוב לאישור הבסיס שמכיל את תוסף האישור של אימות המפתח. אם תוסף האישור של פרטי ההקצאה היה קיים, תוסף האישור של אימות המפתח חייב להיות באישור הבא מיד. משתמשים ב-parser כדי לחלץ את נתוני התוסף של אישור האימות של המפתח מהאישור הזה.

זהירות: אל תניחו שתוסף האישור של אימות המפתח נמצא באישור העלה של השרשרת. אפשר לסמוך רק על המופע הראשון של התוסף בשרשרת. כל המקרים הנוספים של התוסף לא הונפקו על ידי החומרה המאובטחת, ויכול להיות שהם הונפקו על ידי תוקף שהאריך את השרשרת בניסיון ליצור אישורים מזויפים למפתחות לא מהימנים.

הדוגמה לאימות מפתח משתמשת בניתוח ASN.1 מ-Bouncy Castle כדי לחלץ נתוני תוסף של אישור אימות. אתם יכולים להשתמש בדוגמה הזו כהפניה ליצירת מנתח משלכם.

פרטים נוספים זמינים בקטע בנושא סכימת הנתונים של תוסף אימות המפתח.
בודקים את נתוני התוסף שאחזרתם בשלבים הקודמים כדי לוודא שהם עקביים, ומשווים אותם לקבוצת הערכים שאתם מצפים שהמפתח שמגובה בחומרה יכיל.

אישורי בסיס

מהימנות האימות תלויה באישור הבסיס של השרשרת. מכשירי Android שעברו את הבדיקות הנדרשות כדי לקבל את חבילת אפליקציות Google, כולל Google Play, ושמערכת Android שלהם היא מגרסה 7.0 (רמת API‏ 24) ואילך, צריכים להשתמש במפתחות אימות שחתומים על ידי אישור הבסיס של אימות החומרה של Google. שימו לב שאימות לא היה נדרש עד Android 8.0 (רמת API‏ 26). אפשר להוריד את קבוצת אישורי הבסיס התקפים כמערך בפורמט JSON.

אישורי בסיס

צריך להשתמש בשני אישורי הבסיס הבאים כישויות עוגן אמינות כשמאמתים שרשרת של אישורי אימות מפתח.

אישור הבסיס הבא יתחיל לחתום על שרשראות של אישורי אימות ב-1 בפברואר 2025.

Previously Issued Root Certificates

אם אישור הבסיס בשרשרת האישורים שקיבלתם מכיל את המפתח הציבורי הזה, ואף אחד מהאישורים בשרשרת לא בוטל, אתם יכולים לדעת:

המפתח שלכם נמצא בחומרה ש-Google מאמינה שהיא מאובטחת.
יש לו את המאפיינים שמתוארים באישור האימות.

אם בשרשרת האימות יש מפתח ציבורי בסיסי אחר, Google לא מצהירה הצהרות לגבי אבטחת החומרה. זה לא אומר שהמפתח שלכם נפרץ, אלא רק שהאימות לא מוכיח שהמפתח נמצא בחומרה מאובטחת. חשוב לשנות בהתאם את הנחות האבטחה.

אם אישור הבסיס לא מכיל את המפתח הציבורי בדף הזה, יש שתי סיבות אפשריות לכך:

סביר להניח שהמכשיר הושק עם גרסת Android נמוכה מ-7.0, והוא לא תומך באימות חומרה. במקרה הזה, ל-Android יש הטמעה של אימות בתוכנה שמפיקה את אותו סוג של אישור אימות, אבל חתומה באמצעות מפתח שמקודד בקוד המקור של Android. מכיוון שמפתח החתימה הזה הוא לא סודי, יכול להיות שהאימות נוצר על ידי תוקף שהתחזה לספק חומרה מאובטחת.
סיבה סבירה נוספת היא שהמכשיר לא תומך ב-Google Play. במקרה כזה, יצרן המכשיר יכול ליצור שורש משלו ולטעון כל טענה שירצה לגבי המשמעות של האישור. אפשר לעיין במסמכי התיעוד של יצרן המכשיר. חשוב לציין ש-Google לא מכירה יצרני מכשירים שעשו זאת.

סיבוב אישורי הבסיס של אימות החומרה

‫Google מציגה אישור בסיס חדש לאימות עם מפְתח של Android. השינוי הזה משפר את האבטחה והאמינות של תהליך האימות לאפליקציות רגישות. נוצר מפתח בסיס חדש לאימות מפתחות ב-Android (KeyMint). מפתח הבסיס החדש הוא מפתח ECDSA P-384, ומתוכנן מפתח ML-DSA (אלגוריתם חתימה דיגיטלית פוסט-קוונטי) לעתיד.

פעולה למפתחים

אם האפליקציה שלכם מסתמכת על אימות מפתחות ב-Android, עליכם להוסיף את אישור הבסיס החדש למאגרי המפתחות שלכם עד ינואר 2026. מורידים את האישורים החדשים והישנים מהכתובת https://android.googleapis.com/attestation/root
מכשירים שמשתמשים בהקצאת מפתחות מרחוק (RKP) יתחילו לקבל אישורים שמבוססים על האישור החדש הזה בפברואר 2026. מ-10 באפריל 2026, מכשירים עם RKP יתבססו באופן בלעדי על השורש החדש.
צריך לעדכן את תהליכי האימות כדי לתת אמון גם באישור הבסיס החדש וגם בקיים. מכשירים ישנים יותר עם מפתחות שהוקצו להם בהגדרות היצרן לא תומכים ברוטציית מפתחות וממשיכים להשתמש בשורש הישן.
סכימת התוסף של האישור עצמה לא תשתנה, רק הבסיס ישתנה.
הטופס החדש של שורש העץ יהיה זמין לציבור גם בפורמט קריא וגם בפורמט שקריא למחשב.

שיטות מומלצות

אל תשאלו נקודת קצה לגבי שורשים מהימנים בזמן הריצה, כי הפעולה הזו יוצרת סיכוני אבטחה. טיפול בשינויים בשורשי אמון באמצעות תהליך רשמי.

הוצאה משימוש של מפתחות מהיצרן: הקצאת מפתחות מרחוק (RKP)

במכשירים שמופעלים עם Android 16, המערכת תומכת רק ב-RKP. המדיניות הזו מוציאה משימוש את המפתחות של היצרן. הוא משפר את האופן שבו אתם מקצים ומנהלים מפתחות אימות, ומרחיב את המדיניות של Android 15, שבה התמיכה ב-RKP הייתה אופציונלית. ה-RKP מונע דליפת מפתחות כי המערכת לא מתכנת מפתחות ישירות במכשיר. אי אפשר למחוק את המפתחות האלה מהמכשיר. אם אתם חייבים לבטל מפתח, אתם יכולים לבטל אותו רק במכשיר אחד.

ספריות לאימות אישורים

משתמשים בספריית האימות של האישור Kotlin כדי לאמת שרשראות של אישורי אימות מפתחות. בנוסף, הספרייה הזו כבר משלבת את אישורי הבסיס החדשים. אם אתם משתמשים בכלי אימות אחר, מומלץ לעבור לספריית Kotlin. הוא נבדק היטב, והוא כולל מקרים חריגים שבדרך כלל לא נכללים בבודקים מותאמים אישית.

רשימת סטטוסים של ביטול אישורים

אפשר לבטל את המפתחות של האישור מכמה סיבות, כולל טיפול לא נכון או חשד לחילוץ על ידי תוקף. לכן, חשוב מאוד לבדוק את הסטטוס של כל אישור בשרשרת אישורים מול רשימת הסטטוס הרשמית של האישורים שבוטלו (CRL). הרשימה הזו מתעדכנת על ידי Google ומתפרסמת בכתובת: https://android.googleapis.com/attestation/status. הכותרת Cache-Control בתגובת ה-HTTP קובעת באיזו תדירות צריך לבדוק אם יש עדכונים, כך שלא נדרשת בקשת רשת לכל אישור שמאומת. כתובת ה-URL הזו מחזירה קובץ JSON שמכיל את סטטוס הביטול של כל האישורים שלא נמצאים בסטטוס תקין. הפורמט של קובץ ה-JSON תואם להגדרה הבאה של סכימת JSON (טיוטה 07):

{
  "$schema": "http://json-schema.org/draft-07/schema#",
  "type": "object",
  "properties": {
    "entries": {
      "description" : "Each entry represents the status of an attestation key. The dictionary-key is the certificate serial number in lowercase hex.",
      "type": "object",
      "propertyNames": {
        "pattern": "^[a-f1-9][a-f0-9]*$"
      },
      "additionalProperties": {
        "type": "object",
        "properties": {
          "status": {
            "description": "[REQUIRED] Current status of the key.",
            "type": "string",
            "enum": ["REVOKED", "SUSPENDED"]
          },
          "expires": {
            "description": "[OPTIONAL] UTC date when certificate expires in ISO8601 format (YYYY-MM-DD). Can be used to clear expired certificates from the status list.",
            "type": "string",
            "format": "date"
          },
          "reason": {
            "description": "[OPTIONAL] Reason for the current status.",
            "type": "string",
            "enum": ["UNSPECIFIED", "KEY_COMPROMISE", "CA_COMPROMISE", "SUPERSEDED", "SOFTWARE_FLAW"]
          },
          "comment": {
            "description": "[OPTIONAL] Free form comment about the key status.",
            "type": "string",
            "maxLength": 140
          }
        },
        "required": ["status"],
        "additionalProperties": false
      }
    }
  },
  "required": ["entries"],
  "additionalProperties": false
}

דוגמה ל-CRL:

{
  "entries": {
    "2c8cdddfd5e03bfc": {
      "status": "REVOKED",
      "expires": "2020-11-13",
      "reason": "KEY_COMPROMISE",
      "comment": "Key stored on unsecure system"
    },
    "c8966fcb2fbb0d7a": {
      "status": "SUSPENDED",
      "reason": "SOFTWARE_FLAW",
      "comment": "Bug in keystore causes this key malfunction b/555555"
    }
  }
}

מדיניות ביטול אישורים

אימות הוא הבסיס למאבק בהתנהלות פוגעת ולבניית אמון בסביבת Android. הוא מספק הצהרה שניתנת לאימות קריפטוגרפי לצדדים מחוץ למכשיר לגבי מצב האתחול של המכשיר.

האישורים של מפתחות האימות ב-Android יבוטלו אם המפתחות ייפרצו, בגלל החשיבות הקריטית של תוקף האימות. בקטע הזה מפורטת מדיניות בנוגע לביטול אישורים. סביר להניח שהמדיניות הזו תתפתח ותכלול עוד מקרים עם הזמן.

מה נחשב כסיבה לביטול?

דליפות של מפתחות אימות משפיעות רק על מנגנון ההקצאה הישן שנתמך ב-Android, ולא על מפתחות אימות שאושרו על ידי מנגנון הקצאת המפתחות מרחוק (RKP) החדש יותר.

מפתחות אימות שדלפו תמיד עומדים בדרישות לביטול האישורים שלהם. אפשר לגלות דליפות בכמה דרכים, כולל:

ניתוח של נתוני אימות בשימוש נרחב.
גילוי מפתחות אימות ברשתות חברתיות או באתרים ציבוריים אחרים.
דוחות ישירות מחוקרי אבטחה.

כשמגלים אישורים כאלה, הם מבוטלים על ידי הוספת המספרים הסידוריים שלהם לרשימת הביטולים. בדרך כלל, הפעולה הזו מתבצעת תוך כמה ימים מהגילוי, אבל במקרים נדירים היא עשויה להימשך זמן רב יותר. לדוגמה, ביטול האישורים של מפתחות אימות שנחשפו בדרך כלל מתעכב אם אפשר להקצות מחדש באופן מאובטח את המכשירים שמושפעים מהביטול. היקף ההשפעה של הביטול הוא גם גורם חשוב בלוחות הזמנים של הביטול.

אימות זוגות של מפתחות שמגובים באמצעות חומרה באמצעות אימות (attestation) של מפתחות

אחזור ואימות של צמד מפתחות בגיבוי חומרה

אישורי בסיס

סיבוב אישורי הבסיס של אימות החומרה

פעולה למפתחים

שיטות מומלצות

הוצאה משימוש של מפתחות מהיצרן: הקצאת מפתחות מרחוק (RKP)

ספריות לאימות אישורים

רשימת סטטוסים של ביטול אישורים

מדיניות ביטול אישורים

מה נחשב כסיבה לביטול?

סכימת נתונים של תוסף אימות עם מפתח

סכימת נתונים של תוסף לפרטי הקצאת הרשאות