चेहरे की पहचान करने की सुविधा के लिए HIDL

खास जानकारी

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

Android में चेहरे की पहचान करने की सुविधा, Android 10 में नई सुविधा के तौर पर लागू की गई है. नए तरीके से लागू करने पर, IBiometricsFace.hal, IBiometricsFaceClientCallback.hal, और types.hal इंटरफ़ेस उपलब्ध होंगे.

भवन निर्माण

BiometricPrompt API में, बायोमेट्रिक ऑथेंटिकेशन के सभी तरीके शामिल हैं. जैसे, चेहरे, उंगली, और आइरिस की पहचान. Face HAL, इन कॉम्पोनेंट के साथ इंटरैक्ट करता है.

पहली इमेज. बायोमेट्रिक स्टैक.

FaceManager

FaceManager एक निजी इंटरफ़ेस है, जो FaceService से कनेक्शन बनाए रखता है. इसका इस्तेमाल Keyguard करता है, ताकि कस्टम यूज़र इंटरफ़ेस (यूआई) के साथ चेहरे की पहचान की सुविधा को ऐक्सेस किया जा सके. ऐप्लिकेशन के पास FaceManager का ऐक्सेस नहीं होता. इसलिए, उन्हें BiometricPrompt का इस्तेमाल करना चाहिए.

FaceService

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

सामना किया

यह एक Linux एक्ज़ीक्यूटेबल है. यह Face 1.0 HIDL इंटरफ़ेस को लागू करता है. इसका इस्तेमाल FaceService करता है. यह खुद को IBiometricsFace@1.0 के तौर पर रजिस्टर करता है, ताकि FaceService इसे ढूंढ सके.

लागू करना

Face HIDL

Face HIDL को लागू करने के लिए, आपको वेंडर के हिसाब से बनी लाइब्रेरी में IBiometricsFace.hal के सभी तरीकों को लागू करना होगा.

गड़बड़ी के मैसेज

गड़बड़ी के मैसेज, कॉलबैक के ज़रिए भेजे जाते हैं. साथ ही, ये मैसेज भेजे जाने के बाद, स्टेट मशीन को आइडल स्टेट पर वापस ले जाते हैं. ज़्यादातर मैसेज में, उपयोगकर्ता को गड़बड़ी के बारे में बताने के लिए, उपयोगकर्ता को दिखने वाली स्ट्रिंग होती है. हालांकि, सभी गड़बड़ियों में उपयोगकर्ता को दिखने वाली यह स्ट्रिंग नहीं होती. गड़बड़ी के मैसेज के बारे में ज़्यादा जानने के लिए, types.hal देखें. गड़बड़ी के सभी मैसेज, टर्मिनल स्थिति को दिखाते हैं. इसका मतलब है कि फ़्रेमवर्क यह मानता है कि गड़बड़ी का मैसेज भेजने के बाद, एचएएल निष्क्रिय स्थिति में वापस आ जाता है.

उपयोगकर्ता हासिल करने से जुड़े मैसेज

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

हार्डवेयर

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

चेहरे की पहचान करने वाले हार्डवेयर में काफ़ी अंतर होता है. इसलिए, डिवाइस के आर्किटेक्चर के हिसाब से, चेहरे की पहचान करने की सुविधा चालू करने के लिए, हार्डवेयर के हिसाब से ड्राइवर डेवलप करना ज़रूरी है. इसलिए, faced के लिए कोई रेफ़रंस इंप्लीमेंटेशन नहीं है.

माटिंग में इस्तेमाल हुए तरीके

यहां दिए गए सभी तरीके एसिंक्रोनस हैं और इन्हें तुरंत फ़्रेमवर्क पर वापस जाना चाहिए. ऐसा न करने पर, सिस्टम धीमा हो जाता है और वॉचडॉग रीसेट हो सकता है. हमारा सुझाव है कि कॉलर को ब्लॉक करने से बचने के लिए, मैसेज की एक ऐसी कतार बनाएं जिसमें कई थ्रेड हों. सभी GET अनुरोधों को जानकारी को कैश मेमोरी में सेव करना चाहिए, ताकि अनुरोध करने वाले को कम से कम समय के लिए ब्लॉक किया जा सके.

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

बची हुई तीनों विधियां सिंक्रोनस हैं. इन्हें कम से कम समय के लिए ब्लॉक करना चाहिए, ताकि फ़्रेमवर्क में रुकावट न आए.

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

स्टेट डायग्राम

फ़्रेमवर्क को उम्मीद है कि faced, यहां दिए गए स्टेट डायग्राम का पालन करेगा.

दूसरी इमेज. चेहरे की पहचान की स्थिति का फ़्लो.