इस पेज का अनुवाद Cloud Translation API से किया गया है.

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

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

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

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

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

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

ध्यान दें: KeyMaster 3 के ट्रांज़िशन की मदद करने के लिए पुरानी शैली के सी-स्ट्रक्चर एचएएल से लेकर C++ HAL इंटरफ़ेस तक, एक परिभाषा से जनरेट हुए हैं हार्डवेयर इंटरफ़ेस डेफ़िनिशन लैंग्वेज (HIDL), टैग और मेथड के नामों में Android 8.0 में बदल गई हैं. अन्य सभी कीमास्टर ईनम की तरह, अब टैग भी हो गए हैं को C++ स्कोप वाले Enum के तौर पर परिभाषित किया जा सकता है. उदाहरण के लिए, टैग, जिनके नाम से पहले KM_TAG_ के आगे अब Tag:: लगा दिया गया है और तरीके ऐसा माना जाता है. यहां दिए गए उदाहरणों में, कीमास्टर 3 शब्दों का इस्तेमाल किया गया है. हालांकि, ऐसा तब तक नहीं होगा, जब तक इसके लिए निर्देश न दिए जाएं अगर ऐसा नहीं है.

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

कुंजी को प्रमाणित करने की सुविधा का इस्तेमाल करने के लिए, 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

फ़ील्ड का नाम (देखें आरएफ़सी 5280)	वैल्यू
tbsसर्टिफ़िकेट	TBSसर्टिफ़िकेट का क्रम
सिग्नेचर एल्गोरिदम	साइन इन कुंजी के लिए इस्तेमाल किए जाने वाले एल्गोरिदम का AlgorithmIdentifier: EC कुंजियों के लिए ECDSA, आरएसए कुंजियों के लिए आरएसए.
signatureValue	बीआईटी स्ट्रिंग, हस्ताक्षर को ASN.1 DER-एन्कोड किए गए tbsCertificate पर पूरा किया गया है.

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

फ़ील्ड का नाम (देखें आरएफ़सी 5280)	वैल्यू
`version`	पूर्णांक 2 (मतलब v3 प्रमाणपत्र)
`serialNumber`	पूर्णांक 1 (तय वैल्यू: सभी सर्टिफ़िकेट के लिए एक जैसी)
`signature`	साइन कुंजी के लिए इस्तेमाल किए जाने वाले एल्गोरिदम का AlgorithmIdentifier: EC कुंजियों के लिए ECDSA, आरएसए कुंजियों के लिए आरएसए.
`issuer`	बैच अटेस्टेशन कुंजी के विषय फ़ील्ड की तरह ही.
`validity`	दो तारीखों का क्रम, जिसमें टैग::ACTIVE_DATETIME और टैग::USAGE_EXPIRE_DATETIME. ये वैल्यू 1 जनवरी, 1970 से मिलीसेकंड में हैं. सही जानकारी के लिए आरएफ़सी 5280 देखें सर्टिफ़िकेट में तारीख दिखाना. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है अगर `Tag::ACTIVE_DATETIME` मौजूद नहीं है, तो `Tag::CREATION_DATETIME`. अगर आपने `Tag::USAGE_EXPIRE_DATETIME` मौजूद नहीं है, खत्म होने की तारीख इस्तेमाल करें बैच अटेस्टेशन कुंजी सर्टिफ़िकेट की तारीख.
`subject`	CN = "Android कीस्टोर कुंजी" (तय वैल्यू: सभी सर्टिफ़िकेट पर एक जैसी)
`subjectPublicKeyInfo`	SubjectPublicKeyInfo में प्रमाणित सार्वजनिक कुंजी है.
`extensions/Key Usage`	डिजिटल हस्ताक्षर: अगर कुंजी का मकसद `KeyPurpose::SIGN` है, तो यह सेट करें या `KeyPurpose::VERIFY`. अन्य सभी बिट सेट नहीं की गई हैं.
`extensions/CRL Distribution Points`	मान अभी तय नहीं है
`extensions/"attestation"`	ओआईडी, 1.3.6.1.4.1.11129.2.1.17 है; तो कॉन्टेंट के बारे में यहां बताया गया है नीचे, अटेस्टेशन एक्सटेंशन सेक्शन दिया गया है. सभी के साथ X.509 प्रमाणपत्र एक्सटेंशन, सामग्री को OCTET_STRING के रूप में दिखाया जाता है इसमें प्रमाणित करने के SEQUENCE की DER एन्कोडिंग शामिल है.

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

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 प्रकार
`ENUM`	पूर्णांक
`ENUM_REP`	पूर्णांक का सेट
`UINT`	पूर्णांक
`UINT_REP`	पूर्णांक का सेट
`ULONG`	पूर्णांक
`ULONG_REP`	पूर्णांक का सेट
`DATE`	INTEGER (1 जनवरी, 1970 से 00:00:00 GMT से मिलीसेकंड)
`BOOL`	शून्य (कीमास्टर में, टैग वर्तमान का मतलब सही है, मौजूद नहीं का मतलब गलत है. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यही सिमेंटिक्स ASN.1 एन्कोडिंग पर लागू होता है)
`BIGNUM`	फ़िलहाल इसका इस्तेमाल नहीं किया गया है, इसलिए कोई मैपिंग तय नहीं की गई है
`BYTES`	अक्टूबर

