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

हार्डवेयर समर्थित कीस्टोर

एक चिप (SoC) पर एक सिस्टम में एक विश्वसनीय निष्पादन वातावरण की उपलब्धता Android उपकरणों के लिए Android OS, प्लेटफ़ॉर्म सेवाओं और यहां तक कि तृतीय-पक्ष एप्लिकेशन को हार्डवेयर-समर्थित, मजबूत सुरक्षा सेवाएं प्रदान करने का अवसर प्रदान करती है। Android-विशिष्ट एक्सटेंशन चाहने वाले डेवलपर को android.security.keystore पर जाना चाहिए।

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

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

क्रिप्टोग्राफिक प्रिमिटिव्स की सीमा का विस्तार करने के अलावा, एंड्रॉइड 6.0 में कीस्टोर ने निम्नलिखित को जोड़ा:

चाबियों के दुरुपयोग के कारण सुरक्षा समझौता के जोखिम को कम करने के लिए कुंजी उपयोग को सीमित करने की अनुमति देने के लिए एक उपयोग नियंत्रण योजना
निर्दिष्ट उपयोगकर्ताओं, ग्राहकों और एक परिभाषित समय सीमा के लिए चाबियों के प्रतिबंध को सक्षम करने के लिए एक अभिगम नियंत्रण योजना

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

वर्जन बाइंडिंग ऑपरेटिंग सिस्टम और पैच लेवल वर्जन की चाबियों को बांधती है। यह सुनिश्चित करता है कि एक हमलावर जो सिस्टम के पुराने संस्करण या टीईई सॉफ्टवेयर में कमजोरी का पता लगाता है, वह डिवाइस को कमजोर संस्करण में वापस नहीं ले जा सकता है और नए संस्करण के साथ बनाई गई कुंजियों का उपयोग नहीं कर सकता है। इसके अलावा, जब किसी डिवाइस पर दिए गए संस्करण और पैच स्तर वाली कुंजी का उपयोग किया जाता है जिसे नए संस्करण या पैच स्तर पर अपग्रेड किया गया है, तो कुंजी का उपयोग करने से पहले उसे अपग्रेड किया जाता है, और कुंजी का पिछला संस्करण अमान्य हो जाता है। जैसे ही डिवाइस को अपग्रेड किया जाता है, डिवाइस के साथ-साथ "शाफ़्ट" कीज़ आगे की ओर जाती हैं, लेकिन डिवाइस के पिछले रिलीज़ में किसी भी तरह के रिवर्सन के कारण कुंजियाँ अनुपयोगी हो जाती हैं।

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

इस इंटरफ़ेस संशोधन के अलावा, एंड्रॉइड 8.0 ने आईडी सत्यापन का समर्थन करने के लिए कीमास्टर 2 की सत्यापन सुविधा का विस्तार किया। आईडी सत्यापन हार्डवेयर पहचानकर्ताओं, जैसे डिवाइस सीरियल नंबर, उत्पाद का नाम, और फोन आईडी (आईएमईआई / एमईआईडी) को दृढ़ता से प्रमाणित करने के लिए एक सीमित और वैकल्पिक तंत्र प्रदान करता है। इस जोड़ को लागू करने के लिए, Android 8.0 ने आईडी सत्यापन जोड़ने के लिए ASN.1 सत्यापन स्कीमा को बदल दिया। कीमास्टर कार्यान्वयनों को प्रासंगिक डेटा आइटम को पुनः प्राप्त करने के लिए कुछ सुरक्षित तरीके खोजने की आवश्यकता है, साथ ही साथ सुविधा को सुरक्षित और स्थायी रूप से अक्षम करने के लिए एक तंत्र को परिभाषित करने की आवश्यकता है।

Android 9 में, अपडेट शामिल हैं:

कीमास्टर 4 में अपडेट करें
एम्बेडेड सुरक्षित तत्वों के लिए समर्थन
सुरक्षित कुंजी आयात के लिए समर्थन
3DES एन्क्रिप्शन के लिए समर्थन
संस्करण बाइंडिंग में परिवर्तन ताकि boot.img और system.img ने स्वतंत्र अपडेट की अनुमति देने के लिए अलग-अलग संस्करण सेट किए हों

