Uwierzytelnianie twarzą HIDL

Omówienie

Uwierzytelnianie twarzą umożliwia odblokowanie urządzenia przez spojrzenie na jego przednią część. Android 10 dodaje obsługę nowego stosu uwierzytelniania za pomocą rozpoznawania twarzy, który może bezpiecznie przetwarzać klatki z kamery, zachowując bezpieczeństwo i prywatność podczas uwierzytelniania za pomocą rozpoznawania twarzy na obsługiwanym sprzęcie. Android 10 zapewnia też łatwy sposób na włączenie integracji aplikacji w przypadku transakcji, takich jak bankowość internetowa lub inne usługi, w implementacjach zgodnych z wymaganiami dotyczącymi bezpieczeństwa.

Stos uwierzytelniania twarzą na Androidzie to nowa implementacja w Androidzie 10. Nowa implementacja wprowadza interfejsy IBiometricsFace.hal, IBiometricsFaceClientCallback.hal i types.hal.

Architektura

Interfejs BiometricPrompt API obejmuje wszystkie rodzaje uwierzytelniania biometrycznego, w tym rozpoznawanie twarzy, odcisków palców i tęczówki. Face HAL współpracuje z tymi komponentami:

Rysunek 1. Stos biometryczny.

FaceManager

FaceManager to interfejs prywatny, który utrzymuje połączenie z FaceService. Jest on używany przez Keyguard do uzyskiwania dostępu do uwierzytelniania za pomocą twarzy z niestandardowym interfejsem. Aplikacje nie mają dostępu do interfejsu FaceManager i muszą używać interfejsu BiometricPrompt.

FaceService

Jest to implementacja platformy, która zarządza dostępem do sprzętu do uwierzytelniania za pomocą twarzy. Zawiera podstawowe automaty stanów rejestracji i uwierzytelniania oraz różne inne funkcje pomocnicze (np. wyliczanie). Ze względu na stabilność i bezpieczeństwo w tym procesie nie można uruchamiać żadnego kodu dostawcy. Dostęp do całego kodu dostawcy odbywa się za pomocą interfejsu HIDL Face 1.0.

zmierzyć się,

Jest to plik wykonywalny w systemie Linux, który implementuje interfejs HIDL Face 1.0 używany przez FaceService. Rejestruje się jako IBiometricsFace@1.0, aby FaceService mogła ją znaleźć.

Implementacja

Face HIDL

Aby wdrożyć interfejs HIDL Face, musisz zaimplementować wszystkie metody interfejsu IBiometricsFace.hal w bibliotece specyficznej dla dostawcy.

Komunikaty o błędach

Komunikaty o błędach są wysyłane przez wywołanie zwrotne i po wysłaniu przywracają automat stanów do stanu bezczynności. Większość komunikatów ma odpowiedni ciąg znaków widoczny dla użytkownika, który informuje go o błędzie, ale nie wszystkie błędy mają taki ciąg znaków. Więcej informacji o komunikatach o błędach znajdziesz w artykule types.hal. Wszystkie komunikaty o błędach reprezentują stan końcowy, co oznacza, że po wysłaniu komunikatu o błędzie platforma zakłada, że HAL wraca do stanu bezczynności.

Wiadomości dotyczące pozyskiwania

Wiadomości dotyczące pozyskiwania są dostarczane podczas rejestracji lub uwierzytelniania i mają na celu przeprowadzenie użytkownika przez proces rejestracji lub uwierzytelniania. Każda liczba porządkowa ma powiązaną wiadomość z pliku FaceAuthenticationManager.java. Możesz dodawać wiadomości specyficzne dla dostawcy, o ile podasz odpowiednie ciągi pomocy. Komunikaty dotyczące pozyskiwania nie są same w sobie stanami końcowymi. HAL powinien wysyłać ich tyle, ile jest potrzebnych do ukończenia bieżącej rejestracji lub uwierzytelniania. Jeśli komunikat o akwizycji spowoduje przejście do stanu końcowego, w którym nie można osiągnąć postępu, HAL powinien po komunikatach o akwizycji wysłać komunikat o błędzie, np. gdy obraz jest zbyt ciemny i pozostaje zbyt ciemny, aby można było osiągnąć postęp. W takim przypadku po kilku próbach, które nie przyniosły żadnych rezultatów, można wysłać UNABLE_TO_PROCESS.

Sprzęt

