कुंजी और आईडी को प्रमाणित करने की सुविधा

कीस्टोर क्रिप्टोग्राफ़िक बनाने, सेव करने, और इस्तेमाल करने के लिए ज़्यादा सुरक्षित जगह उपलब्ध कराता है मैनेज कर सकती हैं. जब हार्डवेयर-बैक्ड कुंजी का स्टोरेज उपलब्ध हो और इसका इस्तेमाल किया जाता है, तो मुख्य मटीरियल डिवाइस से निकालने से ज़्यादा सुरक्षित होता है और KeyMaster उन पाबंदियों को लागू करता है जिन्हें हटाना मुश्किल होता है.

यह केवल तभी सही होता है, जब कीस्टोर कुंजियां हार्डवेयर-बैक्ड स्टोरेज. KeyMaster 1 में, ऐप्लिकेशन या ताकि ऐसा हो रहा हो. कीस्टोर डीमन उपलब्ध कीमास्टर एचएएल को लोड किया और एचएएल ने जो भी कहा हार्डवेयर बैकिंग के संबंध में.

इसे ठीक करने के लिए, KeyMaster ने Android 7.0 (KeyMaster 2) और आईडी में मुख्य पुष्टि की सुविधा शुरू की को प्रमाणित करना होगा.

कुंजी को प्रमाणित करने की प्रक्रिया का मकसद, यह पता लगाना कि क्या एसिमेट्रिक कुंजी का जोड़ा हार्डवेयर-आधारित है, की हैं और इसके इस्तेमाल पर कौन-कौनसी पाबंदियां लागू होती हैं.

आईडी को प्रमाणित करने से डिवाइस अपने हार्डवेयर आइडेंटिफ़ायर का सबूत दे पाता है. जैसे कि सीरियल नंबर या IMEI नंबर.

कुंजी को प्रमाणित करने की प्रक्रिया

कुंजी को प्रमाणित करने की सुविधा का इस्तेमाल करने के लिए, Android 7.0 ने टैग, टाइप, और को एचएएल में बदल दिया जाता है.

टैग

• 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 तरीका

कीमास्टर 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, कीमास्टर डिवाइस स्ट्रक्चर है.
• keyToAttest, यहां से वापस मिला कुंजी ब्लॉब है generateKey जिसके लिए प्रमाणित किया जाएगा.
• attestParams, उन पैरामीटर की सूची है जो इनके लिए ज़रूरी हैं प्रमाणित करना. इसमें Tag::ATTESTATION_CHALLENGE और Tag::RESET_SINCE_ID_ROTATION का और शायद Tag::APPLICATION_ID और Tag::APPLICATION_DATA. कॉन्टेंट बनाने बाद के दो पैरामीटर, की ब्लॉब को डिक्रिप्ट करने के लिए ज़रूरी होते हैं, बशर्ते इनके बारे में बताया गया हो डेटा इकट्ठा होता रहेगा.
• certChain एक आउटपुट पैरामीटर है, जो सर्टिफ़िकेट. एंट्री 0, प्रमाणित करने का सर्टिफ़िकेट है. इसका मतलब यह है keyToAttest से कुंजी प्रमाणित करता है और इसमें प्रमाणित करने का एक्सटेंशन.

attestKey तरीके को, सार्वजनिक पासकोड से जुड़ी कार्रवाई माना जाता है प्रमाणित की गई कुंजी, क्योंकि इसे किसी भी समय कॉल किया जा सकता है और इसे पूरा करने की ज़रूरत नहीं होती अनुमति लेने से जुड़ी सीमाएं. उदाहरण के लिए, अगर प्रमाणित कुंजी के लिए उपयोगकर्ता की ज़रूरत है पुष्टि करने की सुविधा देते हैं, तो उपयोगकर्ता के बिना ही पुष्टि करने की प्रक्रिया जनरेट की जा सकती है पुष्टि करने के लिए.

प्रमाणित करने से जुड़ा सर्टिफ़िकेट

