गेटकीपर

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

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

भवन निर्माण

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

• gatekeeperd (Gatekeeper डीमन). C++ बाइंडर सेवा, जिसमें प्लैटफ़ॉर्म पर काम करने वाला लॉजिक शामिल होता है. यह सेवा, GateKeeperService Java इंटरफ़ेस से जुड़ी होती है.
• Gatekeeper हार्डवेयर ऐब्स्ट्रैक्शन लेयर (एचएएल). hardware/libhardware/include/hardware/gatekeeper.h में HAL इंटरफ़ेस और लागू करने वाला मॉड्यूल.
• गेटकीपर (टीईई). gatekeeperd के टीईई काउंटरपार्ट. Gatekeeper को टीईई पर आधारित तरीके से लागू करना.

Gatekeeper के लिए, Gatekeeper HAL (खास तौर पर, hardware/libhardware/include/hardware/gatekeeper.h में मौजूद फ़ंक्शन) और टीईई के हिसाब से Gatekeeper कॉम्पोनेंट को लागू करना ज़रूरी है. यह कॉम्पोनेंट, system/gatekeeper/include/gatekeeper/gatekeeper.h हेडर फ़ाइल पर आधारित होता है. इसमें पासकोड बनाने/ऐक्सेस करने और हस्ताक्षर कैलकुलेट करने के लिए, पूरी तरह से वर्चुअल फ़ंक्शन शामिल होते हैं.

LockSettingsService, Binder के ज़रिए एक अनुरोध करता है, जो Android OS में gatekeeperd डेमन तक पहुंचता है. इसके बाद, gatekeeperd डेमन एक अनुरोध करता है, जो TEE में उसके counterpart (Gatekeeper) तक पहुंचता है:

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

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

HAL लागू करना

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

hardware/libhardware/include/hardware/gatekeeper.h हेडर फ़ाइल को लागू करने के लिए, enroll और verify फ़ंक्शन लागू करने होंगे:

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

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

Trusty और अन्य तरीके

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

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

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

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

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

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

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

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

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

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

GateKeeper को उपयोगकर्ता के क्रेडेंशियल पर ब्रूट-फ़ोर्स की कोशिशों को सुरक्षित तरीके से कम करना चाहिए. hardware/libhardware/include/hardware/gatekeeper.h में दिखाए गए तरीके के मुताबिक, एचएएल, मिलीसेकंड में टाइम आउट दिखाता है. टाइम आउट, क्लाइंट को यह जानकारी देता है कि टाइम आउट खत्म होने तक, GateKeeper को फिर से कॉल न करें. अगर कोई टाइम आउट बाकी है, तो GateKeeper को अनुरोधों को प्रोसेस नहीं करना चाहिए.

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

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