सुविधाएं

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

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

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

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

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

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

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

ज़रूरी प्राइमिटिव

KeyMint के सभी वर्शन में ये सुविधाएं मिलती हैं:

• RSA
  • 2048, 3072, और 4096 बिट की कुंजी के साथ काम करना
  • सार्वजनिक घातांक F4 (2^16+1) के लिए सहायता
  • आरएसए साइनिंग के लिए पैडिंग मोड:
    • RSASSA-PSS (PaddingMode::RSA_PSS)
    • RSASSA-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_SIGN)
  • आरएसए साइनिंग के लिए डाइजेस्ट मोड:
    • SHA-256
  • RSA एन्क्रिप्शन/डिक्रिप्शन के लिए पैडिंग मोड:
    • बिना पैड वाले
    • RSAES-OAEP (PaddingMode::RSA_OAEP)
    • RSAES-PKCS1-v1_5 (PaddingMode::RSA_PKCS1_1_5_ENCRYPT)
• ECDSA
  • 224, 256, 384, और 521-बिट की सुविधा वाली कुंजी का इस्तेमाल किया जा सकता है. इसके लिए, क्रमशः NIST P-224, P-256, P-384, और P-521 कर्व का इस्तेमाल किया जाता है
  • ईसीडीएसए के लिए डाइजेस्ट मोड:
    • कोई डाइजेस्ट नहीं (इस्तेमाल नहीं किया जा सकता. आने वाले समय में इसे हटा दिया जाएगा)
    • SHA-256
• AES
  • 128 और 256-बिट की कुंजियां इस्तेमाल की जा सकती हैं
  • सीबीसी, सीटीआर, ईसीबी, और जीसीएम. GCM लागू करने पर, 96 बिट से छोटे टैग या 96 बिट के अलावा किसी दूसरी लंबाई के नॉन्स का इस्तेमाल नहीं किया जा सकता.
  • CBC और ECB मोड के लिए, पैडिंग मोड PaddingMode::NONE और PaddingMode::PKCS7 का इस्तेमाल किया जा सकता है. बिना पैडिंग के, CBC या ECB मोड में एन्क्रिप्शन तब काम नहीं करता, जब इनपुट, ब्लॉक साइज़ का मल्टीपल न हो.
• HMAC SHA-256, जिसमें कुंजी का साइज़ कम से कम 32 बाइट तक हो.

KeyMint को लागू करने के लिए, SHA1 और SHA2 फ़ैमिली के अन्य सदस्यों (SHA-224, SHA384, और SHA512) का इस्तेमाल करने का सुझाव दिया जाता है. अगर हार्डवेयर KeyMint लागू करने की सुविधा उन्हें उपलब्ध नहीं कराती है, तो Keystore उन्हें सॉफ़्टवेयर के तौर पर उपलब्ध कराता है.

अन्य सिस्टम के साथ इंटरऑपरेबिलिटी (दूसरे सिस्टम के साथ काम करना) के लिए, कुछ प्राइमिटिव का भी सुझाव दिया जाता है:

• आरएसए के लिए छोटी कुंजियों के साइज़
• आरएसए के लिए मनमुताबिक सार्वजनिक घातांक

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

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

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

Keymaster 2 और उससे पहले के वर्शन के लिए, संभावित टैग का सेट, एनोटेशनkeymaster_authorization_tag_t में तय किया गया है और इसे हमेशा के लिए तय किया गया है. हालांकि, इसे बढ़ाया जा सकता है. नामों के आगे KM_TAG लगा दिया गया था. टैग आईडी के सबसे ऊपर मौजूद चार बिट का इस्तेमाल, टाइप के बारे में बताने के लिए किया जाता है.

Keymaster 3 ने KM_TAG प्रीफ़िक्स को Tag:: में बदल दिया है.

इनमें ये टाइप शामिल हैं:

ENUM: कई टैग की वैल्यू, सूची में दी गई होती हैं. उदाहरण के लिए, TAG::PURPOSE की संभावित वैल्यू, keymaster_purpose_t में तय की गई हैं.

ENUM_REP: यह ENUM जैसा ही है. हालांकि, अनुमति वाली सूची में टैग को दोहराया जा सकता है. दोहराए जाने पर, अनुमति वाली कई वैल्यू दिखती हैं. उदाहरण के लिए, एन्क्रिप्शन कुंजी में KeyPurpose::ENCRYPT और KeyPurpose::DECRYPT हो सकते हैं.

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

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

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