Aby urządzenia spełniały wymagania dotyczące silnej biometrii w Androidzie 10, muszą mieć bezpieczny sprzęt, który zapewnia integralność danych twarzy i ostateczne porównanie uwierzytelniania. Dokument definicji zgodności z Androidem (CDD) określa wymagany poziom bezpieczeństwa i dopuszczalny wymagany współczynnik akceptacji fałszywych wyników (SAR). Do bezpiecznego przetwarzania i rozpoznawania wymagane jest zaufane środowisko wykonawcze (TEE). Dodatkowo wymagany jest bezpieczny sprzęt aparatu, aby zapobiec atakom typu injection na uwierzytelnianie za pomocą twarzy. Na przykład powiązane strony pamięci dla danych obrazu mogą być uprzywilejowane i oznaczone jako tylko do odczytu, aby tylko sprzęt aparatu mógł je aktualizować. W idealnej sytuacji dostęp do tych danych powinny mieć tylko środowisko TEE i sprzęt.

Sprzęt do uwierzytelniania za pomocą rozpoznawania twarzy jest bardzo zróżnicowany, dlatego w zależności od architektury konkretnego urządzenia konieczne jest opracowanie sterowników specyficznych dla danego sprzętu, aby włączyć uwierzytelnianie za pomocą rozpoznawania twarzy. Dlatego nie ma implementacji referencyjnej dla faced.

Metody

Wszystkie te metody są asynchroniczne i muszą natychmiast zwrócić wartość do platformy. Jeśli tego nie zrobisz, system będzie działać wolno i może dojść do resetowania przez Watchdog. Zalecamy używanie kolejki wiadomości z wieloma wątkami, aby uniknąć blokowania wywołującego. Wszystkie żądania GET powinny buforować informacje, jeśli jest to możliwe, aby wywołujący był blokowany przez minimalny czas.

Metoda	Opis
setCallback()	Wywoływana przez FaceService w celu przekazania wszystkich wiadomości z powrotem do niej.
setActiveUser()	Ustawia aktywnego użytkownika, do którego stosowane są wszystkie kolejne operacje HAL. Uwierzytelnianie zawsze dotyczy tego użytkownika, dopóki ta metoda nie zostanie wywołana ponownie.
revokeChallenge()	Kończy bezpieczną transakcję, unieważniając wygenerowane przez generateChallenge() wyzwanie.
enroll()	Rejestruje twarz użytkownika.
cancel()	Anuluje bieżącą operację (np. rejestrację, uwierzytelnianie, usuwanie lub wyliczanie) i przywraca stan faced.
enumerate()	Wylicza wszystkie szablony twarzy powiązane z aktywnym użytkownikiem.
remove()	Usuwa szablon twarzy lub wszystkie szablony twarzy powiązane z aktywnym użytkownikiem.
authenticate()	Uwierzytelnia aktywnego użytkownika.
userActivity()	Tej metody należy używać tylko wtedy, gdy HAL jest w stanie uwierzytelniania lub gotowości. Użycie tej metody, gdy HAL nie jest w jednym z tych stanów, zwraca wartość OPERATION_NOT_SUPPORTED. Wywołanie tej metody, gdy HAL już uwierzytelnia, może wydłużyć czas, w którym system szuka twarzy.
resetLockout()	Gdy zbyt wiele twarzy zostanie odrzuconych, faced musi przejść w stan blokady (LOCKOUT lub LOCKOUT_PERMANENT). W takim przypadku musi wysłać pozostały czas do platformy, aby mogła go wyświetlić użytkownikowi. Podobnie jak w przypadku setFeature(), ta metoda wymaga aktywnego tokena uwierzytelniania sprzętowego (HAT), aby bezpiecznie zresetować stan wewnętrzny. Resetuje blokadę tylko w przypadku bieżącego użytkownika.

Pozostałe 3 metody są synchroniczne i powinny blokować działanie przez minimalny czas, aby uniknąć wstrzymania działania platformy.

Metoda	Opis
generateChallenge()	Generuje unikalny i kryptograficznie bezpieczny losowy token używany do wskazywania początku bezpiecznej transakcji.
setFeature()	Włącza lub wyłącza funkcję dla bieżącego użytkownika. Ze względów bezpieczeństwa wymaga to sprawdzenia przez HAT kodu PIN, wzoru lub hasła użytkownika w odpowiedzi na powyższe wyzwanie.
getFeature()	Pobiera bieżący stan włączenia funkcji zgodnie z ustawieniem domyślnym lub wywołaniem funkcji setFeature() powyżej. Jeśli identyfikator twarzy jest nieprawidłowy, implementacja musi zwrócić wartość ILLEGAL_ARGUMENT.
getAuthenticatorId()	Zwraca identyfikator powiązany z bieżącym zbiorem twarzy. Ten identyfikator musi się zmieniać za każdym razem, gdy dodawana jest twarz.

Diagram stanów

Platforma oczekuje, że faced będzie zgodny z poniższym diagramem stanu.

Rysunek 2. Przepływ stanu uwierzytelniania twarzą.