हार्डवेयर-बैक्ड कीस्टोर

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

Android 6.0 से पहले, Android में पहले से ही एक सामान्य, हार्डवेयर-बैक्ड क्रिप्टो पहले से मौजूद था services API, जो की-मास्टर हार्डवेयर के 0.2 और 0.3 वर्शन से मिलता है ऐब्स्ट्रैक्शन लेयर (एचएएल). कीस्टोर ने डिजिटल हस्ताक्षर और पुष्टि की सुविधा दी है इसमें साइन इन करने की ज़रूरी शर्तें और एसिमेट्रिक साइनिंग पासकोड के जोड़े जनरेट करना और इंपोर्ट करना शामिल है. यह है कई डिवाइसों पर पहले ही लागू किया जा चुका है, लेकिन सुरक्षा से जुड़े ऐसे कई लक्ष्य हैं जो को सिर्फ़ सिग्नेचर एपीआई की मदद से ऐक्सेस नहीं किया जा सकता. Android 6.0 में कीस्टोर हमने कई तरह की सुविधाएं देने के लिए, Keystore API को बढ़ाया है.

Android 6.0 में, कीस्टोर जोड़ा गया सिमेट्रिक क्रिप्टोग्राफ़िक प्रिमिटिव, AES और HMAC, और हार्डवेयर-बैक्ड कुंजियों के लिए ऐक्सेस कंट्रोल सिस्टम. ऐक्सेस करने का अधिकार कंट्रोल, कुंजी जनरेट करने के दौरान तय किए जाते हैं और सुरक्षा कुंजी. जब उपयोगकर्ता किसी प्रमाणित किया गया है और सिर्फ़ खास मकसद के लिए या बताए गए क्रिप्टोग्राफ़िक तरीके से बनाया गया है पैरामीटर का इस्तेमाल करें. ज़्यादा जानकारी के लिए, देखें अनुमति टैग और फ़ंक्शन पेज.

क्रिप्टोग्राफ़िक प्रिमिटिव की सीमा बढ़ाने के अलावा, कीस्टोर Android 6.0 में ये सुविधाएं जोड़ी गई हैं:

• पासकोड के इस्तेमाल को सीमित करने के लिए इस्तेमाल कंट्रोल स्कीम, ताकि समस्या को कम किया जा सके कुंजियों के गलत इस्तेमाल की वजह से सुरक्षा से छेड़छाड़ का खतरा
• खास उपयोगकर्ताओं के लिए कुंजियों पर पाबंदी लगाने की सुविधा चालू करने के लिए ऐक्सेस कंट्रोल स्कीम, क्लाइंट, और एक परिभाषित समय सीमा है

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

वर्शन बाइंडिंग ऑपरेटिंग सिस्टम और पैच लेवल वर्शन की कुंजियों को बाइंड करता है. इससे पक्का होता है कि किसी हमलावर को सिस्टम के पुराने वर्शन में किसी गड़बड़ी का पता चलता है या TEE सॉफ़्टवेयर, डिवाइस को जोखिम वाले वर्शन पर वापस नहीं ला सकता. साथ ही, वह कुंजियों का इस्तेमाल नहीं कर सकता नए वर्शन की मदद से बनाया गया. इसके अलावा, जब किसी दिए गए वर्शन वाली कुंजी और पैच लेवल का इस्तेमाल ऐसे डिवाइस पर किया जाता है जिसे नए वर्शन पर अपग्रेड किया गया है या पैच लेवल है, तो कुंजी के उपयोग किए जाने से पहले उसे अपग्रेड किया जाता है, और पिछले कुंजी का वर्शन अमान्य हो गया है. डिवाइस अपग्रेड होने पर, "रच" चाबियां डिवाइस के साथ फ़ॉरवर्ड करना, लेकिन डिवाइस के पिछले वर्शन पर वापस जाना रिलीज़ करने से कुंजियों का इस्तेमाल नहीं किया जा सकता.