प्रमाणित करने का सर्टिफ़िकेट एक स्टैंडर्ड X.509 सर्टिफ़िकेट है, जिसमें एक वैकल्पिक सर्टिफ़िकेट भी होता है प्रमाणित करने का एक्सटेंशन, जिसमें प्रमाणित की गई कुंजी की जानकारी शामिल होती है. कॉन्टेंट बनाने सर्टिफ़िकेट पर किसी सर्टिफ़ाइड अटेस्टेशन पासकोड से हस्ताक्षर किया गया हो. प्रमाणित करने वाली कुंजी प्रमाणित की जा रही कुंजी के अलावा किसी दूसरे एल्गोरिदम का इस्तेमाल कर सकता है.

पुष्टि करने के सर्टिफ़िकेट में, नीचे दी गई टेबल के फ़ील्ड शामिल हैं. हालांकि, इनमें ये फ़ील्ड शामिल नहीं किए जा सकते अतिरिक्त फ़ील्ड शामिल नहीं करने चाहिए. कुछ फ़ील्ड में, फ़ील्ड की तय वैल्यू डाली जा सकती है. सीटीएस परीक्षणों से इस बात की पुष्टि होती है कि प्रमाणपत्र की सामग्री ठीक वैसी ही है जैसी परिभाषित की गई है.

सर्टिफ़िकेट SEQUENCE

TBSसर्टिफ़िकेट की जांच

प्रमाणित करने का एक्सटेंशन

attestation एक्सटेंशन में कीमास्टर का पूरा ब्यौरा होता है कुंजी से जुड़े प्राधिकरण, ऐसे स्ट्रक्चर में जो सीधे तौर पर मेल खाते हों को अनुमति देने वाली सूचियों में जोड़ना होगा, जैसा कि Android और कीमास्टर एचएएल में इस्तेमाल किया गया है. इसमें मौजूद हर टैग अनुमति देने वाली सूची को ASN.1 SEQUENCE के ज़रिए दिखाया जाता है साफ़ तौर पर एंट्री कीमास्टर टैग नंबर के साथ टैग किया गया है, लेकिन टाइप डिस्क्रिप्टर (चार उच्च) के साथ ऑर्डर बिट) मास्क आउट कर दिए गए हैं.

उदाहरण के लिए, कीमास्टर 3 में Tag::PURPOSE को type.hal को ENUM_REP | 1 की तरह इस्तेमाल करता है. पुष्टि करने के एक्सटेंशन के लिए, 1 टैग को छोड़कर, ENUM_REP वैल्यू को हटा दिया गया है. (कीमास्टर 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,
  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),
}

मुख्य जानकारी वाले फ़ील्ड

keymasterVersion और attestationChallenge फ़ील्ड की पहचान की जाती है टैग के बजाय क्रमिक रूप से सेट करते हैं, इसलिए एन्कोड किए गए फ़ॉर्म में टैग फ़ील्ड प्रकार. बाकी फ़ील्ड को स्कीमा चुनें.

AuthorizationList फ़ील्ड

AuthorizationList फ़ील्ड ज़रूरी नहीं हैं और उनकी पहचान कर ली गई है कीमास्टर टैग मान के अनुसार, टाइप बिट को मास्क करके निकाल दिया जाता है. एक्सप्लिसिट टैगिंग का इस्तेमाल किया जाता है, ताकि फ़ील्ड में भी एक ऐसा टैग हो जो यह बताता हो उनका ASN.1 प्रकार, आसानी से पार्स करने के लिए.

हर फ़ील्ड की वैल्यू के बारे में जानकारी पाने के लिए, KeyMaster 3 के लिए types.hal और कीमास्टर 2 और इससे पहले के वर्शन के लिए keymaster_defs.h. KeyMaster टैग के नाम KM_TAG को छोड़कर, फ़ील्ड के नामों में बदला गया प्रीफ़िक्स है और ऊंट के केस में शेष, इसलिए Tag::KEY_SIZE keySize.

RootOfTrust फ़ील्ड

