KeyMint के फ़ंक्शन

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

एपीआई का गलत इस्तेमाल

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

ऐप्लिकेशन, फ़्रेमवर्क, और Android Keystore की ज़िम्मेदारी है कि वे यह पक्का करें कि KeyMint मॉड्यूल के कॉल सही और काम के हों.

addRngEntropy एंट्री पॉइंट

addRngEntropy एंट्री पॉइंट, कॉलर से मिले एन्ट्रापी को पूल में जोड़ता है. इस पूल का इस्तेमाल, KeyMint लागू करने के लिए किया जाता है. इससे, कुंजियों और आईवी के लिए, रैंडम नंबर जनरेट किए जाते हैं.

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

मुख्य विशेषताएं

KeyMint पासकोड बनाने वाले हर तरीके (generateKey, importKey, और importWrappedKey) से, बनाई गई नई पासकोड की विशेषताएं मिलती हैं. इन विशेषताओं को सुरक्षा के उन लेवल में बांटा जाता है जो हर विशेषता को लागू करते हैं. लौटाई गई विशेषताओं में, Tag::APPLICATION_ID और Tag::APPLICATION_DATA को छोड़कर, कुंजी बनाने के लिए बताए गए सभी पैरामीटर शामिल होते हैं. अगर इन टैग को मुख्य पैरामीटर में शामिल किया जाता है, तो उन्हें दिखाए गए एट्रिब्यूट से हटा दिया जाता है, ताकि दिखाए गए keyblob की जांच करके उनकी वैल्यू न मिल सके. हालांकि, ये एन्क्रिप्शन की मदद से, कीब्लॉब से जुड़े होते हैं. इसलिए, अगर कुंजी का इस्तेमाल करते समय सही वैल्यू नहीं दी जाती हैं, तो इसका इस्तेमाल नहीं किया जा सकता. इसी तरह, Tag::ROOT_OF_TRUST को पासकोड से क्रिप्टोग्राफ़िक तरीके से जोड़ा जाता है. हालांकि, पासकोड बनाने या इंपोर्ट करने के दौरान इसकी जानकारी नहीं दी जा सकती. साथ ही, इसे कभी भी नहीं दिखाया जाता.

दिए गए टैग के अलावा, KeyMint लागू करने पर Tag::ORIGIN भी जोड़ा जाता है. इससे यह पता चलता है कि पासकोड कैसे बनाया गया था (KeyOrigin::GENERATED, KeyOrigin::IMPORTED या KeyOrigin::SECURELY_IMPORTED).

रोलबैक रेज़िस्टेंस (कुंजी का दोबारा इस्तेमाल न हो पाना)

रोलबैक रेज़िस्टेंस की जानकारी Tag::ROLLBACK_RESISTANCE से मिलती है. इसका मतलब है कि deleteKey या deleteAllKeys की मदद से किसी कुंजी को मिटाने के बाद, सुरक्षित हार्डवेयर यह पक्का करता है कि उसका फिर कभी इस्तेमाल न किया जा सके.

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

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

चालू करें

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

KeyMint को लागू करने पर, एक साथ कम से कम 16 ऑपरेशन किए जा सकते हैं. पासवर्ड एन्क्रिप्ट (सुरक्षित) करने के लिए, vold एक कुंजी का इस्तेमाल करता है. बाकी 15 कुंजियों का इस्तेमाल, पासवर्ड एन्क्रिप्ट (सुरक्षित) करने के लिए, पासवर्ड मैनेजर की कुंजी के तौर पर किया जाता है. जब Keystore में 15 ऑपरेशन चल रहे हों (begin() को कॉल किया गया है, लेकिन finish या abort को कॉल नहीं किया गया है) और उसे 16वां ऑपरेशन शुरू करने का अनुरोध मिलता है, तो वह हाल ही में सबसे कम इस्तेमाल किए गए ऑपरेशन पर abort() को कॉल करता है. इससे, चालू ऑपरेशन की संख्या को 14 पर कम करने के बाद, begin() को कॉल करके नया अनुरोध किया गया ऑपरेशन शुरू किया जाता है.

अगर कुंजी जनरेट करने या इंपोर्ट करने के दौरान Tag::APPLICATION_ID या Tag::APPLICATION_DATA का इस्तेमाल किया गया था, तो begin() को कॉल करने पर, उन टैग को शामिल करना ज़रूरी है जिनकी वैल्यू, इस तरीके के params आर्ग्युमेंट में मूल रूप से दी गई थी.

गड़बड़ी ठीक करना

अगर IKeyMintOperation पर कोई तरीका ErrorCode::OK के अलावा कोई दूसरा गड़बड़ी कोड दिखाता है, तो ऑपरेशन रद्द कर दिया जाता है और ऑपरेशन के लिए इस्तेमाल किया गया Binder ऑब्जेक्ट अमान्य हो जाता है. ऑब्जेक्ट का बाद में किया गया इस्तेमाल, ErrorCode::INVALID_OPERATION_HANDLE दिखाता है.

अनुमति लागू करना

कुंजी की अनुमति लागू करने की प्रोसेस मुख्य रूप से begin() में की जाती है. हालांकि, एक अपवाद यह है कि जब कुंजी में एक या उससे ज़्यादा Tag::USER_SECURE_ID वैल्यू हों और Tag::AUTH_TIMEOUT वैल्यू न हो.

इस मामले में, हर कार्रवाई के लिए पासकोड की अनुमति की ज़रूरत होती है. साथ ही, update() या finish() तरीकों को authToken आर्ग्युमेंट में ऑथराइज़ेशन टोकन मिलता है. टोकन मान्य है या नहीं, यह पक्का करने के लिए KeyMint लागू करने के दौरान:

• पुष्टि करने वाले टोकन पर एचएमएसी हस्ताक्षर की पुष्टि करता है.
• यह जांच करता है कि टोकन में सुरक्षित उपयोगकर्ता आईडी है या नहीं. यह आईडी, पासकोड से जुड़े आईडी से मेल खाना चाहिए.
• यह जांच करता है कि टोकन का पुष्टि करने का तरीका, पासकोड के Tag::USER_AUTH_TYPE से मेल खाता है या नहीं.
• यह जांच करता है कि टोकन में, चैलेंज फ़ील्ड में मौजूदा ऑपरेशन के लिए चैलेंज वैल्यू मौजूद है या नहीं.

अगर ये शर्तें पूरी नहीं होती हैं, तो KeyMint ErrorCode::KEY_USER_NOT_AUTHENTICATED दिखाता है.

कॉलर, update() और finish() पर किए जाने वाले हर कॉल के लिए, ऑथेंटिकेशन टोकन उपलब्ध कराता है. लागू करने के बाद, टोकन की पुष्टि सिर्फ़ एक बार की जा सकती है.