सुविधाएं

इस पेज पर, Android Keystore की क्रिप्टोग्राफ़िक सुविधाओं के बारे में जानकारी दी गई है. ये सुविधाएं, KeyMint (या Keymaster) लागू करने से मिलती हैं.

क्रिप्टोग्राफ़िक प्राइमिटिव

पासकोड की मदद से, ये काम किए जा सकते हैं:

• कुंजियां बनाना, जिससे निजी या गुप्त कुंजी का ऐसा कॉन्टेंट बनता है जिसका ऐक्सेस सिर्फ़ सुरक्षित एनवायरमेंट के पास होता है. क्लाइंट इन तरीकों से पासकोड बना सकते हैं:
  • नई पासकोड जनरेट करना
  • एन्क्रिप्ट (सुरक्षित) नहीं किया गया पासकोड इंपोर्ट करना
  • एन्क्रिप्ट (सुरक्षित) किया गया पासकोड इंपोर्ट करना
• कुंजी की पुष्टि: असिमेट्रिक कुंजी बनाने पर, एक सर्टिफ़िकेट जनरेट होता है. इसमें, कुंजी के जोड़े की सार्वजनिक कुंजी का हिस्सा होता है. इस सर्टिफ़िकेट में, कुंजी के मेटाडेटा और डिवाइस की स्थिति के बारे में भी जानकारी हो सकती है. हालांकि, ऐसा ज़रूरी नहीं है. इसमें मौजूद सभी जानकारी पर, भरोसेमंद रूट पर वापस ले जाने वाली कुंजी की चेन से हस्ताक्षर किया जाता है.
• क्रिप्टोग्राफ़िक ऑपरेशन:
  • सिमेट्रिक एन्क्रिप्शन और डीक्रिप्शन (AES, 3DES)
  • असिमेट्रिक डिक्रिप्शन (आरएसए)
  • असिमेट्रिक साइनिंग (ईसीडीएसए, आरएसए)
  • सिमेट्रिक साइनिंग और पुष्टि (एचएमएसी)
  • असिमेट्रिक की एग्रीमेंट (ईसीडीएच)

ध्यान दें कि Keystore और KeyMint, असिमेट्रिक कुंजियों के लिए सार्वजनिक कुंजी के ऑपरेशन मैनेज नहीं करते.

कुंजियों को जनरेट या इंपोर्ट करने के दौरान, प्रोटोकॉल एलिमेंट तय किए जाते हैं. जैसे, मकसद, मोड, और पैडिंग. साथ ही, ऐक्सेस कंट्रोल की पाबंदियां भी तय की जाती हैं. ये एलिमेंट कुंजी से हमेशा जुड़े रहते हैं. इससे यह पक्का होता है कि कुंजी का इस्तेमाल किसी और तरीके से न किया जा सके.

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

KeyMint को लागू करने के लिए, रैंडम नंबर जनरेट करने की सुविधा का इस्तेमाल करना ज़रूरी है. इससे, कुंजी जनरेट करने और रैंडम पैडिंग या शुरू करने वाले वेक्टर (IVs) बनाने में मदद मिलती है. इसकी सुविधा देने के लिए, Android सिस्टम समय-समय पर, KeyMint को लागू करने के लिए ज़्यादा एन्ट्रापी उपलब्ध कराता है.

पासकोड से ऐक्सेस कंट्रोल

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

ऐक्सेस कंट्रोल को टैग/वैल्यू पेयर की "अनुमति सूची" के तौर पर परिभाषित किया जाता है. अनुमति टैग, 32-बिट के पूर्णांक होते हैं और उनकी वैल्यू कई तरह की होती हैं. एक से ज़्यादा वैल्यू देने के लिए, कुछ टैग दोहराए जा सकते हैं. KeyMint (पहले Keymaster) HAL इंटरफ़ेस में बताया गया है कि किसी टैग को दोहराया जा सकता है या नहीं.

इस्तेमाल किए जा सकने वाले टैग की वैल्यू, Tag.aidl फ़ाइल में तय की जाती हैं. साथ ही, हर वैल्यू के साथ एक TagType जुड़ा होता है. इससे, उससे जुड़ी वैल्यू के टाइप (उदाहरण के लिए, पूर्णांक या बाइट) के बारे में पता चलता है. साथ ही, यह भी पता चलता है कि इस्तेमाल की जा सकने वाली एक से ज़्यादा वैल्यू तय करने के लिए, इसे दोहराया जा सकता है या नहीं.

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

