चेहरा प्रमाणीकरण HIDL

अवलोकन

फेस प्रमाणीकरण उपयोगकर्ताओं को केवल अपने डिवाइस के सामने देखकर अपने डिवाइस को अनलॉक करने की अनुमति देता है। एंड्रॉइड 10 एक नए फेस ऑथेंटिकेशन स्टैक के लिए समर्थन जोड़ता है जो समर्थित हार्डवेयर पर फेस ऑथेंटिकेशन के दौरान सुरक्षा और गोपनीयता को संरक्षित करते हुए कैमरा फ्रेम को सुरक्षित रूप से संसाधित कर सकता है। एंड्रॉइड 10 ऑनलाइन बैंकिंग या अन्य सेवाओं जैसे लेनदेन के लिए एप्लिकेशन एकीकरण को सक्षम करने के लिए सुरक्षा अनुरूप कार्यान्वयन का एक आसान तरीका भी प्रदान करता है।

एंड्रॉइड फेस प्रमाणीकरण स्टैक एंड्रॉइड 10 में एक नया कार्यान्वयन है। नया कार्यान्वयन IBiometricsFace.hal , IBiometricsFaceClientCallback.hal , और types.hal इंटरफेस पेश करता है।

वास्तुकला

बायोमेट्रिकप्रॉम्प्ट एपीआई में चेहरा, उंगली और आईरिस सहित सभी बायोमेट्रिक प्रमाणीकरण शामिल हैं। फेस एचएएल निम्नलिखित घटकों के साथ इंटरैक्ट करता है।

बॉयोमीट्रिक स्टैक
चित्र 1. बायोमेट्रिक स्टैक

फेसमैनेजर

FaceManager एक निजी इंटरफ़ेस है जो FaceService के साथ संबंध बनाए रखता है। इसका उपयोग कीगार्ड द्वारा कस्टम यूआई के साथ चेहरे के प्रमाणीकरण तक पहुंचने के लिए किया जाता है। ऐप्स के पास FaceManager तक पहुंच नहीं है और इसके बजाय उन्हें BiometricPrompt उपयोग करना होगा।

फेससर्विस

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

का सामना करना पड़ा

यह एक Linux निष्पादन योग्य है जो FaceService द्वारा उपयोग किए जाने वाले Face 1.0 HIDL इंटरफ़ेस को लागू करता है। यह खुद को IBiometricsFace@1.0 के रूप में पंजीकृत करता है ताकि FaceService इसे ढूंढ सके।

कार्यान्वयन

फेस एचआईडीएल

फेस एचआईडीएल को लागू करने के लिए, आपको विक्रेता-विशिष्ट लाइब्रेरी में IBiometricsFace.hal की सभी विधियों को लागू करना होगा।

त्रुटि संदेश

त्रुटि संदेश कॉलबैक द्वारा भेजे जाते हैं और भेजे जाने के बाद राज्य मशीन को निष्क्रिय स्थिति में लौटा देते हैं। अधिकांश संदेशों में उपयोगकर्ता को त्रुटि के बारे में सूचित करने के लिए एक संबंधित उपयोगकर्ता-सामना वाली स्ट्रिंग होती है, लेकिन सभी त्रुटियों में यह उपयोगकर्ता-सामना वाली स्ट्रिंग नहीं होती है। त्रुटि संदेशों पर अधिक जानकारी के लिए, types.hal देखें। सभी त्रुटि संदेश एक टर्मिनल स्थिति का प्रतिनिधित्व करते हैं, जिसका अर्थ है कि फ्रेमवर्क मानता है कि त्रुटि संदेश भेजने के बाद एचएएल निष्क्रिय स्थिति में लौट आता है।

अधिग्रहण संदेश

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

हार्डवेयर

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

चूँकि चेहरा प्रमाणीकरण हार्डवेयर काफी भिन्न होता है, विशिष्ट डिवाइस आर्किटेक्चर के आधार पर, चेहरा प्रमाणीकरण सक्षम करने के लिए हार्डवेयर-विशिष्ट ड्राइवर विकसित करना आवश्यक है। इस प्रकार, faced के लिए कोई संदर्भ कार्यान्वयन नहीं है।

तरीकों

निम्नलिखित सभी विधियाँ अतुल्यकालिक हैं और उन्हें तुरंत फ्रेमवर्क पर वापस आना चाहिए। ऐसा करने में विफल रहने पर सिस्टम धीमा हो जाता है और संभावित वॉचडॉग रीसेट हो जाता है। कॉलर को ब्लॉक करने से बचने के लिए एकाधिक थ्रेड वाली संदेश कतार रखने की अनुशंसा की जाती है। जहां संभव हो सभी GET अनुरोधों को जानकारी कैश करनी चाहिए ताकि कॉल करने वाले को कम से कम समय के लिए ब्लॉक किया जा सके।

