דף זה תורגם על ידי 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"
    }
  }
}

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

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

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

מה עומד בדרישות לביטול?

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

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

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

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