नीति उल्लंघन ठीक करने के लिए, हार्डवेयर बनाम सॉफ़्टवेयर

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

इसे KeyMint API में, KeyCharacteristics टाइप के securityLevel फ़ील्ड के साथ दिखाया जाता है. सुरक्षित हार्डवेयर, अनुमतियों को KeyCharacteristics में सही सुरक्षा लेवल के साथ डालने की ज़िम्मेदारी रखता है. यह इस बात पर निर्भर करता है कि वह क्या लागू कर सकता है. यह जानकारी, असिमेट्रिक कुंजियों के पुष्टि करने वाले रिकॉर्ड में भी दिखती है: SecurityLevel::TRUSTED_ENVIRONMENT या SecurityLevel::STRONGBOX की मुख्य विशेषताएं, hardwareEnforced सूची में दिखती हैं. साथ ही, SecurityLevel::SOFTWARE या SecurityLevel::KEYSTORE की विशेषताएं, softwareEnforced सूची में दिखती हैं.

उदाहरण के लिए, आम तौर पर सुरक्षित एनवायरमेंट, तारीख और समय के अंतराल पर पाबंदियां नहीं लगाता. ऐसा इसलिए, क्योंकि उसके पास तारीख और समय की जानकारी का भरोसेमंद ऐक्सेस नहीं होता. इस वजह से, Tag::ORIGINATION_EXPIRE_DATETIME जैसी अनुमतियां, Android में मौजूद पासकोड से सुरक्षित स्टोरेज में लागू की जाती हैं. साथ ही, इनमें SecurityLevel::KEYSTORE होता है.

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

क्रिप्टोग्राफ़िक मैसेज बनाने की अनुमतियां

यहां दिए गए टैग का इस्तेमाल, पासकोड का इस्तेमाल करके किए जाने वाले ऑपरेशन की क्रिप्टोग्राफ़िक विशेषताओं को तय करने के लिए किया जाता है:

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

यहां दिए गए टैग दोहराए जा सकते हैं. इसका मतलब है कि एक ही कुंजी के साथ कई वैल्यू जोड़ी जा सकती हैं:

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

इस्तेमाल की जाने वाली वैल्यू, ऑपरेशन के समय तय की जाती है.

मकसद

कुंजियों के साथ, उनके मकसद का एक सेट जुड़ा होता है. इसे Tag::PURPOSE टैग के साथ एक या उससे ज़्यादा अनुमति वाली एंट्री के तौर पर दिखाया जाता है. इससे यह तय होता है कि उनका इस्तेमाल कैसे किया जा सकता है. मकसद, KeyPurpose.aidl में बताए गए हैं.

ध्यान दें कि 'मकसद' एट्रिब्यूट की वैल्यू के कुछ कॉम्बिनेशन से सुरक्षा से जुड़ी समस्याएं आती हैं. उदाहरण के लिए, ऐसी आरएसए कुंजी जिसका इस्तेमाल एन्क्रिप्ट करने और हस्ताक्षर करने, दोनों के लिए किया जा सकता है. इससे हमलावर, सिस्टम को किसी भी डेटा को डिक्रिप्ट करने के लिए मना सकता है, ताकि वह हस्ताक्षर जनरेट कर सके.

पासकोड इंपोर्ट करना

KeyMint में ये डेटा इंपोर्ट किए जा सकते हैं:

• पासवर्ड पर आधारित एन्क्रिप्शन के बिना, DER-कोड में PKCS#8 फ़ॉर्मैट में एसिमेट्रिक पासकोड
• रॉ बाइट के तौर पर सिमेट्रिक पासकोड

यह पक्का करने के लिए कि इंपोर्ट की गई कुंजियों को सुरक्षित तरीके से जनरेट की गई कुंजियों से अलग किया जा सके, Tag::ORIGIN को कुंजी की अनुमति देने वाली सही सूची में शामिल किया जाता है. उदाहरण के लिए, अगर कोई कुंजी सुरक्षित हार्डवेयर में जनरेट की गई थी, तो कुंजी की विशेषताओं की hw_enforced सूची में, वैल्यू KeyOrigin::GENERATED के साथ Tag::ORIGIN मिलता है. वहीं, सुरक्षित हार्डवेयर में इंपोर्ट की गई कुंजी की वैल्यू KeyOrigin::IMPORTED होती है.

