सुविधाएं

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

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

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

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

ध्यान दें कि 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 कर्व का इस्तेमाल किया जाता है
  • ECDSA के लिए डाइजेस्ट मोड:
    • कोई डाइजेस्ट नहीं (यह सुविधा अब काम नहीं करती. आने वाले समय में इसे हटा दिया जाएगा)
    • 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 में एन्कोड करती है. एनकोड की गई अनुमति वाली सूची को क्रिप्टोग्राफ़िक तरीके से कीब्लॉब में शामिल किया जाता है, ताकि अनुमति वाली सूची में बदलाव करने की किसी भी कोशिश (इसमें क्रम बदलना भी शामिल है) से अमान्य कीब्लॉब बन जाए. इसका इस्तेमाल क्रिप्टोग्राफ़िक कार्रवाइयों के लिए नहीं किया जा सकता.

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

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

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