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