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

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

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

इसका समाधान करने के लिए, कीमास्टर ने एंड्रॉइड 7.0 (कीमास्टर 2) मेंकुंजी सत्यापन और एंड्रॉइड 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 से लौटाई गई कुंजी बूँद generateKey जिसके लिए प्रमाणन बनाया जाएगा।
  • attestParams सत्यापन के लिए आवश्यक किसी भी पैरामीटर की एक सूची है। इसमें Tag::ATTESTATION_CHALLENGE ::ATTESTATION_CHALLENGE और संभवत: Tag::RESET_SINCE_ID_ROTATION , साथ ही Tag::APPLICATION_ID और Tag::APPLICATION_DATA शामिल हैं। बाद के दो कुंजी बूँद को डिक्रिप्ट करने के लिए आवश्यक हैं यदि वे कुंजी पीढ़ी के दौरान निर्दिष्ट किए गए थे।
  • certChain आउटपुट पैरामीटर है, जो प्रमाणपत्रों की एक सरणी देता है। प्रविष्टि 0 सत्यापन प्रमाणपत्र है, जिसका अर्थ है कि यह keyToAttest से कुंजी को प्रमाणित करता है और इसमें सत्यापन एक्सटेंशन शामिल है।

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

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

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

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

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

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

टीबीएससी प्रमाणपत्र अनुक्रम

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

उदाहरण के लिए, Keymaster 3 में, Tag::PURPOSE को type.hal में ENUM_REP | 1 के रूप में परिभाषित किया गया है 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 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 सुरक्षा स्तर इस सत्यापन का सुरक्षा स्तर। हार्डवेयर-समर्थित कुंजियों के सॉफ़्टवेयर सत्यापन प्राप्त करना संभव है। अगर एंड्रॉइड सिस्टम से समझौता किया जाता है तो ऐसे सत्यापन पर भरोसा नहीं किया जा सकता है।
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 प्रकार को इंगित करने वाला टैग भी हो।

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

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

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

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

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

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

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

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

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

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

एक अलग पहचान

विशिष्ट आईडी एक 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 बिट तक छोटा करें।

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

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

आईडी सत्यापन

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

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

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

भंडारण गुण

डिवाइस के पहचानकर्ताओं को रखने वाले स्टोरेज में ये गुण होने चाहिए:

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

निर्माण

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

S = D || HMAC(HBK, D)

कहाँ पे:

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

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

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

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

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

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

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

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

जावा एपीआई

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