कुंजी और आईडी सत्यापन

संग्रह की मदद से व्यवस्थित रहें अपनी प्राथमिकताओं के आधार पर, कॉन्टेंट को सेव करें और कैटगरी में बांटें.

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

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

इसका समाधान करने के लिए, कीमास्टर ने Android 7.0 (कीमास्टर 2) मेंकुंजी सत्यापन और Android 8.0 (कीमास्टर 3) में आईडी सत्यापन पेश किया।

कुंजी प्रमाणन का उद्देश्य दृढ़ता से यह निर्धारित करने का एक तरीका प्रदान करना है कि क्या असममित कुंजी जोड़ी हार्डवेयर-समर्थित है, कुंजी के गुण क्या हैं, और इसके उपयोग के लिए कौन सी बाधाएं लागू होती हैं।

आईडी प्रमाणन डिवाइस को उसके हार्डवेयर पहचानकर्ताओं, जैसे सीरियल नंबर या IMEI का प्रमाण प्रदान करने की अनुमति देता है।

कुंजी प्रमाणन

मुख्य प्रमाणीकरण का समर्थन करने के लिए, एंड्रॉइड 7.1 ने एचएएल को टैग, प्रकार और विधि का एक सेट पेश किया।

टैग

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

टाइप

कीमास्टर 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);

कीमास्टर 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 :: ATTESTATION_CHALLENGE और संभवतः Tag::RESET_SINCE_ID_ROTATION , साथ ही Tag::APPLICATION_ID और Tag::APPLICATION_DATA शामिल हैं। कुंजी जनरेशन के दौरान निर्दिष्ट किए जाने पर बाद वाले दो कुंजी ब्लॉब को डिक्रिप्ट करने के लिए आवश्यक हैं।
  • certChain आउटपुट पैरामीटर है, जो प्रमाणपत्रों की एक सरणी देता है। प्रविष्टि 0 सत्यापन प्रमाणपत्र है, जिसका अर्थ है कि यह keyToAttest से कुंजी को प्रमाणित करता है और इसमें सत्यापन विस्तार शामिल है।

attestKey पद्धति को प्रमाणित कुंजी पर एक सार्वजनिक कुंजी ऑपरेशन माना जाता है, क्योंकि इसे किसी भी समय कॉल किया जा सकता है और प्राधिकरण बाधाओं को पूरा करने की आवश्यकता नहीं है। उदाहरण के लिए, यदि प्रमाणित कुंजी को उपयोग के लिए उपयोगकर्ता प्रमाणीकरण की आवश्यकता होती है, तो उपयोगकर्ता प्रमाणीकरण के बिना प्रमाणीकरण उत्पन्न किया जा सकता है।

सत्यापन प्रमाण पत्र

अनुप्रमाणन प्रमाणपत्र एक मानक X.509 प्रमाणपत्र है, जिसमें एक वैकल्पिक अनुप्रमाणन विस्तार होता है जिसमें अनुप्रमाणित कुंजी का विवरण होता है। प्रमाणपत्र को फ़ैक्टरी-प्रावधान प्रमाणन कुंजी के साथ हस्ताक्षरित किया गया है जो प्रमाणित की जा रही कुंजी के समान एल्गोरिथम का उपयोग करता है (RSA के लिए RSA, EC के लिए EC)।

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

प्रमाणपत्र अनुक्रम

फ़ील्ड का नाम ( RFC 5280 देखें) मूल्य
tbsCertificate टीबीएस सर्टिफिकेट सीक्वेंस
हस्ताक्षरएल्गोरिदम एल्गोरिथ्म का एल्गोरिथम पहचानकर्ता कुंजी पर हस्ताक्षर करने के लिए प्रयोग किया जाता है:
ईसी कुंजी के लिए ईसीडीएसए, आरएसए कुंजी के लिए आरएसए।
सिग्नेचरवैल्यू BIT STRING, ASN.1 DER- एन्कोडेड tbsCertificate पर हस्ताक्षर की गणना।

टीबीएस सर्टिफिकेट सीक्वेंस