ध्यान दें: कुछ टैग स्कीमा से हटा दिए जाते हैं और को प्रमाणित करने की प्रक्रिया में शामिल नहीं किया जाना चाहिए. उदाहरण के लिए, Tag::USER_ID और Tag::SECURE_USER_ID का कोई मतलब नहीं है और Tag::MIN_MAC_LENGTH और एसिमेट्रिक कुंजियों के साथ Tag::CALLER_NONCE काम का नहीं है.

स् कीमा

पुष्टि करने के एक्सटेंशन के कॉन्टेंट के बारे में, यहां दिए गए 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 फ़ील्ड की पहचान की जाती है टैग के बजाय क्रमिक रूप से सेट करते हैं, इसलिए एन्कोड किए गए फ़ॉर्म में टैग फ़ील्ड प्रकार. बाकी फ़ील्ड को स्कीमा चुनें.

फ़ील्ड का नाम	टाइप	वैल्यू
`attestationVersion`	पूर्णांक	पुष्टि करने के स्कीमा का वर्शन: 1, 2 या 3.
`attestationSecurity`	सुरक्षा का स्तर	इस प्रमाणित करने का सुरक्षा स्तर. कोई सॉफ़्टवेयर डाउनलोड किया जा सकता है, हार्डवेयर-बैक्ड कुंजियों को प्रमाणित करना. ऐसे प्रमाणित किए जाने पर भरोसा नहीं किया जा सकता, अगर Android सिस्टम के साथ छेड़छाड़ की गई है.
`keymasterVersion`	पूर्णांक	कीमास्टर डिवाइस का वर्शन: 0, 1, 2, 3 या 4.
`keymasterSecurity`	सुरक्षा का स्तर	कीमास्टर लागू करने का सुरक्षा का स्तर.
`attestationChallenge`	अक्टूबर	`Tag::ATTESTATION_CHALLENGE` की वैल्यू, जिसे प्रमाणित करने के अनुरोध के लिए तय किया गया है.
`uniqueId`	अक्टूबर	वैकल्पिक यूनीक आईडी, अगर कुंजी में है, तो यह मौजूद है `Tag::INCLUDE_UNIQUE_ID` अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है
`softwareEnforced`	अनुमति सूची	यह ज़रूरी नहीं है कि कीमास्टर से मिलने वाली अनुमतियां, जिन्हें टीईई ने लागू नहीं किया है, अगर कोई भी.
`teeEnforced`	अनुमति सूची	ज़रूरी नहीं, अगर टीईई की ओर से लागू किया जाता है, तो कीमास्टर से मिलने वाली अनुमतियां.

AuthorizationList फ़ील्ड

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

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

RootOfTrust फ़ील्ड

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

