Authentication

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

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

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

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

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

सेट अप

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

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

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

पुष्टि करना

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

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

पहली इमेज. पुष्टि करने का तरीका

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

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

AuthToken का फ़ॉर्मैट

AuthToken का फ़ॉर्मैट, HardwareAuthToken.aidl में एआईडीएल स्पेसिफ़िकेशन में दिया गया है.

डिवाइस के बूट होने का फ़्लो

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

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

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

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

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

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