गेटकीपर

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

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

भवन निर्माण

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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