फ़ील्ड का नाम	टाइप	वैल्यू
`verifiedBootKey`	अक्टूबर	सिस्टम इमेज की पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी का सुरक्षित हैश. SHA-256 सुझाया गया.
`deviceLocked`	बूलियन	अगर बूटलोडर लॉक हो, तो 'सही' का मतलब है कि सिर्फ़ साइन की हुई इमेज ही फ़्लैश किया जाएगा और यह कि पुष्टि किए गए बूट की जांच हो गई है.
`verifiedBootState`	वेरिफ़ाइडबूटस्टेट	पुष्टि किए गए बूट की स्थिति.
`verifiedBootHash`	अक्टूबर	वेरिफ़ाइड बूट की सुविधा का इस्तेमाल करके सुरक्षित किए गए पूरे डेटा का डाइजेस्ट. इस्तेमाल करने वाले डिवाइसों के लिए वेरिफ़ाइड बूट की सुविधा को Android वेरिफ़ाइड बूट की सुविधा के तहत लागू किया गया है, जो इसमें VBMeta निर्देश या वेरिफ़ाइड बूट का डाइजेस्ट शामिल होता है मेटाडेटा स्ट्रक्चर. इस मान की गणना करने के तरीके के बारे में ज़्यादा जानने के लिए, यह देखें VBMeta डाइजेस्ट

VerifiedBootState वैल्यू

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

वैल्यू	मतलब
`Verified`	इससे पता चलता है कि बूटलोडर से पुष्टि किए गए तक पूरी तरह से भरोसेमंद नेटवर्क लागू होता है पार्टिशन, जिसमें बूटलोडर, बूट पार्टिशन, और पुष्टि किए गए सभी हिस्से शामिल हैं विभाजन. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस स्थिति में, `verifiedBootKey` वैल्यू, एम्बेड की गई प्रॉपर्टी का हैश होता है सर्टिफ़िकेट, जिसका मतलब है कि ROM में जलाया गया न बदला जा सकने वाला सर्टिफ़िकेट. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यह स्थिति हरे बूट स्थिति से मेल खाती है, जैसा कि पुष्टि किए गए बूट फ़्लो दस्तावेज़.
`SelfSigned`	इससे पता चलता है कि बूट पार्टिशन की पुष्टि एम्बेड किए गए वर्शन का इस्तेमाल करके की गई है की पुष्टि करनी होती है और हस्ताक्षर मान्य होता है. बूटलोडर पर एक चेतावनी और सार्वजनिक कुंजी के फ़िंगरप्रिंट को पहचान सकें. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस स्थिति में, `verifiedBootKey` वैल्यू खुद हस्ताक्षर करने वाले व्यक्ति का हैश होता है प्रमाणपत्र. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यह स्थिति पीले रंग की बूट स्थिति से मेल खाती है, जैसा कि पुष्टि किए गए बूट फ़्लो दस्तावेज़.
`Unverified`	इससे पता चलता है कि किसी डिवाइस में आसानी से बदलाव किया जा सकता है. डिवाइस इंटिग्रिटी की सुविधा चालू है उपयोगकर्ता को आउट-ऑफ़-बैंड की पुष्टि करनी होगी. बूटलोडर, उपयोगकर्ता को एक चेतावनी दिखाता है बूट प्रोसेस को जारी रखने की अनुमति देने से पहले. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है इस स्थिति में `verifiedBootKey` की वैल्यू नहीं दी जाती है. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यह स्थिति नारंगी बूट स्थिति से मेल खाती है, जैसा कि पुष्टि किए गए बूट फ़्लो दस्तावेज़.
`Failed`	इससे पता चलता है कि डिवाइस की पुष्टि नहीं हो सकी. प्रमाणित करने का कोई सर्टिफ़िकेट नहीं है असल में यह वैल्यू शामिल होती है, क्योंकि इस स्थिति में बूटलोडर रुक जाता है. यह समय है पूरा होने के लिए यहां शामिल किया गया है. अभी तक किसी भी व्यक्ति ने चेक इन नहीं किया है यह स्थिति लाल बूट स्थिति से मेल खाती है, जैसा कि पुष्टि किए गए बूट फ़्लो दस्तावेज़.

Securitylevel की वैल्यू

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

वैल्यू	मतलब
`Software`	वह कोड जो प्रासंगिक एलीमेंट को बनाता या प्रबंधित करता है (प्रमाणित या कुंजी) को Android सिस्टम में लागू किया जाता है और उसे बदला जा सकता है, अगर वह सिस्टम डिवाइस हैक हो गया है.
`TrustedEnvironment`	वह कोड जो प्रासंगिक एलीमेंट को बनाता या प्रबंधित करता है (प्रमाणित या कुंजी) को ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (TEE) में लागू किया जाता है. यह काम किया जा सकता है अगर TEE को हैक किया जाता है, लेकिन TEE में बदलाव होता है, तो वह डायरेक्ट हार्डवेयर अटैक से समझौता करने के लिए, और थोड़े-थोड़े प्रतिरोधक क्षमता के साथ.
`StrongBox`	वह कोड जो प्रासंगिक एलीमेंट को बनाता या प्रबंधित करता है (प्रमाणित या कुंजी) को एक खास हार्डवेयर सुरक्षा मॉड्यूल में लागू किया गया है. यह काम किया जा सकता है हार्डवेयर सुरक्षा मॉड्यूल के साथ छेड़छाड़ किए जाने की स्थिति में बदलाव किया जाता है, लेकिन यह बहुत दूर से समझौता करने के लिए प्रतिरोधक और प्रत्यक्ष रूप से समझौता करने के लिए बहुत ज़्यादा प्रतिरोध हार्डवेयर अटैक.