RootOfTrust फ़ील्ड की पहचान, पोज़िशन के हिसाब से की जाती है.

VerifiedBootState वैल्यू

verifiedBootState की वैल्यू के ये मतलब होते हैं:

Securitylevel की वैल्यू

securityLevel की वैल्यू के ये मतलब होते हैं:

अनन्य ID

यूनीक आईडी 128-बिट की वैल्यू होती है, जो डिवाइस की पहचान करती है. हालांकि, सीमित समय के लिए. वैल्यू का हिसाब इस तरह से लगाया जाता है:

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

कहाँ:

• T "अस्थायी काउंटर वैल्यू" है. इसकी गिनती Tag::CREATION_DATETIME का मान 2592000000 से कम हो गया है शेष. T हर 30 दिन में बदलता है (25,92000000 = 30 * 24 * 60 * 60 * 1,000).
• C, Tag::APPLICATION_ID का मान है
• अगर Tag::RESET_SINCE_ID_ROTATION है, तो R की वैल्यू 1 होगी atest_key कॉल में attest_params पैरामीटर मौजूद है या 0 है, अगर टैग मौजूद नहीं है.
• HBK एक अनोखा हार्डवेयर-आधारित सीक्रेट है, जो भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट और इसके ज़रिए कभी भी ज़ाहिर न किया गया हो. सीक्रेट में कम से कम एंट्रॉपी के 128 बिट और हर डिवाइस के लिए खास (संभावित रूप से) एंट्रॉपी के 128 बिट के आधार पर, खासियत स्वीकार की जाती है). एचबीके को यह होना चाहिए जिसे HMAC या AES_CMAC के ज़रिए फ़्यूज़्ड की मटीरियल से लिया गया है.

HMAC_SHA256 आउटपुट को 128 बिट तक छोटा करें.

प्रमाणित करने वाली कुंजियां और सर्टिफ़िकेट

दो कुंजियां, एक आरएसए और एक ईसीडीएसए, और इससे जुड़ी सर्टिफ़िकेट चेन डिवाइस में सुरक्षित रूप से प्रावधान किया जा सकता है.

Android 12 में, रिमोट की प्रॉविज़निंग की सुविधा लॉन्च की गई है. साथ ही, Android 13 के लिए डिवाइसों की ज़रूरत है उसे लागू करें. रिमोट कुंजी के प्रावधान की मदद से, फ़ील्ड में वे डिवाइस उपलब्ध होते हैं जिनमें हर आवेदन के लिए, ECDSA P256 की पुष्टि करने का सर्टिफ़िकेट. ये सर्टिफ़िकेट सर्टिफ़िकेट, फ़ैक्ट्री में प्रावधान किए गए सर्टिफ़िकेट से कम समय के लिए होता है.

एक से ज़्यादा IMEI नंबर

Android 14 के साथ कई IMEIs का इस्तेमाल किया जा सकता है Android पर कुंजी को प्रमाणित करने से जुड़ा रिकॉर्ड. OEM, किसी दूसरे IMEI नंबर के लिए KeyMint टैग जोड़कर इस सुविधा को लागू कर सकते हैं. डिवाइसों में एक से ज़्यादा सेल्युलर रेडियो होना बहुत आम बात होती जा रही है और OEM अब दो IMEI वाले डिवाइसों पर काम कर सकते हैं.

अगर OEMs के डिवाइसों में दूसरा IMEI नंबर मौजूद होता है, तो उसे KeyMint को लागू करने की प्रक्रिया के लिए प्रावधान किया गया है, ताकि उन तरीकों से लागू किया जा सके इसे प्रमाणित करने के लिए उसी तरह से प्रमाणित करते हैं जिस तरह वे पहले IMEI के मुताबिक प्रमाणित करते हैं

आईडी की पुष्टि करना