शब्दकोष

यहां कीस्टोर घटकों और उनके संबंधों का त्वरित अवलोकन दिया गया है।

AndroidKeystore , Android Framework API और घटक है जिसका उपयोग ऐप्स द्वारा Keystore कार्यक्षमता तक पहुंचने के लिए किया जाता है। इसे मानक जावा क्रिप्टोग्राफी आर्किटेक्चर एपीआई के विस्तार के रूप में लागू किया गया है, और इसमें जावा कोड शामिल है जो ऐप के अपने प्रोसेस स्पेस में चलता है। AndroidKeystore कीस्टोर व्यवहार के लिए एप्लिकेशन अनुरोधों को कीस्टोर डेमॉन को अग्रेषित करके पूरा करता है।

कीस्टोर डेमॉन एक एंड्रॉइड सिस्टम डेमॉन है जो एक बाइंडर एपीआई के माध्यम से सभी कीस्टोर कार्यक्षमता तक पहुंच प्रदान करता है। यह "कुंजी ब्लॉब्स" को संग्रहीत करने के लिए ज़िम्मेदार है, जिसमें वास्तविक गुप्त कुंजी सामग्री होती है, एन्क्रिप्ट की जाती है ताकि कीस्टोर उन्हें स्टोर कर सके लेकिन उनका उपयोग या प्रकट नहीं कर सके।

keymasterd एक HIDL सर्वर है जो Keymaster TA तक पहुंच प्रदान करता है। (यह नाम मानकीकृत नहीं है और वैचारिक उद्देश्यों के लिए है।)

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

LockSettingsService Android सिस्टम घटक है जो उपयोगकर्ता प्रमाणीकरण, पासवर्ड और फ़िंगरप्रिंट दोनों के लिए ज़िम्मेदार है। यह कीस्टोर का हिस्सा नहीं है, लेकिन प्रासंगिक है क्योंकि कई कीस्टोर कुंजी संचालन के लिए उपयोगकर्ता प्रमाणीकरण की आवश्यकता होती है। LockSettingsService प्रमाणीकरण टोकन प्राप्त करने के लिए गेटकीपर टीए और फ़िंगरप्रिंट टीए के साथ इंटरैक्ट करता है, जो कि कीस्टोर डेमॉन को प्रदान करता है, और जो अंततः कीमास्टर टीए एप्लिकेशन द्वारा उपभोग किया जाता है।

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

फ़िंगरप्रिंट टीए (विश्वसनीय एप्लिकेशन) सुरक्षित संदर्भ में चलने वाला एक अन्य घटक है जो उपयोगकर्ता फ़िंगरप्रिंट को प्रमाणित करने और कीमास्टर टीए को साबित करने के लिए उपयोग किए जाने वाले प्रमाणीकरण टोकन उत्पन्न करने के लिए ज़िम्मेदार है कि किसी विशेष उपयोगकर्ता के लिए एक विशेष समय पर प्रमाणीकरण किया गया था।

आर्किटेक्चर

एंड्रॉइड कीस्टोर एपीआई और अंतर्निहित कीमास्टर एचएएल क्रिप्टोग्राफिक प्राइमेटिव्स का एक बुनियादी लेकिन पर्याप्त सेट प्रदान करते हैं ताकि एक्सेस-नियंत्रित, हार्डवेयर-समर्थित कुंजियों का उपयोग करके प्रोटोकॉल के कार्यान्वयन की अनुमति मिल सके।

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

चित्र 1. कीमास्टर तक पहुंच

एंड्रॉइड डिवाइस के भीतर, कीमास्टर एचएएल के "क्लाइंट" में कई परतें होती हैं (जैसे ऐप, फ्रेमवर्क, कीस्टोर डेमॉन), लेकिन इस दस्तावेज़ के उद्देश्यों के लिए इसे अनदेखा किया जा सकता है। इसका मतलब है कि वर्णित कीमास्टर एचएएल एपीआई निम्न-स्तरीय है, जिसका उपयोग प्लेटफ़ॉर्म-आंतरिक घटकों द्वारा किया जाता है, और ऐप डेवलपर्स के संपर्क में नहीं आता है। Android डेवलपर साइट पर उच्च-स्तरीय API का वर्णन किया गया है।

