Authentication

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

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

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

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

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

रजिस्ट्रेशन

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

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

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

प्रमाणीकरण

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

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

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

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

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

AuthToken का फ़ॉर्मैट

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

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

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

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

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

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

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

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