उपयोगकर्ता की पुष्टि

सुरक्षित KeyMint लागू करने की सुविधा, उपयोगकर्ता की पुष्टि नहीं करती. हालांकि, यह पुष्टि करने के लिए, भरोसेमंद अन्य ऐप्लिकेशन पर निर्भर करती है. इन ऐप्लिकेशन के लागू किए गए इंटरफ़ेस के बारे में जानने के लिए, Gatekeeper पेज देखें.

उपयोगकर्ता की पुष्टि करने से जुड़ी ज़रूरी शर्तों के बारे में, टैग के दो सेट के ज़रिए बताया जाता है. पहले सेट से पता चलता है कि पुष्टि करने के किन तरीकों से कुंजी का इस्तेमाल किया जा सकता है:

• Tag::USER_SECURE_ID में 64-बिट की संख्या वाली वैल्यू होती है, जिसमें सुरक्षित उपयोगकर्ता आईडी की जानकारी होती है. यह वैल्यू, पुष्टि करने वाले सुरक्षित टोकन में दी जाती है, ताकि कुंजी का इस्तेमाल किया जा सके. अगर कुंजी को दोहराया जाता है, तो पुष्टि करने वाले सुरक्षित टोकन में दी गई किसी भी वैल्यू का इस्तेमाल किया जा सकता है.

दूसरे सेट से पता चलता है कि उपयोगकर्ता की पुष्टि कब और ज़रूरी है. अगर इनमें से कोई भी टैग मौजूद नहीं है, लेकिन Tag::USER_SECURE_ID मौजूद है, तो कुंजी के हर इस्तेमाल के लिए पुष्टि करना ज़रूरी है.

• Tag::NO_AUTHENTICATION_REQUIRED से पता चलता है कि उपयोगकर्ता की पुष्टि करने की ज़रूरत नहीं है. हालांकि, पासकोड का ऐक्सेस अब भी उस ऐप्लिकेशन के पास ही है जिसके पास पासकोड है. साथ ही, जिन ऐप्लिकेशन को उसने ऐक्सेस दिया है उनके पास भी पासकोड का ऐक्सेस है.
• Tag::AUTH_TIMEOUT एक संख्या होती है, जो सेकंड में बताती है कि कुंजी के इस्तेमाल की अनुमति देने के लिए, उपयोगकर्ता की पुष्टि कितनी हाल की होनी चाहिए. टाइम आउट, रीबूट के बाद लागू नहीं होते. रीबूट होने के बाद, पुष्टि की सभी प्रक्रियाएं अमान्य हो जाती हैं. टाइम आउट को बड़ी वैल्यू पर सेट किया जा सकता है, ताकि यह पता चल सके कि हर बूट के लिए पुष्टि एक बार ज़रूरी है (2^32 सेकंड ~136 साल होते हैं; माना जाता है कि Android डिवाइसों को इससे ज़्यादा बार रीबूट किया जाता है).

डिवाइस अनलॉक होना चाहिए

Tag::UNLOCKED_DEVICE_REQUIRED वाली बटन का इस्तेमाल सिर्फ़ तब किया जा सकता है, जब डिवाइस अनलॉक हो. सेमेटिक्स के बारे में ज़्यादा जानकारी के लिए, KeyProtection.Builder#setUnlockedDeviceRequired(boolean) देखें.

UNLOCKED_DEVICE_REQUIRED को Keystore लागू करता है, न कि KeyMint. हालांकि, Android 12 और इसके बाद के वर्शन में, डिवाइस के लॉक होने पर Keystore, क्रिप्टोग्राफ़िक तरीके से UNLOCKED_DEVICE_REQUIRED कुंजियों को सुरक्षित रखता है. इससे यह पक्का होता है कि ज़्यादातर मामलों में, डिवाइस के लॉक होने पर Keystore के हैक होने के बावजूद, इन कुंजियों का इस्तेमाल नहीं किया जा सकता.