फ़ील्ड का नाम ( RFC 5280 देखें) मूल्य
version पूर्णांक 2 (मतलब v3 प्रमाणपत्र)
serialNumber पूर्णांक 1 (निश्चित मान: सभी प्रमाणपत्रों पर समान)
signature कुंजी पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले एल्गोरिथम का एल्गोरिदम पहचानकर्ता: ईसी कुंजी के लिए ईसीडीएसए, आरएसए कुंजी के लिए आरएसए।
issuer बैच प्रमाणन कुंजी के विषय क्षेत्र के समान।
validity दो तारीखों का अनुक्रम, जिसमें टैग::ACTIVE_DATETIME और टैग::USAGE_EXPIRE_DATETIME के ​​मान हैं। वे मान 1 जनवरी, 1970 से मिलीसेकंड में हैं। प्रमाणपत्रों में सही दिनांक प्रतिनिधित्व के लिए RFC 5280 देखें।
यदि Tag::ACTIVE_DATETIME मौजूद नहीं है, तो Tag::CREATION_DATETIME के ​​मान का उपयोग करें। यदि Tag::USAGE_EXPIRE_DATETIME मौजूद नहीं है, तो बैच प्रमाणन कुंजी प्रमाणपत्र की समाप्ति तिथि का उपयोग करें।
subject सीएन = "एंड्रॉइड कीस्टोर कुंजी" (निश्चित मूल्य: सभी प्रमाणपत्रों पर समान)
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 विस्तार में कुंजी से जुड़े कीमास्टर प्राधिकरणों का पूरा विवरण होता है, एक संरचना में जो एंड्रॉइड और कीमास्टर एचएएल में उपयोग की जाने वाली प्राधिकरण सूचियों से सीधे मेल खाता है। प्राधिकरण सूची में प्रत्येक टैग को ASN.1 SEQUENCE प्रविष्टि द्वारा दर्शाया जाता है, स्पष्ट रूप से कीमास्टर टैग संख्या के साथ टैग किया जाता है, लेकिन टाइप डिस्क्रिप्टर (चार उच्च क्रम बिट्स) के साथ नकाबपोश होता है।

उदाहरण के लिए, कीमास्टर 3 में, Tag::PURPOSE को टाइप.हाल में ENUM_REP के रूप में परिभाषित किया गया है ENUM_REP | 1 । प्रमाणन विस्तार के लिए, ENUM_REP मान हटा दिया गया है, टैग 1 को छोड़ दिया गया है। (कीमास्टर 2 और उससे नीचे के लिए, KM_TAG_PURPOSE को keymaster_defs.h में परिभाषित किया गया है।)

इस तालिका के अनुसार मानों को सरल तरीके से ASN.1 प्रकारों में अनुवादित किया जाता है:

कीमास्टर प्रकार ASN.1 प्रकार
ENUM पूर्णांक
ENUM_REP पूर्णांक का सेट
UINT पूर्णांक
UINT_REP पूर्णांक का सेट
ULONG पूर्णांक
ULONG_REP पूर्णांक का सेट
DATE पूर्णांक (1 जनवरी, 1970 00:00:00 GMT से मिलीसेकंड)
BOOL NULL (कीमास्टर में, मौजूद टैग का अर्थ है सत्य, अनुपस्थित का अर्थ है असत्य।
वही शब्दार्थ 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),
}

कुंजी विवरण फ़ील्ड

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

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

प्राधिकरण सूची फ़ील्ड

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

प्रत्येक फ़ील्ड के मूल्यों के विवरण के लिए, types.hal 3 के लिए type.hal और keymaster_defs.h 2 और नीचे के लिए keymaster_defs.h देखें। कीमास्टर टैग नामों को KM_TAG उपसर्ग को हटाकर और शेष को कैमल केस में बदलकर फ़ील्ड नामों में बदल दिया गया था, इसलिए Tag::KEY_SIZE keySize गया।

रूटऑफट्रस्ट फ़ील्ड

RootOfTrust फ़ील्ड्स की स्थितिगत रूप से पहचान की जाती है।

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

सत्यापित बूटस्टेट मान

verifiedBootState के मूल्यों के निम्नलिखित अर्थ हैं:

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