Android 8.0 में, आईडी की पुष्टि करने की सुविधा वाले डिवाइसों के लिए वैकल्पिक सहायता शामिल है कीमास्टर 3. आईडी को प्रमाणित करने से डिवाइस को अपने हार्डवेयर का सबूत देने की अनुमति मिलती है आइडेंटिफ़ायर, जैसे कि सीरियल नंबर या IMEI नंबर. यह एक वैकल्पिक सुविधा है, लेकिन यह हम इसकी सलाह देते हैं कि सभी KeyMaster 3 कार्यान्वयन इसके समर्थन के साथ काम करते हैं क्योंकि डिवाइस की पहचान को साबित कर पाने से, इस तरह के इस्तेमाल के उदाहरण ज़ीरो-टच रिमोट कॉन्फ़िगरेशन को ज़्यादा सुरक्षित बनाने के लिए, क्योंकि रिमोट साइड पक्का कर लें कि यह सही डिवाइस से बात कर रहा है, न कि डिवाइस अपने पहचान).

आईडी की पुष्टि करने की प्रोसेस, डिवाइस के हार्डवेयर आइडेंटिफ़ायर की कॉपी बनाकर काम करती है जिसे डिवाइस से पहले सिर्फ़ ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) ऐक्सेस कर सकता है कार से बाहर चला जाता है. उपयोगकर्ता, डिवाइस के बूटलोडर को अनलॉक कर सकता है और Android फ़्रेमवर्क के ज़रिए रिपोर्ट किए गए आइडेंटिफ़ायर और सिस्टम सॉफ़्टवेयर के बारे में भी बताया गया है. कॉन्टेंट बनाने TEE के पास मौजूद आइडेंटिफ़ायर की कॉपी में इस तरह से छेड़छाड़ नहीं की जा सकती, पक्का करना कि डिवाइस आईडी से प्रमाणित करने की सुविधा कभी भी डिवाइस के इससे ओरिजनल हार्डवेयर आइडेंटिफ़ायर, झूठे नाम से मेल भेजने की कोशिशों को रोकते हैं.

आईडी की पुष्टि करने के लिए मुख्य एपीआई प्लैटफ़ॉर्म, मौजूदा पासकोड के ऊपर बनता है कीमास्टर 2 के साथ प्रमाणित करने की प्रक्रिया शुरू की गई. किसी कीमास्टर के पास रखी कुंजी के लिए प्रमाणित करने का प्रमाणपत्र, कॉलर अनुरोध कर सकता है पुष्टि करने की प्रक्रिया में डिवाइस के हार्डवेयर आइडेंटिफ़ायर को शामिल किया जाना चाहिए सर्टिफ़िकेट का मेटाडेटा. अगर टीईई में कुंजी रखी जाती है, तो सर्टिफ़िकेट एक जानी-पहचानी भरोसे की बुनियाद तैयार करना. इस तरह के प्रमाणपत्र का प्राप्तकर्ता यह कर सकता है: पुष्टि करें कि सर्टिफ़िकेट, उसमें मौजूद कॉन्टेंट, और हार्डवेयर जिन्हें टीईई ने लिखा है. जब हार्डवेयर शामिल करने के लिए कहा जाए को प्रमाणित करता है, तो TEE आइडेंटिफ़ायर के बारे में जानकारी होती है. ये आइडेंटिफ़ायर, डिवाइस के स्टोरेज में मौजूद होते हैं. ये आइडेंटिफ़ायर, फ़ैक्ट्री फ़्लोर पर मौजूद होते हैं.

स्टोरेज प्रॉपर्टी

डिवाइस के आइडेंटिफ़ायर को सेव करने वाले स्टोरेज में ये प्रॉपर्टी होनी चाहिए:

• डिवाइस के ओरिजनल आइडेंटिफ़ायर से मिली वैल्यू को डिवाइस के बाहर निकलने से पहले का स्टोरेज.
• destroyAttestationIds() तरीका हमेशा के लिए बंद कर सकता है आइडेंटिफ़ायर से मिले डेटा की यह कॉपी. हमेशा के लिए नष्ट होने का मतलब है कि डेटा पूरी तरह से हटा दिया जाता है, इसलिए न तो फ़ैक्ट्री रीसेट किया जाता है और न ही कोई डिवाइस पर की गई प्रक्रिया से उसे वापस लाया जा सकता है. यह खास तौर पर यह उन डिवाइस के लिए ज़रूरी है जिनमें उपयोगकर्ता ने बूटलोडर को अनलॉक किया हो और बदल दिया हो सिस्टम के सॉफ़्टवेयर को बदल दिया और Android से लौटाए गए आइडेंटिफ़ायर में बदलाव किया फ़्रेमवर्क शामिल हैं.
• आरएमए सुविधाओं में ये सुविधाएं होनी चाहिए हार्डवेयर आइडेंटिफ़ायर से मिले डेटा की नई कॉपी जनरेट करनी होंगी. इस तरह, किसी आरएमए की मदद से पास होने वाले डिवाइस, आईडी की पुष्टि फिर से कर सकते हैं. कॉन्टेंट बनाने आरएमए सुविधाओं के लिए इस्तेमाल होने वाले तरीके सुरक्षित होने चाहिए, ताकि उपयोगकर्ता खुद इस्तेमाल करना शुरू कर सकते हैं, जिससे वे खुद से प्रमाण पत्र पाने के लिए नकली आईडी.
• TEE में मौजूद KeyMaster के भरोसेमंद ऐप्लिकेशन के अलावा कोई भी कोड, आइडेंटिफ़ायर से हासिल किया गया डेटा, जो स्टोरेज में रखा जाता है.
• स्टोरेज से छेड़छाड़ की गई है: अगर स्टोरेज का कॉन्टेंट टीईई इसे ठीक वैसे ही मानता है जैसे कॉन्टेंट की कॉपी में को नष्ट कर दिया गया है और यह आईडी प्रमाणित करने के सभी तरीकों को अस्वीकार कर देता है. यह लागू किया गया है स्टोरेज को नीचे बताया गया है.
• स्टोरेज में ओरिजनल आइडेंटिफ़ायर मौजूद नहीं होते हैं. आईडी की पुष्टि करने की वजह से में एक चैलेंज शामिल होता है. कॉलर हमेशा प्रमाणित किया गया. टीईई को सिर्फ़ इस बात की पुष्टि करनी है कि ये दोनों हमारे पास पहले से ही है. अपने-आप जनरेट होने वाले मैसेज के बजाय, ओरिजनल वैल्यू के सुरक्षित हैश सेव करना वैल्यू इस पुष्टि को चालू करती हैं.

निर्माण

ऊपर दी गई प्रॉपर्टी वाला कोई तरीका लागू करने के लिए, नीचे दिए गए 'एस' कंस्ट्रक्शन में आईडी से ली गई वैल्यू. इसकी अन्य प्रतियाँ संग्रहित न करें सिस्टम में उन सामान्य स्थानों को छोड़कर, जिन्हें डिवाइस का मालिक रूट करके संशोधित कर सकता है:

S = D || HMAC(HBK, D)

कहां:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC एक एचएमएसी कंस्ट्रक्शन है, जिसमें सही सुरक्षित हैश शामिल है (SHA-256 सुझाया गया)
• HBK, हार्डवेयर वाली एक कुंजी है. इसे किसी दूसरे काम के लिए इस्तेमाल नहीं किया जाता
• ID1...IDn, ओरिजनल आईडी की वैल्यू हैं; इसका असोसिएशन किसी खास इंडेक्स के लिए खास वैल्यू, लागू करने पर निर्भर करती है, क्योंकि अलग-अलग डिवाइसों में आइडेंटिफ़ायर की संख्या अलग-अलग होगी
• || से कोड जोड़ने की प्रोसेस का पता चलता है