Keymaster HAL का उद्देश्य सुरक्षा-संवेदनशील एल्गोरिदम को लागू करना नहीं है, बल्कि सुरक्षित दुनिया के लिए केवल मार्शल और अनमर्शल अनुरोधों को लागू करना है। तार प्रारूप कार्यान्वयन-परिभाषित है।

पिछले संस्करणों के साथ संगतता

कीमास्टर 1 एचएएल पहले जारी किए गए एचएएल के साथ पूरी तरह से असंगत है, उदाहरण के लिए कीमास्टर 0.2 और 0.3। पुराने कीमास्टर एचएएल के साथ लॉन्च किए गए एंड्रॉइड 5.0 और इससे पहले के उपकरणों पर इंटरऑपरेबिलिटी की सुविधा के लिए, कीस्टोर एक एडेप्टर प्रदान करता है जो मौजूदा हार्डवेयर लाइब्रेरी में कॉल के साथ कीमास्टर 1 एचएएल को लागू करता है। परिणाम Keymaster 1 HAL में कार्यक्षमता की पूरी श्रृंखला प्रदान नहीं कर सकता है। विशेष रूप से, यह केवल आरएसए और ईसीडीएसए एल्गोरिदम का समर्थन करता है, और गैर-सुरक्षित दुनिया में, एडेप्टर द्वारा सभी प्रमुख प्राधिकरण प्रवर्तन किए जाते हैं।

Keymaster 2 ने get_supported_* मेथड्स को हटाकर और इनपुट को स्वीकार करने के लिए finish() मेथड को अनुमति देकर HAL इंटरफेस को और सरल बनाया। यह उन मामलों में टीईई के लिए राउंड ट्रिप की संख्या को कम करता है जहां इनपुट एक ही बार में उपलब्ध होता है, और एईएडी डिक्रिप्शन के कार्यान्वयन को सरल बनाता है।

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

एचआईडीएल सिंहावलोकन

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

HIDL इंटरफेस में विधियों का एक सेट होता है, जिसे इस प्रकार व्यक्त किया जाता है:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

Keymaster 3 IKeymasterDevice.hal से एक उदाहरण विधि है:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

यह keymaster2 HAL से निम्नलिखित के बराबर है:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

एचआईडीएल संस्करण में, dev तर्क हटा दिया जाता है, क्योंकि यह निहित है। params तर्क अब एक स्ट्रक्चर नहीं है जिसमें key_parameter_t ऑब्जेक्ट्स की एक सरणी को संदर्भित करने वाला पॉइंटर होता है, लेकिन एक vec (वेक्टर) जिसमें KeyParameter ऑब्जेक्ट्स होता है। वापसी मान " generates " खंड में सूचीबद्ध हैं, जिसमें कुंजी ब्लॉब के लिए uint8_t मानों का वेक्टर शामिल है।

HIDL कंपाइलर द्वारा उत्पन्न C++ वर्चुअल विधि है:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

जहां GenerateKey_cb एक generateKey_cb पॉइंटर है जिसे इस प्रकार परिभाषित किया गया है:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

यही है, GenerateKey_cb एक ऐसा फ़ंक्शन है जो generateKey_cb क्लॉज में सूचीबद्ध रिटर्न मान लेता है। HAL कार्यान्वयन वर्ग इस generateKey विधि को ओवरराइड करता है और कॉलर को ऑपरेशन के परिणाम को वापस करने के लिए GenerateKey_cb generateKey_cb पॉइंटर को कॉल करता है। ध्यान दें कि फ़ंक्शन पॉइंटर कॉल सिंक्रोनस है। कॉलर जेनरेटकी को कॉल generateKey और generateKey आपूर्ति किए गए फ़ंक्शन पॉइंटर को कॉल करता है, जो पूरा होने के लिए निष्पादित होता है, generateKey कार्यान्वयन पर नियंत्रण लौटाता है, जो फिर कॉलर पर वापस आ जाता है।

विस्तृत उदाहरण के लिए, hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp में डिफ़ॉल्ट कार्यान्वयन देखें। डिफ़ॉल्ट कार्यान्वयन पुराने-शैली के keymaster0, keymaster1, या keymaster2 HALS वाले उपकरणों के लिए पश्चगामी संगतता प्रदान करता है।