ऐसा करने के लिए, Keystore अपने डेटाबेस में सेव करने से पहले, सभी UNLOCKED_DEVICE_REQUIRED कुंजियों को "सुपर एन्क्रिप्ट" करता है. साथ ही, जब भी संभव हो, डिवाइस को इस तरह से लॉक करता है कि सुपर एन्क्रिप्शन कुंजियों (सुपर कुंजियों) को सिर्फ़ डिवाइस अनलॉक करने के बाद ही वापस पाया जा सके. "सुपर एन्क्रिप्शन" शब्द का इस्तेमाल इसलिए किया जाता है, क्योंकि एन्क्रिप्शन की यह लेयर, एन्क्रिप्शन की उस लेयर के साथ-साथ लागू की जाती है जो KeyMint पहले से ही सभी कुंजियों पर लागू करता है.

हर उपयोगकर्ता (इसमें प्रोफ़ाइलें भी शामिल हैं) के पास UNLOCKED_DEVICE_REQUIRED से जुड़ी दो सुपर कुंजियां होती हैं:

• UnlockedDeviceRequired सिमेट्रिक सुपर पासकोड. यह एक AES‑256‑GCM पासकोड है. यह उन UNLOCKED_DEVICE_REQUIRED कुंजियों को एन्क्रिप्ट करता है जिन्हें डिवाइस के अनलॉक होने पर, इंपोर्ट या जनरेट किया जाता है.
• UnlockedDeviceRequired असिमेट्रिक सुपर पासकोड. यह ईसीडीएच पी‑521 कुंजी का जोड़ा है. यह UNLOCKED_DEVICE_REQUIRED उन कुंजियों को एन्क्रिप्ट करता है जिन्हें डिवाइस के लॉक होने पर, इंपोर्ट या जनरेट किया जाता है. इस असिमेट्रिक पासकोड से एन्क्रिप्ट की गई कुंजियों को, पहली बार इस्तेमाल करने पर, सिमेट्रिक पासकोड से फिर से एन्क्रिप्ट किया जाता है. ऐसा सिर्फ़ डिवाइस के अनलॉक होने पर किया जा सकता है.

Keystore, उपयोगकर्ता बनाने के समय ये सुपर पासकोड जनरेट करता है और उन्हें अपने डेटाबेस में सेव करता है. ये पासकोड, उपयोगकर्ता के सिंथेटिक पासवर्ड से एन्क्रिप्ट (सुरक्षित) किए जाते हैं. इससे, पिन, पैटर्न या पासवर्ड के बराबर के पासवर्ड का इस्तेमाल करके, उन्हें वापस पाया जा सकता है.

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

• अगर उपयोगकर्ता ने सिर्फ़ पिन, पैटर्न या पासवर्ड चालू किया है, तो Keystore अपनी कैश मेमोरी में सेव की गई सुपर कुंजियों के गुप्त हिस्सों को शून्य कर देता है. इससे सुपर कुंजियों को सिर्फ़ डेटाबेस में मौजूद एन्क्रिप्ट की गई कॉपी से वापस पाया जा सकता है. इस कॉपी को सिर्फ़ पिन, पैटर्न या पासवर्ड से डिक्रिप्ट किया जा सकता है.
• अगर उपयोगकर्ता के पास सिर्फ़ तीसरे लेवल की ("बेहतर") बायोमेट्रिक जानकारी है और पिन, पैटर्न या पासवर्ड की सुविधा चालू है, तो Keystore, सुपर पासकी को वापस पाने के लिए, उपयोगकर्ता के रजिस्टर किए गए तीसरे लेवल की बायोमेट्रिक जानकारी (आम तौर पर फ़िंगरप्रिंट) का इस्तेमाल करता है. यह पिन, पैटर्न या पासवर्ड के बराबर का विकल्प होता है. ऐसा करने के लिए, यह एईएस‑256‑जीसीएम की एक नई कुंजी जनरेट करता है. साथ ही, सुपर पासकोड के गोपनीय हिस्सों को एन्क्रिप्ट करता है. इसके बाद, एईएस‑256‑जीसीएम कुंजी को, बायोमेट्रिक पासकोड के तौर पर KeyMint में इंपोर्ट करता है. इसके लिए, यह ज़रूरी है कि पिछले 15 सेकंड में बायोमेट्रिक पुष्टि की गई हो. साथ ही, इन सभी पासकोड की सादा टेक्स्ट कॉपी को शून्य कर देता है.
• अगर उपयोगकर्ता के पास क्लास 1 ("सुविधा") बायोमेट्रिक, क्लास 2 ("कमज़ोर") बायोमेट्रिक या चालू अनलॉक ट्रस्ट एजेंट है, तो Keystore, सुपर पासकोड को साफ़ टेक्स्ट में कैश मेमोरी में सेव रखता है. इस मामले में, UNLOCKED_DEVICE_REQUIRED कुंजियों के लिए क्रिप्टोग्राफ़िक सुरक्षा नहीं दी जाती. उपयोगकर्ता, डिवाइस को अनलॉक करने के इन तरीकों को चालू न करके, कम सुरक्षित फ़ॉलबैक से बच सकते हैं. इन कैटगरी में, डिवाइस को अनलॉक करने के सबसे सामान्य तरीके ये हैं: कई डिवाइसों पर, डिवाइस को चेहरे की पहचान से अनलॉक करना और जोड़ी गई स्मार्टवॉच से अनलॉक करना.

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

