द्वारपाल

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

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

आर्किटेक्चर

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

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

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

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

द्वारपाल प्रवाह
चित्र 1. गेटकीपर द्वारा प्रमाणीकरण के लिए उच्च-स्तरीय डेटा प्रवाह

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 में कार्यों और टिप्पणियों को देखें। TEE गेटकीपर के लिए, एक अनुपालन कार्यान्वयन की प्राथमिक जिम्मेदारियों में शामिल हैं:

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

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

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

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

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

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

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

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

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