खास जानकारी
चेहरे की पहचान की सुविधा की मदद से, उपयोगकर्ता अपने डिवाइस को सिर्फ़ डिवाइस के सामने देखकर अनलॉक कर सकते हैं. 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 एक्सीक्यूटेबल है, जो FaceService का इस्तेमाल करने वाले Face 1.0 HIDL इंटरफ़ेस को लागू करता है. यह अपने-आप IBiometricsFace@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() |
यह उस ऐक्टिव उपयोगकर्ता को सेट करता है जिस पर बाद में HAL के सभी ऑपरेशन लागू किए जाते हैं. जब तक इस तरीके को फिर से नहीं बुलाया जाता, तब तक पुष्टि हमेशा इस उपयोगकर्ता के लिए की जाती है. |
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 को नीचे दिए गए स्टेटस डायग्राम का पालन करना चाहिए.
दूसरी इमेज. चेहरे की पहचान की स्थिति का फ़्लो.