पहुँच नियंत्रण

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

विक्रेता घटकों को समायोजित करने और हार्ड-कोडित अपवादों के बिना अभिगम नियंत्रण को सामान्य बनाने के लिए, कीस्टोर 2.0 डोमेन और SELinux नामस्थान पेश करता है।

कीस्टोर डोमेन

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

हम पांच डोमेन पैरामीटर पेश करते हैं जो नियंत्रित करते हैं कि चाबियों तक कैसे पहुंचा जा सकता है। वे कुंजी डिस्क्रिप्टर के नेमस्पेस पैरामीटर के शब्दार्थ को नियंत्रित करते हैं और एक्सेस कंट्रोल कैसे किया जाता है।

DOMAIN_APP : ऐप डोमेन लीगेसी व्यवहार को कवर करता है। Java Keystore SPI डिफ़ॉल्ट रूप से इस डोमेन का उपयोग करता है। जब इस डोमेन का उपयोग किया जाता है, तो नेमस्पेस तर्क को अनदेखा कर दिया जाता है और इसके बजाय कॉलर के यूआईडी का उपयोग किया जाता है। इस डोमेन तक पहुंच को कीस्टोर लेबल द्वारा SELinux नीति में keystore_key वर्ग के लिए नियंत्रित किया जाता है।
DOMAIN_SELINUX : यह डोमेन इंगित करता है कि SELinux नीति में नेमस्पेस का एक लेबल है। नेमस्पेस पैरामीटर को देखा जाता है और लक्ष्य संदर्भ में अनुवादित किया जाता है, और keystore_key वर्ग के लिए SELinux संदर्भ को कॉल करने के लिए एक अनुमति जांच की जाती है। जब दिए गए ऑपरेशन के लिए अनुमति स्थापित की जाती है, तो कुंजी देखने के लिए पूर्ण टपल का उपयोग किया जाता है।
DOMAIN_GRANT : ग्रांट डोमेन इंगित करता है कि नेमस्पेस पैरामीटर एक ग्रांट आइडेंटिफ़ायर है। उपनाम पैरामीटर पर ध्यान नहीं दिया जाता है। जब अनुदान बनाया जाता है तो SELinux जाँच की जाती है। आगे अभिगम नियंत्रण केवल तभी जांचता है जब कॉलर यूआईडी अनुरोधित अनुदान के अनुदानग्राही यूआईडी से मेल खाता हो।
DOMAIN_KEY_ID : यह डोमेन इंगित करता है कि नेमस्पेस पैरामीटर एक अद्वितीय कुंजी आईडी है। कुंजी स्वयं DOMAIN_APP या DOMAIN_SELINUX के साथ बनाई गई हो सकती है। अनुमति जांच domain के बाद की जाती है और namespace को कुंजी डेटाबेस से उसी तरह लोड किया जाता है जैसे कि डोमेन, नेमस्पेस और उपनाम टपल द्वारा ब्लॉब लोड किया गया था। कुंजी आईडी डोमेन का औचित्य निरंतरता है। जब किसी कुंजी को उपनाम से एक्सेस किया जाता है, तो बाद की कॉल अलग-अलग कुंजियों पर काम कर सकती हैं, क्योंकि एक नई कुंजी उत्पन्न या आयात की जा सकती है और इस उपनाम से बंधी हो सकती है। कुंजी आईडी, हालांकि, कभी नहीं बदलती है। इसलिए कीस्टोर डेटाबेस से एक बार लोड होने के बाद कुंजी आईडी द्वारा कुंजी का उपयोग करते समय, कोई निश्चित हो सकता है कि यह वही कुंजी है जब तक कुंजी आईडी अभी भी मौजूद है। यह कार्यक्षमता ऐप डेवलपर्स के सामने नहीं आती है। इसके बजाय, इसका उपयोग एंड्रॉइड कीस्टोर एसपीआई के भीतर एक असुरक्षित तरीके से समवर्ती रूप से उपयोग किए जाने पर भी अधिक सुसंगत अनुभव प्रदान करने के लिए किया जाता है।
DOMAIN_BLOB : ब्लॉब डोमेन इंगित करता है कि कॉलर स्वयं बूँद का प्रबंधन करता है। इसका उपयोग उन क्लाइंट के लिए किया जाता है जिन्हें डेटा विभाजन माउंट होने से पहले कीस्टोर तक पहुंचने की आवश्यकता होती है। कुंजी बूँद कुंजी विवरणक के blob क्षेत्र में शामिल है।

