गेटकीपर

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

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

भवन निर्माण

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

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

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

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

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

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

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

वेंडर को IGatekeeper HAL लागू करते समय, 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 को भेजे गए AuthToken को साइन करने के लिए किया जाता है. इससे पासवर्ड की पुष्टि के बारे में जानकारी मिलती है. Trusty Gatekeeper, हर इस्तेमाल के लिए KeyMint से पासकोड का अनुरोध करता है. साथ ही, यह वैल्यू को सेव या कैश मेमोरी में सेव नहीं करता है. इस सीक्रेट को शेयर करने के लिए, किसी भी तरीके का इस्तेमाल किया जा सकता है. हालांकि, यह ज़रूरी है कि इससे सुरक्षा को कोई खतरा न हो.

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

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

• IGatekeeper एचएएल का पालन करना.
• लौटाए गए पुष्टि करने वाले टोकन, HardwareAuthToken के स्पेसिफ़िकेशन के मुताबिक फ़ॉर्मैट किए जाने चाहिए. इसके बारे में पुष्टि करने की प्रक्रिया में बताया गया है.
• टीईई गेटकीपर के पास, KeyMint के साथ एचएमएसी कुंजी शेयर करने की सुविधा होनी चाहिए. इसके लिए, वह टीईई आईपीसी के ज़रिए मांग पर कुंजी का अनुरोध कर सकता है या हर समय वैल्यू का मान्य कैश बनाए रख सकता है.

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

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

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

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

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

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

अनुरोधों को सीमित करना

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

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

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