खास जानकारी
चेहरे की पहचान की सुविधा की मदद से, उपयोगकर्ता अपने डिवाइस को सिर्फ़ डिवाइस के सामने देखकर अनलॉक कर सकते हैं. Android 10 में, चेहरे की पहचान की पुष्टि करने के लिए एक नया स्टैक जोड़ा गया है. यह स्टैक, कैमरे के फ़्रेम को सुरक्षित तरीके से प्रोसेस कर सकता है. साथ ही, यह पुष्टि करने के लिए इस्तेमाल किए जा सकने वाले हार्डवेयर पर, चेहरे की पहचान की पुष्टि के दौरान सुरक्षा और निजता को बनाए रखता है. Android 10, सुरक्षा का पालन करने वाली सुविधाओं को लागू करने का एक आसान तरीका भी है. इसकी मदद से, ऑनलाइन बैंकिंग या दूसरी सेवाओं जैसे लेन-देन के लिए, ऐप्लिकेशन इंटिग्रेशन को चालू किया जा सकता है.
Android चेहरे की पुष्टि करने वाला स्टैक, Android 10 में एक नई सुविधा के साथ लागू किया गया है. नए वर्शन में IBiometricsFace.hal,
IBiometricsFaceClientCallback.hal, और types.hal इंटरफ़ेस जोड़े गए हैं.
भवन निर्माण
BiometricPrompt API में, बायोमेट्रिक ऑथेंटिकेशन के सभी तरीके शामिल हैं. जैसे, चेहरे, उंगली, और आईरिस की पहचान. Face HAL, इन कॉम्पोनेंट के साथ इंटरैक्ट करता है.
पहली इमेज. बायोमेट्रिक स्टैक.
FaceManager
FaceManager एक निजी इंटरफ़ेस है, जो FaceService से जुड़ा रहता है. कीगार्ड इसे पसंद के मुताबिक बनाए गए यूज़र इंटरफ़ेस (यूआई) से चेहरे की पुष्टि
ऐक्सेस करने के लिए इस्तेमाल करता है. ऐप्लिकेशन के पास, FaceManager का ऐक्सेस नहीं होता. इसके बजाय, उन्हें BiometricPrompt का इस्तेमाल करना चाहिए.
FaceService
यह फ़्रेमवर्क, चेहरे की पहचान करने वाले हार्डवेयर के ऐक्सेस को मैनेज करता है. इसमें रजिस्ट्रेशन और पुष्टि करने की स्टेटस मशीन के साथ-साथ, कई अन्य सहायक मशीनें भी शामिल हैं. उदाहरण के लिए, गिनती करने वाली मशीन. स्थिरता और सुरक्षा से जुड़ी समस्याओं की वजह से, इस प्रोसेस में किसी भी वेंडर कोड को चलाने की अनुमति नहीं है. सभी वेंडर कोड, Face 1.0 HIDL इंटरफ़ेस से ऐक्सेस किए जा सकते हैं.
सामना करना पड़ा
यह एक Linux एक्सीक्यूटेबल है, जो FaceService का इस्तेमाल करने वाले Face 1.0 HIDL इंटरफ़ेस को लागू करता है. यह खुद को IBiometricFace@1.0 के तौर पर रजिस्टर करता है, ताकि FaceService इसे ढूंढ सके.
लागू करना
फ़ेस HIDL
Face HIDL लागू करने के लिए, आपको वेंडर के हिसाब से बनी लाइब्रेरी में IBiometricsFace.hal के सभी तरीके लागू करने होंगे.
गड़बड़ी के मैसेज
गड़बड़ी के मैसेज, कॉलबैक की मदद से भेजे जाते हैं. साथ ही, भेजे जाने के बाद स्टेट मशीन को idle स्टेटस पर वापस ले जाते हैं. ज़्यादातर मैसेज में उपयोगकर्ता को दिखने वाली स्ट्रिंग होती है, ताकि उपयोगकर्ता को गड़बड़ी की जानकारी दी जा सके. हालांकि, सभी गड़बड़ियों में उपयोगकर्ता को दिखने वाली यह स्ट्रिंग नहीं होती. गड़बड़ी के मैसेज के बारे में ज़्यादा जानकारी के लिए, types.hal देखें.
गड़बड़ी के सभी मैसेज, टर्मिनल स्टेटस दिखाते हैं. इसका मतलब है कि फ़्रेमवर्क यह मानता है कि गड़बड़ी का मैसेज भेजने के बाद, एचएएल, आइडल स्टेटस पर वापस आ जाता है.
उपयोगकर्ता हासिल करने से जुड़े मैसेज
उपयोगकर्ता हासिल करने के मैसेज, रजिस्टर करने या पुष्टि करने के दौरान डिलीवर किए जाते हैं. इनका मकसद, उपयोगकर्ता को रजिस्टर करने या पुष्टि करने के लिए गाइड करना होता है.
हर ऑर्डिनल के साथ, FaceAuthenticationManager.java फ़ाइल का एक मैसेज जुड़ा होता है. वेंडर के मैसेज तब तक जोड़े जा सकते हैं, जब तक उनसे जुड़ी सहायता स्ट्रिंग दी गई हों. उपयोगकर्ता हासिल करने के मैसेज, अपने-आप बंद नहीं होते. एचएएल को मौजूदा रजिस्ट्रेशन या पुष्टि की प्रक्रिया पूरी करने के लिए, ज़रूरत के हिसाब से ये मैसेज भेजने चाहिए. अगर ऐक्वज़िशन मैसेज की वजह से, फ़ोटो खींचने की प्रोसेस पूरी नहीं हो पाती है, तो HAL को ऐक्वज़िशन मैसेज के बाद गड़बड़ी का मैसेज भेजना चाहिए. उदाहरण के लिए, जब इमेज बहुत गहरे रंग की हो और उसे खींचने के लिए ज़रूरी लाइट न हो. इस मामले में, कई बार कोशिश करने के बाद भी कोई फ़ायदा न मिलने पर, UNABLE_TO_PROCESS भेजा जा सकता है.
हार्डवेयर
Android 10 के लिए, मज़बूत बायोमेट्रिक की ज़रूरी शर्तों को पूरा करने के लिए, डिवाइसों में सुरक्षित हार्डवेयर होना चाहिए. इससे, यह पक्का किया जा सकेगा कि फ़ेस डेटा पूरी तरह से सुरक्षित है और पुष्टि करने के लिए, सबसे बेहतर तरीके से तुलना की जा रही है. Android के साथ काम करने की शर्तों के बारे में बताने वाले दस्तावेज़ (सीडीडी) में, सुरक्षा के लिए ज़रूरी लेवल और स्पैम के स्वीकार किए जाने की दर (एसएआर) के बारे में बताया गया है. सुरक्षित प्रोसेसिंग और पहचान के लिए, एक भरोसेमंद एक्ज़ीक्यूशन एनवायरमेंट (टीईई) ज़रूरी है. इसके अलावा, चेहरे की पहचान की पुष्टि करने के लिए, इंजेक्शन अटैक से बचाने के लिए, सुरक्षित कैमरा हार्डवेयर की ज़रूरत होती है. उदाहरण के लिए, इमेज डेटा से जुड़े मेमोरी पेजों को खास सुविधाएं दी जा सकती हैं और उन्हें रीड-ओनली के तौर पर मार्क किया जा सकता है, ताकि सिर्फ़ कैमरा हार्डवेयर उन्हें अपडेट कर सके. आम तौर पर, TEE और हार्डवेयर के अलावा किसी भी प्रोसेस के पास इसका ऐक्सेस नहीं होना चाहिए.
चेहरे की पहचान करने वाला हार्डवेयर काफ़ी अलग-अलग होता है. इसलिए, डिवाइस के खास आर्किटेक्चर के आधार पर, चेहरे की पुष्टि करने की सुविधा चालू करने के लिए खास तरह के हार्डवेयर ड्राइवर डेवलप करना ज़रूरी है. इसलिए, faced के लिए कोई रेफ़रंस लागू नहीं किया गया है.
माटिंग में इस्तेमाल हुए तरीके
यहां दिए गए सभी तरीके असाइनोक्रोनस हैं और इन्हें तुरंत फ़्रेमवर्क पर वापस आना चाहिए. ऐसा न करने पर, सिस्टम धीमा हो जाता है और वॉचडॉग रीसेट हो सकता है. हमारा सुझाव है कि कॉलर को ब्लॉक करने से बचने के लिए, मैसेज की सूची में एक से ज़्यादा थ्रेड रखें. जहां भी हो सके, सभी GET अनुरोधों को जानकारी को कैश मेमोरी में सेव करना चाहिए, ताकि कॉल करने वाले को कम से कम समय के लिए ब्लॉक किया जा सके.
| Method | ब्यौरा |
|---|---|
setCallback() |
FaceService, सभी मैसेज को वापस अपने पास लाने के लिए इसे कॉल करता है. |
setActiveUser() |
यह सक्रिय उपयोगकर्ता सेट करता है, जिस पर बाद में होने वाले सभी एचएएल ऑपरेशन लागू होते हैं. जब तक इस तरीके को फिर से नहीं बुलाया जाता, तब तक पुष्टि हमेशा इस उपयोगकर्ता के लिए की जाती है. |
revokeChallenge() |
generateChallenge() से जनरेट किए गए चैलेंज को अमान्य करके सुरक्षित लेन-देन पूरा किया जाता है. |
enroll() |
उपयोगकर्ता के चेहरे की जानकारी को रजिस्टर करता है. |
cancel() |
मौजूदा कार्रवाई को रद्द करता है (उदाहरण के लिए, रजिस्टर करना, पुष्टि करना, हटाना या उसकी गिनती करना) और faced को कुछ समय से इस्तेमाल में नहीं है. |
enumerate() |
सक्रिय उपयोगकर्ता से जुड़े सभी चेहरे के टेंप्लेट की जानकारी देता है. |
remove() |
यह किसी चेहरे के टेंप्लेट या चालू उपयोगकर्ता से जुड़े सभी चेहरे के टेंप्लेट को हटा देता है. |
authenticate() |
सक्रिय उपयोगकर्ता की पुष्टि करता है. |
userActivity() |
इस तरीके का इस्तेमाल सिर्फ़ तब करना चाहिए, जब एचएएल की पुष्टि की जा रही हो या वह स्टैंडबाय मोड की स्थिति में हो. अगर HAL इनमें से किसी एक स्थिति में नहीं है, तो इस तरीके का इस्तेमाल करने पर OPERATION_NOT_SUPPORTED दिखता है. HAL की पुष्टि हो जाने के बाद, इस तरीके को कॉल करने पर, सिस्टम को चेहरे का पता लगाने में ज़्यादा समय लग सकता है. |
resetLockout() |
जब बहुत ज़्यादा चेहरों को अस्वीकार कर दिया जाता है, तो faced को लॉकआउट की स्थिति (LOCKOUT या LOCKOUT_PERMANENT) में जाना होगा. ऐसा करने पर, उसे फ़्रेमवर्क को बचे हुए समय की जानकारी भेजनी होगी, ताकि वह उपयोगकर्ता को उसे दिखा सके. setFeature() की तरह ही, इस तरीके से भी डिवाइस की इंटरनल स्थिति को सुरक्षित तरीके से रीसेट करने के लिए, ऐक्टिव हार्डवेयर पुष्टि करने वाला टोकन (एचएटी) ज़रूरी है. लॉकआउट को सिर्फ़ मौजूदा उपयोगकर्ता के लिए रीसेट करता है. |
बाकी बचे तीनों तरीके सिंक्रोनस हैं. साथ ही, फ़्रेमवर्क को रोकने से बचने के लिए, इन्हें कम से कम समय के लिए ब्लॉक किया जाना चाहिए.
| Method | ब्यौरा |
|---|---|
generateChallenge() |
यह एक यूनीक और क्रिप्टोग्राफ़िक तौर पर सुरक्षित रैंडम टोकन जनरेट करता है. इसका इस्तेमाल, सुरक्षित लेन-देन की शुरुआत के बारे में बताने के लिए किया जाता है. |
setFeature() |
इससे मौजूदा उपयोगकर्ता के लिए कोई सुविधा चालू या बंद होती है. सुरक्षा वजहों से, इसके लिए एचएटी को ऊपर दिए गए चैलेंज के हिसाब से उपयोगकर्ता के पिन/पैटर्न/पासवर्ड की जांच करनी होती है |
getFeature() |
यह सुविधा के चालू होने की मौजूदा स्थिति दिखाता है. यह स्थिति, डिफ़ॉल्ट तौर पर या ऊपर दिए गए setFeature() को कॉल करने पर तय होती है. अगर Face ID अमान्य है, तो
लागू करने पर ILLEGAL_ARGUMENT दिखना चाहिए |
getAuthenticatorId() |
मौजूदा चेहरे के सेट से जुड़ा आइडेंटिफ़ायर दिखाता है. जब भी कोई चेहरा जोड़ा जाता है, तो इस आइडेंटिफ़ायर को बदलना ज़रूरी है |
स्टेट डायग्राम
फ़्रेमवर्क के मुताबिक, faced को नीचे दिए गए स्टेटस डायग्राम का पालन करना चाहिए.
दूसरी इमेज. चेहरे की पहचान की स्थिति का फ़्लो.