אישור מפתח ותעודת זהות

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

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

כדי לתקן זאת, Keymaster הציגה אישור מפתח באנדרואיד 7.0 (Keymaster 2) ואישור מזהה באנדרואיד 8.0 (Keymaster 3).

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

אישור מזהה מאפשר למכשיר לספק הוכחה למזהי החומרה שלו, כגון מספר סידורי או IMEI.

אישור מפתח

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

תגים

• Tag::ATTESTATION_CHALLENGE
• Tag::INCLUDE_UNIQUE_ID
• Tag::RESET_SINCE_ID_ROTATION

סוּג

Keymaster 2 ומטה

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

שיטת AttestKey

Keymaster 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 ומטה

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);

• dev הוא מבנה מכשיר keymaster.
• keyToAttest הוא גוש המפתח שהוחזר מ- generateKey שעבורו תיווצר האישור.
• attestParams היא רשימה של כל הפרמטרים הדרושים לאישור. זה כולל Tag::ATTESTATION_CHALLENGE ואולי Tag::RESET_SINCE_ID_ROTATION , כמו גם Tag::APPLICATION_ID ותג Tag::APPLICATION_DATA . שני האחרונים נחוצים כדי לפענח את גוש המפתח אם הם צוינו במהלך יצירת המפתח.
• certChain הוא פרמטר הפלט, המחזיר מערך של אישורים. ערך 0 הוא אישור האישור, כלומר הוא מאשר את המפתח מ- keyToAttest ומכיל את סיומת האישור.

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

תעודת אישור

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

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

רצף האישורים

TBSCertificate SEQUENCE

הרחבת אישור

תוסף attestation מכיל תיאור מלא של הרשאות ה-keymaster המשויכות למפתח, במבנה התואם ישירות לרשימות ההרשאות כפי שמשמשות באנדרואיד וב-keymaster HAL. כל תג ברשימת הרשאות מיוצג על ידי ערך ASN.1 SEQUENCE , מתויג במפורש עם מספר תג keymaster, אך עם מתאר הסוג (ארבעה סיביות בסדר גבוה) מוסווה.

לדוגמה, ב-Keymaster 3, Tag::PURPOSE מוגדר ב-types.hal כ- ENUM_REP | 1 . עבור תוסף האישור, הערך ENUM_REP מוסר ומשאיר תג 1 . (עבור Keymaster 2 ומטה, KM_TAG_PURPOSE מוגדר ב-keymaster_defs.h.)

ערכים מתורגמים בצורה פשוטה לסוגי ASN.1, לפי טבלה זו:

סכֵימָה

תוכן הרחבת האישור מתואר על ידי סכימת ASN.1 הבאה.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  applicationId               [601] EXPLICIT OCTET_STRING OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

שדות KeyDescription

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

שדות רשימת ההרשאות

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

לפרטים על ערכי כל שדה, ראה types.hal עבור Keymaster 3 ו- keymaster_defs.h עבור Keymaster 2 ומטה. שמות תג Keymaster הומרו לשמות שדות על-ידי השמטת הקידומת KM_TAG ושינוי השאר ל-Camel, כך שתג Tag::KEY_SIZE הפך ל- keySize .

שדות RootOfTrust

שדות RootOfTrust מזוהים במיקום.

ערכי VerifiedBootState

לערכים של verifiedBootState יש את המשמעויות הבאות:

ערכי SecurityLevel

לערכים של securityLevel יש את המשמעויות הבאות:

מזהה ייחודי

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

HMAC_SHA256(T || C || R, HBK)

איפה:

