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

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

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

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

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

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

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

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

הערה: במכשירים שכוללים אימות מפתחות ברמת החומרה, Android 7.0 (רמת API‏ 24) ואילך ו-Google Play Services, האימות של אישור הבסיס מתבצע באמצעות מפתח הבסיס של 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 יש הטמעה תוכנתית של אימות שמפיקה את אותו סוג של אישור אימות, אבל חתומה על ידי מפתח שנקבע בקוד המקור של 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"
    }
  }
}