एचएमएसी आउटपुट का साइज़ तय होने की वजह से, कोई हेडर या अन्य स्ट्रक्चर नहीं होता अलग-अलग आईडी हैश या D के एचएमएसी को ढूंढने की ज़रूरत होती है. इसके अलावा प्रमाणित करने के लिए, दी गई वैल्यू की जांच करनी होगी. लागू करने के लिए ज़रूरी है कि S को S से D एक्सट्रैक्ट करके, HMAC(HBK, D) की गिनती करके, S की पुष्टि करें. इसके बाद, S में मान है, ताकि यह पुष्टि की जा सके कि किसी भी व्यक्तिगत आईडी में बदलाव नहीं किया गया है या उसे खराब नहीं किया गया है. साथ ही, लागू करने के लिए, सभी अलग-अलग आईडी के लिए, लगातार तुलना करने की सुविधा का इस्तेमाल करना चाहिए एलिमेंट और एस. तुलना समय स्थिर होना चाहिए, भले ही दिए गए आईडी की संख्या और परीक्षण के किसी भी हिस्से का सही मिलान.

हार्डवेयर आइडेंटिफ़ायर

आईडी की पुष्टि करने की सुविधा, इन हार्डवेयर आइडेंटिफ़ायर के साथ काम करती है:

1. ब्रैंड का नाम, जैसा कि Android में Build.BRAND से मिला है
2. डिवाइस का नाम, जैसा कि Android में Build.DEVICE ने लौटाया है
3. प्रॉडक्ट का नाम, जैसा कि Android में Build.PRODUCT ने लौटाया है
4. मैन्युफ़ैक्चरर का नाम, जो Android में Build.MANUFACTURER से मिला है
5. मॉडल का नाम, जैसा कि Android में Build.MODEL ने दिखाया है
6. सीरियल नंबर
7. सभी रेडियो के IMEI नंबर
8. सभी रेडियो के MEID

डिवाइस आईडी की पुष्टि करने के लिए, कोई डिवाइस इन आइडेंटिफ़ायर को प्रमाणित करता है. सभी Android डिवाइसों पर चलने वाले डिवाइसों के शुरुआती छह वर्शन होते हैं और इस काम के लिए ये ज़रूरी हैं सुविधा मिलती है. अगर डिवाइस में कोई इंटिग्रेट किया हुआ सेल्युलर रेडियो है, तो डिवाइस यह भी ज़रूरी है कि रेडियो के IMEIs और/या 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 पर काम नहीं करते.

अगर डिवाइस आईडी प्रमाणित करने की सुविधा देता है और ऊपर दिए गए एक या एक से ज़्यादा टैग में को प्रमाणित करने के अनुरोध में शामिल किया गया है, तो टीईई, आइडेंटिफ़ायर की पुष्टि करता है हर टैग के साथ दी गई जानकारी, हार्डवेयर आइडेंटिफ़ायर की कॉपी से मेल खाती है. अगर आपने एक या ज़्यादा आइडेंटिफ़ायर मेल नहीं खाते, तो पूरा प्रमाणित नहीं किया जाता ErrorCode::CANNOT_ATTEST_IDS. यह उसी टैग के लिए मान्य है, कई बार दी गई है. उदाहरण के लिए, IMEI को प्रमाणित करते समय यह तरीका काम का हो सकता है: किसी डिवाइस में कई IMEI वाले कई रेडियो हो सकते हैं. प्रमाणित करने का अनुरोध है अगर हर ATTESTATION_ID_IMEI के लिए दी गई वैल्यू मेल खाती है, तो मान्य है डिवाइस के किसी रेडियो स्टेशन का इस्तेमाल करें. यही बात अन्य सभी टैग पर भी लागू होती है.

अगर प्रमाणित किया जाता है, तो प्रमाणित आईडी अटेस्टेशन एक्सटेंशन जारी किए गए प्रमाणित करने के सर्टिफ़िकेट का (OID 1.3.6.1.4.1.11129.2.1.17), ऊपर दिए गए स्कीमा का इस्तेमाल करके. कीमास्टर 2 के बदलाव प्रमाणित करने का स्कीमा, टिप्पणियों के साथ बोल्ड किया हुआ होता है.

Java API

यह सेक्शन सिर्फ़ जानकारी के लिए है. इनमें से कोई भी मुख्य-मास्टर लागू करने वाला नहीं है 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].