तरीका विवरण
setCallback() सभी संदेशों को वापस अपने पास भेजने के लिए FaceService द्वारा कॉल किया गया।
setActiveUser() सक्रिय उपयोगकर्ता को सेट करता है, जिस पर बाद के सभी एचएएल ऑपरेशन लागू होते हैं। प्रमाणीकरण हमेशा इस उपयोगकर्ता के लिए होता है जब तक कि इस विधि को दोबारा नहीं बुलाया जाता है।
revokeChallenge() generateChallenge() द्वारा उत्पन्न चुनौती को अमान्य करके सुरक्षित लेनदेन को समाप्त करता है।
enroll() उपयोगकर्ता का चेहरा नामांकित करता है.
cancel() वर्तमान ऑपरेशन को रद्द कर देता है (उदाहरण के लिए, नामांकन करना, प्रमाणित करना, हटाना या गणना करना) और निष्क्रिय faced में वापस आ जाता है।
enumerate() सक्रिय उपयोगकर्ता से जुड़े सभी फेस टेम्प्लेट की गणना करता है।
remove() सक्रिय उपयोगकर्ता से संबद्ध फेस टेम्प्लेट या सभी फेस टेम्प्लेट हटा देता है।
authenticate() सक्रिय उपयोगकर्ता को प्रमाणित करता है.
userActivity() इस पद्धति का उपयोग केवल तभी किया जाना चाहिए जब एचएएल प्रमाणीकरण या स्टैंडबाय स्थिति में हो। जब HAL इनमें से किसी एक स्थिति में नहीं है तो इस पद्धति का उपयोग करने से OPERATION_NOT_SUPPORTED रिटर्न मिलता है। जब एचएएल पहले से ही प्रमाणीकरण कर रहा हो तो इस पद्धति को कॉल करने से सिस्टम द्वारा चेहरे की तलाश में लगने वाले समय में वृद्धि हो सकती है।
resetLockout() जब बहुत सारे चेहरे अस्वीकार कर दिए जाते हैं, faced लॉकआउट स्थिति ( LOCKOUT या LOCKOUT_PERMANENT ) में प्रवेश करना आवश्यक होता है। जब ऐसा होता है, तो उसे शेष समय फ्रेमवर्क को भेजने की आवश्यकता होती है ताकि वह इसे उपयोगकर्ता के लिए प्रदर्शित कर सके। setFeature() की तरह, इस विधि को आंतरिक स्थिति को सुरक्षित रूप से रीसेट करने के लिए एक सक्रिय हार्डवेयर प्रमाणीकरण टोकन (HAT) की आवश्यकता होती है। केवल वर्तमान उपयोगकर्ता के लिए लॉकआउट रीसेट करता है।

शेष तीन विधियां समकालिक हैं और ढांचे को रोकने से बचने के लिए उन्हें न्यूनतम समय के लिए ब्लॉक करना चाहिए।

तरीका विवरण
generateChallenge() एक अद्वितीय और क्रिप्टोग्राफ़िक रूप से सुरक्षित यादृच्छिक टोकन उत्पन्न करता है जिसका उपयोग सुरक्षित लेनदेन की शुरुआत को इंगित करने के लिए किया जाता है।
setFeature() वर्तमान उपयोगकर्ता के लिए किसी सुविधा को सक्षम या अक्षम करता है। सुरक्षा कारणों से, उपरोक्त चुनौती के विरुद्ध उपयोगकर्ता के पिन/पैटर्न/पासवर्ड की जांच करने के लिए HAT की आवश्यकता होती है
getFeature() सुविधा की वर्तमान सक्षमता स्थिति को पुनः प्राप्त करता है, जैसा कि डिफ़ॉल्ट या ऊपर setFeature() पर कॉल द्वारा निर्धारित होता है। यदि फेस आईडी अमान्य है, तो कार्यान्वयन को ILLEGAL_ARGUMENT लौटाना होगा
getAuthenticatorId() वर्तमान फेस सेट से जुड़ा एक पहचानकर्ता लौटाता है। जब भी कोई चेहरा जोड़ा जाए तो यह पहचानकर्ता अवश्य बदलना चाहिए

राज्य आरेख

फ्रेमवर्क को नीचे दिए गए राज्य आरेख का पालन करने की faced है।

राज्य आरेख
चित्र 2. चेहरा प्रमाणीकरण स्थिति प्रवाह