Authentication

Android में, उपयोगकर्ता की पहचान की पुष्टि करने वाले सिस्टम का कॉन्सेप्ट है. इनका इस्तेमाल, डिवाइस को अनलॉक करने और क्रिप्टोग्राफ़िक कुंजियों को ऐक्सेस करने के लिए किया जाता है. इसमें ये कॉम्पोनेंट शामिल होते हैं:

• क्रिप्टोग्राफ़िक कुंजी सेव करने और सेवा देने वाली कंपनी. यह क्रिप्टोग्राफ़िक कुंजियों को सेव करती है और उन कुंजियों के लिए, क्रिप्टोग्राफ़िक की सामान्य प्रोसेस उपलब्ध कराती है. Android, क्रिप्टोग्राफ़िक सेवाओं के लिए, हार्डवेयर की मदद से काम करने वाले कीस्टोर और KeyMint (पहले इसे Keymaster कहा जाता था) की सुविधा देता है. इसमें, कुंजी सेव करने के लिए हार्डवेयर की मदद से क्रिप्टोग्राफ़ी की सुविधा शामिल है. इसमें ट्रस्टेड एक्ज़ीक्यूशन एनवायरमेंट (टीईई) या Secure Element (एसई) शामिल हो सकता है. जैसे, StrongBox.
• उपयोगकर्ता की पहचान की पुष्टि करने वाले सिस्टम. ये उपयोगकर्ता की मौजूदगी और/या पुष्टि की प्रोसेस के सफल होने की पुष्टि करते हैं. Android, पिन/पैटर्न/पासवर्ड से पुष्टि करने के लिए Gatekeeper और फ़िंगरप्रिंट से पुष्टि करने के लिए Fingerprint की सुविधा देता है. Android 9 और इसके बाद के वर्शन वाले डिवाइस, फ़िंगरप्रिंट और अन्य बायोमेट्रिक डेटा के लिए, BiometricPrompt को एक इंटिग्रेशन पॉइंट के तौर पर इस्तेमाल कर सकते हैं. ये कॉम्पोनेंट, पुष्टि की स्थिति के बारे में कीस्टोर सेवा को, पुष्टि किए गए चैनल के ज़रिए बताते हैं. फ़्रेमवर्क लेवल पर, Android Keystore सिस्टम को भी कीस्टोर सेवा से मदद मिलती है.

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

वेंडर के लागू किए गए सिस्टम को आम तौर पर दो हिस्सों में बांटा जाता है. ये दोनों हिस्से, वेंडर के हिसाब से तय किए गए कम्यूनिकेशन मैकेनिज़्म से कनेक्ट होते हैं :

• एचएएल सेवा, Android सिस्टम प्रोसेस के तौर पर काम करती है. यह Android सिस्टम से बाइंडर के अनुरोध स्वीकार करती है.
• ट्रस्टेड ऐप्लिकेशन (टीए), सुरक्षित एनवायरमेंट में काम करता है. यह सुरक्षित तरीके से काम करने की प्रोसेस को पूरा करता है.

रजिस्ट्रेशन

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

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

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

पुष्टि करना

इस सेक्शन में, पुष्टि की सामान्य प्रोसेस के बारे में बताया गया है. इसमें Android और सुरक्षित एनवायरमेंट, दोनों में कई कॉम्पोनेंट के बीच इंटरैक्शन शामिल होते हैं. ध्यान दें कि सुरक्षित कॉम्पोनेंट, हर बूट के लिए एक सीक्रेट एचएमएसी कुंजी शेयर करते हैं. इसका इस्तेमाल, वे एक-दूसरे के मैसेज की पुष्टि करने के लिए करते हैं.

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

पहली इमेज. पुष्टि की प्रोसेस

1. कोई उपयोगकर्ता, पुष्टि करने का कोई तरीका चुनता है. इसके बाद, उससे जुड़ी सेवा एचएएल सेवा को अनुरोध भेजती है.
   • पिन, पैटर्न या पासवर्ड के लिए, LockSettingsService अनुरोध भेजता है gatekeeperd को.
   • बायोमेट्रिक डेटा के आधार पर पुष्टि की प्रोसेस, Android के वर्शन पर निर्भर करती है. Android 8.x और इससे पहले के वर्शन वाले डिवाइसों पर, FingerprintService fingerprintd को अनुरोध भेजता है. Android 9 और इसके बाद के वर्शन वाले डिवाइसों पर, BiometricPrompt सही बायोमेट्रिक डेमॉन को अनुरोध भेजता है. जैसे, फ़िंगरप्रिंट के लिए fingerprintd या चेहरे की पहचान के लिए faced. इसके लिए, सही BiometricManager क्लास का इस्तेमाल किया जाता है. जैसे, FingerprintManager या FaceManager. वर्शन कोई भी हो, अनुरोध भेजने के बाद, बायोमेट्रिक ऑथेंटिकेशन की प्रोसेस एसिंक्रोनस तरीके से होती है.