इसे 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 में बताए गए हैं.

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

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

Keymaster, सिर्फ़ X.509 फ़ॉर्मैट में सार्वजनिक कुंजियों को एक्सपोर्ट करने की सुविधा देता है. साथ ही, इनके इंपोर्ट की सुविधा भी देता है:

• पासवर्ड पर आधारित एन्क्रिप्शन के बिना, 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, क्लाइंट बाइंडिंग डेटा नहीं दिखाता. डिजिटल बटन का इस्तेमाल करने के लिए, कॉल करने वाले व्यक्ति को यह कोड पता होना चाहिए.

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

समयसीमा

पासकोड की मदद से, तारीख के हिसाब से पासकोड के इस्तेमाल पर पाबंदी लगाई जा सकती है. किसी पासकोड के लिए, पासकोड की समयसीमा शुरू होने और खत्म होने की तारीख सेट की जा सकती है. अगर मौजूदा तारीख/समय, पासकोड की समयसीमा की तय सीमा से बाहर है, तो Keymaster पासकोड से जुड़े कोई भी काम करने से मना कर देता है. पासकोड की मान्य होने की सीमा, टैग 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 के कुछ सुरक्षित हार्डवेयर, एन्क्रिप्ट (सुरक्षित) किए गए पासकोड के बजाय, पासकोड को अंदरूनी तौर पर स्टोर करने और हैंडल दिखाने का विकल्प चुन सकते हैं. इसके अलावा, ऐसे और भी मामले हो सकते हैं जिनमें कुंजियों का इस्तेमाल तब तक नहीं किया जा सकता, जब तक कि कोई दूसरा गैर-सुरक्षित या सुरक्षित वर्ल्ड सिस्टम कॉम्पोनेंट उपलब्ध न हो. KeyMint HAL की मदद से, कॉलर TAG::STANDALONE टैग का इस्तेमाल करके, किसी कुंजी को "स्टैंडअलोन" बनाने का अनुरोध कर सकता है. इसका मतलब है कि ब्लॉब और चल रहे KeyMint सिस्टम के अलावा, किसी और संसाधन की ज़रूरत नहीं है. किसी कुंजी से जुड़े टैग की जांच करके यह देखा जा सकता है कि कुंजी स्टैंडअलोन है या नहीं. फ़िलहाल, सिर्फ़ दो वैल्यू तय की गई हैं:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

वेलोसिटी

इसे बनाने के बाद, TAG::MIN_SECONDS_BETWEEN_OPS की मदद से, इस्तेमाल की सबसे ज़्यादा दर तय की जा सकती है. अगर कोई कार्रवाई TAG::MIN_SECONDS_BETWEEN_OPS सेकंड से कम समय पहले की गई थी, तो TrustZone लागू होने पर उस कुंजी से क्रिप्टोग्राफ़िक ऑपरेशन नहीं किए जा सकते.

अनुरोधों की संख्या पर पाबंदी लगाने का आसान तरीका, कुंजी आईडी और आखिरी इस्तेमाल के टाइमस्टैंप की टेबल है. इस टेबल का साइज़ सीमित है, लेकिन इसमें कम से कम 16 एंट्री हो सकती हैं. अगर टेबल पूरी हो जाती है और किसी भी एंट्री को अपडेट या खारिज नहीं किया जा सकता, तो सुरक्षित हार्डवेयर लागू करने की प्रोसेस "सुरक्षित नहीं रहती". साथ ही, जब तक किसी एंट्री की समयसीमा खत्म नहीं हो जाती, तब तक वे सभी मुख्य ऑपरेशन करने से मना कर देती है जिनमें गति की सीमा होती है. रीबूट करने पर, सभी एंट्री की समयसीमा खत्म हो सकती है.

TAG::MAX_USES_PER_BOOT का इस्तेमाल करके, बूट होने पर बटनों के इस्तेमाल की संख्या को n तक सीमित किया जा सकता है. इसके लिए, ट्रैकिंग टेबल की भी ज़रूरत होती है. इसमें कम से कम चार कुंजियां होनी चाहिए और यह फ़ेल-सेफ़ होनी चाहिए. ध्यान दें कि ऐप्लिकेशन, हर बार बूट होने पर सीमित कुंजियां नहीं बना सकते. यह सुविधा, पासकोड के ज़रिए ऐक्सेस नहीं की जा सकती. इसे सिर्फ़ सिस्टम के कामों के लिए इस्तेमाल किया जाता है.

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

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

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

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