Android 8.0 में, KeyMaster 3 को पुरानी शैली के सी-स्ट्रक्चर हार्डवेयर से ट्रांसफ़र किया गया डेफ़िनिशन से जनरेट की गई C++ HAL इंटरफ़ेस में ऐब्स्ट्रैक्शन लेयर (HAL) का डेटा में एक नई सुविधा जोड़ी है. इस बदलाव के तहत, आर्ग्युमेंट के कई टाइप बदल गए हैं. हालांकि, टाइप और मेथड के तौर पर वन-टू-वन के तरीके से मेल खाता है. ज़्यादा जानकारी के लिए, ज़्यादा जानकारी के लिए, फ़ंक्शन पेज विवरण.

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

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

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

शब्दावली

यहां कीस्टोर कॉम्पोनेंट और उनके संबंधों की खास जानकारी दी गई है.

AndroidKeystore Android फ़्रेमवर्क एपीआई और इस्तेमाल किया जाने वाला कॉम्पोनेंट है कीस्टोर सुविधाओं को ऐक्सेस करने के लिए ऐप्लिकेशन के ज़रिए. इसे एक्सटेंशन के रूप में लागू किया जाता है, का इस्तेमाल करके स्टैंडर्ड Java क्रिप्टोग्राफ़ी आर्किटेक्चर एपीआई का इस्तेमाल किया जा सकता है. साथ ही, इसमें Java कोड शामिल है, जो ऐप्लिकेशन के अपने प्रोसेस स्पेस में चलता है. AndroidKeystore ऐप्लिकेशन पूरा करता है कीस्टोर डीमन पर फ़ॉरवर्ड करके, कीस्टोर व्यवहार के लिए अनुरोधों को सबमिट करता है.

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

keyMasterd एक HIDL सर्वर है, जो कीमास्टर टीए. (यह नाम स्टैंडर्ड के मुताबिक नहीं है और इसका इस्तेमाल सैद्धांतिक तौर पर किया जाता है.)

KeyMaster TA (भरोसेमंद ऐप्लिकेशन) एक ऐसा सॉफ़्टवेयर है जो एक सुरक्षित कॉन्टेक्स्ट है. अक्सर इसे ARM SoC पर TrustZone में शामिल किया जाता है. इससे कीस्टोर ऑपरेशन सुरक्षित होते हैं, इसमें रॉ कुंजी मटीरियल का ऐक्सेस होता है, और यह बटन वगैरह पर ऐक्सेस कंट्रोल की शर्तें

LockSettingsService Android सिस्टम का एक ऐसा कॉम्पोनेंट है जो उपयोगकर्ता की पुष्टि करने के लिए, पासवर्ड और फ़िंगरप्रिंट, दोनों का इस्तेमाल किया जा सकता है. यह इसका हिस्सा नहीं है कीस्टोर, लेकिन प्रासंगिक है, क्योंकि कई कीस्टोर कुंजी से जुड़े कामों के लिए उपयोगकर्ता की ज़रूरत होती है पुष्टि करने के लिए. LockSettingsService, गेटकीपर से इंटरैक्ट करता है TA और फ़िंगरप्रिंट TA, पुष्टि करने वाले टोकन पाने के लिए, जिसे वह कीस्टोर डीमन का इस्तेमाल करता है और जिसका इस्तेमाल आखिरकार KeyMaster TA करता है का इस्तेमाल करें.

गेटकीपर टीए (भरोसेमंद ऐप्लिकेशन) एक और कॉम्पोनेंट है सुरक्षित कॉन्टेक्स्ट में इस्तेमाल किया जा रहा है. इसकी पुष्टि उपयोगकर्ता की पुष्टि करने के लिए होती है पासवर्ड बनाने और पुष्टि करने वाले टोकन जनरेट करने की सुविधा देता है, जिनका इस्तेमाल KeyMaster TA को साबित करने के लिए किया जाता है यह पता चलता है कि किसी खास उपयोगकर्ता के लिए, खास समय पर पुष्टि की गई थी समय.

फ़िंगरप्रिंट टीए (भरोसेमंद ऐप्लिकेशन) एक और कॉम्पोनेंट है सुरक्षित कॉन्टेक्स्ट में चलता है जो उपयोगकर्ता की पुष्टि करने के लिए ज़िम्मेदार है कीमास्टर को साबित करने के लिए इस्तेमाल किए जाने वाले फ़िंगरप्रिंट और पुष्टि करने वाले टोकन जनरेट करना टीए कि एक खास पॉइंट पर किसी खास उपयोगकर्ता के लिए पुष्टि की गई थी समय पर.

भवन निर्माण

