Authentication

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

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

Gatekeeper, फ़िंगरप्रिंट, और बायोमेट्रिक कॉम्पोनेंट, हार्डवेयर के साथ काम करने वाले ऑथेंटिकेशन टोकन (AuthTokens) का इस्तेमाल करने के लिए, Keystore और अन्य कॉम्पोनेंट के साथ काम करते हैं.

सेट अप

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

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

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

पुष्टि करना

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

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

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

ध्यान दें: डिवाइस के रीबूट होने पर, AuthToken अमान्य हो जाते हैं.

AuthToken का फ़ॉर्मैट

hw_auth_token.h में AuthToken फ़ॉर्मैट के बारे में बताया गया है, ताकि यह पक्का किया जा सके कि टोकन को सभी भाषाओं और कॉम्पोनेंट के साथ शेयर किया जा सके और वह उन पर काम कर सके. यह फ़ॉर्मैट, तय साइज़ वाले फ़ील्ड वाला एक आसान सीरियलाइज़ेशन प्रोटोकॉल है.

फ़ील्ड	टाइप	ज़रूरी है	ब्यौरा
AuthToken का वर्शन	1 बाइट	हां	नीचे दिए गए सभी फ़ील्ड के लिए ग्रुप टैग.
चुनौती	64-बिट का बिना हस्ताक्षर वाला पूर्णांक	नहीं	रीप्ले अटैक को रोकने के लिए, एक रैंडम इंटिजर. आम तौर पर, यह क्रिप्टो ऑपरेशन के अनुरोध का आईडी होता है. फ़िलहाल, इसका इस्तेमाल लेन-देन के लिए फ़िंगरप्रिंट की अनुमति देने के लिए किया जाता है. अगर मौजूद है, तो AuthToken सिर्फ़ उन क्रिप्टो ऑपरेशन के लिए मान्य है जिनमें एक ही चैलेंज शामिल है.
उपयोगकर्ता का एसआईडी	64-बिट का बिना हस्ताक्षर वाला पूर्णांक	हां	डिवाइस की पुष्टि करने से जुड़ी सभी कुंजियों से क्रिप्टोग्राफ़िक तरीके से जुड़ा, ऐसा उपयोगकर्ता आइडेंटिफ़ायर जो दोहराया नहीं जाता. ज़्यादा जानकारी के लिए, गेटकीपर्स लेख पढ़ें.
पुष्टि करने वाला आईडी (एएसआईडी)	नेटवर्क ऑर्डर में 64-बिट का बिना हस्ताक्षर वाला इंटिजर	नहीं	आइडेंटिफ़ायर, जिसका इस्तेमाल पुष्टि करने वाले किसी खास ऐप्लिकेशन की नीति से बांधने के लिए किया जाता है. सभी पुष्टि करने वाले टूल के पास अपनी ASID वैल्यू होती है, जिसे वे अपनी ज़रूरतों के हिसाब से बदल सकते हैं.
पुष्टि करने वाले ऐप्लिकेशन या डिवाइस का टाइप	नेटवर्क क्रम में 32-बिट का बिना हस्ताक्षर वाला पूर्णांक	हां	0x00, गेटकीपर है. 0x01, फ़िंगरप्रिंट है.
टाइमस्टैंप	नेटवर्क ऑर्डर में 64-बिट का बिना हस्ताक्षर वाला इंटिजर	हां	सिस्टम के हाल ही में बूट होने के बाद से अब तक का समय (मिलीसेकंड में).
AuthToken HMAC (SHA-256)	256-बिट ब्लॉब	हां	HMAC फ़ील्ड को छोड़कर, सभी फ़ील्ड का पासकोड वाला SHA-256 मैक.

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

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

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

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

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