Google 致力于为黑人社区推动种族平等。查看具体举措
इस पेज का अनुवाद Cloud Translation API से किया गया है.
Switch to English

हार्डवेयर समर्थित Keystore

चिप (SoC) पर एक सिस्टम में एक विश्वसनीय निष्पादन वातावरण की उपलब्धता एंड्रॉइड डिवाइसों को एंड्रॉइड ओएस के लिए हार्डवेयर-समर्थित, मजबूत सुरक्षा सेवाएं प्रदान करने, प्लेटफ़ॉर्म सेवाओं और यहां तक ​​कि तृतीय-पक्ष एप्लिकेशन के लिए अवसर प्रदान करती है। 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 के सत्यापन सुविधा का विस्तार करता है । आईडी अटैचमेंट हार्डवेयर पहचानकर्ताओं, जैसे डिवाइस सीरियल नंबर, उत्पाद का नाम, और फोन आईडी (IMEI / MEID) को दृढ़ता से सत्यापित करने के लिए एक सीमित और वैकल्पिक तंत्र प्रदान करता है। इस जोड़ को लागू करने के लिए, ID attestation को जोड़ने के लिए ASN.1 अटेस्टेशन स्कीमा को बदलें। कीमास्टर कार्यान्वयन को संबंधित डेटा आइटम को पुनः प्राप्त करने के लिए कुछ सुरक्षित तरीके खोजने की आवश्यकता है, साथ ही सुविधा को सुरक्षित और स्थायी रूप से अक्षम करने के लिए एक तंत्र को परिभाषित करना है।

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

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

शब्दकोष

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

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

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

कीमास्टर एक एचआईडीएल सर्वर है जो कीमास्टर टीए तक पहुंच प्रदान करता है। (यह नाम मानकीकृत नहीं है और वैचारिक उद्देश्यों के लिए है।)

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

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

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

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

आर्किटेक्चर

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

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

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

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

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

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

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

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

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

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

HIDL अवलोकन

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

HIDL इंटरफेस के रूप में व्यक्त तरीकों का एक सेट से मिलकर बनता है:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

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

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

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

यह कीमास्टर 2 एचएएल से निम्नलिखित के बराबर है:

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 मानों का एक वेक्टर शामिल है।

H ++L संकलक द्वारा उत्पन्न 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 में डिफ़ॉल्ट कार्यान्वयन देखें। डिफ़ॉल्ट कार्यान्वयन पुराने-शैली कीमास्टर 0, कीमास्टर 1, या कीमास्टर 2 HALS युक्त उपकरणों के लिए पिछड़ी संगतता प्रदान करता है।

अभिगम नियंत्रण

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

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

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

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

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

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

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

कीस्टोरे_की के लिए SELinux नीति

Namespace लेबल 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 को नए नामस्थान में कुंजियों को प्राप्त करने और उपयोग करने की अनुमति wpa_supplicant लिए हम निम्नलिखित पंक्ति को hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_keys:keystore2_key { get, use };

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

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

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

किसी दिए गए नामस्थान में एक कुंजी उत्पन्न करने के लिए, नामस्थान आईडी KeyGenParameterSpec.Builder#setNamespace(): का उपयोग करके दिया जाना चाहिए 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 08 बी 596 एफ 410

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

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

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

पहुंच क्षेत्र

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

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

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

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