• T הוא "ערך המונה הזמני", המחושב על ידי חלוקת הערך של Tag::CREATION_DATETIME ב-2592000000, תוך שחרור שארית כלשהי. T משתנה כל 30 יום (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C הוא הערך של Tag::APPLICATION_ID
• R הוא 1 אם Tag::RESET_SINCE_ID_ROTATION קיים בפרמטר attest_params לקריאה attest_key, או 0 אם התג אינו קיים.
• HBK הוא סוד ייחודי הקשור לחומרה הידוע לסביבת הביצוע המהימנה ומעולם לא נחשף על ידה. הסוד מכיל לפחות 128 סיביות של אנטרופיה והוא ייחודי למכשיר הבודד (ייחודיות הסתברותית מקובלת בהתחשב ב-128 סיביות של אנטרופיה). HBK צריך להיות נגזר מחומר מפתח התמזג באמצעות HMAC או AES_CMAC.

חתוך את פלט HMAC_SHA256 ל-128 סיביות.

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

שני מפתחות, אחד RSA ואחד ECDSA, ושרשרות האישורים המתאימות, מסודרים בצורה מאובטחת למכשיר.

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

מספר IMEI

אנדרואיד 14 מוסיף תמיכה עבור מספר IMEIs ברשומת אישור מפתח אנדרואיד. יצרני OEM יכולים ליישם תכונה זו על ידי הוספת תג KeyMint עבור IMEI שני. זה נהיה יותר ויותר נפוץ שלמכשירים יש מספר מכשירי רדיו סלולריים ויצרני OEM יכולים כעת לתמוך במכשירים עם שני IMEIs.

יצרני ציוד מקורי נדרשים להחזיק ב-IMEI משני, אם קיים במכשירים שלהם, שיסופק למימוש/ים של KeyMint, כך שיישומים אלה יוכלו להעיד עליו באותה דרך שהם מעידים על ה-IMEI הראשון

תעודת זהות

אנדרואיד 8.0 כולל תמיכה אופציונלית עבור אישור מזהה עבור מכשירים עם Keymaster 3. אישור מזהה מאפשר למכשיר לספק הוכחה למזהי החומרה שלו, כגון מספר סידורי או IMEI. למרות שהיא תכונה אופציונלית, מומלץ מאוד שכל ההטמעות של Keymaster 3 יספקו תמיכה עבורה מכיוון שהיכולת להוכיח את זהות המכשיר מאפשרת למקרי שימוש כמו תצורת מרחוק אמיתית אפס מגע להיות מאובטחת יותר (מכיוון שהצד המרוחק יכול להיות בטוח שזה מדבר למכשיר הנכון, לא למכשיר שמזייף את זהותו).

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

משטח ה-API הראשי לאימות זיהוי מתבסס על מנגנון אישור המפתח הקיים שהוצג עם Keymaster 2. בעת בקשת אישור אישור למפתח שבידי keymaster, המתקשר רשאי לבקש שמזהי החומרה של המכשיר ייכללו במטא נתונים של אישור האישור. אם המפתח מוחזק ב-TEE, האישור ישלח חזרה לשורש אמון ידוע. מקבל אישור כזה יכול לוודא שהתעודה ותכולתה, לרבות מזהי החומרה, נכתבו על ידי ה-TEE. כאשר מתבקשים לכלול מזהי חומרה בתעודת האישור, ה-TEE מעיד רק על המזהים המוחזקים באחסון שלו, כפי שהם מאוכלסים בקומת המפעל.

מאפייני אחסון

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

• הערכים הנגזרים מהמזהים המקוריים של המכשיר מועתקים לאחסון לפני שהמכשיר יוצא מהמפעל.
• השיטה destroyAttestationIds() יכולה להרוס לצמיתות עותק זה של הנתונים שמקורם במזהה. השמדה לצמיתות פירושה שהנתונים מוסרים לחלוטין ולכן לא איפוס להגדרות היצרן או כל הליך אחר שבוצע במכשיר יכולים לשחזר אותם. זה חשוב במיוחד עבור מכשירים שבהם משתמש ביטל את הנעילה של טוען האתחול ושינה את תוכנת המערכת ושינה את המזהים המוחזרים על ידי מסגרות אנדרואיד.
• מתקני RMA צריכים להיות בעלי יכולת ליצור עותקים חדשים של הנתונים שמקורם במזהה החומרה. בדרך זו, מכשיר שעובר דרך RMA יכול לבצע שוב אישור מזהה. המנגנון המשמש את מתקני RMA חייב להיות מוגן כך שמשתמשים לא יוכלו להפעיל אותו בעצמם, שכן זה יאפשר להם לקבל אישורים של תעודות זהות מזויפות.
• שום קוד מלבד אפליקציית Keymaster מהימנה ב-TEE אינו מסוגל לקרוא את הנתונים הנגזרים מהמזהה שנשמרו באחסון.
• האחסון הוא ברור: אם תוכן האחסון השתנה, ה-TEE מתייחס אליו כמו שהעתקי התוכן הושמדו ומסרב לכל ניסיונות אישור מזהה. זה מיושם על ידי חתימה או MAC של האחסון כמתואר להלן .
• האחסון אינו מכיל את המזהים המקוריים. מכיוון שאישור זיהוי כרוך באתגר, המתקשר תמיד מספק את המזהים שיש לאשר. ה-TEE רק צריך לוודא שאלו תואמים לערכים שהיו להם במקור. אחסון גיבוב מאובטח של הערכים המקוריים ולא של הערכים מאפשר אימות זה.

בְּנִיָה

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

S = D || HMAC(HBK, D)

איפה:

• D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
• HMAC הוא קונסטרוקציית HMAC עם hash מאובטח מתאים (מומלץ SHA-256)
• HBK הוא מפתח קשור לחומרה שאינו משמש לשום מטרה אחרת
• ID 1 ...ID n הם ערכי המזהה המקוריים; שיוך של ערך מסוים לאינדקס מסוים תלוי ביישום, מכיוון שלמכשירים שונים יהיו מספרים שונים של מזהים
• || מייצג שרשור

מכיוון שיציאות ה-HMAC הן בגודל קבוע, אין צורך בכותרות או מבנה אחר כדי להיות מסוגל למצוא גיבובים של מזהים בודדים, או את ה-HMAC של D. בנוסף לבדיקת הערכים שסופקו כדי לבצע אישור, יישומים צריכים לאמת את S על ידי חילוץ D מ-S , מחשוב HMAC(HBK, D) והשוואתו לערך ב-S כדי לוודא שאף מזהים בודדים לא השתנו/הושחתו. כמו כן, יישומים חייבים להשתמש בהשוואות בזמן קבוע עבור כל רכיבי המזהה הבודדים והאימות של S. זמן ההשוואה חייב להיות קבוע ללא קשר למספר המזהים שסופקו ולהתאמה הנכונה של כל חלק מהבדיקה.

מזהי חומרה

אישור מזהה תומך במזהי החומרה הבאים:

1. שם המותג, כפי שהוחזר על ידי Build.BRAND באנדרואיד
2. שם המכשיר, כפי שהוחזר על ידי Build.DEVICE באנדרואיד
3. שם המוצר, כפי שהוחזר על ידי Build.PRODUCT באנדרואיד
4. שם היצרן, כפי שהוחזר על ידי Build.MANUFACTURER באנדרואיד
5. שם הדגם, כפי שהוחזר על ידי Build.MODEL באנדרואיד
6. מספר סידורי
7. IMEI של כל מכשירי הרדיו
8. MEID של כל מכשירי הרדיו

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

אישור זיהוי מתבקש על ידי ביצוע אישור מפתח והכללת מזהי המכשירים שיעידו בבקשה. המזהים מתויגים כ:

• ATTESTATION_ID_BRAND
• ATTESTATION_ID_DEVICE
• ATTESTATION_ID_PRODUCT
• ATTESTATION_ID_MANUFACTURER
• ATTESTATION_ID_MODEL
• ATTESTATION_ID_SERIAL
• ATTESTATION_ID_IMEI
• ATTESTATION_ID_MEID

המזהה שיש להעיד הוא מחרוזת בתים מקודדת UTF-8. פורמט זה חל גם על מזהים מספריים. כל מזהה לאישור מבוטא כמחרוזת מקודדת UTF-8.

אם ההתקן אינו תומך באישור מזהה (או שהתקשרו בעבר destroyAttestationIds() והמכשיר אינו יכול עוד לאשר את המזהים שלו), כל בקשת אישור מפתח הכוללת אחד או יותר מהתגים הללו נכשלת עם ErrorCode::CANNOT_ATTEST_IDS .

אם ההתקן תומך באישור מזהה ואחד או יותר מהתגים שלעיל נכללו בבקשת אישור מפתח, ה-TEE מאמת שהמזהה שסופק עם כל אחד מהתגים תואם את העותק שלו של מזהי החומרה. אם מזהה אחד או יותר אינם תואמים, האישור כולו נכשל עם ErrorCode::CANNOT_ATTEST_IDS . זה תקף שאותו תג יסופק מספר פעמים. זה יכול להיות שימושי, למשל, בעת אישור IMEI: למכשיר עשויים להיות מספר מכשירי רדיו עם מספר IMEI. בקשת אישור תקפה אם הערך שסופק עם כל ATTESTATION_ID_IMEI תואם לאחד ממכשירי הרדיו של המכשיר. אותו דבר חל על כל שאר התגים.

אם האישור מצליח, המזהים המאושרים מתווספים להרחבת האישור (OID 1.3.6.1.4.1.11129.2.1.17) של תעודת האישור שהונפק, באמצעות הסכימה מלמעלה . שינויים מסכימת האישורים של Keymaster 2 מודגשות , עם הערות.

Java API

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

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].