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

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

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

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

רצף האישורים

שם שדה (ראה RFC 5280 ) ערך
tbsCertificate TBSCertificate SEQUENCE
אלגוריתם חתימה AlgorithmIdentifier של האלגוריתם המשמש לחתימה על מפתח:
ECDSA עבור מפתחות EC, RSA עבור מפתחות RSA.
signatureValue BIT STRING, חתימה מחושבת על tbsCertificate מקודד ASN.1 DER.

TBSCertificate SEQUENCE

שם שדה (ראה RFC 5280 ) ערך
version INTEGER 2 (פירושו אישור v3)
serialNumber שלם 1 (ערך קבוע: זהה בכל האישורים)
signature AlgorithmIdentifier של האלגוריתם המשמש לחתימה על מפתח: ECDSA עבור מפתחות EC, RSA עבור מפתחות RSA.
issuer זהה לשדה הנושא של מפתח אישור האצווה.
validity SEQUENCE של שני תאריכים, המכיל את הערכים של Tag ::ACTIVE_DATETIME ותג::USAGE_EXPIRE_DATETIME . ערכים אלה הם באלפיות שניות מאז 1 בינואר 1970. ראה RFC 5280 עבור ייצוגי תאריכים נכונים בתעודות.
אם Tag::ACTIVE_DATETIME אינו קיים, השתמש בערך של Tag::CREATION_DATETIME . אם Tag::USAGE_EXPIRE_DATETIME אינו קיים, השתמש בתאריך התפוגה של אישור מפתח אצווה.
subject CN = "מפתח חנות המפתחות של אנדרואיד" (ערך קבוע: זהה בכל האישורים)
subjectPublicKeyInfo SubjectPublicKeyInfo המכיל מפתח ציבורי מאושר.
extensions/Key Usage digitalSignature: הגדר אם למפתח יש מטרה KeyPurpose::SIGN או KeyPurpose::VERIFY . כל שאר הביטים לא מוגדרים.
extensions/CRL Distribution Points ערך TBD
extensions/"attestation" ה-OID הוא 1.3.6.1.4.1.11129.2.1.17; התוכן מוגדר בסעיף הרחבת אישור למטה. כמו בכל תוספות אישור X.509, התוכן מיוצג כ-OCTET_STRING המכיל קידוד DER של האישור 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, לפי טבלה זו:

סוג Keymaster סוג ASN.1
ENUM מספר שלם
ENUM_REP SET של INTEGER
UINT מספר שלם
UINT_REP SET של INTEGER
ULONG מספר שלם
ULONG_REP SET של INTEGER
DATE שלם (מילישניות מאז 1 בינואר 1970 00:00:00 GMT)
BOOL NULL (ב-keymaster, תג נוכח פירושו אמיתי, חסר פירושו שקר.
אותה סמנטיקה חלה על קידוד ASN.1)
BIGNUM לא בשימוש כרגע, אז לא מוגדר מיפוי
BYTES OCTET_STRING

סכֵימָה

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

שם שדה סוּג ערך
attestationVersion מספר שלם גרסה של סכימת אישור: 1, 2 או 3.
attestationSecurity רמת אבטחה רמת האבטחה של אישור זה. אפשר לקבל אישורי תוכנה של מפתחות מגובי חומרה. לא ניתן לסמוך על עדויות כאלה אם מערכת אנדרואיד נפגעת.
keymasterVersion מספר שלם גרסת התקן keymaster: 0, 1, 2, 3 או 4.
keymasterSecurity רמת אבטחה רמת האבטחה של יישום keymaster.
attestationChallenge OCTET_STRING ערך Tag::ATTESTATION_CHALLENGE , צוין לבקשת אישור.
uniqueId OCTET_STRING מזהה ייחודי אופציונלי, קיים אם למפתח יש Tag::INCLUDE_UNIQUE_ID
softwareEnforced רשימת ההרשאות אופציונלי, הרשאות keymaster שאינן נאכפות על ידי ה-TEE, אם קיימות.
teeEnforced רשימת ההרשאות אופציונלי, הרשאות Keymaster שנאכפות על ידי ה-TEE, אם קיימות.

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

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

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

שדות RootOfTrust

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

שם שדה סוּג ערך
verifiedBootKey OCTET_STRING Hash מאובטח של המפתח המשמש לאימות תמונת המערכת. מומלץ SHA-256.
deviceLocked בולאני נכון אם טוען האתחול נעול, מה שאומר שניתן להבהב רק תמונות חתומות, ושנעשה בדיקת אתחול מאומתת.
verifiedBootState VerifiedBootState מצב האתחול המאומת.
verifiedBootHash OCTET_STRING תקציר של כל הנתונים המוגנים על ידי אתחול מאומת. עבור מכשירים המשתמשים ביישום Android Verified Boot של Verified Boot, ערך זה מכיל את התקציר של מבנה VBMeta , או מבנה המטא נתונים של אתחול מאומת. למידע נוסף על אופן חישוב הערך הזה, ראה The VBMeta Digest

ערכי VerifiedBootState

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

ערך מַשְׁמָעוּת
Verified מציין שרשרת אמון מלאה המשתרעת ממטען האתחול ועד למחיצות מאומתות, כולל טוען האתחול, מחיצת האתחול וכל המחיצות המאומתות.
במצב זה, הערך verifiedBootKey הוא ה-hash של האישור המוטבע, כלומר האישור הבלתי ניתן לשינוי צרוב ב-ROM.
SelfSigned מציין שמחיצת האתחול אומתה באמצעות האישור המוטבע, והחתימה תקפה. טוען האתחול מציג אזהרה וטביעת האצבע של המפתח הציבורי לפני שהוא מאפשר לתהליך האתחול להמשיך.
במצב זה, ערך verifiedBootKey הוא ה-hash של אישור החתימה העצמית.
Unverified מציין שניתן לשנות מכשיר באופן חופשי. תקינות המכשיר נותרת למשתמש כדי לאמת מחוץ לתחום. טוען האתחול מציג אזהרה למשתמש לפני שהוא מאפשר לתהליך האתחול להמשיך.
במצב זה ערך verifiedBootKey ריק.
Failed מציין שהמכשיר נכשל באימות. אף אישור אישור לא מכיל למעשה את הערך הזה, מכיוון שבמצב זה טוען האתחול נעצר. זה כלול כאן לשלמות.

ערכי SecurityLevel

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

ערך מַשְׁמָעוּת
Software הקוד שיוצר או מנהל את האלמנט הרלוונטי (אישור או מפתח) מיושם במערכת אנדרואיד ועשוי להשתנות אם המערכת הזו נפגעת.
TrustedEnvironment הקוד שיוצר או מנהל את האלמנט הרלוונטי (אישור או מפתח) מיושם בסביבת ביצוע מהימנה (TEE). זה יכול להשתנות אם ה-TEE נפגע, אבל ה-TEE עמיד מאוד בפני פשרה מרחוק ועמיד בינוני בפני פשרה על ידי התקפת חומרה ישירה.
StrongBox הקוד שיוצר או מנהל את האלמנט הרלוונטי (אישור או מפתח) מיושם במודול אבטחת חומרה ייעודי. זה יכול להשתנות אם מודול אבטחת החומרה נפגע, אבל הוא עמיד מאוד בפני פשרה מרחוק ועמיד מאוד בפני פשרה על ידי התקפת חומרה ישירה.

מזהה ייחודי

ה-Unique ID הוא ערך של 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, ושרשרות האישורים המתאימות, מסודרים בצורה מאובטחת למכשיר.

אישור תעודת זהות

אנדרואיד 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. MEIDs של כל מכשירי הרדיו

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

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

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