सुविधाएं

इस पेज पर, Android 6.0 और उसके बाद के वर्शन में Keystore की क्रिप्टोग्राफ़िक सुविधाओं के बारे में जानकारी दी गई है.

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

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

  • पासकोड जनरेट करना
  • असिमेट्रिक पासकोड इंपोर्ट और एक्सपोर्ट करना (बिना पासकोड रैपिंग के)
  • रॉ सिमेट्रिक पासकोड इंपोर्ट करना (बिना पासकोड रैपिंग के)
  • सही पैडिंग मोड के साथ एसिमेट्रिक एन्क्रिप्शन और डिक्रिप्शन
  • डाइजेस्ट और सही पैडिंग मोड के साथ, असिमेट्रिक साइनिंग और पुष्टि करना
  • सही मोड में सिमेट्रिक एन्क्रिप्शन और डिक्रिप्शन, जिसमें AEAD मोड भी शामिल है
  • मैसेज की पुष्टि करने वाले सिमेट्रिक कोड जनरेट करना और उनकी पुष्टि करना

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

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

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

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

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

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

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

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

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

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

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

UINT: 32-बिट के बिना साइन वाले पूर्णांक. उदाहरण: TAG::KEY_SIZE

UINT_REP: यह UINT जैसा ही है. हालांकि, अनुमति वाली सूची में टैग को दोहराया जा सकता है. दोहराए जाने पर, अनुमति वाली कई वैल्यू दिखती हैं.

ULONG: बिना साइन वाले 64-बिट पूर्णांक. उदाहरण: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP: यह ULONG जैसा ही है. हालांकि, अनुमति वाली सूची में टैग को दोहराया जा सकता है. दोहराए जाने पर, अनुमति वाली कई वैल्यू दिखती हैं.

DATE: तारीख/समय की वैल्यू, जिन्हें 1 जनवरी, 1970 से मिलीसेकंड के तौर पर दिखाया जाता है. उदाहरण: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL: सही या गलत. अगर BOOL टाइप का टैग मौजूद नहीं है, तो उसे "गलत" माना जाता है. अगर टैग मौजूद है, तो उसे "सही" माना जाता है. उदाहरण: TAG::ROLLBACK_RESISTANT

BIGNUM: बिग-एंडियन क्रम में बाइट कलेक्शन के तौर पर दिखाए गए, अपनी पसंद के हिसाब से लंबाई वाले पूर्णांक. उदाहरण: TAG::RSA_PUBLIC_EXPONENT

BYTES: बाइट का क्रम. उदाहरण: TAG::ROOT_OF_TRUST

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

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

लागू करने के सभी तरीके:

  • सभी अनुमतियों के लिए एग्ज़ैक्ट मैच लागू करें (लागू नहीं करें). पासकोड ब्लॉब में मौजूद अनुमति की सूचियां, पासकोड जनरेट करने के दौरान मिली अनुमतियों से पूरी तरह मेल खाती हैं. इनमें क्रम भी शामिल है. अगर कोई मेल नहीं खाता है, तो गड़बड़ी का विश्लेषण किया जाता है.
  • उन अनुमतियों का एलान करें जिनकी सेमेटिक वैल्यू लागू की गई हैं.

हार्डवेयर से लागू की गई अनुमतियों का एलान करने के लिए, एपीआई का तरीका keymaster_key_characteristics_t स्ट्रक्चर में है. यह अनुमति वाली सूची को दो सब-लिस्ट, hw_enforced और sw_enforced में बांटता है. सुरक्षित हार्डवेयर, हर फ़ील्ड में सही वैल्यू डालने के लिए ज़िम्मेदार होता है. यह इस बात पर निर्भर करता है कि वह क्या लागू कर सकता है.

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

उदाहरण के लिए, TrustZone पर आधारित ऐसा तरीका जो पासकोड की समयसीमा खत्म होने की सुविधा के साथ काम नहीं करता. हालांकि, अब भी ऐसी कुंजी बनाई जा सकती है जिसकी समयसीमा खत्म हो. उस पासकोड की अनुमति वाली सूची में, खत्म होने की तारीख वाला टैग TAG::ORIGINATION_EXPIRE_DATETIME शामिल है. पासकोड की विशेषताओं के लिए Keystore से किए गए अनुरोध से, sw_enforced सूची में यह टैग मिलता है. साथ ही, सुरक्षित हार्डवेयर, पासकोड की समयसीमा खत्म होने की ज़रूरी शर्त लागू नहीं करता. हालांकि, समयसीमा खत्म होने के बाद कुंजी का इस्तेमाल करने की कोशिश करने पर, Keystore उसे अस्वीकार कर देता है.

