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

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

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

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

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

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

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

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

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

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

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

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

शब्दकोष

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

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

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

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

Keymaster प्रादेशिक सेना (भरोसा आवेदन), सॉफ्टवेयर एक हाथ SoC पर TrustZone में, सुरक्षित कॉन्टेक्स्ट में चल रहा है सबसे अधिक बार, कि सुरक्षित KeyStore कार्यों के सभी प्रदान करता है, कच्चे कुंजी सामग्री की पहुँच है कुंजी पर पहुँच नियंत्रण शर्तों के सभी मान्य करता है , आदि।

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

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

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

आर्किटेक्चर

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

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

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

चित्र 1 Keymaster तक पहुंच

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

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

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

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

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

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

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

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

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

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);

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

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

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

कहाँ generate_cb एक समारोह सूचक के रूप में परिभाषित किया गया है:

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

यही कारण है, generate_cb एक समारोह है कि उत्पन्न खंड में सूचीबद्ध वापसी मान लेता है। एचएएल कार्यान्वयन वर्ग इस ओवरराइड करता है generateKey विधि और कॉल generate_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 डिफ़ॉल्ट रूप से इस डोमेन का उपयोग करता है। जब इस डोमेन का उपयोग किया जाता है, तो नेमस्पेस तर्क को अनदेखा कर दिया जाता है और इसके बजाय कॉलर के यूआईडी का उपयोग किया जाता है। इस डोमेन में पहुंच वर्ग के लिए KeyStore लेबल द्वारा नियंत्रित किया जाता keystore_key SELinux नीति में।
  • DOMAIN_SELINUX : इस डोमेन को इंगित करता है नाम स्थान SELinux नीति में एक लेबल है। नाम स्थान पैरामीटर ऊपर देखा जाता है और लक्ष्य संदर्भ में अनुवाद किया है, और एक अनुमति की जांच के लिए बुला SELinux संदर्भ के लिए किया जाता है keystore_key वर्ग। जब दिए गए ऑपरेशन के लिए अनुमति स्थापित की जाती है, तो कुंजी देखने के लिए पूर्ण टपल का उपयोग किया जाता है।
  • 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 का उपयोग लगभग हमेशा की तरह किया जा सकता है। अंतर केवल इतना है कि नाम स्थान आईडी निर्दिष्ट किया जाना चाहिए। से और कीस्टोर में लोड करने और चाबी आयात करने के लिए, नाम स्थान आईडी का उपयोग कर निर्दिष्ट किया जाता है 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 एन/ए वोल्ड द्वारा उपयोग के लिए अभिप्रेत है।
१०१ odsing_key एन/ए ऑन-डिवाइस साइनिंग डेमॉन द्वारा उपयोग किया जाता है।
102 वाईफाई_की AID_WIFI(1010) wpa_supplicant सहित Android के Wifi sybsystem द्वारा उपयोग किया जाता है।
१२० रिज्यूमे_ऑन_रिबूट_की AID_SYSTEM(1000) रीबूट पर फिर से शुरू करने का समर्थन करने के लिए एंड्रॉइड के सिस्टम सर्वर द्वारा उपयोग किया जाता है।

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

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

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

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

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