Przegląd
Uwierzytelnianie twarzą pozwala użytkownikom odblokować urządzenie, po prostu patrząc na przód urządzenia. W systemie Android 10 dodano obsługę nowego stosu uwierzytelniania za pomocą twarzy, który może bezpiecznie przetwarzać klatki z kamer, zachowując bezpieczeństwo i prywatność podczas uwierzytelniania za pomocą twarzy na obsługiwanym sprzęcie. Android 10 zapewnia także łatwy sposób implementacji zgodnych z bezpieczeństwem, umożliwiający integrację aplikacji do transakcji, takich jak bankowość internetowa lub inne usługi.
Stos uwierzytelniania twarzy w systemie Android to nowa implementacja w systemie Android 10. Nowa implementacja wprowadza interfejsy IBiometricsFace.hal , IBiometricsFaceClientCallback.hal i types.hal .
Architektura
Interfejs API BiometricPrompt obejmuje wszystkie uwierzytelnienia biometryczne, w tym twarz, palec i tęczówkę. Face HAL współdziała z następującymi komponentami.
Menedżer twarzy
FaceManager to prywatny interfejs utrzymujący połączenie z FaceService . Jest używany przez 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 .
Usługa FaceService
Jest to implementacja frameworka zarządzająca dostępem do sprzętu do uwierzytelniania twarzą. Zawiera podstawowe maszyny stanu rejestracji i uwierzytelniania, a także różne inne pomoce (na przykład wyliczenie). Ze względów stabilności i bezpieczeństwa w tym procesie nie można uruchamiać żadnego kodu dostawcy. Dostęp do całego kodu dostawcy można uzyskać poprzez interfejs Face 1.0 HIDL .
twarzą w twarz
Jest to plik wykonywalny systemu Linux, który implementuje interfejs Face 1.0 HIDL używany przez FaceService . Rejestruje się jako IBiometricsFace@1.0, dzięki czemu FaceService może go znaleźć.
Realizacja
Twarz HIDL
Aby zaimplementować Face HIDL, musisz zaimplementować wszystkie metody 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ą maszynę stanu do stanu bezczynności . Większość komunikatów ma odpowiedni ciąg skierowany do użytkownika, który informuje użytkownika o błędzie, ale nie wszystkie błędy mają ten ciąg skierowany do użytkownika. Aby uzyskać więcej informacji na temat komunikatów o błędach, zobacz types.hal . Wszystkie komunikaty o błędach reprezentują stan terminala, co oznacza, że struktura zakłada, że warstwa HAL powraca do stanu bezczynności po wysłaniu komunikatu o błędzie.
Wiadomości o przejęciu
Komunikaty dotyczące pozyskiwania są dostarczane podczas rejestracji lub uwierzytelniania i mają na celu poprowadzenie użytkownika w kierunku pomyślnej rejestracji lub uwierzytelnienia. Z każdą liczbą porządkową jest powiązany komunikat z pliku FaceAuthenticationManager.java . Można dodawać komunikaty specyficzne dla dostawcy, pod warunkiem że zapewnione są odpowiednie ciągi pomocy. Komunikaty o przejęciu same w sobie nie są stanami końcowymi; oczekuje się, że warstwa HAL wyśle tyle z nich, ile będzie konieczne do zakończenia bieżącej rejestracji lub uwierzytelnienia. Jeśli komunikat o akwizycji skutkuje stanem końcowym, w którym nie można poczynić postępu, warstwa HAL powinna po komunikatach o akwizycji wyświetlić komunikat o błędzie, na przykład gdy obraz jest zbyt ciemny i pozostaje zbyt ciemny, aby można było dokonać postępu. W takim przypadku rozsądne jest wysłanie UNABLE_TO_PROCESS po kilku próbach, ale nie można poczynić dalszych postępów.
Sprzęt komputerowy
Aby urządzenia spełniały rygorystyczne wymagania biometryczne dla Androida 10, muszą mieć bezpieczny sprzęt, aby zapewnić integralność danych twarzy i ostateczne porównanie uwierzytelniania. Dokument definicji zgodności z systemem Android (CDD) określa wymagany poziom bezpieczeństwa i wymagany akceptowalny współczynnik akceptacji fałszywych treści (SAR). Do bezpiecznego przetwarzania i rozpoznawania wymagane jest zaufane środowisko wykonawcze (TEE). Ponadto wymagany jest bezpieczny sprzęt kamery, aby zapobiec atakom polegającym na wstrzykiwaniu uwierzytelniania za pomocą twarzy. Na przykład powiązane strony pamięci zawierające dane obrazu mogą być uprzywilejowane i oznaczone jako tylko do odczytu, tak aby tylko sprzęt aparatu mógł je aktualizować. W idealnym przypadku żaden proces nie powinien mieć dostępu z wyjątkiem TEE i sprzętu.
Ponieważ sprzęt do uwierzytelniania za pomocą twarzy znacznie się różni, konieczne jest opracowanie sterowników dostosowanych do sprzętu, aby umożliwić uwierzytelnianie za pomocą twarzy, w zależności od konkretnej architektury urządzenia. W związku z tym nie ma implementacji referencyjnej dla faced .
Metody
Wszystkie poniższe metody są asynchroniczne i muszą natychmiast powrócić do platformy. Niezastosowanie się do tego powoduje powolne działanie systemu i potencjalne resetowanie Watchdoga. Zaleca się posiadanie kolejki komunikatów z wieloma wątkami, aby uniknąć blokowania osoby wywołującej. Wszystkie żądania GET powinny, jeśli to możliwe, buforować informacje, aby obiekt wywołujący był blokowany przez minimalny czas.
| metoda | Opis |
|---|---|
setCallback() | Wywoływany przez FaceService w celu przesłania wszystkich wiadomości z powrotem do siebie. |
setActiveUser() | Ustawia aktywnego użytkownika, do którego będą stosowane wszystkie kolejne operacje HAL. Uwierzytelnianie odbywa się zawsze dla tego użytkownika, dopóki ta metoda nie zostanie wywołana ponownie. |
revokeChallenge() | Kończy bezpieczną transakcję, unieważniając wyzwanie wygenerowane przez generateChallenge() . |
enroll() | Rejestruje twarz użytkownika. |
cancel() | Anuluje bieżącą operację (na przykład rejestrowanie, uwierzytelnianie, usuwanie lub wyliczanie) i powraca faced stanu bezczynności. |
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 warstwa HAL znajduje się w stanie uwierzytelniania lub gotowości. Użycie tej metody, gdy warstwa HAL nie znajduje się w żadnym z tych stanów, zwraca OPERATION_NOT_SUPPORTED . Wywołanie tej metody, gdy warstwa HAL jest już uwierzytelniona, może wydłużyć czas wyszukiwania twarzy przez system. |
resetLockout() | Kiedy zbyt wiele twarzy zostanie odrzuconych, faced musi wejść w stan blokady ( LOCKOUT lub LOCKOUT_PERMANENT ). Gdy tak się stanie, wymagane jest wysłanie pozostałego czasu do platformy, aby mogła wyświetlić go 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 dla bieżącego użytkownika. |
Wszystkie trzy pozostałe metody są synchroniczne i powinny blokować się przez minimalny czas, aby uniknąć zablokowania frameworka.
| metoda | Opis |
|---|---|
generateChallenge() | Generuje unikalny i bezpieczny kryptograficznie losowy token używany do wskazania rozpoczęcia 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/hasła użytkownika pod kątem powyższego wyzwania |
getFeature() | Pobiera bieżący stan włączenia funkcji zgodnie z wartością domyślną lub wywołaniem metody 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. Identyfikator ten musi się zmieniać za każdym razem, gdy dodawana jest twarz |
Diagram stanu
Struktura oczekuje faced zgodnie z poniższym diagramem stanu.
