KeyMint के फ़ंक्शन

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

एपीआई का दुरुपयोग

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

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

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

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

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

मुख्य बातें

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

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

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

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

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

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

चालू करें

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

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

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

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

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