चेहरे की पहचान की सुविधा से, उपयोगकर्ता सिर्फ़ अपने डिवाइस के सामने देखकर उसे अनलॉक कर सकते हैं. 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, इमेज में दिखाए गए स्टेट डायग्राम के मुताबिक काम करेगा:
दूसरी इमेज. चेहरे की पहचान की स्टेट फ़्लो.