सिस्टम ऑन चिप (SoC) में भरोसेमंद एक्सीक्यूशन एनवायरमेंट की उपलब्धता, Android डिवाइसों को Android OS, प्लैटफ़ॉर्म सेवाओं, और यहां तक कि तीसरे पक्ष के ऐप्लिकेशन को हार्डवेयर की मदद से बेहतर सुरक्षा सेवाएं देने का मौका देती है. यह सेवा, स्टैंडर्ड Java क्रिप्टोग्राफ़ी आर्किटेक्चर के लिए Android के खास एक्सटेंशन के तौर पर मिलती है. ज़्यादा जानकारी के लिए, KeyGenParameterSpec देखें.
शब्दावली
यहां पासकोड के कॉम्पोनेंट और उनके बीच के संबंधों के बारे में खास जानकारी दी गई है.
AndroidKeyStore- Android फ़्रेमवर्क एपीआई और कॉम्पोनेंट, जिसका इस्तेमाल ऐप्लिकेशन, पासकोड सेव करने की सुविधा को ऐक्सेस करने के लिए करते हैं. यह स्टैंडर्ड Java Cryptography Architecture API को लागू करने का एक तरीका है. साथ ही, इसमें Android के लिए खास एक्सटेंशन भी जोड़े जाते हैं. इसमें Java कोड भी होता है, जो ऐप्लिकेशन के प्रोसेस स्पेस में चलता है.
AndroidKeyStore, ऐप्लिकेशन के अनुरोधों को keystore डेमन पर फ़ॉरवर्ड करके, keystore के व्यवहार को पूरा करता है. - keystore डेमन
- Android सिस्टम डेमन, जो Binder API के ज़रिए, Keystore की सभी सुविधाओं का ऐक्सेस देता है. यह डेमन, keyblobs को सेव करने के लिए ज़िम्मेदार होता है. ये keyblobs, KeyMint या Keymaster के लागू होने पर जनरेट होते हैं. इनमें एन्क्रिप्ट की गई गुप्त कुंजी होती है, ताकि Keystore उन्हें सेव कर सके, लेकिन उनका इस्तेमाल न कर सके या उन्हें न दिखा सके.
- KeyMint एचएएल सेवा
- ऐसा एआईडीएल सर्वर जो
IKeyMintDeviceएचएएल को लागू करता है. इससे, उसमें मौजूद KeyMint टीए को ऐक्सेस किया जा सकता है. - KeyMint का भरोसेमंद ऐप्लिकेशन (टीए)
- सुरक्षित कॉन्टेक्स्ट में चलने वाला सॉफ़्टवेयर. आम तौर पर, यह ARM SoC पर TrustZone में चलता है. यह सभी सुरक्षित क्रिप्टोग्राफ़िक ऑपरेशन उपलब्ध कराता है. इस ऐप्लिकेशन के पास रॉ पासकोड का ऐक्सेस होता है. साथ ही, वह पासकोड का इस्तेमाल करने की अनुमति देने से पहले, ऐक्सेस कंट्रोल की सभी शर्तों की पुष्टि करता है.
LockSettingsService- Android सिस्टम का कॉम्पोनेंट, जो उपयोगकर्ता की पुष्टि करने के लिए ज़िम्मेदार होता है. इसमें पासवर्ड और उंगली के निशान, दोनों का इस्तेमाल किया जाता है. यह पासकोड, पासकोड की जगह पर इस्तेमाल नहीं किया जा सकता. हालांकि, यह पुष्टि करने के लिए इस्तेमाल की जाने वाली पासकोड के कॉन्सेप्ट के साथ काम करता है. इन पासकोड का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब उपयोगकर्ता ने पुष्टि कर ली हो.
LockSettingsService, पुष्टि करने वाले टोकन पाने के लिए, Gatekeeper TA और फ़िंगरप्रिंट TA के साथ इंटरैक्ट करता है. ये टोकन, Keystore डेमन को दिए जाते हैं और KeyMint TA का इस्तेमाल किया जाता है. - Gatekeeper TA
- यह एक ऐसा कॉम्पोनेंट है जो सुरक्षित माहौल में काम करता है. यह उपयोगकर्ता के पासवर्ड की पुष्टि करता है और पुष्टि करने वाले टोकन जनरेट करता है. इन टोकन का इस्तेमाल, KeyMint TA को यह साबित करने के लिए किया जाता है कि किसी खास समय पर किसी खास उपयोगकर्ता की पुष्टि की गई थी.
- फ़िंगरप्रिंट टीए
- यह एक ऐसा कॉम्पोनेंट है जो सुरक्षित माहौल में काम करता है. यह उपयोगकर्ता के फ़िंगरप्रिंट की पुष्टि करता है और पुष्टि करने वाले टोकन जनरेट करता है. इन टोकन का इस्तेमाल, KeyMint TA को यह साबित करने के लिए किया जाता है कि किसी खास समय पर किसी खास उपयोगकर्ता की पुष्टि की गई थी.
भवन निर्माण
Android Keystore API और उसमें मौजूद KeyMint HAL, क्रिप्टोग्राफ़िक प्राइमिटिव का बुनियादी, लेकिन ज़रूरत के मुताबिक सेट उपलब्ध कराता है. इससे, ऐक्सेस कंट्रोल करने वाली और हार्डवेयर की मदद से काम करने वाली कुंजियों का इस्तेमाल करके, प्रोटोकॉल लागू किए जा सकते हैं.
KeyMint HAL, OEM की ओर से दी जाने वाली एक सेवा है. इसका इस्तेमाल, कुंजीस्टोर सेवा करती है, ताकि हार्डवेयर की मदद से क्रिप्टोग्राफ़िक सेवाएं दी जा सकें. निजी कुंजी के कॉन्टेंट को सुरक्षित रखने के लिए, एचएएल लागू करने वाले टूल, उपयोगकर्ता स्पेस या कर्नेल स्पेस में कोई संवेदनशील ऑपरेशन नहीं करते. इसके बजाय, Android में चल रही KeyMint HAL सेवा, संवेदनशील ऑपरेशन को किसी सुरक्षित माहौल में चल रहे टीए को सौंपती है. आम तौर पर, ऐसा करने के लिए, अनुरोधों को मार्शल और अनमार्शल किया जाता है. यह अनुरोध, लागू करने के लिए तय किए गए वायर फ़ॉर्मैट में होते हैं.
इससे मिलने वाला आर्किटेक्चर कुछ ऐसा दिखता है:
पहली इमेज. KeyMint का ऐक्सेस.
KeyMint HAL API, लो लेवल का एपीआई है. इसका इस्तेमाल प्लैटफ़ॉर्म के अंदरूनी कॉम्पोनेंट करते हैं. साथ ही, इसे ऐप्लिकेशन डेवलपर के लिए उपलब्ध नहीं कराया जाता. ऐप्लिकेशन के लिए उपलब्ध, बेहतर लेवल के Java API के बारे में जानकारी, Android डेवलपर साइट पर दी गई है.
ऐक्सेस कंट्रोल
Android Keystore, ऐप्लिकेशन और सिस्टम के अन्य कॉम्पोनेंट, दोनों के लिए, हार्डवेयर की मदद से सुरक्षित की गई क्रिप्टोग्राफ़िक कुंजियों को स्टोर और इस्तेमाल करने का मुख्य कॉम्पोनेंट उपलब्ध कराता है. इसलिए, आम तौर पर किसी कुंजी का ऐक्सेस, उस ऐप्लिकेशन या सिस्टम कॉम्पोनेंट तक सीमित होता है जिसने कुंजी बनाई है.
कीस्टोर डोमेन
ऐक्सेस कंट्रोल की सुविधा के साथ काम करने के लिए, कुंजियों को की डिस्क्रिप्टर की मदद से Keystore में पहचाना जाता है. यह मुख्य डिस्क्रिप्टर, उस डोमेन के बारे में बताता है जिससे डिस्क्रिप्टर जुड़ा है. साथ ही, उस डोमेन में मौजूद किसी पहचान के बारे में भी बताता है.
Android ऐप्लिकेशन, स्टैंडर्ड Java क्रिप्टोग्राफ़ी आर्किटेक्चर का इस्तेमाल करके कीस्टोर को ऐक्सेस करते हैं. यह आर्किटेक्चर, स्ट्रिंग के उपनाम से कुंजियों की पहचान करता है. पहचान करने का यह तरीका, इंटरनल तौर पर 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 को इन कुंजियों को पाने और इस्तेमाल करने की अनुमति देने के लिए, 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
|
पासकोड को पासवर्ड के तौर पर इस्तेमाल करने के लिए ज़रूरी है. इसका इस्तेमाल, Gatekeeper या BiometricManager जैसी पुष्टि करने वाली सेवा देने वाली कंपनियां करती हैं. |
clear_ns
|
किसी नेमस्पेस में मौजूद सभी कुंजियों को मिटाने के लिए ज़रूरी है. ऐप्लिकेशन अनइंस्टॉल होने पर, इसे रखरखाव के तौर पर इस्तेमाल किया जाता है. |
list
|
सिस्टम को अलग-अलग प्रॉपर्टी के हिसाब से पासकोड की गिनती करने के लिए ज़रूरी है. जैसे, मालिकाना हक या पुष्टि करने के लिए ज़रूरी है या नहीं. कॉल करने वाले को अपने नेमस्पेस की सूची बनाने के लिए, इस अनुमति की ज़रूरत नहीं होती. नेमस्पेस की सूची बनाने के लिए, get_info अनुमति की ज़रूरत होती है. |
lock
|
यह सुविधा, पासकोड सेव करने वाली जगह को यह सूचना देने के लिए ज़रूरी है कि डिवाइस लॉक हो गया है. इससे सुपर-कुंजियां हट जाती हैं, ताकि पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियां उपलब्ध न हों. |
unlock
|
यह ज़रूरी है कि डिवाइस अनलॉक होने पर, पासकोड को इसकी सूचना दी जाए. इससे पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजियों को सुरक्षित रखने वाली सुपर-कुंजियों का ऐक्सेस वापस मिल जाता है. |
reset
|
Keystore को फ़ैक्ट्री डिफ़ॉल्ट पर रीसेट करने के लिए ज़रूरी है. साथ ही, Android OS के काम करने के लिए ज़रूरी नहीं होने वाली सभी कुंजियों को मिटाता है. |
इतिहास
Android 5 और उससे पहले के वर्शन में, Android में एक आसान और हार्डवेयर पर आधारित क्रिप्टोग्राफ़िक सेवाओं का एपीआई था. इसे Keymaster हार्डवेयर एब्स्ट्रैक्शन लेयर (एचएएल) के 0.2 और 0.3 वर्शन से उपलब्ध कराया गया था. कीस्टोर में डिजिटल हस्ताक्षर और पुष्टि करने की सुविधाएं मिलती हैं. साथ ही, असिमेट्रिक साइनिंग पासकोड के पेयर जनरेट करने और इंपोर्ट करने की सुविधा भी मिलती है. यह सुविधा कई डिवाइसों पर पहले से लागू है. हालांकि, सुरक्षा से जुड़े कई लक्ष्यों को सिर्फ़ हस्ताक्षर एपीआई की मदद से आसानी से हासिल नहीं किया जा सकता. Android 6.0 में Keystore API को बेहतर बनाया गया है, ताकि ज़्यादा से ज़्यादा सुविधाएं दी जा सकें.
Android 6.0
Android 6.0 में, Keymaster 1.0 ने सिमेट्रिक क्रिप्टोग्राफ़िक प्राइमिटिव, एईएस, और एचएमएससी जोड़ा. साथ ही, हार्डवेयर की मदद से सुरक्षित की गई कुंजियों के लिए ऐक्सेस कंट्रोल सिस्टम भी जोड़ा. ऐक्सेस कंट्रोल, पासकोड जनरेट करने के दौरान तय किए जाते हैं और पासकोड के पूरे जीवनकाल के लिए लागू होते हैं. पासकोड को इस तरह से सेट किया जा सकता है कि उपयोगकर्ता की पुष्टि होने के बाद ही उसे इस्तेमाल किया जा सके. साथ ही, उसे सिर्फ़ तय किए गए कामों के लिए या तय किए गए क्रिप्टोग्राफ़िक पैरामीटर के साथ इस्तेमाल किया जा सके.
क्रिप्टोग्राफ़िक प्राइमिटिव की रेंज को बढ़ाने के अलावा, Android 6.0 में मौजूद Keystore में ये चीज़ें जोड़ी गई हैं:
- कुंजी के इस्तेमाल को सीमित करने की अनुमति देने के लिए, इस्तेमाल कंट्रोल करने की योजना. इससे, कुंजियों के गलत इस्तेमाल की वजह से सुरक्षा से जुड़े जोखिम को कम किया जा सकता है
- ऐक्सेस कंट्रोल स्कीम, जिसकी मदद से चुनिंदा उपयोगकर्ताओं, क्लाइंट, और तय की गई समयसीमा के लिए कुंजियों पर पाबंदी लगाई जा सकती है
Android 7.0
Android 7.0 में, Keymaster 2 ने कुंजी की पुष्टि करने और वर्शन को बाइंड करने की सुविधा जोड़ी है.
कुंजी की पुष्टि करने की सुविधा से, सार्वजनिक कुंजी के सर्टिफ़िकेट मिलते हैं. इनमें कुंजी और उसके ऐक्सेस कंट्रोल के बारे में पूरी जानकारी होती है. इससे, सुरक्षित हार्डवेयर में कुंजी मौजूद होने और उसके कॉन्फ़िगरेशन की पुष्टि, रिमोट से की जा सकती है.
वर्शन बाइंडिंग, बटन को ऑपरेटिंग सिस्टम और पैच लेवल वर्शन से बांधती है. इससे यह पक्का होता है कि अगर कोई हमलावर, सिस्टम या TEE सॉफ़्टवेयर के पुराने वर्शन में कोई कमज़ोरी ढूंढता है, तो वह डिवाइस को उस वर्शन पर वापस नहीं ला सकता जिसमें कमज़ोरी है. साथ ही, वह नए वर्शन से बनाई गई कुंजियों का इस्तेमाल भी नहीं कर सकता. इसके अलावा, जब किसी डिवाइस पर किसी खास वर्शन और पैच लेवल वाले पासकोड का इस्तेमाल किया जाता है, जिसे नए वर्शन या पैच लेवल पर अपग्रेड किया गया है, तो पासकोड का इस्तेमाल करने से पहले उसे अपग्रेड कर दिया जाता है. साथ ही, पासकोड का पिछला वर्शन अमान्य कर दिया जाता है. डिवाइस को अपग्रेड करने पर, डिवाइस के साथ-साथ कुंजियां भी अपग्रेड हो जाती हैं. हालांकि, डिवाइस को किसी पुराने वर्शन पर वापस ले जाने पर, कुंजियां काम नहीं करतीं.
Android 8.0
Android 8.0 में, Keymaster 3 को पुराने स्टाइल के C-स्ट्रक्चर वाले एचएएल से, C++ एचएएल इंटरफ़ेस पर ट्रांसफ़र कर दिया गया. यह इंटरफ़ेस, नई हार्डवेयर इंटरफ़ेस डेफ़िनिशन लैंग्वेज (एचआईडीएल) में मौजूद डेफ़िनिशन से जनरेट होता है. इस बदलाव के तहत, कई तरह के आर्ग्युमेंट बदल गए हैं. हालांकि, टाइप और तरीकों का पुराने टाइप और HAL स्ट्रक्चर के तरीकों के साथ एक-एक का मेल खाता है.
इंटरफ़ेस में किए गए इस बदलाव के अलावा, Android 8.0 में Keymaster 2 की पुष्टि करने की सुविधा को आईडी की पुष्टि के लिए भी उपलब्ध कराया गया है. आईडी की पुष्टि करने की सुविधा, हार्डवेयर आइडेंटिफ़ायर की पुष्टि करने के लिए एक सीमित और वैकल्पिक तरीका उपलब्ध कराती है. जैसे, डिवाइस का सीरियल नंबर, प्रॉडक्ट का नाम, और फ़ोन आईडी (IMEI या MEID). इस सुविधा को लागू करने के लिए, Android 8.0 ने आईडी की पुष्टि करने के लिए, ASN.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 का वर्शन 2 जोड़ा गया है. इसमें हस्ताक्षर करने और कुंजी के समझौते, दोनों के लिए Curve25519 का इस्तेमाल किया जा सकता है.