सुविधाएं

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

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

Keystore में, इन कैटगरी के ऑपरेशन किए जा सकते हैं:

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

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

ऊपर दी गई सूची के अलावा, एक और सेवा है जो 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 बिट से अलग लंबाई वाले नॉनस का इस्तेमाल नहीं किया जा सकता.
  • पैडिंग मोड PaddingMode::NONE और PaddingMode::PKCS7 का इस्तेमाल, सीबीसी और ईसीबी मोड के लिए किया जा सकता है. पैडिंग के बिना, अगर इनपुट ब्लॉक साइज़ का मल्टीपल नहीं है, तो सीबीसी या ईसीबी मोड में एन्क्रिप्शन नहीं हो पाता.
• HMAC SHA-256, जिसमें कम से कम 32 बाइट तक का कोई भी कुंजी साइज़ हो.

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

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

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

कुंजी के ऐक्सेस कंट्रोल

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

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

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

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

ये टाइप हो सकते हैं:

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

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

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

हार्डवेयर और सॉफ़्टवेयर की मदद से पाबंदी लागू करने की सुविधा के बीच अंतर

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

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

उदाहरण के लिए, सुरक्षित एनवायरमेंट में आम तौर पर, तारीख और समय के उस इंटरवल पर पाबंदियां नहीं लगाई जाती हैं जब किसी कुंजी का इस्तेमाल किया जा सकता है. ऐसा इसलिए होता है, क्योंकि इसके पास तारीख और समय की जानकारी का भरोसेमंद ऐक्सेस नहीं होता. इस वजह से, Android में Keystore, Tag::ORIGINATION_EXPIRE_DATETIME जैसी अनुमतियां लागू करता है और इसमें 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 को कुंजी के लिए अनुमति देने वाली सूची में शामिल किया जाता है. उदाहरण के लिए, अगर किसी कुंजी को सुरक्षित हार्डवेयर में जनरेट किया गया है, तो Tag::ORIGIN वैल्यू वाला KeyOrigin::GENERATED, कुंजी की विशेषताओं की hw_enforced सूची में मौजूद होता है. वहीं, सुरक्षित हार्डवेयर में इंपोर्ट की गई कुंजी की वैल्यू 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 को KeyMint के बजाय Keystore लागू करता है. हालांकि, Android 12 और इसके बाद के वर्शन में, डिवाइस लॉक होने पर Keystore, UNLOCKED_DEVICE_REQUIRED कुंजियों को क्रिप्टोग्राफ़िक तरीके से सुरक्षित रखता है. इससे यह पक्का किया जाता है कि ज़्यादातर मामलों में, डिवाइस लॉक होने पर Keystore के साथ छेड़छाड़ होने पर भी इन कुंजियों का इस्तेमाल न किया जा सके.

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

UnlockedDeviceRequired सुपर कुंजियां

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

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

• UnlockedDeviceRequired सिमेट्रिक सुपर पासकोड. यह AES‑256‑GCM कुंजी है. यह उन UNLOCKED_DEVICE_REQUIRED कुंजियों को एन्क्रिप्ट (सुरक्षित) करता है जिन्हें इंपोर्ट किया जाता है, जनरेट किया जाता है या डिवाइस के अनलॉक होने पर इस्तेमाल किया जाता है.
• यह UnlockedDeviceRequired असिमेट्रिक सुपर कुंजी है. यह ECDH P‑521 कुंजी का जोड़ा है. यह उन UNLOCKED_DEVICE_REQUIRED कुंजियों को एन्क्रिप्ट (सुरक्षित) करता है जिन्हें डिवाइस लॉक होने पर इंपोर्ट या जनरेट किया जाता है. ज़्यादा जानकारी के लिए, डिवाइस लॉक होने पर कुंजियां सेव करना लेख पढ़ें.

सुपर कुंजियां जनरेट करें और उनकी सुरक्षा करें

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

1. सिस्टम सर्वर, SP800‑108 KDF का इस्तेमाल करके, उपयोगकर्ता के सिंथेटिक पासवर्ड से उपयोगकर्ता के Keystore का पासवर्ड हासिल करता है.
2. सिस्टम सर्वर, उपयोगकर्ता के कीस्टोर पासवर्ड को कीस्टोर पर भेजता है.
3. Keystore, उपयोगकर्ता की सुपर कुंजियां जनरेट करता है.
4. उपयोगकर्ता की हर सुपर की के लिए:
   1. Keystore, रैंडम सॉल्ट जनरेट करता है.
   2. Keystore, HKDF‑SHA256 का इस्तेमाल करके, उपयोगकर्ता के Keystore पासवर्ड और सॉल्ट से AES‑256‑GCM कुंजी बनाता है.
   3. कीस्टोर, इस AES‑256‑GCM कुंजी का इस्तेमाल करके सुपर की के सीक्रेट हिस्से को एन्क्रिप्ट यानी सुरक्षित करता है.
   4. Keystore, एन्क्रिप्ट (सुरक्षित) की गई सुपर की और उसके सॉल्ट को अपने डेटाबेस में सेव करता है. अगर यह एसिमेट्रिक कुंजी है, तो कुंजी का सार्वजनिक हिस्सा भी बिना एन्क्रिप्ट (सुरक्षित) किए सेव किया जाता है.