2. एचएएल सेवा, डेटा को अपने काउंटरपार्ट टीए को भेजती है. इससे AuthToken जनरेट होता है:
   • पिन/पैटर्न/पासवर्ड से पुष्टि करने के लिए, gatekeeperd भेजता है Gatekeeper HAL सेवा के ज़रिए, टीईई में Gatekeeper TA को पिन, पैटर्न या पासवर्ड हैश भेजता है. अगर टीईई में पुष्टि की प्रोसेस सफल होती है, तो Gatekeeper TA, AuthToken जनरेट करता है. इसमें, शेयर की गई एचएमएसी कुंजी से साइन किया गया, उपयोगकर्ता एसआईडी शामिल होता है.
   • फ़िंगरप्रिंट से पुष्टि करने के लिए, fingerprintd फ़िंगरप्रिंट इवेंट को सुनता है और Fingerprint HAL के ज़रिए, टीईई में Fingerprint TA को डेटा भेजता है. अगर टीईई में पुष्टि की प्रोसेस सफल होती है, तो Fingerprint TA, AuthToken जनरेट करता है. इस पर, AuthToken एचएमएसी कुंजी से साइन किया जाता है.
   • अन्य बायोमेट्रिक डेटा से पुष्टि करने के लिए, सही बायोमेट्रिक डेमॉन बायोमेट्रिक इवेंट को सुनता है और उसे सही बायोमेट्रिक एचएएल सेवा और टीए को भेजता है.
3. डेमॉन को साइन किया गया AuthToken मिलता है. इसके बाद, वह इसे कीस्टोर सेवा के बाइंडर इंटरफ़ेस के एक्सटेंशन के ज़रिए, कीस्टोर सेवा को पास करता है. (gatekeeperd जब डिवाइस फिर से लॉक होता है और जब डिवाइस का पासवर्ड बदलता है, तब कीस्टोर सेवा को सूचना भी देता है.)
4. कीस्टोर सेवा, AuthToken को KeyMint को पास करती है और Gatekeeper और बायोमेट्रिक टीईई कॉम्पोनेंट के साथ शेयर की गई कुंजी का इस्तेमाल करके, उनकी पुष्टि करती है. KeyMint, टोकन में मौजूद टाइमस्टैंप को, पुष्टि के आखिरी समय के तौर पर मानता है. साथ ही, टाइमस्टैंप के आधार पर, कुंजी रिलीज़ करने का फ़ैसला लेता है. इससे किसी ऐप्लिकेशन को कुंजी का इस्तेमाल करने की अनुमति मिलती है.

पुष्टि की प्रोसेस के लिए, सुरक्षित एनवायरमेंट में मौजूद टीए के बीच सीधे कम्यूनिकेशन की ज़रूरत नहीं होती: AuthToken, पुष्टि करने वाले टीए से Android में keystore2 सेवा में जाता है. इसके बाद, यह KeyMint TA को पास होता है. इससे keystore2 सेवा, उन अनुरोधों को तुरंत अस्वीकार कर सकती है जिनके पूरे न होने की संभावना होती है. ऐसा इसलिए, क्योंकि उसे सिस्टम में उपलब्ध AuthToken के बारे में जानकारी होती है. इससे, टीईई में होने वाले संभावित महंगे आईपीसी को बचाया जा सकता है.

AuthToken का फ़ॉर्मैट

AuthToken का फ़ॉर्मैट, HardwareAuthToken.aidl में मौजूद AIDL की ज़रूरी शर्तों के हिसाब से तय होता है.

डिवाइस के बूट होने की प्रोसेस

किसी डिवाइस के हर बूट पर, AuthToken एचएमएसी कुंजी जनरेट की जानी चाहिए और इसे सभी टीईई कॉम्पोनेंट (Gatekeeper, KeyMint, और बायोमेट्रिक ट्रस्टलेट) के साथ शेयर किया जाना चाहिए. इसलिए, रीप्ले हमलों से अतिरिक्त सुरक्षा पाने के लिए, डिवाइस के हर बार रीबूट होने पर, एचएमएसी कुंजी को रैंडम तरीके से जनरेट किया जाना चाहिए.

टीए, शेयर की गई इस एचएमएसी कुंजी को दो सामान्य तरीकों से ऐक्सेस करते हैं:

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

किसी भी मामले में, एचएमएसी कुंजी को टीईई के बाहर कभी भी उपलब्ध नहीं कराया जाना चाहिए.

Trusty ऑपरेटिंग सिस्टम, टीईई का एक उदाहरण है. यह Android के साथ चलता है. हालांकि, इसके बजाय अन्य टीईई का इस्तेमाल किया जा सकता है. Trusty, KeyMint और Gatekeeper या सही बायोमेट्रिक ट्रस्टलेट के बीच सीधे कम्यूनिकेट करने के लिए, इंटरनल आईपीसी सिस्टम का इस्तेमाल करता है. एचएमएसी कुंजी सिर्फ़ KeyMint में सेव की जाती है. Fingerprint और Gatekeeper, हर इस्तेमाल के लिए KeyMint से कुंजी का अनुरोध करते हैं. साथ ही, वे वैल्यू को सेव या कैश नहीं करते.

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