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

सिस्टम ऑन अ चिप (SoC) में भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) की उपलब्धता, Android डिवाइसों को Android OS और प्लैटफ़ॉर्म सेवाओं के लिए, हार्डवेयर की मदद से सुरक्षा से जुड़ी सेवाएं उपलब्ध कराने का मौका देती है. साथ ही, यह तीसरे पक्ष के ऐप्लिकेशन को भी सुरक्षा से जुड़ी सेवाएं उपलब्ध कराने का मौका देती है. ये सेवाएं, स्टैंडर्ड Java Cryptography Architecture के Android के हिसाब से बनाए गए एक्सटेंशन के तौर पर उपलब्ध कराई जाती हैं. इसके बारे में जानने के लिए, KeyGenParameterSpec देखें.

शब्दावली

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

AndroidKeyStore

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

keystore daemon

यह एक Android सिस्टम डेमॉन है. यह Binder API के ज़रिए, Keystore की सभी सुविधाओं का ऐक्सेस देता है. यह डेमॉन, KeyMint (या Keymaster) के ज़रिए बनाए गए keyblob को सेव करने के लिए ज़िम्मेदार होता है. इनमें सीक्रेट की मटीरियल होता है. इसे इस तरह से एन्क्रिप्ट (सुरक्षित) किया जाता है कि Keystore इन्हें सेव कर सके, लेकिन इनका इस्तेमाल न कर सके या इन्हें ज़ाहिर न कर सके.

KeyMint HAL service

एक AIDL सर्वर, जो IKeyMintDevice एचएएल को लागू करता है. यह KeyMint टीए को ऐक्सेस करने की सुविधा देता है.

KeyMint का भरोसेमंद ऐप्लिकेशन (टीए)

यह एक ऐसा सॉफ़्टवेयर है जो सुरक्षित कॉन्टेक्स्ट में काम करता है. ज़्यादातर मामलों में, यह एआरएम एसओसी पर TrustZone में काम करता है. यह सभी सुरक्षित क्रिप्टोग्राफ़िक ऑपरेशन उपलब्ध कराता है. इस ऐप्लिकेशन के पास रॉ की मटीरियल का ऐक्सेस होता है. साथ ही, यह कुंजियों के इस्तेमाल की अनुमति देने से पहले, ऐक्सेस कंट्रोल से जुड़ी सभी शर्तों की पुष्टि करता है.

LockSettingsService

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

Gatekeeper TA

यह सुरक्षित एनवायरमेंट में काम करने वाला कॉम्पोनेंट है. यह उपयोगकर्ता के पासवर्ड की पुष्टि करने के लिए ज़िम्मेदार होता है. साथ ही, यह पुष्टि करने वाले टोकन जनरेट करता है. इन टोकन का इस्तेमाल, KeyMint TA को यह साबित करने के लिए किया जाता है कि किसी खास समय पर किसी उपयोगकर्ता की पुष्टि की गई थी.

फ़िंगरप्रिंट टीए

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

भवन निर्माण

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

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

इससे मिलने वाला आर्किटेक्चर कुछ ऐसा दिखता है:

पहली इमेज. KeyMint का ऐक्सेस.

KeyMint HAL API, लो लेवल का एपीआई है. इसका इस्तेमाल प्लैटफ़ॉर्म के इंटरनल कॉम्पोनेंट करते हैं. साथ ही, इसे ऐप्लिकेशन डेवलपर के लिए उपलब्ध नहीं कराया जाता. ऐप्लिकेशन के लिए उपलब्ध Java API के बारे में Android Developer साइट पर बताया गया है.

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

Android Keystore, हार्डवेयर की मदद से एन्क्रिप्ट (सुरक्षित) की गई क्रिप्टोग्राफ़िक कुंजियों को सेव करने और उनका इस्तेमाल करने के लिए एक सेंट्रल कॉम्पोनेंट उपलब्ध कराता है. इसका इस्तेमाल ऐप्लिकेशन और सिस्टम के अन्य कॉम्पोनेंट, दोनों के लिए किया जा सकता है. इसलिए, किसी भी कुंजी का ऐक्सेस आम तौर पर उस ऐप्लिकेशन या सिस्टम कॉम्पोनेंट तक सीमित होता है जिसने कुंजी बनाई है.

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