अनन्य 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, ID₁) || HMAC(HBK, ID₂) || ... || HMAC(HBK, ID_n)
HMAC एक एचएमएसी कंस्ट्रक्शन है, जिसमें सही सुरक्षित हैश शामिल है (SHA-256 सुझाया गया)
HBK, हार्डवेयर वाली एक कुंजी है. इसे किसी दूसरे काम के लिए इस्तेमाल नहीं किया जाता
ID₁...ID_n, ओरिजनल आईडी की वैल्यू हैं; इसका असोसिएशन किसी खास इंडेक्स के लिए खास वैल्यू, लागू करने पर निर्भर करती है, क्योंकि अलग-अलग डिवाइसों में आइडेंटिफ़ायर की संख्या अलग-अलग होगी
|| से कोड जोड़ने की प्रोसेस का पता चलता है

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

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

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

ब्रैंड का नाम, जैसा कि Android में Build.BRAND से मिला है
डिवाइस का नाम, जैसा कि Android में Build.DEVICE ने लौटाया है
प्रॉडक्ट का नाम, जैसा कि Android में Build.PRODUCT ने लौटाया है
मैन्युफ़ैक्चरर का नाम, जो Android में Build.MANUFACTURER से मिला है
मॉडल का नाम, जैसा कि Android में Build.MODEL ने दिखाया है
सीरियल नंबर
सभी रेडियो के IMEI नंबर
सभी रेडियो के 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 लागू नहीं करना चाहिए. इसके ज़रिए, लागू करने वालों को यह समझने में मदद मिलती है कि ऐप्लिकेशन इस सुविधा का इस्तेमाल कैसे करते हैं. सिस्टम के कॉम्पोनेंट इसका इस्तेमाल कर सकते हैं इसलिए, यह ज़रूरी है कि इस सेक्शन को स्टैंडर्ड न माना जाए.

ऐप्लिकेशन डेवलपर, पुष्टि करने की प्रक्रिया का इस्तेमाल कैसे करते हैं

कुंजी जनरेट करने का अनुरोध बनाता है, जिसमें कुंजी उपनाम और कुंजी जनरेशन तय होता है EC या आरएसए कुंजी के जोड़े के लिए पैरामीटर.
"अटेस्टेशन चैलेंज" सेट किया जाता है अनुरोध करने के लिए KeyPairGenerator.setAttestationChallenge(byte[]). चैलेंज देने वाला है इससे पता चलता है कि पुष्टि करने का अनुरोध किया गया है. यह वैल्यू, पुष्टि करने वाली सेवा की ओर से दी जानी चाहिए. साथ ही, इसका इस्तेमाल यह पुष्टि करने के लिए किया जाना चाहिए कि प्रमाणित करने का सर्टिफ़िकेट दिए गए अनुरोध से मेल खाता है. मान कम से कम होना चाहिए 16 बाइट और नॉन्स भी होना चाहिए. अगर किसी चैलेंज का दोबारा इस्तेमाल किया जाता है, तो हो सकता है कि पुरानी पुष्टि करने के सर्टिफ़िकेट को फिर से चलाने पर जोखिम हो.
कुंजी का जोड़ा जनरेट करता है.
AndroidKeyStore से सर्टिफ़िकेट चेन का अनुरोध करता है. पहला पुष्टि करना ही चेन में सर्टिफ़िकेट है; तो अन्य सर्टिफ़िकेट रूट प्रमाणित करने की कुंजी और फिर से भरोसेमंद होने की चेन.

इस उदाहरण में कुंजी का जोड़ा जनरेट किया गया है और पुष्टि करने का अनुरोध किया गया है.

// 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].