गेटकीपर

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

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

वास्तुकला

Gatekeeper में तीन मुख्य कॉम्पोनेंट शामिल हैं:

• gatekeeperd (गेटकीपर डीमन) — Android में मौजूद C++ बाइंडर सेवा. इसमें प्लैटफ़ॉर्म पर निर्भर न रहने वाला लॉजिक होता है. यह लॉजिक, IGatekeeper के वेंडर के हिसाब से लागू किए गए लॉजिक के आधार पर, IGateKeeperService AIDL इंटरफ़ेस को लागू करता है.
• Gatekeeper हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल) सेवा — IGatekeeper एआईडीएल इंटरफ़ेस को वेंडर के हिसाब से लागू करना. यह एचएएल सेवा Android में चलती है. हालांकि, Gatekeeper की मुख्य सुविधा को सुरक्षित एनवायरमेंट में चलाना ज़रूरी है. इसलिए, यह आम तौर पर Gatekeeper टीए के साथ कम्यूनिकेट करती है.
• Gatekeeper Trusted Application (टीए) — वेंडर के हिसाब से लागू किया गया एक ऐसा सिस्टम जो टीईई में चलता है. साथ ही, पासवर्ड या पैटर्न की असल पुष्टि करता है.

LockSettingsService, बाइंडर के ज़रिए एक अनुरोध करता है, जो Android OS में gatekeeperd डीमन तक पहुंचता है. इसके बाद, gatekeeperd डीमन, IGatekeeper एचएएल सेवा से अनुरोध करता है. इसके बाद, यह अनुरोध टीईई में मौजूद Gatekeeper टीए तक पहुंचता है:

पहली इमेज. GateKeeper से पुष्टि करने के लिए, हाई-लेवल डेटा फ़्लो.

gatekeeperd डीमन, Android फ़्रेमवर्क एपीआई को एचएएल का ऐक्सेस देता है. साथ ही, कीस्टोर को डिवाइस की पुष्टि की जानकारी देने में मदद करता है. gatekeeperd डीमन अपनी प्रोसेस में चलता है और सिस्टम सर्वर से अलग होता है.

एचएएल लागू करना

gatekeeperd डीमन, पासवर्ड की पुष्टि करने के लिए, पहले से मौजूद Gatekeeper टीए के साथ इंटरैक्ट करने के लिए IGatekeeper एचएएल का इस्तेमाल करता है. Gatekeeper टीए को लागू करने के लिए, ब्लॉब पर हस्ताक्षर (रजिस्टर) करने और उनकी पुष्टि करने की सुविधा होनी चाहिए. यह ज़रूरी है कि सभी इंटिग्रेशन, पुष्टि करने वाले टोकन (HardwareAuthToken) के स्टैंडर्ड फ़ॉर्मैट का पालन करें. यह टोकन, पासवर्ड की पुष्टि होने पर जनरेट होता है. HardwareAuthToken के कॉन्टेंट और सिमैंटिक के बारे में ज़्यादा जानने के लिए, HardwareAuthToken.aidl की परिभाषा देखें.

IGatekeeper एचएएल के वेंडर को enroll और verify फ़ंक्शन लागू करने होंगे:

• enroll तरीका, पासवर्ड ब्लॉब लेता है, उस पर हस्ताक्षर करता है, और हस्ताक्षर को हैंडल के तौर पर दिखाता है. enroll को कॉल करने से मिले ब्लॉब का स्ट्रक्चर, system/gatekeeper/include/gatekeeper/password_handle.h में दिखाए गए स्ट्रक्चर जैसा होना चाहिए.
• verify फ़ंक्शन को, दिए गए पासवर्ड से जनरेट किए गए सिग्नेचर की तुलना करनी चाहिए. साथ ही, यह पक्का करना चाहिए कि वह रजिस्टर किए गए पासवर्ड हैंडल से मेल खाता हो.

रजिस्टर करने और पुष्टि करने के लिए इस्तेमाल की जाने वाली कुंजी कभी नहीं बदलनी चाहिए. साथ ही, डिवाइस के हर बार चालू होने पर, इसे फिर से जनरेट किया जाना चाहिए.

Trusty और अन्य इंप्लिमेंटेशन

Trusty ऑपरेटिंग सिस्टम, टीईई एनवायरमेंट के लिए Google का ओपन सोर्स भरोसेमंद ओएस है. इसमें Gatekeeper को लागू करने की अनुमति है. हालांकि, कोई भी टीईई ओएस Gatekeeper को तब तक लागू कर सकता है, जब तक टीईई के पास हार्डवेयर से सुरक्षित कुंजी और सुरक्षित, मोनोटोनिक क्लॉक का ऐक्सेस हो. यह क्लॉक, सस्पेंड मोड में भी काम करती है.