ऐक्सेस कंट्रोल की इस सुविधा के लिए, Keystore में कुंजियों की पहचान कुंजी के ब्यौरे के साथ की जाती है. यह कुंजी डिस्क्रिप्टर, उस डोमेन के बारे में बताता है जिससे डिस्क्रिप्टर जुड़ा है. साथ ही, उस डोमेन में मौजूद पहचान के बारे में भी बताता है.

Android ऐप्लिकेशन, स्टैंडर्ड Java Cryptography Architecture का इस्तेमाल करके Keystore को ऐक्सेस करते हैं. यह आर्किटेक्चर, स्ट्रिंग एलियास की मदद से कुंजियों की पहचान करता है. पहचान करने का यह तरीका, Keystore APP डोमेन पर इंटरनल तौर पर मैप करता है. साथ ही, कॉलर का यूआईडी भी शामिल किया जाता है, ताकि अलग-अलग ऐप्लिकेशन की कुंजियों को अलग किया जा सके. इससे एक ऐप्लिकेशन को दूसरे ऐप्लिकेशन की कुंजियों को ऐक्सेस करने से रोका जा सकता है.

इंटरनल तौर पर, फ़्रेमवर्क के कोड को भी एक यूनीक न्यूमेरिक key ID मिलता है. यह आईडी, कुंजी लोड होने के बाद मिलता है. इस संख्या वाले आईडी का इस्तेमाल, KEY_ID डोमेन में मौजूद मुख्य डिस्क्रिप्टर के आइडेंटिफ़ायर के तौर पर किया जाता है. हालांकि, ऐक्सेस कंट्रोल अब भी लागू होता है: अगर कोई ऐप्लिकेशन, किसी दूसरे ऐप्लिकेशन की कुंजी का आईडी ढूंढ लेता है, तो भी वह सामान्य परिस्थितियों में इसका इस्तेमाल नहीं कर सकता.

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

कीस्टोर, कुंजी के डिस्क्रिप्टर के लिए दो अन्य डोमेन भी इस्तेमाल करता है. इनका इस्तेमाल सिस्टम के अन्य कॉम्पोनेंट के लिए किया जाता है. ये ऐप्लिकेशन से बनाई गई कुंजियों के लिए उपलब्ध नहीं होते:

• BLOB डोमेन से पता चलता है कि कुंजी के ब्यौरे में कुंजी के लिए कोई आइडेंटिफ़ायर नहीं है. इसके बजाय, कुंजी के ब्यौरे में कीब्लॉब मौजूद होता है और क्लाइंट, कीब्लॉब स्टोरेज को मैनेज करता है. इसका इस्तेमाल उन क्लाइंट (उदाहरण के लिए, 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 को इन कुंजियों को पाने और इस्तेमाल करने की अनुमति देने के लिए, 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 लेबल	यूआईडी	ब्यौरा
0	su_key	लागू नहीं	सुपर यूज़र बटन. इसका इस्तेमाल सिर्फ़ userdebug और eng बिल्ड पर टेस्टिंग के लिए किया जाता है. उपयोगकर्ता के बिल्ड पर काम नहीं करता.
1	shell_key	लागू नहीं	शेल के लिए उपलब्ध नेमस्पेस. इसका इस्तेमाल ज़्यादातर टेस्टिंग के लिए किया जाता है. हालांकि, इसे कमांड लाइन से उपयोगकर्ता के बिल्ड पर भी इस्तेमाल किया जा सकता है.
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	Keystore में पुष्टि करने वाले टोकन जोड़ने के लिए ज़रूरी है. इसका इस्तेमाल, पुष्टि करने की सेवाएं देने वाली कंपनियां करती हैं. जैसे, Gatekeeper या BiometricManager.
clear_ns	किसी खास नेमस्पेस में मौजूद सभी कुकी मिटाने के लिए ज़रूरी है. इसका इस्तेमाल, ऐप्लिकेशन अनइंस्टॉल होने पर रखरखाव के तौर पर किया जाता है.
list	सिस्टम को इसकी ज़रूरत होती है, ताकि वह अलग-अलग प्रॉपर्टी के हिसाब से कुंजियों की गिनती कर सके. जैसे, मालिकाना हक या पुष्टि से जुड़ी हैं या नहीं. कॉल करने वालों को इस अनुमति की ज़रूरत नहीं होती. वे अपने नेमस्पेस की गिनती करते हैं, जो get_info अनुमति के दायरे में आते हैं.
lock	इस कुकी का इस्तेमाल, कीस्टोर को यह सूचना देने के लिए किया जाता है कि डिवाइस लॉक कर दिया गया है. इससे सुपर-कुंजियां हट जाती हैं, ताकि यह पक्का किया जा सके कि पुष्टि से जुड़ी कुंजियां उपलब्ध न हों.
unlock	इस कुकी का इस्तेमाल, कीस्टोर को यह सूचना देने के लिए किया जाता है कि डिवाइस अनलॉक हो गया है. इससे पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों को सुरक्षित रखने वाली सुपर-कुंजियों का ऐक्सेस वापस मिल जाता है.
reset	Keystore को फ़ैक्ट्री डिफ़ॉल्ट पर रीसेट करने के लिए ज़रूरी है. साथ ही, उन सभी कुंजियों को मिटाने के लिए ज़रूरी है जो Android OS के काम करने के लिए ज़रूरी नहीं हैं.

इतिहास

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

Android 6.0

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

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

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

Android 7.0

Android 7.0 में, Keymaster 2 ने कुंजी को प्रमाणित करने और वर्शन बाइंडिंग की सुविधा जोड़ी.

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

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

Android 8.0

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

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

Android 9

Android 9 में, इन अपडेट को शामिल किया गया था:

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

Android 10

Android 10 में Keymaster एचएएल का वर्शन 4.1 पेश किया गया था. इसमें ये सुविधाएं जोड़ी गई थीं:

• ऐसी कुंजियों के लिए सहायता जो डिवाइस के अनलॉक होने पर ही इस्तेमाल की जा सकती हैं
• ऐसी कुंजियों के लिए सहायता जो सिर्फ़ बूटिंग के शुरुआती चरणों में इस्तेमाल की जा सकती हैं
• हार्डवेयर रैप की गई स्टोरेज कुंजियों के लिए, सहायता की सुविधा (ज़रूरी नहीं)
• StrongBox में, डिवाइस के हिसाब से पुष्टि करने की सुविधा (ज़रूरी नहीं)

Android 12

Android 12 में नया KeyMint HAL पेश किया गया है. यह Keymaster HAL की जगह लेता है, लेकिन इसमें मिलती-जुलती सुविधाएं मिलती हैं. ऊपर दी गई सभी सुविधाओं के अलावा, KeyMint HAL में ये सुविधाएं भी शामिल हैं:

• ECDH की-एग्रीमेंट के लिए सहायता
• उपयोगकर्ता की ओर से तय की गई पुष्टि करने वाली कुंजियों के लिए सहायता
• कुंजी के लिए सहायता, जिसका इस्तेमाल सीमित बार किया जा सकता है

Android 12 में, कीस्टोर सिस्टम डेमॉन का नया वर्शन भी शामिल है. इसे Rust में फिर से लिखा गया है और इसे keystore2 के नाम से जाना जाता है

Android 13

Android 13 में KeyMint HAL का v2 जोड़ा गया है. इससे हस्ताक्षर करने और कुंजी के समझौते, दोनों के लिए Curve25519 का इस्तेमाल किया जा सकता है.