सुरक्षा स्तर के मान

securityLevel स्तर के मूल्यों के निम्नलिखित अर्थ हैं:

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

अनोखा 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 बिट तक छोटा करें।

सत्यापन कुंजी और प्रमाण पत्र

दो चाबियां, एक आरएसए और एक ईसीडीएसए, और संबंधित प्रमाणपत्र श्रृंखलाएं डिवाइस में सुरक्षित रूप से प्रावधानित हैं।

आईडी प्रमाणन

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

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

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

भंडारण गुण

उपकरण के पहचानकर्ताओं को रखने वाले संग्रहण में इन गुणों का होना आवश्यक है:

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

निर्माण

एक कार्यान्वयन बनाने के लिए जिसमें ऊपर सूचीबद्ध गुण हैं, निम्नलिखित निर्माण एस में आईडी-व्युत्पन्न मानों को संग्रहीत करें। सिस्टम में सामान्य स्थानों को छोड़कर आईडी मूल्यों की अन्य प्रतियों को संग्रहीत न करें, जिसे डिवाइस स्वामी रूट करके संशोधित कर सकता है:

S = D || HMAC(HBK, D)

कहाँ पे:

  • D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
  • HMAC एक उपयुक्त सुरक्षित हैश (SHA-256 अनुशंसित) के साथ HMAC निर्माण है
  • HBK एक हार्डवेयर-बाध्य कुंजी है जिसका उपयोग किसी अन्य उद्देश्य के लिए नहीं किया जाता है
  • ID 1 ...ID n मूल आईडी मान हैं; किसी विशेष सूचकांक के लिए किसी विशेष मान का जुड़ाव कार्यान्वयन-निर्भर है, क्योंकि विभिन्न उपकरणों में अलग-अलग संख्या में पहचानकर्ता होंगे
  • || संकरण का प्रतिनिधित्व करता है

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

हार्डवेयर पहचानकर्ता

आईडी प्रमाणन निम्नलिखित हार्डवेयर पहचानकर्ताओं का समर्थन करता है:

  1. ब्रांड नाम, जैसा Android में Build.BRAND द्वारा दिया गया है
  2. डिवाइस का नाम, जैसा Android में Build.DEVICE द्वारा दिया गया है
  3. उत्पाद का नाम, जैसा Android में Build.PRODUCT द्वारा लौटाया गया है
  4. निर्माता का नाम, जैसा Android में Build.MANUFACTURER द्वारा दिया गया है
  5. मॉडल का नाम, जैसा Android में Build.MODEL द्वारा दिया गया है
  6. क्रमांक
  7. सभी रेडियो के आईएमईआई
  8. सभी रेडियो के MEID

डिवाइस आईडी सत्यापन का समर्थन करने के लिए, एक डिवाइस इन पहचानकर्ताओं को प्रमाणित करता है। Android चलाने वाले सभी उपकरणों में पहले छह होते हैं और वे इस सुविधा के काम करने के लिए आवश्यक होते हैं। यदि डिवाइस में कोई एकीकृत सेलुलर रेडियो है, तो डिवाइस को रेडियो के 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 एन्कोडेड बाइट स्ट्रिंग है। यह प्रारूप संख्यात्मक पहचानकर्ताओं पर भी लागू होता है। प्रमाणित करने के लिए प्रत्येक पहचानकर्ता को यूटीएफ -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 प्रमाणन स्कीमा से परिवर्तन टिप्पणियों के साथ बोल्ड किए गए हैं।

जावा एपीआई

यह खंड केवल सूचनात्मक है। कीमास्टर कार्यान्वयनकर्ता जावा एपीआई को न तो लागू करते हैं और न ही उसका उपयोग करते हैं। यह कार्यान्वयनकर्ताओं को यह समझने में मदद करने के लिए प्रदान किया जाता है कि एप्लिकेशन द्वारा सुविधा का उपयोग कैसे किया जाता है। सिस्टम घटक इसे अलग तरह से उपयोग कर सकते हैं, यही कारण है कि यह महत्वपूर्ण है कि इस खंड को मानक के रूप में नहीं माना जाए।