Trusty, शेयर किए गए सीक्रेट को सीधे KeyMint (पहले Keymaster) और Gatekeeper के Trusty वर्शन (Trusty Gatekeeper) के बीच शेयर करने के लिए, इंटरनल आईपीसी सिस्टम का इस्तेमाल करता है. इस शेयर किए गए सीक्रेट का इस्तेमाल, Keystore को भेजे गए पुष्टि करने वाले टोकन पर हस्ताक्षर करने के लिए किया जाता है. इससे पासवर्ड की पुष्टि करने के सबूत मिलते हैं. Trusty Gatekeeper, हर बार इस्तेमाल के लिए KeyMint से कुंजी का अनुरोध करता है. साथ ही, यह वैल्यू को सेव या कैश मेमोरी में सेव नहीं करता. लागू करने वाले लोग, इस सीक्रेट को किसी भी ऐसे तरीके से शेयर कर सकते हैं जिससे सुरक्षा से समझौता न हो.

पासवर्ड रजिस्टर करने और उनकी पुष्टि करने के लिए इस्तेमाल की जाने वाली एचएमएसी कुंजी, सिर्फ़ Gatekeeper में जनरेट और सेव की जाती है.

Android, C++ Gatekeeper को लागू करने का एक सामान्य तरीका उपलब्ध कराता है. इसके लिए, सिर्फ़ डिवाइस के हिसाब से रूटीन जोड़ने की ज़रूरत होती है. Trusty को लागू करने का तरीका इसी पर आधारित है. अपने टीईई के लिए, डिवाइस के हिसाब से कोड वाले टीईई गेटकीपर को लागू करने के लिए, system/gatekeeper/include/gatekeeper/gatekeeper.h में दिए गए फ़ंक्शन और टिप्पणियां देखें. नीति का पालन करने वाले तरीके की मुख्य ज़िम्मेदारियों में ये शामिल हैं:

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

उपयोगकर्ता के सुरक्षित आईडी (एसआईडी)

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

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

पासवर्ड रजिस्टर होने पर, उपयोगकर्ता का एसआईडी, पासवर्ड हैंडल में पासवर्ड के साथ एचएमएसी ऑथेंटिकेशन में शामिल होता है.

उपयोगकर्ता के एसआईडी, verify() फ़ंक्शन से मिले HardwareAuthToken में शामिल होते हैं. साथ ही, ये पुष्टि करने के लिए इस्तेमाल होने वाली Keystore की सभी कुंजियों से जुड़े होते हैं. HardwareAuthToken फ़ॉर्मैट और Keystore के बारे में ज़्यादा जानने के लिए, पुष्टि करना लेख पढ़ें.

ध्यान दें कि enroll() फ़ंक्शन को किए गए किसी अविश्वसनीय कॉल से उपयोगकर्ता का SID बदल जाता है. इस वजह से, कॉल उस पासवर्ड से जुड़ी कुंजियों को बेकार कर देता है. अगर हमलावरों के पास Android OS का कंट्रोल है, तो वे डिवाइस का पासवर्ड बदल सकते हैं. हालांकि, इस प्रोसेस में वे रूट से सुरक्षित की गई संवेदनशील कुंजियों को मिटा देते हैं.

अनुरोधों को थ्रॉटल करना

Gatekeeper को उपयोगकर्ता के क्रेडेंशियल पर ब्रूट-फ़ोर्स अटैक को सुरक्षित तरीके से रोकने में सक्षम होना चाहिए. GatekeeperVerifyResponse.aidl में दिखाए गए तरीके के मुताबिक, एचएएल मिलीसेकंड में टाइम आउट दिखाता है. टाइम आउट, क्लाइंट को सूचना देता है कि टाइम आउट खत्म होने तक, Gatekeeper को फिर से कॉल न करें. अगर टाइम आउट की प्रोसेस बाकी है, तो Gatekeeper को अनुरोधों को पूरा नहीं करना चाहिए.

उपयोगकर्ता के पासवर्ड की पुष्टि करने से पहले, Gatekeeper को फ़ेलियर काउंटर लिखना होगा. अगर पासवर्ड की पुष्टि हो जाती है, तो गड़बड़ी का काउंटर हट जाना चाहिए. इससे उन हमलों को रोका जा सकता है जो verify कॉल करने के बाद, एम्बेड किए गए एमएमसी (ईएमएमसी) को बंद करके, थ्रॉटलिंग को रोकते हैं. enroll फ़ंक्शन, उपयोगकर्ता के पासवर्ड की भी पुष्टि करता है (अगर दिया गया हो). साथ ही, इसे भी उसी तरह थ्रॉटल किया जाना चाहिए.

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