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