Authentication

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

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

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

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

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

सेट अप

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

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

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

पुष्टि करना

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

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

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

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

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

AuthToken का फ़ॉर्मैट

AuthToken का फ़ॉर्मैट, एआईडीएल की खास बातों में दिया गया है. इसे HardwareAuthToken.aidl में देखा जा सकता है.

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

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

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

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

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

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

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