अगर डिवाइस को ऐसे सुरक्षित हार्डवेयर के साथ अपग्रेड किया जाता है जो पासकोड की समयसीमा खत्म होने की सुविधा के साथ काम करता है, तो पासकोड की विशेषताओं के लिए अनुरोध करने पर, hw_enforced सूची में TAG::ORIGINATION_EXPIRE_DATETIME मिलता है. साथ ही, पासकोड की समयसीमा खत्म होने के बाद, पासकोड का इस्तेमाल करने की कोशिश की जाती है. भले ही, पासकोड स्टोर को बदला गया हो या बायपास किया गया हो.

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

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

इन टैग का इस्तेमाल, एन्क्रिप्शन की सुविधाओं को तय करने के लिए किया जाता है. इन सुविधाओं को तय करने के लिए, एन्क्रिप्शन की कुंजी का इस्तेमाल किया जाता है: TAG::ALGORITHM, TAG::KEY_SIZE, TAG::BLOCK_MODE, TAG::PADDING, TAG::CALLER_NONCE, और TAG::DIGEST

TAG::PADDING, TAG::DIGEST, और PaddingMode::BLOCK_MODE को दोहराया जा सकता है. इसका मतलब है कि एक ही बटन से कई वैल्यू असोसिएट की जा सकती हैं. साथ ही, इस्तेमाल की जाने वाली वैल्यू को ऑपरेशन के समय तय किया जाता है.

मकसद

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

  • KeyPurpose::ENCRYPT
  • KeyPurpose::DECRYPT
  • KeyPurpose::SIGN
  • KeyPurpose::VERIFY

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

इंपोर्ट और एक्सपोर्ट

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

  • पासवर्ड पर आधारित एन्क्रिप्शन के बिना, डीईआर में एन्कोड किए गए पीकेसीएस#8 फ़ॉर्मैट में सार्वजनिक और निजी पासकोड
  • रॉ बाइट के तौर पर सिमेट्रिक पासकोड

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

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

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

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

  • TAG::ALL_USERS से पता चलता है कि पासकोड का इस्तेमाल सभी उपयोगकर्ता कर सकते हैं. अगर यह मौजूद है, तो TAG::USER_ID और TAG::USER_SECURE_ID मौजूद नहीं है.
  • TAG::USER_ID की वैल्यू संख्या होती है, जिसमें अनुमति पा चुके उपयोगकर्ता का आईडी होता है. ध्यान दें कि यह एक से ज़्यादा उपयोगकर्ताओं के लिए Android यूज़र आईडी है, न कि ऐप्लिकेशन का यूआईडी. साथ ही, इसे सिर्फ़ गैर-सुरक्षित सॉफ़्टवेयर लागू करता है. अगर यह मौजूद है, तो TAG::ALL_USERS मौजूद नहीं है.
  • TAG::USER_SECURE_ID में 64-बिट की संख्या वाली वैल्यू होती है, जिसमें सुरक्षित उपयोगकर्ता आईडी की जानकारी होती है. यह आईडी, पुष्टि करने के लिए इस्तेमाल किए जाने वाले सुरक्षित टोकन में दिया जाता है, ताकि कुंजी का इस्तेमाल किया जा सके. अगर कुंजी को दोहराया जाता है, तो उसका इस्तेमाल तब किया जा सकता है, जब पुष्टि करने वाले किसी सुरक्षित टोकन में कोई वैल्यू दी गई हो.

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

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

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

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

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

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

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

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

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

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

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

समयसीमा

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

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

वॉल-क्लॉक टाइम, असुरक्षित वर्ल्ड से मिलता है. इसलिए, यह संभावना नहीं है कि समयसीमा से जुड़े टैग, हार्डवेयर से लागू की गई सूची में हों. हार्डवेयर के लिए समयसीमा लागू करने के लिए, यह ज़रूरी है कि सुरक्षित वर्ल्ड किसी तरह से भरोसेमंद समय और डेटा हासिल करे. उदाहरण के लिए, किसी भरोसेमंद रिमोट टाइम सर्वर के साथ चैलेंज रिस्पॉन्स प्रोटोकॉल की मदद से.

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

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

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

स्टैंडअलोन बटन

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

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

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

वेलोसिटी

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

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

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

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

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

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

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

यह सुविधा ऐप्लिकेशन के लिए उपलब्ध नहीं है. हालांकि, फ़्रेमवर्क इसका इस्तेमाल करता है. यह फ़्रेमवर्क, सुरक्षित हार्डवेयर को नियमित तौर पर अतिरिक्त एन्ट्रापी उपलब्ध कराता है. यह एन्ट्रापी, Java SecureRandom इंस्टेंस से ली जाती है.