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

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

לפני שמתחילים: מוודאים שהמכשיר תומך באימות מפתחות ברמת החומרה

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

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

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

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

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

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

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

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

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

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

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

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

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

אישורי בסיס

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

אישורי בסיס

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

אישורי בסיס שהונפקו בעבר

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

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

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

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

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

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

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

מה צריך לעשות

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

אימות התאימות עם שורש חדש

כדי לוודא שהאפליקציה שלכם תואמת לאישור הבסיס החדש, אתם יכולים לרשום מכשיר בדיקה בשרת העורפי של Google RKP, כדי שהוא יקבל אישורים שנחתמו על ידי אישור הבסיס החדש. כדי לבדוק את האפליקציה באמצעות שורש חדש:

דרישות מוקדמות

חשוב לוודא שהדרישות הבאות מתקיימות:

‫Python 3
ממשק הגישור של Android‏ (ADB‏)‎
מכשיר עם מערכת הפעלה Android שהוגדר באופן הבא:
- מערכת ההפעלה Android מגרסה 15 ואילך.
- האפשרות 'אפשרויות למפתחים' מופעלת.
- המכשיר תומך ב-RKP. רוב המכשירים שנמכרים בשנת 2025 ואילך תומכים ב-RKP. אפשר לאמת את התמיכה ב-RKP באמצעות adb shell cmd remote_provisioning dump. הפלט צריך לכלול את הפרטים הבאים:
```
default:
  hwVersion=[INTEGER]
  rpcAuthorName=[DEVICE MAKER]
    
```

צירוף המכשיר לתוכנית

כדי לרשום את המכשיר, צריך לפעול לפי השלבים הבאים.

מורידים את כלי הרישום של מכשיר הבדיקה: google_root_register.py
מריצים את כלי הרישום: python3 google_root_register.py
מאפסים את המכשיר להגדרות המקוריות. השלב הזה נדרש כדי לנקות את כל האישורים שהוקצו בעבר.

כדי לוודא שהמכשיר מקבל אישורים שחתומים על ידי שורש חדש, מריצים את הפקודה

adb shell
    cmd remote_provisioning certify default

. הפלט הוא שרשרת אישורים מסוג X.509 בפורמט PEM. האישור האחרון הוא אישור הבסיס, והוא צריך להיות זהה לערך הבא:

בודקים את האפליקציה במכשיר.

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

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

הוצאה משימוש של מפתחות מהיצרן: הקצאת מפתחות מרחוק (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 יבוטלו אם המפתחות ייפרצו, בגלל החשיבות הקריטית של תוקף האימות. בקטע הזה מפורטת מדיניות בנוגע לביטול אישורים. סביר להניח שהמדיניות הזו תתפתח ותכלול עוד מקרים עם הזמן.

מהם התנאים לביטול?

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

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

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

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

לפני שמתחילים: מוודאים שהמכשיר תומך באימות מפתחות ברמת החומרה

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

אישורי בסיס

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

מה צריך לעשות

אימות התאימות עם שורש חדש

דרישות מוקדמות

צירוף המכשיר לתוכנית

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

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

ספריות אימות של הצהרות

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

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

מהם התנאים לביטול?

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

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

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

לפני שמתחילים: מוודאים שהמכשיר תומך באימות מפתחות ברמת החומרה

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

אישורי בסיס

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

מה צריך לעשות

אימות התאימות עם שורש חדש

דרישות מוקדמות

צירוף המכשיר לתוכנית

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

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

ספריות אימות של הצהרות

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

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

מהם התנאים לביטול?

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

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

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