सिस्टम ऑन अ चिप
(एसओसी) में ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) की सुविधा होने से, Android डिवाइसों को हार्डवेयर की मदद से,
सुरक्षा से जुड़ी बेहतर सेवाएं देने का मौका मिलता है. ये सेवाएं Android ओएस, प्लैटफ़ॉर्म सेवाओं, और यहां तक कि
तीसरे पक्ष के ऐप्लिकेशन को भी दी जाती हैं. ये सेवाएं, Java Cryptography Architecture के स्टैंडर्ड में,
Android के हिसाब से किए गए एक्सटेंशन के तौर पर दी जाती हैं. इसके लिए,
KeyGenParameterSpec देखें.
शब्दावली
यहां कीस्टोर कॉम्पोनेंट और उनके बीच के संबंधों के बारे में खास जानकारी दी गई है.
AndroidKeyStore- यह Android फ़्रेमवर्क एपीआई और कॉम्पोनेंट है. इसका इस्तेमाल, ऐप्लिकेशन कीस्टोर की सुविधा को ऐक्सेस करने के लिए करते हैं.
यह Java Cryptography Architecture के स्टैंडर्ड एपीआई का एक वर्शन है. हालांकि, इसमें Android के हिसाब से किए गए एक्स101टेंशन भी शामिल हैं. इसमें Java कोड होता है, जो ऐप्लिकेशन के प्रोसेस स्पेस में चलता है.
AndroidKeyStoreकीस्टोर के व्यवहार के लिए ऐप्लिकेशन के अनुरोधों को कीस्टोर डेमॉन को फ़ॉरवर्ड करके पूरा करता है. - कीस्टोर डेमॉन
- यह Android सिस्टम डेमॉन है, जो Binder API के ज़रिए कीस्टोर की सभी सुविधाओं का ऐक्सेस देता है. यह डेमॉन, KeyMint (या Keymaster) के वर्शन से बनाए गए keyblobs को सेव करने के लिए ज़िम्मेदार है. इनमें सीक्रेट कुंजी का डेटा एन्क्रिप्ट (सुरक्षित) किया जाता है, ताकि कीस्टोर उन्हें सेव कर सके, लेकिन उनका इस्तेमाल न कर सके या उन्हें ज़ाहिर न कर सके.
- KeyMint HAL सेवा
- यह AIDL सर्वर है, जो
IKeyMintDeviceHAL को लागू करता है. इससे, KeyMint TA को ऐक्सेस किया जा सकता है. - KeyMint ट्रस्टेड ऐप्लिकेशन (टीए) यह सॉफ़्टवेयर, सुरक्षित कॉन्टेक्स्ट में चलता है. ज़्यादातर, यह एआरएम एसओसी पर TrustZone में चलता है. यह क्रिप्टोग्राफ़िक की सभी सुरक्षित कार्रवाइयां करता है.
- इस ऐप्लिकेशन के पास, रॉ कुंजी का डेटा ऐक्सेस करने की अनुमति होती है. साथ ही, यह कुंजियों के इस्तेमाल की अनुमति देने से पहले, ऐक्सेस कंट्रोल की सभी शर्तों की पुष्टि करता है.
LockSettingsService- यह Android सिस्टम कॉम्पोनेंट है, जो पासवर्ड और
फ़िंगरप्रिंट, दोनों की मदद से उपयोगकर्ता की पुष्टि करने के लिए ज़िम्मेदार है. यह कीस्टोर का हिस्सा नहीं है, लेकिन यह ज़रूरी है, क्योंकि कीस्टोर
पुष्टि से जुड़ी कुंजियों के कॉन्सेप्ट के साथ काम करता है. ये कुंजियां सिर्फ़ तब इस्तेमाल की जा सकती हैं, जब उपयोगकर्ता की पुष्टि हो चुकी हो.
LockSettingsServiceपुष्टि करने वाले टोकन पाने के लिए, Gatekeeper TA और Fingerprint TA के साथ इंटरैक्ट करता है. इसके बाद, यह टोकन कीस्टोर डेमॉन को देता है. इन टोकन का इस्तेमाल, KeyMint TA करता है. - Gatekeeper TA
- यह कॉम्पोनेंट, सुरक्षित एनवायरमेंट में चलता है. यह उपयोगकर्ता के पासवर्ड की पुष्टि करने और पुष्टि करने वाले टोकन जनरेट करने के लिए ज़िम्मेदार है. इन टोकन का इस्तेमाल, KeyMint TA को यह साबित करने के लिए किया जाता है कि किसी खास समय पर, किसी खास उपयोगकर्ता की पुष्टि की गई थी.
- Fingerprint TA
- यह कॉम्पोनेंट, सुरक्षित एनवायरमेंट में चलता है. यह उपयोगकर्ता के फ़िंगरप्रिंट की पुष्टि करने और पुष्टि करने वाले टोकन जनरेट करने के लिए ज़िम्मेदार है. इन टोकन का इस्तेमाल, KeyMint TA को यह साबित करने के लिए किया जाता है कि किसी खास समय पर, किसी खास उपयोगकर्ता की पुष्टि की गई थी.
वास्तुकला
Android Keystore API और KeyMint HAL, क्रिप्टोग्राफ़िक प्रिमिटिव का एक बुनियादी, लेकिन ज़रूरी सेट उपलब्ध कराते हैं. इससे, ऐक्सेस कंट्रोल वाले, हार्डवेयर की मदद से सुरक्षित कुंजियों का इस्तेमाल करके प्रोटोकॉल लागू किए जा सकते हैं.
KeyMint HAL, ओईएम की ओर से दी जाने वाली एक सेवा है. इसका इस्तेमाल, कीस्टोर सेवा, हार्डवेयर की मदद से सुरक्षित क्रिप्टोग्राफ़िक सेवाएं देने के लिए करती है. निजी कुंजी के डेटा को सुरक्षित रखने के लिए, HAL के वर्शन, उपयोगकर्ता स्पेस या कर्नेल स्पेस में, संवेदनशील कार्रवाइयां नहीं करते. इसके बजाय, Android में चलने वाली KeyMint HAL सेवा, संवेदनशील कार्रवाइयों को किसी सुरक्षित एनवायरमेंट में चलने वाले टीए को सौंपती है. आम तौर पर, यह कार्रवाइयों के अनुरोधों को किसी वर्शन के हिसाब से तय किए गए वायर फ़ॉर्मैट में मार्शल और अनमार्शल करके करती है.
इसके बाद, आर्किटेक्चर इस तरह दिखता है:
पहली इमेज. KeyMint का ऐक्सेस.
KeyMint HAL API, लो लेवल का होता है. इसका इस्तेमाल, प्लैटफ़ॉर्म के इंटरनल कॉम्पोनेंट करते हैं. इसे ऐप्लिकेशन डेवलपर के लिए उपलब्ध नहीं कराया जाता. ऐप्लिकेशन के लिए उपलब्ध, Java API के हाई लेवल के बारे में, Android डेवलपर की साइट पर बताया गया है.
ऐक्सेस कंट्रोल
Android Keystore, हार्डवेयर की मदद से सुरक्षित क्रिप्टोग्राफ़िक कुंजियों को सेव करने और उनका इस्तेमाल करने के लिए, एक सेंट्रल कॉम्पोनेंट उपलब्ध कराता है. इसका इस्तेमाल, ऐप्लिकेशन और सिस्टम के अन्य कॉम्पोनेंट, दोनों के लिए किया जा सकता है. आम तौर पर, किसी भी कुंजी का ऐक्सेस, सिर्फ़ उस ऐप्लिकेशन या सिस्टम कॉम्पोनेंट तक सीमित होता है जिसने कुंजी बनाई है.
कीस्टोर डोमेन
ऐक्सेस कंट्रोल की इस सुविधा के लिए, कुंजियों की पहचान, कीस्टोर में कुंजी के ब्यौरे से की जाती है. कुंजी का यह ब्यौरा, उस डोमेन के बारे में बताता है जिससे ब्यौरा जुड़ा है. साथ ही, यह उस डोमेन में मौजूद पहचान के बारे में भी बताता है.
Android ऐप्लिकेशन, Java Cryptography Architecture के स्टैंडर्ड का इस्तेमाल करके, कीस्टोर को ऐक्सेस करते हैं. यह आर्किटेक्चर, कुंजियों की पहचान, स्ट्रिंग एलियास से करता है. पहचान का यह तरीका, कीस्टोर के APP डोमेन से इंटरनली मैप होता है. अलग-अलग ऐप्लिकेशन की कुंजियों में अंतर करने के लिए, कॉलर का यूआईडी भी शामिल किया जाता है. इससे, कोई ऐप्लिकेशन किसी दूसरे ऐप्लिकेशन की कुंजियों को ऐक्सेस नहीं कर पाता.
इंटरनली, फ़्रेमवर्क के कोड को कुंजी लोड होने के बाद, एक यूनीक न्यूमेरिक कुंजी आईडी भी मिलती है. इस न्यूमेरिक आईडी का इस्तेमाल, KEY_ID डोमेन में मौजूद कुंजी के ब्यौरों के आइडेंटिफ़ायर के तौर पर किया जाता है. हालांकि, ऐक्सेस कंट्रोल अब भी लागू होता है. भले ही, किसी ऐप्लिकेशन को किसी दूसरे ऐप्लिकेशन की कुंजी का आईडी मिल जाए, लेकिन सामान्य परिस्थितियों में वह उसका इस्तेमाल नहीं कर सकता.
हालांकि, किसी ऐप्लिकेशन के पास, किसी दूसरी ऐप्लिकेशन (यूआईडी से पहचान की गई) को कुंजी का इस्तेमाल करने की अनुमति देने का विकल्प होता है. अनुमति देने की इस कार्रवाई से, अनुमति का एक यूनीक आइडेंटिफ़ायर मिलता है. इसका इस्तेमाल, GRANT डोमेन में मौजूद कुंजी के ब्यौरों के आइडेंटिफ़ायर के तौर पर किया जाता है. यहां भी, ऐक्सेस कंट्रोल अब भी लागू होता है. भले ही, किसी तीसरे ऐप्लिकेशन को अनुमति पाने वाले ऐप्लिकेशन की कुंजी का आईडी मिल जाए, लेकिन वह उसका इस्तेमाल नहीं कर सकता.
कीस्टोर, कुंजी के ब्यौरों के लिए दो अन्य डोमेन के साथ भी काम करता है. इनका इस्तेमाल, सिस्टम के अन्य कॉम्पोनेंट के लिए किया जाता है. ये डोमेन, ऐप्लिकेशन से बनाई गई कुंजियों के लिए उपलब्ध नहीं होते:
BLOBडोमेन से पता चलता है कि कुंजी के ब्यौरे में, कुंजी के लिए कोई आइडेंटिफ़ायर नहीं है. इसके बजाय, कुंजी के ब्यौरे में keyblob और क्लाइंट, keyblob स्टोरेज को हैंडल करता है. इसका इस्तेमाल, उन क्लाइंट (उदाहरण के लिए,vold) के लिए किया जाता है जिन्हें डेटा पार्टिशन माउंट होने से पहले, कीस्टोर को ऐक्सेस करना होता है.SELINUXडोमेन की मदद से, सिस्टम के कॉम्पोनेंट, कुंजियों को शेयर कर सकते हैं. इनका ऐक्सेस, एक न्यूमेरिक आइडेंटिफ़ायर से नियंत्रित किया जाता है. यह आइडेंटिफ़ायर, SELinux लेबल से मेल खाता है. ज़्यादा जानकारी के लिए, keystore_key के लिए SELinux नीति देखें.
keystore_key के लिए SELinux नीति
Domain::SELINUX कुंजी के ब्यौरों के लिए इस्तेमाल की जाने वाली आइडेंटिफ़ायर वैल्यू, keystore2_key_context SELinux नीति की फ़ाइल में कॉन्फ़िगर की जाती हैं.
इन फ़ाइलों में मौजूद हर लाइन, किसी न्यूमेरिक को 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
SELINUX डोमेन में, आईडी 102 वाली कुंजी को ऐक्सेस करने के लिए, कॉम्पोनेंट के पास उससे जुड़ी SELinux नीति होनी चाहिए. उदाहरण के लिए, wpa_supplicant को ये कुंजियां पाने और उनका इस्तेमाल करने की अनुमति देने के लिए, hal_wifi_supplicant.te में यह लाइन जोड़ें:
allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };
Domain::SELINUX कुंजियों के लिए न्यूमेरिक आइडेंटिफ़ायर को, अलग-अलग पार्टिशन के साथ काम करने के लिए, रेंज में बांटा जाता है, ताकि कोई टकराव न हो:
| बंटवारा | सीमा | कॉन्फ़िगरेशन फ़ाइलें |
|---|---|---|
| सिस्टम | 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
|
सिस्टम पार्टिशन के लिए, ये खास वैल्यू तय की गई हैं:
| नेमस्पेस ID | SEPolicy लेबल | UID | ब्यौरा |
|---|---|---|---|
| 0 | su_key |
लागू नहीं | सुपर यूज़र कुंजी. इसका इस्तेमाल, सिर्फ़ userdebug और eng बिल्ड पर जांच के लिए किया जाता है. यह user बिल्ड पर लागू नहीं होती. |
| 1 | shell_key |
लागू नहीं | शेल के लिए उपलब्ध नेमस्पेस. इसका इस्तेमाल ज़्यादातर जांच के लिए किया जाता है, लेकिन इसे कमांड लाइन से user बिल्ड पर भी इस्तेमाल किया जा सकता है. |
| 100 | vold_key |
लागू नहीं | इसका इस्तेमाल, vold के लिए किया जाता है. |
| 101 | odsign_key |
लागू नहीं | इसका इस्तेमाल, डिवाइस पर साइन करने वाले डेमॉन के लिए किया जाता है. |
| 102 | wifi_key |
AID_WIFI(1010) |
इसका इस्तेमाल, Android के वाई-फ़ाई सबसिस्टम के लिए किया जाता है. इसमें wpa_supplicant भी शामिल है. |
| 103 | locksettings_key |
लागू नहीं | इसका इस्तेमाल, LockSettingsService के लिए किया जाता है |
| 120 | resume_on_reboot_key |
AID_SYSTEM(1000) |
इसका इस्तेमाल, Android के सिस्टम सर्वर के लिए किया जाता है, ताकि रीबूट करने पर फिर से शुरू करने की सुविधा दी जा सके. |
ऐक्सेस वेक्टर
कीस्टोर, किसी कुंजी पर की जा सकने वाली कार्रवाइयों को कंट्रोल करने की सुविधा देता है. इसके अलावा, यह किसी कुंजी के पूरे ऐक्सेस को भी कंट्रोल करता है. keystore2_key
अनुमतियों के बारे में,
KeyPermission.aidl
फ़ाइल में बताया गया है.
सिस्टम अनुमतियां
keystore_key के लिए SELinux नीति में बताई गई, हर कुंजी के लिए ऐक्सेस कंट्रोल के अलावा, यहां दी गई टेबल में अन्य SELinux अनुमतियों के बारे में बताया गया है. ये अनुमतियां, सिस्टम और रखरखाव से जुड़ी अलग-अलग कार्रवाइयां करने के लिए ज़रूरी हैं:
| अनुमति | मतलब |
|---|---|
add_auth
|
कीस्टोर में पुष्टि करने वाले टोकन जोड़ने के लिए ज़रूरी है. इसका इस्तेमाल, पुष्टि करने वाले प्रोवाइडर करते हैं. जैसे, Gatekeeper या BiometricManager. |
clear_ns
|
किसी खास नेमस्पेस में मौजूद सभी कुंजियों को मिटाने के लिए ज़रूरी है. इसका इस्तेमाल, ऐप्लिकेशन अनइंस्टॉल किए जाने पर, रखरखाव की कार्रवाई के तौर पर किया जाता है. |
list
|
सिस्टम को, मालिकाना हक या पुष्टि से जुड़ी होने जैसी अलग-अलग प्रॉपर्टी के हिसाब से कुंजियों की गिनती करने के लिए ज़रूरी है. कॉलर को अपने नेमस्पेस की गिनती करने के लिए, इस अनुमति की ज़रूरत नहीं होती. यह अनुमति, get_info अनुमति के तहत आती है. |
lock
|
कीस्टोर को यह सूचना देने के लिए ज़रूरी है कि डिवाइस लॉक कर दिया गया है. इससे, सुपर-कुंजियों को हटा दिया जाता है, ताकि पुष्टि से जुड़ी कुंजियां उपलब्ध न हों. |
unlock
|
कीस्टोर को यह सूचना देने के लिए ज़रूरी है कि डिवाइस अनलॉक कर दिया गया है. इससे, उन सुपर-कुंजियों का ऐक्सेस वापस मिल जाता है जो पुष्टि से जुड़ी कुंजियों को सुरक्षित रखती हैं. |
reset
|
कीस्टोर को फ़ैक्ट्री डिफ़ॉल्ट पर रीसेट करने के लिए ज़रूरी है. इससे, वे सभी कुंजियां मिट जाती हैं जो Android OS के काम करने के लिए ज़रूरी नहीं हैं. |
इतिहास
Android 5 और इससे पुराने वर्शन में, Android के पास हार्डवेयर की मदद से सुरक्षित क्रिप्टोग्राफ़िक सेवाओं का एक आसान एपीआई था. यह एपीआई, Keymaster हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) के 0.2 और 0.3 वर्शन से मिला था. कीस्टोर, डिजिटल साइनिंग और पुष्टि करने की कार्रवाइयां करता था. इसके अलावा, यह एसिमेट्रिक साइनिंग कुंजी के जोड़े जनरेट और इंपोर्ट भी करता था. यह सुविधा, कई डिवाइसों पर पहले से लागू है. हालांकि, सुरक्षा के कई लक्ष्यों को सिर्फ़ सिग्नेचर एपीआई की मदद से आसानी से हासिल नहीं किया जा सकता. Android 6.0 में, कीस्टोर एपीआई को बढ़ाकर, ज़्यादा सुविधाएं दी गईं.
Android 6.0
Android 6.0 में, Keymaster 1.0 में सिमेट्रिक क्रिप्टोग्राफ़िक प्रिमिटिव, एईएस और एचएमएसी, और हार्डवेयर की मदद से सुरक्षित कुंजियों के लिए ऐक्सेस कंट्रोल सिस्टम जोड़ा गया. कुंजी जनरेट करने के दौरान, ऐक्सेस कंट्रोल तय किए जाते हैं. ये कंट्रोल, कुंजी के लाइफ़टाइम के लिए लागू होते हैं. कुंजियों को सिर्फ़ तब इस्तेमाल किया जा सकता है, जब उपयोगकर्ता की पुष्टि हो चुकी हो. साथ ही, इन्हें सिर्फ़ तय किए गए मकसद या तय किए गए क्रिप्टोग्राफ़िक पैरामीटर के साथ इस्तेमाल किया जा सकता है.
Android 6.0 में, क्रिप्टोग्राफ़िक प्रिमिटिव की रेंज बढ़ाने के अलावा, कीस्टोर में ये सुविधाएं जोड़ी गईं:
- कुंजी के इस्तेमाल को सीमित करने के लिए, इस्तेमाल कंट्रोल स्कीम. इससे, कुंजियों के दुरुपयोग की वजह से सुरक्षा से जुड़े जोखिम को कम किया जा सकता है
- कुंजियों को तय किए गए उपयोगकर्ताओं, क्लाइंट, और तय की गई समयावधि तक सीमित करने के लिए, ऐक्सेस कंट्रोल स्कीम
Android 7.0
Android 7.0 में, Keymaster 2 में कुंजी की पुष्टि करने और वर्शन बाइंडिंग की सुविधा जोड़ी गई.
कुंजी की पुष्टि करने की सुविधा सार्वजनिक कुंजी सर्टिफ़िकेट उपलब्ध कराती है. इनमें कुंजी और उसके ऐक्सेस कंट्रोल के बारे में पूरी जानकारी होती है. इससे, सुरक्षित हार्डवेयर में कुंजी के मौजूद होने और उसके कॉन्फ़िगरेशन की पुष्टि, रिमोट तरीके से की जा सकती है.
वर्शन बाइंडिंग की मदद से, कुंजियों को ऑपरेटिंग सिस्टम और पैच लेवल वर्शन से बाइंड किया जाता है. इससे, अगर किसी हमलावर को सिस्टम या टीईई सॉफ़्टवेयर के पुराने वर्शन में कोई गड़बड़ी मिलती है, तो वह डिवाइस को गड़बड़ी वाले वर्शन पर वापस नहीं ले जा सकता. साथ ही, वह नए वर्शन से बनाई गई कुंजियों का इस्तेमाल नहीं कर सकता. इसके अलावा, जब किसी डिवाइस को नए वर्शन या पैच लेवल पर अपग्रेड किया जाता है, तो उस पर किसी वर्शन और पैच लेवल वाली कुंजी का इस्तेमाल करने से पहले, कुंजी को अपग्रेड किया जाता है. साथ ही, कुंजी का पिछला वर्शन अमान्य कर दिया जाता है. डिवाइस को अपग्रेड करने पर, कुंजियां भी डिवाइस के साथ आगे बढ़ती हैं. हालांकि, डिवाइस को पिछली रिलीज़ पर वापस ले जाने पर, कुंजियों का इस्तेमाल नहीं किया जा सकता.
Android 8.0
Android 8.0 में, Keymaster 3 को पुराने स्टाइल के सी-स्ट्रक्चर HAL से, नए हार्डवेयर इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एचआईडीएल) में मौजूद डेफ़िनिशन से जनरेट किए गए C++ HAL इंटरफ़ेस में ट्रांज़िशन किया गया. बदलाव के तहत, आर्ग्युमेंट के कई टाइप बदल गए. हालांकि, टाइप और तरीकों का पुराने टाइप और एचएएल स्ट्रक्ट के तरीकों से वन-टू-वन कॉरेस्पॉन्डेंस है.
इस इंटरफ़ेस में बदलाव के अलावा, Android 8.0 में Keymaster 2 की पुष्टि करने की सुविधा को बढ़ाकर, आईडी की पुष्टि करने की सुविधा जोड़ी गई. आईडी की पुष्टि करने की सुविधा, हार्डवेयर आइडेंटिफ़ायर की पुष्टि करने के लिए, सीमित और वैकल्पिक तरीका उपलब्ध कराती है. जैसे, डिवाइस का सीरियल नंबर, प्रॉडक्ट का नाम, और फ़ोन आईडी (आईएमईआई या एमईआईडी). इस सुविधा को लागू करने के लिए, Android 8.0 में एएसएन.1 पुष्टि करने के स्कीमा में बदलाव किया गया, ताकि आईडी की पुष्टि करने की सुविधा जोड़ी जा सके. Keymaster के वर्शन को, काम के डेटा आइटम को पाने के लिए, कोई सुरक्षित तरीका ढूंढना होगा. साथ ही, इस सुविधा को सुरक्षित और हमेशा के लिए बंद करने के लिए, कोई तरीका तय करना होगा.
Android 9
Android 9 में, ये अपडेट शामिल थे:
- Keymaster 4 पर अपडेट
- एम्बेड किए गए सुरक्षित एलिमेंट के लिए सहायता
- सुरक्षित कुंजी इंपोर्ट करने के लिए सहायता
- 3DES एन्क्रिप्शन के लिए सहायता
- वर्शन बाइंडिंग में बदलाव, ताकि
boot.imgऔरsystem.imgके लिए अलग-अलग वर्शन सेट किए जा सकें. इससे, इन्हें अलग-अलग अपडेट किया जा सकेगा
Android 10
Android 10 में, Keymaster HAL का वर्शन 4.1 लॉन्च किया गया. इसमें ये सुविधाएं जोड़ी गईं:
- ऐसी कुंजियों के लिए सहायता जो सिर्फ़ तब इस्तेमाल की जा सकती हैं, जब डिवाइस अनलॉक हो
- ऐसी कुंजियों के लिए सहायता जो सिर्फ़ बूट के शुरुआती चरणों में इस्तेमाल की जा सकती हैं
- हार्डवेयर-रैप किए गए स्टोरेज कुंजियों के लिए वैकल्पिक सहायता
- StrongBox में, डिवाइस के लिए यूनीक पुष्टि करने की सुविधा के लिए वैकल्पिक सहायता
Android 12
Android 12 में, नया KeyMint HAL लॉन्च किया गया. यह Keymaster HAL की जगह लेता है, लेकिन यह उसी तरह की सुविधाएं देता है. ऊपर बताई गई सभी सुविधाओं के अलावा, KeyMint HAL में ये सुविधाएं भी शामिल हैं:
- ईसीडीएच कुंजी एग्रीमेंट के लिए सहायता
- उपयोगकर्ता की ओर से तय की गई पुष्टि करने वाली कुंजियों के लिए सहायता
- ऐसी कुंजियों के लिए सहायता जिनका इस्तेमाल सीमित बार किया जा सकता है
Android 12 में, कीस्टोर सिस्टम डेमॉन का नया वर्शन भी शामिल है. इसे Rust में फिर से लिखा गया है और इसे keystore2 के तौर पर जाना जाता है
Android 13
Android 13 में, KeyMint HAL का v2 जोड़ा गया. इसमें, साइनिंग और कुंजी एग्रीमेंट, दोनों के लिए Curve25519 के लिए सहायता जोड़ी गई है.