कीस्टोर नियंत्रित तरीके से क्रिप्टोग्राफ़िक कुंजियाँ बनाने, संग्रहीत करने और उपयोग करने के लिए अधिक सुरक्षित स्थान प्रदान करता है। जब हार्डवेयर-समर्थित कुंजी भंडारण उपलब्ध और उपयोग किया जाता है, तो कुंजी सामग्री डिवाइस से निष्कर्षण के खिलाफ अधिक सुरक्षित होती है, और कीमास्टर उन प्रतिबंधों को लागू करता है जिन्हें हटाना मुश्किल होता है।
हालाँकि, यह केवल तभी सत्य है, जब कीस्टोर कुंजियाँ हार्डवेयर-समर्थित स्टोरेज में हों। कीमास्टर 1 में, ऐप्स या रिमोट सर्वर के लिए विश्वसनीय रूप से सत्यापित करने का कोई तरीका नहीं था कि क्या यह मामला था। कीस्टोर डेमॉन ने उपलब्ध कीमास्टर एचएएल को लोड किया और कुंजी के हार्डवेयर बैकिंग के संबंध में एचएएल ने जो कुछ भी कहा, उस पर विश्वास किया।
इसका समाधान करने के लिए, कीमास्टर ने एंड्रॉइड 7.0 (कीमास्टर 2) में कुंजी सत्यापन और एंड्रॉइड 8.0 (कीमास्टर 3) में आईडी सत्यापन पेश किया।
कुंजी सत्यापन का उद्देश्य दृढ़ता से यह निर्धारित करने का एक तरीका प्रदान करना है कि क्या एक असममित कुंजी जोड़ी हार्डवेयर-समर्थित है, कुंजी के गुण क्या हैं, और इसके उपयोग पर क्या बाधाएं लागू होती हैं।
आईडी सत्यापन डिवाइस को अपने हार्डवेयर पहचानकर्ताओं, जैसे सीरियल नंबर या आईएमईआई, का प्रमाण प्रदान करने की अनुमति देता है।
मुख्य सत्यापन
कुंजी सत्यापन का समर्थन करने के लिए, एंड्रॉइड 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
और संभवतःTag::RESET_SINCE_ID_ROTATION
, साथ हीTag::APPLICATION_ID
औरTag::APPLICATION_DATA
शामिल हैं। बाद वाले दो कुंजी ब्लॉब को डिक्रिप्ट करने के लिए आवश्यक हैं यदि वे कुंजी पीढ़ी के दौरान निर्दिष्ट किए गए थे। -
certChain
आउटपुट पैरामीटर है, जो प्रमाणपत्रों की एक श्रृंखला लौटाता है। प्रविष्टि 0 सत्यापन प्रमाणपत्र है, जिसका अर्थ है कि यहkeyToAttest
से कुंजी को प्रमाणित करता है और इसमें सत्यापन एक्सटेंशन शामिल है।
attestKey
विधि को सत्यापित कुंजी पर एक सार्वजनिक कुंजी ऑपरेशन माना जाता है, क्योंकि इसे किसी भी समय कॉल किया जा सकता है और इसे प्राधिकरण बाधाओं को पूरा करने की आवश्यकता नहीं है। उदाहरण के लिए, यदि सत्यापित कुंजी को उपयोग के लिए उपयोगकर्ता प्रमाणीकरण की आवश्यकता है, तो उपयोगकर्ता प्रमाणीकरण के बिना एक सत्यापन उत्पन्न किया जा सकता है।
सत्यापन प्रमाण पत्र
सत्यापन प्रमाणपत्र एक मानक X.509 प्रमाणपत्र है, जिसमें एक वैकल्पिक सत्यापन एक्सटेंशन होता है जिसमें सत्यापित कुंजी का विवरण होता है। प्रमाणपत्र पर प्रमाणित सत्यापन कुंजी के साथ हस्ताक्षर किए गए हैं। सत्यापन कुंजी सत्यापित की जा रही कुंजी से भिन्न एल्गोरिदम का उपयोग कर सकती है।
सत्यापन प्रमाणपत्र में नीचे दी गई तालिका में फ़ील्ड शामिल हैं और इसमें कोई अतिरिक्त फ़ील्ड नहीं हो सकती हैं। कुछ फ़ील्ड एक निश्चित फ़ील्ड मान निर्दिष्ट करते हैं। सीटीएस परीक्षण सत्यापित करते हैं कि प्रमाणपत्र सामग्री बिल्कुल परिभाषित के अनुसार है।
प्रमाणपत्र अनुक्रम
फ़ील्ड नाम ( आरएफसी 5280 देखें) | कीमत |
---|---|
tbs प्रमाणपत्र | टीबीएससी प्रमाणपत्र अनुक्रम |
हस्ताक्षर एल्गोरिदम | कुंजी पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले एल्गोरिदम का एल्गोरिदम पहचानकर्ता: EC कुंजियों के लिए ECDSA, RSA कुंजियों के लिए RSA। |
हस्ताक्षरमूल्य | बिट स्ट्रिंग, ASN.1 DER-एन्कोडेड tbsCertificate पर हस्ताक्षरित हस्ताक्षर। |
टीबीएससी प्रमाणपत्र अनुक्रम
फ़ील्ड नाम ( आरएफसी 5280 देखें) | कीमत |
---|---|
version | पूर्णांक 2 (मतलब v3 प्रमाणपत्र) |
serialNumber | पूर्णांक 1 (निश्चित मान: सभी प्रमाणपत्रों पर समान) |
signature | कुंजी पर हस्ताक्षर करने के लिए उपयोग किए जाने वाले एल्गोरिदम का एल्गोरिदम पहचानकर्ता: ईसी कुंजी के लिए ईसीडीएसए, आरएसए कुंजी के लिए आरएसए। |
issuer | बैच सत्यापन कुंजी के विषय क्षेत्र के समान। |
validity | दो तिथियों का अनुक्रम, जिसमें Tag::ACTIVE_DATETIME और Tag::USAGE_EXPIRE_DATETIME के मान शामिल हैं। वे मान 1 जनवरी 1970 से मिलीसेकंड में हैं। प्रमाणपत्रों में सही दिनांक प्रतिनिधित्व के लिए आरएफसी 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 के रूप में दर्शाया जाता है जिसमें सत्यापन अनुक्रम का DER एन्कोडिंग होता है। |
सत्यापन विस्तार
attestation
एक्सटेंशन में कुंजी से जुड़े कीमास्टर प्राधिकरणों का पूरा विवरण शामिल है, एक ऐसी संरचना में जो सीधे एंड्रॉइड और कीमास्टर एचएएल में उपयोग की जाने वाली प्राधिकरण सूचियों से मेल खाती है। प्राधिकरण सूची में प्रत्येक टैग को ASN.1 SEQUENCE
प्रविष्टि द्वारा दर्शाया जाता है, जिसे स्पष्ट रूप से कीमास्टर टैग संख्या के साथ टैग किया जाता है, लेकिन टाइप डिस्क्रिप्टर (चार उच्च क्रम बिट्स) को छिपा दिया जाता है।
उदाहरण के लिए, कीमास्टर 3 में, Tag::PURPOSE
type.hal में ENUM_REP | 1
के रूप में परिभाषित किया गया है। 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 | शून्य (कीमास्टर में, टैग वर्तमान का अर्थ सत्य है, अनुपस्थित का अर्थ गलत है। वही शब्दार्थ 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 फ़ील्ड
RootOfTrust
फ़ील्ड्स को स्थितिगत रूप से पहचाना जाता है।
कार्यक्षेत्र नाम | प्रकार | कीमत |
---|---|---|
verifiedBootKey | OCTET_STRING | सिस्टम छवि को सत्यापित करने के लिए कुंजी का एक सुरक्षित हैश उपयोग किया जाता है। SHA-256 अनुशंसित। |
deviceLocked | बूलियन | यह सत्य है यदि बूटलोडर लॉक है, जिसका अर्थ है कि केवल हस्ताक्षरित छवियों को फ्लैश किया जा सकता है, और सत्यापित बूट जाँच की जाती है। |
verifiedBootState | सत्यापितबूटस्टेट | सत्यापित बूट की स्थिति. |
verifiedBootHash | OCTET_STRING | सत्यापित बूट द्वारा संरक्षित सभी डेटा का एक डाइजेस्ट। उन उपकरणों के लिए जो सत्यापित बूट के एंड्रॉइड सत्यापित बूट कार्यान्वयन का उपयोग करते हैं, इस मान में VBMeta संरचना , या सत्यापित बूट मेटाडेटा संरचना का डाइजेस्ट शामिल है। इस मान की गणना करने के तरीके के बारे में अधिक जानने के लिए,VBMeta डाइजेस्ट देखें |
सत्यापितबूटस्टेट मान
verifiedBootState
के मानों के निम्नलिखित अर्थ हैं:
कीमत | अर्थ |
---|---|
Verified | बूटलोडर से सत्यापित विभाजन तक विस्तारित विश्वास की एक पूरी श्रृंखला को इंगित करता है, जिसमें बूटलोडर, बूट विभाजन और सभी सत्यापित विभाजन शामिल हैं। इस स्थिति में, verifiedBootKey मान एम्बेडेड प्रमाणपत्र का हैश है, जिसका अर्थ है कि अपरिवर्तनीय प्रमाणपत्र ROM में जला दिया गया है।यह स्थिति हरे बूट स्थिति से मेल खाती है जैसा कि सत्यापित बूट प्रवाह दस्तावेज़ में दर्ज़ किया गया है। |
SelfSigned | इंगित करता है कि बूट विभाजन को एम्बेडेड प्रमाणपत्र का उपयोग करके सत्यापित किया गया है, और हस्ताक्षर मान्य है। बूट प्रक्रिया को जारी रखने की अनुमति देने से पहले बूटलोडर एक चेतावनी और सार्वजनिक कुंजी का फिंगरप्रिंट प्रदर्शित करता है। इस स्थिति में, verifiedBootKey मान स्व-हस्ताक्षरित प्रमाणपत्र का हैश है।यह स्थिति पीले बूट स्थिति से मेल खाती है जैसा कि सत्यापित बूट प्रवाह दस्तावेज़ में दर्ज़ किया गया है। |
Unverified | इंगित करता है कि एक उपकरण को स्वतंत्र रूप से संशोधित किया जा सकता है। डिवाइस की अखंडता को आउट-ऑफ़-बैंड सत्यापित करने के लिए उपयोगकर्ता पर छोड़ दिया गया है। बूट लोडर बूट प्रक्रिया को जारी रखने की अनुमति देने से पहले उपयोगकर्ता को एक चेतावनी प्रदर्शित करता है। इस स्थिति में verifiedBootKey मान रिक्त है।यह स्थिति नारंगी बूट स्थिति से मेल खाती है जैसा कि सत्यापित बूट प्रवाह दस्तावेज़ में दर्ज़ किया गया है। |
Failed | इंगित करता है कि डिवाइस सत्यापन में विफल रहा है। किसी भी सत्यापन प्रमाणपत्र में वास्तव में यह मान नहीं होता है, क्योंकि इस स्थिति में बूटलोडर रुक जाता है। इसे संपूर्णता के लिए यहां शामिल किया गया है। यह स्थिति सत्यापित बूट प्रवाह दस्तावेज़ में प्रलेखित लाल बूट स्थिति से मेल खाती है। |
सुरक्षा स्तर मान
securityLevel
के मानों के निम्नलिखित अर्थ हैं:
कीमत | अर्थ |
---|---|
Software | वह कोड जो प्रासंगिक तत्व (सत्यापन या कुंजी) बनाता या प्रबंधित करता है, एंड्रॉइड सिस्टम में लागू किया जाता है और यदि उस सिस्टम से समझौता किया जाता है तो उसे बदला जा सकता है। |
TrustedEnvironment | वह कोड जो प्रासंगिक तत्व (सत्यापन या कुंजी) बनाता या प्रबंधित करता है, एक विश्वसनीय निष्पादन वातावरण (टीईई) में कार्यान्वित किया जाता है। यदि टीईई से समझौता किया जाता है तो इसे बदला जा सकता है, लेकिन टीईई दूरस्थ समझौते के लिए अत्यधिक प्रतिरोधी है और प्रत्यक्ष हार्डवेयर हमले से समझौता करने के लिए मध्यम रूप से प्रतिरोधी है। |
StrongBox | वह कोड जो प्रासंगिक तत्व (सत्यापन या कुंजी) बनाता या प्रबंधित करता है, एक समर्पित हार्डवेयर सुरक्षा मॉड्यूल में कार्यान्वित किया जाता है। यदि हार्डवेयर सुरक्षा मॉड्यूल से समझौता किया जाता है तो इसे बदला जा सकता है, लेकिन यह दूरस्थ समझौता के प्रति अत्यधिक प्रतिरोधी है और प्रत्यक्ष हार्डवेयर हमले से समझौता करने के लिए अत्यधिक प्रतिरोधी है। |
अनोखा ID
यूनिक आईडी एक 128-बिट मान है जो डिवाइस की पहचान करता है, लेकिन केवल सीमित समय के लिए। मान की गणना इसके साथ की जाती है:
HMAC_SHA256(T || C || R, HBK)
कहाँ:
-
T
"टेम्पोरल काउंटर वैल्यू" है, जिसकी गणनाTag::CREATION_DATETIME
के मान को 2592000000 से विभाजित करके, किसी भी शेष को छोड़कर की जाती है।T
हर 30 दिन में बदलता है (25920000000 = 30 * 24 * 60 * 60 * 1000)। -
C
Tag::APPLICATION_ID
का मान है -
R
1 है यदिTag::RESET_SINCE_ID_ROTATION
attest_key कॉल के attest_params पैरामीटर में मौजूद है, या यदि टैग मौजूद नहीं है तो 0 है। -
HBK
एक अनोखा हार्डवेयर-बाउंड रहस्य है जो विश्वसनीय निष्पादन पर्यावरण के लिए जाना जाता है और इसके द्वारा कभी प्रकट नहीं किया गया है। रहस्य में एन्ट्रापी के कम से कम 128 बिट्स शामिल हैं और यह व्यक्तिगत डिवाइस के लिए अद्वितीय है (एंट्रॉपी के 128 बिट्स को देखते हुए संभाव्य विशिष्टता स्वीकार्य है)। एचबीके को एचएमएसी या एईएस_सीएमएसी के माध्यम से फ़्यूज्ड कुंजी सामग्री से प्राप्त किया जाना चाहिए।
HMAC_SHA256 आउटपुट को 128 बिट्स तक छोटा करें।
सत्यापन कुंजियाँ और प्रमाणपत्र
दो कुंजियाँ, एक आरएसए और एक ईसीडीएसए, और संबंधित प्रमाणपत्र श्रृंखलाएं, डिवाइस में सुरक्षित रूप से प्रावधानित हैं।
Android 12 रिमोट कुंजी प्रावधान की शुरुआत करता है, और Android 13 के लिए इसे लागू करने वाले उपकरणों की आवश्यकता होती है। रिमोट कुंजी प्रोविजनिंग क्षेत्र में प्रति-आवेदन, ईसीडीएसए पी256 सत्यापन प्रमाणपत्र के साथ उपकरण प्रदान करता है। ये प्रमाणपत्र फ़ैक्टरी-प्रावधान प्रमाणपत्रों की तुलना में कम समय तक चलते हैं।
एकाधिक IMEI
Android 14, Android कुंजी सत्यापन रिकॉर्ड में एकाधिक IMEI के लिए समर्थन जोड़ता है। OEM दूसरे IMEI के लिए KeyMint टैग जोड़कर इस सुविधा को कार्यान्वित कर सकते हैं। उपकरणों में कई सेल्युलर रेडियो होना आम होता जा रहा है और ओईएम अब दो आईएमईआई वाले उपकरणों का समर्थन कर सकते हैं।
ओईएम को एक द्वितीयक IMEI की आवश्यकता होती है, यदि उनके डिवाइस पर मौजूद है, तो इसे KeyMint कार्यान्वयन में प्रावधानित किया जाना चाहिए ताकि वे कार्यान्वयन इसे उसी तरह सत्यापित कर सकें जैसे वे पहले IMEI को प्रमाणित करते हैं।
आईडी सत्यापन
एंड्रॉइड 8.0 में कीमास्टर 3 वाले उपकरणों के लिए आईडी सत्यापन के लिए वैकल्पिक समर्थन शामिल है। आईडी सत्यापन डिवाइस को अपने हार्डवेयर पहचानकर्ताओं, जैसे सीरियल नंबर या आईएमईआई का प्रमाण प्रदान करने की अनुमति देता है। हालांकि एक वैकल्पिक सुविधा, यह अत्यधिक अनुशंसित है कि सभी कीमास्टर 3 कार्यान्वयन इसके लिए समर्थन प्रदान करते हैं क्योंकि डिवाइस की पहचान साबित करने में सक्षम होने से वास्तविक शून्य-स्पर्श रिमोट कॉन्फ़िगरेशन जैसे मामलों का उपयोग अधिक सुरक्षित हो जाता है (क्योंकि रिमोट पक्ष निश्चित हो सकता है) सही डिवाइस से बात कर रहा है, न कि किसी डिवाइस से जो उसकी पहचान खराब कर रही है)।
आईडी सत्यापन डिवाइस के हार्डवेयर पहचानकर्ताओं की प्रतियां बनाकर काम करता है जिसे केवल विश्वसनीय निष्पादन पर्यावरण (टीईई) डिवाइस फैक्ट्री छोड़ने से पहले एक्सेस कर सकता है। उपयोगकर्ता डिवाइस के बूटलोडर को अनलॉक कर सकता है और सिस्टम सॉफ़्टवेयर और एंड्रॉइड फ्रेमवर्क द्वारा रिपोर्ट किए गए पहचानकर्ताओं को बदल सकता है। टीईई द्वारा रखे गए पहचानकर्ताओं की प्रतियों को इस तरह से हेरफेर नहीं किया जा सकता है, यह सुनिश्चित करते हुए कि डिवाइस आईडी सत्यापन केवल डिवाइस के मूल हार्डवेयर पहचानकर्ताओं को प्रमाणित करेगा जिससे स्पूफिंग प्रयासों को विफल कर दिया जाएगा।
आईडी सत्यापन के लिए मुख्य एपीआई सतह कीमास्टर 2 के साथ शुरू की गई मौजूदा कुंजी सत्यापन तंत्र के शीर्ष पर बनाई गई है। जब कीमास्टर द्वारा रखी गई कुंजी के लिए सत्यापन प्रमाणपत्र का अनुरोध किया जाता है, तो कॉलर अनुरोध कर सकता है कि डिवाइस के हार्डवेयर पहचानकर्ताओं को सत्यापन प्रमाणपत्र के मेटाडेटा में शामिल किया जाए। यदि कुंजी टीईई में रखी गई है, तो प्रमाणपत्र विश्वास की ज्ञात जड़ पर वापस आ जाएगा। ऐसे प्रमाणपत्र का प्राप्तकर्ता यह सत्यापित कर सकता है कि प्रमाणपत्र और उसकी सामग्री, हार्डवेयर पहचानकर्ताओं सहित, टीईई द्वारा लिखी गई थी। जब सत्यापन प्रमाणपत्र में हार्डवेयर पहचानकर्ताओं को शामिल करने के लिए कहा जाता है, तो टीईई केवल अपने भंडारण में रखे गए पहचानकर्ताओं को प्रमाणित करता है, जैसा कि कारखाने के फर्श पर भरा हुआ है।
भंडारण गुण
डिवाइस के पहचानकर्ताओं को रखने वाले भंडारण में ये गुण होने चाहिए:
- डिवाइस के मूल पहचानकर्ताओं से प्राप्त मानों को डिवाइस के फ़ैक्टरी छोड़ने से पहले स्टोरेज में कॉपी किया जाता है।
-
destroyAttestationIds()
विधि पहचानकर्ता-व्युत्पन्न डेटा की इस प्रति को स्थायी रूप से नष्ट कर सकती है। स्थायी विनाश का मतलब है कि डेटा पूरी तरह से हटा दिया गया है, इसलिए न तो फ़ैक्टरी रीसेट और न ही डिवाइस पर की गई कोई अन्य प्रक्रिया इसे पुनर्स्थापित कर सकती है। यह उन उपकरणों के लिए विशेष रूप से महत्वपूर्ण है जहां उपयोगकर्ता ने बूटलोडर को अनलॉक किया है और सिस्टम सॉफ़्टवेयर को बदल दिया है और एंड्रॉइड फ्रेमवर्क द्वारा लौटाए गए पहचानकर्ताओं को संशोधित किया है। - आरएमए सुविधाओं में हार्डवेयर पहचानकर्ता-व्युत्पन्न डेटा की नई प्रतियां उत्पन्न करने की क्षमता होनी चाहिए। इस तरह, एक उपकरण जो आरएमए से गुजरता है वह फिर से आईडी सत्यापन कर सकता है। आरएमए सुविधाओं द्वारा उपयोग किए जाने वाले तंत्र को संरक्षित किया जाना चाहिए ताकि उपयोगकर्ता इसे स्वयं लागू न कर सकें, क्योंकि इससे उन्हें नकली आईडी के सत्यापन प्राप्त करने की अनुमति मिल जाएगी।
- टीईई में कीमास्टर विश्वसनीय ऐप के अलावा कोई भी कोड स्टोरेज में रखे गए पहचानकर्ता-व्युत्पन्न डेटा को पढ़ने में सक्षम नहीं है।
- भंडारण छेड़छाड़-स्पष्ट है: यदि भंडारण की सामग्री को संशोधित किया गया है, तो टीईई इसे उसी तरह मानता है जैसे कि सामग्री की प्रतियां नष्ट कर दी गई थीं और सभी आईडी सत्यापन प्रयासों को अस्वीकार कर दिया गया था। इसे नीचे वर्णित अनुसार भंडारण पर हस्ताक्षर या मैकिंग करके कार्यान्वित किया जाता है।
- भंडारण में मूल पहचानकर्ता नहीं हैं। क्योंकि आईडी सत्यापन में एक चुनौती शामिल होती है, कॉल करने वाला हमेशा सत्यापित होने के लिए पहचानकर्ता प्रदान करता है। टीईई को केवल यह सत्यापित करने की आवश्यकता है कि ये उन मूल्यों से मेल खाते हैं जो उनके मूल में थे। मूल्यों के बजाय मूल मूल्यों के सुरक्षित हैश को संग्रहीत करना इस सत्यापन को सक्षम बनाता है।
निर्माण
एक कार्यान्वयन बनाने के लिए जिसमें ऊपर सूचीबद्ध गुण हैं, आईडी-व्युत्पन्न मानों को निम्नलिखित निर्माण एस में संग्रहीत करें। सिस्टम में सामान्य स्थानों को छोड़कर, आईडी मानों की अन्य प्रतियां संग्रहीत न करें, जिन्हें डिवाइस मालिक रूट करके संशोधित कर सकता है:
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 को मान्य करने की आवश्यकता होती है। , एचएमएसी (एचबीके, डी) की गणना करना और इसकी तुलना एस में मान से यह सत्यापित करने के लिए करना कि कोई भी व्यक्तिगत आईडी संशोधित/दूषित नहीं हुई है। इसके अलावा, कार्यान्वयन को सभी व्यक्तिगत आईडी तत्वों और एस के सत्यापन के लिए निरंतर-समय तुलना का उपयोग करना चाहिए। प्रदान की गई आईडी की संख्या और परीक्षण के किसी भी भाग के सही मिलान की परवाह किए बिना तुलना समय स्थिर होना चाहिए।
हार्डवेयर पहचानकर्ता
आईडी सत्यापन निम्नलिखित हार्डवेयर पहचानकर्ताओं का समर्थन करता है:
- ब्रांड नाम, जैसा कि एंड्रॉइड में
Build.BRAND
द्वारा दिया गया है - डिवाइस का नाम, जैसा कि Android में
Build.DEVICE
द्वारा दिया गया है - उत्पाद का नाम, जैसा कि Android में
Build.PRODUCT
द्वारा दिया गया है - निर्माता का नाम, जैसा कि Android में
Build.MANUFACTURER
द्वारा दिया गया है - मॉडल का नाम, जैसा कि एंड्रॉइड में
Build.MODEL
द्वारा दिया गया है - क्रम संख्या
- सभी रेडियो के IMEI
- सभी रेडियो के MEIDs
डिवाइस आईडी सत्यापन का समर्थन करने के लिए, एक डिवाइस इन पहचानकर्ताओं को प्रमाणित करता है। एंड्रॉइड चलाने वाले सभी उपकरणों में पहले छह होते हैं और वे इस सुविधा के काम करने के लिए आवश्यक हैं। यदि डिवाइस में कोई एकीकृत सेलुलर रेडियो है, तो डिवाइस को रेडियो के 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 एन्कोडेड बाइट स्ट्रिंग है। यह प्रारूप संख्यात्मक पहचानकर्ताओं पर भी लागू होता है। सत्यापित करने के लिए प्रत्येक पहचानकर्ता को 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 सत्यापन स्कीमा से परिवर्तन टिप्पणियों के साथ बोल्ड किए गए हैं।
जावा एपीआई
यह अनुभाग केवल सूचनात्मक है. कीमास्टर कार्यान्वयनकर्ता जावा एपीआई को न तो लागू करते हैं और न ही उसका उपयोग करते हैं। यह कार्यान्वयनकर्ताओं को यह समझने में मदद करने के लिए प्रदान किया जाता है कि एप्लिकेशन द्वारा सुविधा का उपयोग कैसे किया जाता है। सिस्टम घटक इसका उपयोग अलग-अलग तरीके से कर सकते हैं, यही कारण है कि यह महत्वपूर्ण है कि इस अनुभाग को मानक के रूप में नहीं माना जाए।