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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

אישורי בסיס

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

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

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

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

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

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

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

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

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

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

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

למזהה ה-OID של התוסף של פרטי הקצאת ההרשאות הוא 1.3.6.1.4.1.11129.2.1.30. התוסף מספק מידע על המכשיר שידוע לשרת ההקצאה. התוסף הזה עוקב אחרי הסכימה של CDDL.

  {
        1 : int,   ; certificates issued
  }

המפה לא מחולקת לגרסאות, וניתן להוסיף לה שדות אופציונליים חדשים.

certs_issued: מספר משוער של אישורים שהונפקו למכשיר ב-30 הימים האחרונים. אם הערך גדול מהממוצע בסדר גודל מסוים, הוא יכול לשמש כאות לניצול לרעה של התהליכים שלנו.