सुविधाएं

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

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

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

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

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

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

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

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 नहीं) के ज़रिए की जाती है.

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

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

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