इस प्रोसेस से, सुपर की को डिक्रिप्ट किया जा सकता है. ऐसा तब होता है, जब उपयोगकर्ता को सिंथेटिक पासवर्ड पता हो. जैसे, जब उपयोगकर्ता सही पिन, पैटर्न या पासवर्ड डालता है.

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

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

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

डिवाइस लॉक होने पर कुंजियां सेव करें

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

• एन्क्रिप्शन (डिवाइस लॉक होने पर UNLOCKED_DEVICE_REQUIRED कुंजी इंपोर्ट करना या जनरेट करना):
  1. Keystore, कुछ समय के लिए इस्तेमाल होने वाली नई ECDH P‑521 कुंजी का जोड़ा जनरेट करता है.
  2. कीस्टोर, शेयर किया जाने वाला सीक्रेट कोड जनरेट करता है. इसके लिए, वह इस छोटे समय के लिए इस्तेमाल होने वाली कुंजी के जोड़े की निजी कुंजी और UnlockedDeviceRequired असिमेट्रिक सुपर कुंजी के सार्वजनिक हिस्से के बीच ECDH कुंजी समझौता करता है.
  3. Keystore, रैंडम सॉल्ट जनरेट करता है.
  4. कीस्टोर, HKDF‑SHA256 का इस्तेमाल करके, शेयर किए गए सीक्रेट और सॉल्ट से AES‑256‑GCM कुंजी बनाता है.
  5. कीस्टोर, इस AES‑256‑GCM कुंजी का इस्तेमाल करके UNLOCKED_DEVICE_REQUIRED कुंजी को एन्क्रिप्ट करता है.
  6. Keystore, एन्क्रिप्ट (सुरक्षित) की गई UNLOCKED_DEVICE_REQUIRED की, साल्ट, और कुछ समय तक काम करने वाले की-पेयर के सार्वजनिक हिस्से को अपने डेटाबेस में सेव करता है.
• डिक्रिप्ट करना (डिवाइस अनलॉक होने पर, बनाई गई UNLOCKED_DEVICE_REQUIRED कुंजी का इस्तेमाल करके):
  1. Keystore, अपने डेटाबेस से एन्क्रिप्ट (सुरक्षित) की गई UNLOCKED_DEVICE_REQUIRED की, साल्ट, और कुछ समय के लिए इस्तेमाल होने वाले की-पेयर का सार्वजनिक हिस्सा लोड करता है.
  2. कीस्टोर, शेयर किया जाने वाला सीक्रेट कोड जनरेट करता है. इसके लिए, वह कुछ समय के लिए इस्तेमाल की जाने वाली कुंजी के जोड़े के सार्वजनिक हिस्से और UnlockedDeviceRequired असिमेट्रिक सुपर कुंजी के निजी हिस्से के बीच, ECDH कुंजी का कानूनी समझौता करता है. डिवाइस अनलॉक होने की वजह से, निजी कुंजी उपलब्ध है.
  3. कीस्टोर, HKDF‑SHA256 का इस्तेमाल करके, शेयर किए गए सीक्रेट और सॉल्ट से AES‑256‑GCM कुंजी बनाता है. यह AES‑256‑GCM कुंजी, एन्क्रिप्शन के दौरान इस्तेमाल की गई कुंजी के जैसी ही है.
  4. कीस्टोर, AES‑256‑GCM कुंजी का इस्तेमाल करके UNLOCKED_DEVICE_REQUIRED कुंजी को डिक्रिप्ट करता है.
  5. Keystore, UnlockedDeviceRequired सिमेट्रिक सुपर पासकोड का इस्तेमाल करके, UNLOCKED_DEVICE_REQUIRED पासकोड को फिर से एन्क्रिप्ट (सुरक्षित) करता है. इससे कुंजी की सुरक्षा से जुड़ी प्रॉपर्टी पर कोई असर नहीं पड़ता. हालांकि, इससे बाद में कुंजी को ज़्यादा तेज़ी से ऐक्सेस किया जा सकता है.

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

1. कीस्टोर से बाहर, AES‑256‑GCM कुंजी जनरेट करें.
2. एईएस‑256‑जीसीएम कुंजी का इस्तेमाल करके डेटा को एन्क्रिप्ट (सुरक्षित) करें.
3. एईएस‑256‑जीसीएम की को कीस्टोर में इंपोर्ट करें. इसके लिए, setUnlockedDeviceRequired(true) की सुरक्षा सेट करें.
4. कुंजी की ओरिजनल कॉपी को मिटा दें.

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

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

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

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

खत्म होने की तारीख

Keystore, तारीख के हिसाब से कुंजी के इस्तेमाल को सीमित करने की सुविधा देता है. कुंजी की वैधता की शुरुआत और कुंजी की समयसीमा खत्म होने की तारीख, किसी कुंजी से जुड़ी हो सकती है. अगर मौजूदा तारीख/समय, मान्य सीमा से बाहर है, तो 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 बार तक सीमित किया जा सकता है. इसके लिए, ट्रैकिंग टेबल की भी ज़रूरत होती है. इसमें कम से कम चार कुंजियां होनी चाहिए और यह फ़ेल सेफ़ भी होनी चाहिए. ध्यान दें कि ऐप्लिकेशन, बूट के हिसाब से सीमित कुंजियां नहीं बना सकते. यह सुविधा, Keystore के ज़रिए उपलब्ध नहीं कराई जाती है. इसे सिस्टम के कामों के लिए रिज़र्व किया गया है.

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

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

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

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