क्लाइंट बाइंडिंग

क्लाइंट बाइंडिंग, किसी खास क्लाइंट ऐप्लिकेशन के साथ कुंजी को जोड़ने की प्रोसेस है. इसे क्लाइंट आईडी और कुछ क्लाइंट डेटा (Tag::APPLICATION_ID और Tag::APPLICATION_DATA) के ज़रिए किया जाता है. हालांकि, क्लाइंट आईडी और क्लाइंट डेटा का इस्तेमाल करना ज़रूरी नहीं है. Keystore इन वैल्यू को ओपेक ब्लॉब के तौर पर इस्तेमाल करता है. साथ ही, यह पक्का करता है कि कुंजी जनरेट करने/इंपोर्ट करने के दौरान दिखाए गए ब्लॉब, हर इस्तेमाल के लिए दिखाए गए ब्लॉब से मेल खाते हों और बाइट-टू-बाइट एक जैसे हों. KeyMint, क्लाइंट बाइंडिंग डेटा नहीं दिखाता. डिजिटल बटन का इस्तेमाल करने के लिए, कॉल करने वाले व्यक्ति को यह कोड पता होना चाहिए.

यह सुविधा ऐप्लिकेशन के लिए उपलब्ध नहीं है.

समयसीमा

पासकोड की मदद से, तारीख के हिसाब से पासकोड के इस्तेमाल पर पाबंदी लगाई जा सकती है. पासकोड की समयसीमा शुरू होने और खत्म होने की तारीख, पासकोड से जुड़ी हो सकती है. अगर मौजूदा तारीख/समय, पासकोड की समयसीमा की तय सीमा से बाहर है, तो पासकोड से जुड़े काम नहीं किए जा सकते. पासकोड की मान्य होने की सीमा, टैग Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME, और Tag::USAGE_EXPIRE_DATETIME से तय की जाती है. "बनाना" और "इस्तेमाल करना" के बीच का फ़र्क़ इस बात पर निर्भर करता है कि कुंजी का इस्तेमाल, किसी नए सिफरटेक्स्ट/हस्ताक्षर वगैरह को "बनाने" के लिए किया जा रहा है या किसी मौजूदा सिफरटेक्स्ट/हस्ताक्षर वगैरह को "इस्तेमाल करने" के लिए. ध्यान दें कि यह फ़र्क़ ऐप्लिकेशन को नहीं दिखाया जाता.

Tag::ACTIVE_DATETIME, Tag::ORIGINATION_EXPIRE_DATETIME, और Tag::USAGE_EXPIRE_DATETIME टैग ज़रूरी नहीं हैं. अगर टैग मौजूद नहीं हैं, तो यह माना जाता है कि मैसेज को डिक्रिप्ट करने/पुष्टि करने के लिए, उस कुंजी का इस्तेमाल हमेशा किया जा सकता है.

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

रूट ऑफ़ ट्रस्ट बाइंडिंग

Keystore के लिए ज़रूरी है कि कुंजियों को भरोसेमंद रूट से बंधा हो. यह एक बिटस्ट्रिंग होती है, जो स्टार्टअप के दौरान KeyMint के सुरक्षित हार्डवेयर को दी जाती है. आम तौर पर, इसे बूटलोडर से दिया जाता है. यह बिटस्ट्रिंग, क्रिप्टोग्राफ़िक तरीके से KeyMint की ओर से मैनेज की जाने वाली हर कुंजी से जुड़ी होती है.

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

रैंडम नंबर जनरेटर को फिर से सेट करना

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

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