Omówienie
Uwierzytelnianie twarzą pozwala użytkownikom odblokowywać urządzenie przez spojrzenie na jego przód. Android 10 obsługuje nowy moduł uwierzytelniania twarzy, który może bezpiecznie przetwarzać klatki z kamery, zapewniając bezpieczeństwo i prywatność podczas uwierzytelniania twarzy na obsługiwanym sprzęcie. Android 10 ułatwia też wdrażanie zgodnych z zasadami zabezpieczeń rozwiązań, aby umożliwić integrację aplikacji z transakcjami, takimi jak bankowość internetowa czy inne usługi.
Narzędzia do uwierzytelniania twarzą na Androidzie to nowa implementacja w Androidzie 10. Nowa implementacja wprowadza interfejsy IBiometricsFace.hal, IBiometricsFaceClientCallback.hal i types.hal.
Architektura
Interfejs API BiometricPrompt obejmuje wszystkie metody uwierzytelniania biometrycznego, w tym twarzy, palca i tęczówki. HAL Face HAL współdziała z tymi komponentami.
Rysunek 1. Usługa biometryczna.
FaceManager
FaceManager to prywatny interfejs utrzymujący połączenie z FaceService. Używa go Keyguard do uzyskiwania dostępu do uwierzytelniania twarzą za pomocą niestandardowego interfejsu użytkownika. Aplikacje nie mają dostępu do FaceManagera i zamiast tego muszą używać BiometricPrompt.
FaceService
Jest to implementacja platformy, która zarządza dostępem do sprzętu do uwierzytelniania za pomocą twarzy. Zawiera on podstawowe stany maszyn rejestracji i uwierzytelniania, a także różne inne pomocniki (np. enumerację). 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 jest możliwy przez interfejs HIDL Face 1.0.
obliczony
To plik wykonywalny dla systemu Linux, w którym zaimplementowano interfejs HIDL Face 1.0 używany przez FaceService. Rejestruje się jako IBiometricsFace@1.0, aby usługa FaceService mogła ją znaleźć.
Implementacja
Face HIDL
Aby zaimplementować Face HIDL, musisz zaimplementować wszystkie metody biblioteki IBiometricsFace.hal w bibliotece konkretnego dostawcy.
Komunikaty o błędach
Komunikaty o błędach są wysyłane przez wywołanie zwrotne i po wysłaniu maszyny stanu do stanu nieaktywnego. Większość komunikatów zawiera odpowiedni ciąg znaków dla użytkownika, który informuje 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 framework zakłada, że po wysłaniu komunikatu o błędzie HAL wraca do stanu bezczynności.
Wiadomości dotyczące pozyskiwania
Komunikaty dotyczące pozyskiwania klientów są wysyłane podczas rejestracji lub uwierzytelniania i mają na celu poprowadzenie użytkownika przez proces rejestracji lub uwierzytelniania.
Każda liczba porządkowa ma powiązany komunikat z pliku FaceAuthenticationManager.java. Można dodawać wiadomości dotyczące konkretnych dostawców, o ile są one opatrzone odpowiednimi ciągami tekstowymi pomocy. Wiadomości o pozyskaniu nie są w ogóle stanami terminalnymi; HAL powinien wysyłać tyle takich wiadomości, ile jest konieczne do ukończenia bieżącej rejestracji lub uwierzytelniania. Jeśli wiadomość o pozyskaniu prowadzi do stanu końcowego, w którym nie można już nic zrobić, HAL powinien po wiadomości o pozyskaniu wyświetlić komunikat o błędzie, na przykład gdy obraz jest zbyt ciemny i pozostanie zbyt ciemny, aby można było coś z nim zrobić. W takim przypadku po kilku próbach rozsądne jest wysłanie wiadomości UNABLE_TO_PROCESS, jeśli nie udało się uzyskać dalszych informacji.
Sprzęt
Aby spełniać wymagania dotyczące silnych danych biometrycznych w Androidzie 10, urządzenia muszą mieć bezpieczny sprzęt, który zapewni integralność danych twarzy i najlepszą metodę porównywania danych. Dokument z definicją zgodności z Androidem (Android Compatibility Definition Document, CDD) określa wymagany poziom zabezpieczeń i akceptowalny współczynnik akceptacji podszywania się (SAR). Bezpieczne przetwarzanie i rozpoznawanie wymaga zaufanego środowiska wykonawczego (TEE). Dodatkowo wymagany jest bezpieczny sprzęt kamery, aby zapobiec atakom polegającym na wstrzykiwaniu kodu w procesie uwierzytelniania twarzy. Na przykład strony pamięci powiązane z danymi obrazu mogą być uprzywilejowane i oznaczone jako tylko do odczytu, aby tylko sprzęt aparatu mógł je aktualizować. W idealnej sytuacji żaden proces nie powinien mieć dostępu do TEE i sprzętu.
Sprzęt do uwierzytelniania twarzy jest bardzo zróżnicowany, dlatego konieczne jest opracowanie sterowników dla poszczególnych urządzeń, aby umożliwić uwierzytelnianie twarzy w zależności od ich architektury. Dlatego w przypadku faced nie ma implementacji referencyjnej.
Metody
Wszystkie podane niżej metody są asynchroniczne i muszą natychmiast zwracać dane do frameworka. Jeśli tego nie zrobisz, system będzie działał wolniej, a watchdog może się zresetować. Zalecamy użycie kolejki wiadomości z wieloma wątkami, aby uniknąć blokowania dzwoniącego. Wszystkie żądania GET powinny przechowywać informacje w pamięci podręcznej, aby ograniczyć czas blokowania wywołującego.
| Metoda | Opis |
|---|---|
setCallback() |
Jest wywoływany przez FaceService, aby przekazać wszystkie wiadomości z powrotem do siebie. |
setActiveUser() |
Ustawia aktywnego użytkownika, do którego są stosowane wszystkie kolejne operacje HAL. Uwierzytelnianie jest zawsze dla tego użytkownika, dopóki metoda nie zostanie wywołana ponownie. |
revokeChallenge() |
Zakończenie bezpiecznej transakcji przez unieważnienie wyzwania wygenerowanego przez generateChallenge(). |
enroll() |
Rejestruje twarz użytkownika. |
cancel() |
Anuluje bieżącą operację (np. rejestrowanie, uwierzytelnianie, usuwanie lub zliczanie) i przechodzi do stanu bezczynności.faced |
enumerate() |
Wypisuje 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 żadnym z tych stanów, spowoduje zwrócenie wartości OPERATION_NOT_SUPPORTED. Wywołanie tej metody podczas uwierzytelniania HAL może wydłużyć czas, przez jaki system wyszukuje twarz. |
resetLockout() |
Gdy zbyt wiele twarzy zostanie odrzuconych, faced musi przejść w stan blokady (LOCKOUT lub LOCKOUT_PERMANENT). W takim przypadku musi wysłać do frameworku pozostały czas, aby mógł wyświetlić go użytkownikowi. Tak jak w przypadku setFeature(), ta metoda wymaga aktywnego tokena uwierzytelniania sprzętowego (HAT), aby bezpiecznie zresetować stan wewnętrzny. Resetuje blokadę tylko dla bieżącego użytkownika. |
Pozostałe 3 metody są synchroniczne i powinny blokować minimalny czas, aby uniknąć zawieszania frameworku.
| 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/wzorca/hasła użytkownika w powiązaniu z powyższym wyzwaniem. |
getFeature() |
Pobiera bieżący stan włączenia funkcji zgodnie z domyślnym ustawieniem lub wywołaniem funkcji setFeature() powyżej. Jeśli identyfikator twarzy jest nieprawidłowy, implementacja musi zwrócić ILLEGAL_ARGUMENT |
getAuthenticatorId() |
Zwraca identyfikator powiązany z bieżącym zestawem twarzy. Ten identyfikator musi się zmieniać po dodaniu twarzy. |
Diagram stanu
Platforma wymaga, aby faced przestrzegała diagramu stanu przedstawionego poniżej.
Rysunek 2. Przepływ stanu uwierzytelniania twarzą.