SELinux डोमेन का उपयोग करके, हम विक्रेता घटकों को बहुत विशिष्ट कीस्टोर नेमस्पेस तक पहुंच प्रदान कर सकते हैं जिन्हें सिस्टम घटकों जैसे सेटिंग्स डायलॉग द्वारा साझा किया जा सकता है।

keystore_key के लिए SELinux नीति

नेमस्पेस लेबल को keystore2_key_context फ़ाइल का उपयोग करके कॉन्फ़िगर किया गया है।
इन फ़ाइलों की प्रत्येक पंक्ति एक सांख्यिक नामस्थान आईडी को SELinux लेबल पर मैप करती है। उदाहरण के लिए,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

इस तरह से एक नया कुंजी नामस्थान स्थापित करने के बाद, हम एक उपयुक्त नीति जोड़कर उस तक पहुंच प्रदान कर सकते हैं। उदाहरण के लिए, wpa_supplicant को नए नाम स्थान में कुंजी प्राप्त करने और उपयोग करने की अनुमति देने के लिए हम निम्नलिखित पंक्ति को hal_wifi_supplicant.te में जोड़ देंगे:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

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

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

किसी दिए गए नाम स्थान में एक कुंजी उत्पन्न करने के लिए, नाम स्थान आईडी KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

Keystore 2.0 SELinux नेमस्पेस को कॉन्फ़िगर करने के लिए निम्नलिखित संदर्भ फाइलों का उपयोग किया जा सकता है। टकराव से बचने के लिए प्रत्येक विभाजन में 10,000 नामस्थान आईडी की एक अलग आरक्षित श्रेणी होती है।

PARTITION	सीमा	कॉन्फ़िग फ़ाइलें
व्यवस्था	0 ... 9,999	/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts
विस्तारित प्रणाली	10,000 ... 19,999	/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts
उत्पाद	20,000 ... 29,999	/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts
वेंडर	30,000 ... 39,999	/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

क्लाइंट SELinux डोमेन और वांछित वर्चुअल नेमस्पेस का अनुरोध करके कुंजी का अनुरोध करता है, इस मामले में "wifi_key" , इसकी संख्यात्मक आईडी द्वारा।

उसके ऊपर, निम्नलिखित नामस्थानों को परिभाषित किया गया है। यदि वे विशेष नियमों को प्रतिस्थापित करते हैं, तो निम्न तालिका उस UID को इंगित करती है जिसका वे उपयोग करते थे।

नाम स्थान आईडी	सेपॉलिसी लेबल	यूआईडी	विवरण
0	सु_की	एन/ए	सुपर उपयोगकर्ता कुंजी। केवल userdebug और eng बिल्ड पर परीक्षण के लिए उपयोग किया जाता है। उपयोगकर्ता बिल्ड पर प्रासंगिक नहीं है।
1	खोल_कुंजी	एन/ए	नेमस्पेस खोल के लिए उपलब्ध है। ज्यादातर परीक्षण के लिए उपयोग किया जाता है, लेकिन कमांड लाइन से उपयोगकर्ता के निर्माण पर भी इस्तेमाल किया जा सकता है।
100	vold_key	एन/ए	वोल्ड द्वारा उपयोग के लिए अभिप्रेत है।
101	odsing_key	एन/ए	ऑन-डिवाइस साइनिंग डेमॉन द्वारा उपयोग किया जाता है।
102	वाईफाई_की	AID_WIFI(1010)	wpa_supplicant सहित Android के Wifi sybsystem द्वारा उपयोग किया जाता है।
120	रिज्यूमे_ऑन_रिबूट_की	AID_SYSTEM(1000)	रिबूट पर फिर से शुरू करने का समर्थन करने के लिए एंड्रॉइड के सिस्टम सर्वर द्वारा उपयोग किया जाता है।