Android Keystore API और बुनियादी तौर पर मौजूद KeyMaster HAL क्रिप्टोग्राफ़िक प्रिमिटिव का बेसिक लेकिन काफ़ी सेट उपलब्ध कराना होगा, ताकि ऐक्सेस-कंट्रोल वाली, हार्डवेयर-बैक्ड कुंजियों का इस्तेमाल करके, प्रोटोकॉल लागू करना.

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

पहला डायग्राम. कीमास्टर का ऐक्सेस

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

कीमास्टर एचएएल का मकसद, सुरक्षा के लिए संवेदनशील जानकारी को लागू करना नहीं है एल्गोरिदम के लिए किया जाता है, लेकिन सुरक्षित दुनिया के लिए सिर्फ़ मार्शल और अनमार्शल के अनुरोधों के लिए. कॉन्टेंट बनाने वायर फ़ॉर्मैट लागू करना तय है.

पिछले वर्शन के साथ काम करता है वर्शन

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

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

Android 8.0 में, KeyMaster 3 को पुरानी शैली के C-स्ट्रक्चर से बदल दिया गया HAL से C++ HAL इंटरफ़ेस तक को नई परिभाषा में जनरेट किया गया है हार्डवेयर इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एचआईडीएल). नई शैली का एचएएल लागू करने के लिए, जनरेट की गई IKeymasterDevice क्लास और प्योर वर्चुअल को लागू करना तरीकों का इस्तेमाल करना होगा. बदलाव के हिस्से के तौर पर, कई आर्ग्युमेंट टाइप बदल गए हैं, हालांकि, टाइप और मेथड से पुराने टाइप और एचएएल स्ट्रक्चर के तरीके का इस्तेमाल करना है.

HIDL खास जानकारी

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

HIDL इंटरफ़ेस में तरीकों का एक सेट होता है, जिन्हें इस तरह से दिखाया जाता है:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

पहले से तय किए गए कई टाइप होते हैं. एचएएल, नई इनयूमरेटेड और स्ट्रक्चर के टाइप. एचआईडीएल के बारे में ज़्यादा जानकारी पाने के लिए, रेफ़रंस सेक्शन देखें.

कीमास्टर 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 आर्ग्युमेंट में अब कोई निर्देश नहीं है पॉइंटर जो 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, फ़ंक्शन पॉइंटर को इस तरह परिभाषित करता है:

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

इसका मतलब है कि generateKey_cb एक ऐसा फ़ंक्शन है जो रिटर्न वैल्यू को लेता है जनरेट क्लॉज़ में दी गई सूची में शामिल है. HAL लागू करने वाली क्लास इसे बदल देती है generateKey तरीका है और generateKey_cb फ़ंक्शन को कॉल करता है पॉइंटर का इस्तेमाल करें. फ़ंक्शन को नोट करें पॉइंटर कॉल सिंक्रोनस है. कॉल करने वाला (कॉलर) कॉल करता है generateKey और generateKey दिए गए कॉल फ़ंक्शन पॉइंटर, जो पूरा होने तक एक्ज़ीक्यूट करता है और फिर generateKey लागू करना, जो इसके बाद कॉलर को वापस दे देता है.

बेहतर उदाहरण के लिए, डिफ़ॉल्ट रूप से लागू होने वाला यह तरीका देखें hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp. डिफ़ॉल्ट रूप से लागू किया गया तरीका, ऐसे डिवाइसों के लिए पुराने सिस्टम के साथ काम करता है जिनमें पुरानी शैली के keyMaster0, keyMaster1 या keyMaster2 HALS.

ऐक्सेस कंट्रोल

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

वेंडर के कॉम्पोनेंट शामिल करने और ऐक्सेस कंट्रोल को सामान्य बनाने के लिए हार्ड कोड किए गए अपवादों के बिना, कीस्टोर 2.0 में डोमेन और SELinux पेश करते हैं नेमस्पेस.

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

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

हमने पांच डोमेन पैरामीटर शुरू किए हैं, जो यह तय करते हैं कि कुंजियों को कैसे ऐक्सेस किया जा सकता है. वे की डिस्क्रिप्टर के नेमस्पेस पैरामीटर के सिमेंटिक्स को कंट्रोल करते हैं और ऐक्सेस कंट्रोल कैसे किया जाता है.

