द्वारपाल

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

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

आर्किटेक्चर

द्वारपाल में तीन मुख्य घटक शामिल हैं:

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

गेटकीपर को गेटकीपर एचएएल (विशेष रूप से hardware/libhardware/include/hardware/gatekeeper.h में कार्य) और टीईई -विशिष्ट गेटकीपर घटक ( system/gatekeeper/include/gatekeeper/gatekeeper.h हेडर फ़ाइल पर आधारित) के कार्यान्वयन की आवश्यकता होती है। जिसमें कुंजी बनाने/पहुंचने और हस्ताक्षरों की गणना करने के लिए शुद्ध आभासी कार्य शामिल हैं)।

LockSettingsService एक अनुरोध करता है (बाइंडर के माध्यम से) जो एंड्रॉइड ओएस में gatekeeperd डेमॉन तक पहुंचता है। gatekeeperd डेमॉन तब एक अनुरोध करता है जो टीईई में अपने समकक्ष (द्वारपाल) तक पहुंचता है:

gatekeeperd डेमॉन एंड्रॉइड फ्रेमवर्क एपीआई को एचएएल तक पहुंच प्रदान करता है, और कीस्टोर को डिवाइस प्रमाणीकरण की रिपोर्ट करने में भाग लेता है। gatekeeperd डेमॉन अपनी प्रक्रिया में चलता है और सिस्टम सर्वर से अलग होता है।

एचएएल कार्यान्वयन

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

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

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

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

भरोसेमंद और अन्य कार्यान्वयन

ट्रस्टी ऑपरेटिंग सिस्टम टीईई वातावरण के लिए Google का ओपन सोर्स विश्वसनीय ओएस है और इसमें गेटकीपर का स्वीकृत कार्यान्वयन शामिल है। हालाँकि, आप गेटकीपर को लागू करने के लिए किसी भी टीईई ओएस का उपयोग कर सकते हैं, जब तक कि टीईई के पास हार्डवेयर-समर्थित कुंजी और एक सुरक्षित, मोनोटोनिक घड़ी है जो सस्पेंड में टिक करती है ।

ट्रस्टी एक आंतरिक आईपीसी प्रणाली का उपयोग करता है जो सीधे कीमास्टर और गेटकीपर ( ट्रस्टी गेटकीपर ) के ट्रस्टी कार्यान्वयन के बीच एक साझा रहस्य को संप्रेषित करता है। इस साझा रहस्य का उपयोग पासवर्ड सत्यापन के सत्यापन प्रदान करने के लिए कीस्टोर को भेजे गए AuthTokens पर हस्ताक्षर करने के लिए किया जाता है। ट्रस्टी गेटकीपर प्रत्येक उपयोग के लिए कीमास्टर से कुंजी का अनुरोध करता है और मूल्य को कायम या कैश नहीं करता है। कार्यान्वयन इस रहस्य को किसी भी तरह से साझा करने के लिए स्वतंत्र हैं जो सुरक्षा से समझौता नहीं करता है।

पासवर्ड दर्ज करने और सत्यापित करने के लिए उपयोग की जाने वाली HMAC कुंजी केवल गेटकीपर में प्राप्त और रखी जाती है।

एंड्रॉइड गेटकीपर का एक सामान्य सी ++ कार्यान्वयन प्रदान करता है जिसके लिए केवल डिवाइस-विशिष्ट रूटीन को पूरा करने की आवश्यकता होती है। अपने टीईई के लिए डिवाइस-विशिष्ट कोड के साथ एक टीईई गेटकीपर को लागू करने के लिए, system/gatekeeper/include/gatekeeper/gatekeeper.h में कार्यों और टिप्पणियों का संदर्भ लें। टीईई गेटकीपर के लिए, एक अनुपालन कार्यान्वयन की प्राथमिक जिम्मेदारियों में शामिल हैं:

• गेटकीपर एचएएल का पालन।
• लौटाए गए AuthTokens को AuthToken विनिर्देश ( प्रमाणीकरण में वर्णित) के अनुसार स्वरूपित किया जाना चाहिए।
• टीईई गेटकीपर को कीमास्टर के साथ एचएमएसी कुंजी साझा करने में सक्षम होना चाहिए, या तो मांग पर टीईई आईपीसी के माध्यम से कुंजी का अनुरोध करके या हर समय मूल्य का वैध कैश बनाए रखना चाहिए।

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

एक उपयोगकर्ता SID एक उपयोगकर्ता का TEE प्रतिनिधित्व है (जिसका Android उपयोगकर्ता आईडी से कोई मजबूत संबंध नहीं है)। SID एक क्रिप्टोग्राफ़िक छद्म यादृच्छिक संख्या जनरेटर (PRNG) के साथ उत्पन्न होता है जब भी कोई उपयोगकर्ता पिछला पासवर्ड प्रदान किए बिना एक नया पासवर्ड दर्ज करता है। इसे एक अविश्वसनीय पुन: नामांकन के रूप में जाना जाता है और सामान्य परिस्थितियों में एंड्रॉइड फ्रेमवर्क द्वारा इसकी अनुमति नहीं है। एक विश्वसनीय पुन: नामांकन तब होता है जब कोई उपयोगकर्ता एक मान्य, पिछला पासवर्ड प्रदान करता है; इस मामले में, उपयोगकर्ता SID को नए पासवर्ड हैंडल में माइग्रेट किया जाता है, जो इससे जुड़ी कुंजियों को संरक्षित करता है।

जब पासवर्ड दर्ज किया जाता है तो पासवर्ड हैंडल में पासवर्ड के साथ उपयोगकर्ता SID को HMAC'ed किया जाता है।

उपयोगकर्ता SID को verify फ़ंक्शन द्वारा लौटाए गए AuthToken में लिखा जाता है और सभी प्रमाणीकरण-बाध्य कीस्टोर कुंजियों से जुड़ा होता है (AuthToken प्रारूप और कीस्टोर पर विवरण के लिए, प्रमाणीकरण देखें)। enroll समारोह में एक अविश्वसनीय कॉल के रूप में उपयोगकर्ता एसआईडी बदल जाएगा, कॉल उस पासवर्ड से जुड़ी चाबियों को बेकार कर देगा। यदि वे Android OS को नियंत्रित करते हैं, तो हमलावर डिवाइस के लिए पासवर्ड बदल सकते हैं, लेकिन वे इस प्रक्रिया में रूट-संरक्षित, संवेदनशील कुंजियों को नष्ट कर देंगे।

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

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

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

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