एक्सेस वैक्टर

SELinux वर्ग keystore_key काफ़ी पुराना हो गया है और कुछ अनुमतियाँ, जैसे कि verify या sign ने अपना अर्थ खो दिया है। यहाँ अनुमतियों का नया सेट, keystore2_key है, जिसे Keystore 2.0 लागू करेगा।

अनुमति	अर्थ
`delete`	कीस्टोर से चाबियां निकालते समय चेक किया गया।
`get_info`	किसी कुंजी के मेटाडेटा का अनुरोध किए जाने पर जाँच की जाती है।
`grant`	लक्ष्य संदर्भ में कुंजी को अनुदान बनाने के लिए कॉलर को इस अनुमति की आवश्यकता होती है।
`manage_blob`	कॉलर दिए गए SELinux नेमस्पेस पर `DOMAIN_BLOB` का उपयोग कर सकता है, जिससे ब्लॉब्स को अपने आप मैनेज किया जा सकता है। यह वोल्ड के लिए विशेष रूप से उपयोगी है।
`rebind`	यह अनुमति नियंत्रित करती है कि कोई उपनाम किसी नई कुंजी पर वापस आ सकता है या नहीं। यह सम्मिलन के लिए आवश्यक है और इसका तात्पर्य है कि पहले से बंधी हुई कुंजी हटा दी जाएगी। यह मूल रूप से एक सम्मिलित अनुमति है, लेकिन यह कीस्टोर के सिमेंटिक को बेहतर तरीके से कैप्चर करता है।
`req_forced_op`	इस अनुमति वाले ग्राहक अप्राप्य संचालन बना सकते हैं, और संचालन निर्माण तब तक विफल नहीं होता जब तक कि सभी ऑपरेशन स्लॉट अप्राप्य संचालन द्वारा नहीं लिए जाते।
`update`	किसी कुंजी के उप-घटक को अद्यतन करने के लिए आवश्यक है।
`use`	कुंजी सामग्री का उपयोग करने वाला कीमिंट ऑपरेशन बनाते समय चेक किया गया, उदाहरण के लिए, हस्ताक्षर करने, एन/डिक्रिप्शन के लिए।
`use_dev_id`	डिवाइस आईडी सत्यापन जैसी डिवाइस की पहचान करने वाली जानकारी जनरेट करते समय आवश्यक है।

इसके अतिरिक्त, हम SELinux सुरक्षा वर्ग keystore2 में गैर-कुंजी विशिष्ट कीस्टोर अनुमतियों के एक सेट को विभाजित करते हैं:

अनुमति	अर्थ
`add_auth`	प्रमाणीकरण प्रदाता जैसे गेटकीपर या बायोमेट्रिक्समैनेजर द्वारा प्रमाणीकरण टोकन जोड़ने के लिए आवश्यक है।
`clear_ns`	पूर्व में clear_uid, यह अनुमति किसी नामस्थान के गैर-स्वामी को उस नामस्थान की सभी कुंजियों को हटाने की अनुमति देती है।
`list`	विभिन्न गुणों, जैसे कि स्वामित्व या ऑथ बाउंडनेस द्वारा कुंजियों की गणना के लिए सिस्टम द्वारा आवश्यक। इस अनुमति की आवश्यकता कॉल करने वालों को अपने स्वयं के नामस्थानों की गणना करने के लिए नहीं है। यह `get_info` अनुमति द्वारा कवर किया गया है।
`lock`	यह अनुमति कीस्टोर को लॉक करने की अनुमति देती है, अर्थात, मास्टर कुंजी को बेदखल करती है, जैसे कि ऑथ बाउंड कुंजियाँ अनुपयोगी और अप्राप्य हो जाती हैं।
`reset`	यह अनुमति कीस्टोर को फ़ैक्टरी डिफ़ॉल्ट पर रीसेट करने की अनुमति देती है, उन सभी कुंजियों को हटाती है जो एंड्रॉइड ओएस के कामकाज के लिए महत्वपूर्ण नहीं हैं।
`unlock`	ऑथ बाउंड कुंजियों के लिए मास्टर कुंजी को अनलॉक करने का प्रयास करने के लिए यह अनुमति आवश्यक है।