• DOMAIN_APP: ऐप्लिकेशन का डोमेन पुराना व्यवहार. Java कीस्टोर SPI, डिफ़ॉल्ट रूप से इस डोमेन का इस्तेमाल करता है. जब यह डोमेन का इस्तेमाल किया जाता है, नेमस्पेस आर्ग्युमेंट को अनदेखा कर दिया जाता है और कॉलर का यूआईडी का इस्तेमाल किया गया है. इस डोमेन की ऐक्सेस को SELinux नीति की keystore_key क्लास के बारे में ज़्यादा जानें.
• DOMAIN_SELINUX: यह डोमेन बताता है कि नेमस्पेस में SELinux नीति में एक लेबल है. नेमस्पेस पैरामीटर देखा गया किया गया है और उसे टारगेट कॉन्टेक्स्ट में अनुवाद किया गया है. साथ ही, keystore_key क्लास के लिए, SELinux को कॉल करने का कॉन्टेक्स्ट. जब दी गई कार्रवाई के लिए अनुमति तय की गई है, पूरे टपल का इस्तेमाल किया जाता है का भी इस्तेमाल किया जा सकता है.
• DOMAIN_GRANT: अनुदान डोमेन यह बताता है कि नेमस्पेस पैरामीटर, ग्रांट आइडेंटिफ़ायर है. उपनाम पैरामीटर को अनदेखा किया जाता है. अनुदान मिलने के बाद, SELinux की जांच की जाती है. ऐक्सेस कंट्रोल करने की बेहतर सुविधा सिर्फ़ यह जांच करता है कि कॉल करने वाले का यूआईडी, अनुरोध किए गए अनुदान के लिए अनुदान पाने वाले का यूआईडी मेल खाता है या नहीं.
• DOMAIN_KEY_ID: यह डोमेन बताता है कि नेमस्पेस पैरामीटर एक यूनीक की आईडी है. ऐसा हो सकता है कि कुंजी को अपने-आप बनाया गया हो DOMAIN_APP या DOMAIN_SELINUX के साथ. अनुमति domain और namespace के बाद जांच की जाती है कुंजी डेटाबेस से उसी तरह लोड किए गए हों जैसे ब्लॉब को लोड किया जाता था डोमेन, नेमस्पेस, और एलियास टपल से. कुंजी आईडी डोमेन इस्तेमाल करने की वजह एक निरंतरता है. अन्य नाम से कुंजी ऐक्सेस करने पर, बाद वाले कॉल इस पर चल सकते हैं क्योंकि एक नई कुंजी जनरेट या इंपोर्ट की गई है और बाउंड और इस उपनाम को. हालांकि, कुंजी का आईडी कभी नहीं बदलता. इसलिए कुंजी आईडी से कुंजी का उपयोग करते समय के बाद इसे कीस्टोर डेटाबेस से लोड किए जाने के बाद, एक बार उपनाम का इस्तेमाल करके, यह पक्का हो सकता है कि वह समान कुंजी है, लेकिन कुंजी आईडी अब भी मौजूद है. यह काम करने का ऐक्सेस, ऐप्लिकेशन डेवलपर को नहीं मिलता है. इसके बजाय, इसका इस्तेमाल Android कीस्टोर SPI का इस्तेमाल करने पर भी आपको बेहतर अनुभव मिलता है असुरक्षित तरीके से.
• DOMAIN_BLOB: 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);

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

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

क्लाइंट, SELinux डोमेन और वर्चुअल नेमस्पेस, इस मामले में "wifi_key", उसके अंकों वाले आईडी से.

इसके ऊपर, ये नेमस्पेस तय किए गए हैं. अगर वे नीचे दी गई टेबल में उस यूआईडी के बारे में बताया गया है जिसका इस्तेमाल करके से.

ऐक्सेस वेक्टर

SELinux क्लास keystore_key काफ़ी पुराना है और कुछ अनुमतियां, जैसे कि verify या sign खो गई हैं उनका मतलब भी. ये रही अनुमतियों का नया सेट, keystore2_key, जिसे कीस्टोर 2.0 लागू करेगा.

साथ ही, हमने गैर-खास कीस्टोर अनुमतियों के एक सेट को SELinux सिक्योरिटी क्लास keystore2: