Biometria oferuje wygodniejszy, ale potencjalnie mniej bezpieczny sposób potwierdzania tożsamości za pomocą urządzenia. W modelu uwierzytelniania warstwowego uwierzytelnianie podstawowe (czyli metody oparte na czynnikach wiedzy, takie jak PIN, wzór i hasło) zapewnia najwyższy poziom bezpieczeństwa. Dane biometryczne znajdują się na drugim poziomie uwierzytelniania, oferując równowagę pomiędzy wygodą i bezpieczeństwem. Android CDD definiuje trzy klasy siły biometrycznej: klasa 3 (dawniej silna), klasa 2 (dawniej słaba) i klasa 1 (dawniej wygoda). Każda klasa ma zestaw wymagań wstępnych, przywilejów i ograniczeń — więcej szczegółów można znaleźć w CDD powyżej. Wszystkie trzy klasy mogą integrować się z ekranem blokady, ale tylko silne i słabe uwierzytelnienia mogą integrować się z interfejsami API android.hardware.biometrics. W tej tabeli opisano każdy moduł uwierzytelniający i obsługiwane przez niego funkcje.
Uwierzytelniacz | Ekran blokady | Integracja BiometricPrompt | Magazyn kluczy (klucz czasowy) | Magazyn kluczy (klucz oparty na operacji) |
---|---|---|---|---|
BIOMETRIC_STRONG (klasa 3) | Tak | Tak | Tak | Tak |
BIOMETRIC_WEAK (klasa 2) | Tak | Tak | NIE | NIE |
BIOMETRYCZNA_WYGODA (Klasa 1) | Tak | NIE | NIE | NIE |
DEVICE_CREDENTIAL | Tak | Tak | Tak | Tak |
Struktura systemu Android obejmuje obsługę uwierzytelniania biometrycznego za pomocą twarzy i odcisków palców. Androida można dostosować do obsługi innych metod biometrycznych (takich jak Iris). Integracja biometryczna będzie jednak zależeć od bezpieczeństwa biometrycznego, a nie od modalności. Aby uzyskać więcej informacji na temat specyfikacji zabezpieczeń biometrycznych, zobacz temat Pomiar bezpieczeństwa odblokowania biometrycznego .
Źródło
Androida 12
- Wprowadzono interfejs API BiometricManager.Strings , który udostępnia zlokalizowane ciągi dla aplikacji korzystających z BiometricPrompt do uwierzytelniania. Te ciągi mają uwzględniać urządzenie i zapewniać większą szczegółowość tego, jakie typy uwierzytelniania mogą być używane.
- Obejmuje obsługę czujnika odcisków palców pod wyświetlaczem (UDFPS).
Androida 11
- Wprowadzono interfejs BiometricManager.Authenticators , który udostępnia stałe, których programiści mogą używać do określania typów uwierzytelniania akceptowanych przez ich aplikacje.
- Dodajeakcję intencji
ACTION_BIOMETRIC_ENROLL
, której programiści mogą używać, aby poinstruować użytkownika, aby zarejestrował metodę uwierzytelniania spełniającą wymagania ich aplikacji. - Dodaje metodę
AuthenticationResult #getAuthenticationType ()
, której programiści mogą używać do sprawdzania, czy użytkownik uwierzytelnił się przy użyciu danych biometrycznych, czy danych uwierzytelniających urządzenia. - Zapewnia dodatkową obsługę kluczy uwierzytelniania na użycie w klasie BiometricPrompt.
Androida 10
- Wprowadzono klasę
BiometricManager
, której deweloperzy mogą używać do sprawdzania dostępności uwierzytelniania biometrycznego. - Obejmuje integrację uwierzytelniania odcisków palców i twarzy dla
BiometricPrompt
Androida 9
- Obejmuje integrację odcisków palców tylko dla
BiometricPrompt
. - Przestarzała klasa FingerprintManager. Jeśli aplikacje dołączone i systemowe korzystają z tej klasy, zaktualizuj je, aby zamiast tego korzystały z funkcji
BiometricPrompt
iBiometricManager
. - Zaktualizowano testy weryfikatora
FingerprintManager
CTS, aby przetestowaćBiometricPrompt
przy użyciuBiometricPromptBoundKeysTest
.
Realizacja
Aby zapewnić użytkownikom i programistom bezproblemową obsługę biometryczną, zintegruj stos biometryczny z interfejsami API BiometricPrompt
, BiometricManager
i ACTION_BIOMETRIC_ENROLL
. Urządzenia z czujnikami biometrycznymi muszą spełniać te wymagania wytrzymałościowe . Dodatkowo wszystkie wdrożenia muszą przejść moduł CtsBiometricsTestCases CTS.
Aby zintegrować swój stos biometryczny z API ACTION_BIOMETRIC_ENROLL:
- Zmodyfikuj BiometricEnrollActivity , aby przedstawić przepływ rejestracji. Należy pamiętać, że dane biometryczne mogą zostać przedstawione tylko wtedy, gdy spełniają wymaganą siłę. Jeśli Twoje urządzenie obsługuje więcej niż jedno, ta akcja powinna wyświetlić listę, z której użytkownik może wybierać.
Wytyczne dotyczące wdrażania HAL
Postępuj zgodnie z poniższymi wytycznymi biometrycznymi HAL, aby mieć pewność, że dane biometryczne nie wyciekną i nie zostaną usunięte po usunięciu użytkownika z urządzenia:
- Upewnij się, że surowe dane biometryczne lub ich pochodne (takie jak szablony) nigdy nie są dostępne spoza bezpiecznego, izolowanego środowiska (takiego jak TEE lub bezpieczny element). Wszystkie przechowywane dane muszą być szyfrowane kluczem specyficznym dla urządzenia, znanym jedynie TEE (Trusted Execution Environment). Jeśli sprzęt to obsługuje, ogranicz dostęp sprzętu do bezpiecznego, izolowanego środowiska i chroń je polityką SELinux. Udostępnij kanał komunikacyjny (na przykład SPI, I2C) tylko dla bezpiecznego, izolowanego środowiska z wyraźną polityką SELinux dla wszystkich plików urządzenia.
- Pozyskiwanie, rejestracja i rozpoznawanie danych biometrycznych musi odbywać się w bezpiecznym, izolowanym środowisku, aby zapobiec naruszeniom danych i innym atakom. Wymóg ten dotyczy wyłącznie danych biometrycznych klasy 3 (dawniej Silna) i Klasy 2 (dawniej Słaba) .
- Aby zabezpieczyć się przed atakami typu „replay”, podpisuj szablony biometryczne prywatnym kluczem specyficznym dla urządzenia. W przypadku standardu Advanced Encryption Standard (AES) podpisz szablon co najmniej bezwzględną ścieżką systemu plików, grupą i identyfikatorem biometrycznym, tak aby pliki szablonów nie mogły działać na innym urządzeniu ani dla nikogo innego niż użytkownik, który zarejestrował je na tym samym urządzeniu . Na przykład zapobiegaj kopiowaniu danych biometrycznych od innego użytkownika na tym samym urządzeniu lub z innego urządzenia.
- Jeśli chcesz przechowywać dane poza TEE, użyj ścieżki systemu plików dostarczonej przez
setActiveUser() HIDL method
lub zapewnij inny sposób usunięcia wszystkich danych szablonu użytkownika po usunięciu użytkownika. Powodem jest ochrona przed wyciekiem danych użytkownika. Urządzenia, które nie korzystają z tej ścieżki , muszą zostać wyczyszczone po usunięciu użytkownika. CDD wymaga, aby dane biometryczne i pliki pochodne były przechowywane w postaci zaszyfrowanej – szczególnie jeśli nie w TEE. Jeśli jest to niemożliwe ze względu na wymagania dotyczące przechowywania w bezpiecznym izolowanym środowisku, dodaj haki, aby zapewnić usunięcie danych po usunięciu użytkownika lub urządzenia jest wycierany. Zobacz LockSettingsService.removeBiometricsForUser()
Dostosowywanie
Jeśli Twoje urządzenie obsługuje wiele metod biometrycznych, użytkownik powinien mieć możliwość określenia wartości domyślnej w ustawieniach. Twoja implementacja BiometricPrompt
powinna preferować biometrykę klasy 3 (wcześniej Silną) jako domyślną, chyba że użytkownik wyraźnie ją zastąpi. Wtedy powinien zostać wyświetlony komunikat ostrzegawczy wyjaśniający ryzyko związane z biometrią (na przykład Twoje zdjęcie może odblokować urządzenie )
Ciągi uwierzytelniające specyficzne dla urządzenia
Począwszy od Androida 12, kontekstowe ciągi uwierzytelniające są udostępniane programistom za pośrednictwem interfejsu API BiometricManager.Strings . Możesz dostosować wartości zasobów zwracane przez ten interfejs API, aby zaimplementować ciągi specyficzne dla urządzenia. Jeśli to zrobisz, upewnij się, że wszystkie nowe ciągi znaków zostały przetłumaczone dla wszystkich ustawień regionalnych obsługiwanych przez urządzenie. Dodatkowo upewnij się, że zachowane zostały następujące właściwości:
metoda | Cel ciągu | Typy uwierzytelniania, które należy uwzględnić | Jeśli możliwe są zarówno dane biometryczne, jak i blokada ekranu |
---|---|---|---|
getButtonLabel() | Etykieta przycisku wyzwalającego BiometricPrompt | Tylko zarejestrowane typy (jeśli to możliwe), które spełniają wymagania modułu uwierzytelniającego | Użyj ciągu wyłącznie biometrycznego (np. „Użyj odcisku palca”) |
getPromptMessage() | Wiadomość wyświetlana w BiometricPrompt podczas uwierzytelniania | Tylko zarejestrowane typy (jeśli to możliwe), które spełniają wymagania modułu uwierzytelniającego | Użyj połączonego ciągu biometrycznego i blokady ekranu (np. „Użyj odcisku palca lub kodu PIN, aby kontynuować”) |
getSettingName() | Nazwa ustawienia włączającego BiometricPrompt do uwierzytelniania | Wszystkie typy obsługiwane przez urządzenie (nawet jeśli nie są zarejestrowane), które spełniają wymagania modułu uwierzytelniającego | Użyj połączonego hasła biometrycznego i blokady ekranu (np. „Użyj odcisku palca lub blokady ekranu”) |
Rozważmy na przykład urządzenie wyposażone w czujnik twarzy klasy 2 z zarejestrowaną twarzą , zarejestrowany kod PIN i czujnik odcisków palców klasy 3 bez zarejestrowanych odcisków palców . Poniższa tabela zawiera przykładowe ciągi znaków dla każdej kombinacji dozwolonych uwierzytelniaczy i wywołanej metody BiometricManager.Strings :
Dozwolone uwierzytelniacze | getButtonLabel() | getPromptMessage() | getSettingName() |
---|---|---|---|
Biometryczna klasa 3 ( BIOMETRIC_STRONG ) | „Użyj odcisku palca” (Tylko odcisk palca spełnia wymagania modułu uwierzytelniającego) | „Użyj odcisku palca, aby kontynuować” (Tylko odcisk palca spełnia wymagania modułu uwierzytelniającego) | „Użyj odcisku palca” (Tylko odcisk palca spełnia wymagania modułu uwierzytelniającego) |
Biometryczna klasa 2 ( BIOMETRIC_WEAK ) | „Użyj twarzy” (Twarz i odcisk palca spełniają wymagania; zarejestrowana jest tylko twarz) | „Użyj twarzy, aby kontynuować” (Twarz i odcisk palca spełniają wymagania; zarejestrowana jest tylko twarz) | „Użyj twarzy lub odcisku palca” (Twarz i odcisk palca spełniają wymagania; urządzenie obsługuje oba) |
Blokada ekranu ( DEVICE_CREDENTIAL ) | „Użyj kodu PIN” (Każda blokada ekranu spełnia wymagania; kod PIN został zarejestrowany) | „Wprowadź swój PIN, aby kontynuować” (Każda blokada ekranu spełnia wymagania; kod PIN został zarejestrowany) | „Użyj blokady ekranu” (Każda blokada ekranu spełnia wymagania) |
Biometryczna blokada ekranu LUB klasy 3 | „Użyj kodu PIN” (Odcisk palca i dowolna blokada ekranu spełniają wymagania; zarejestrowany jest tylko PIN) | „Wprowadź swój PIN, aby kontynuować” (Odcisk palca i dowolna blokada ekranu spełniają wymagania; zarejestrowany jest tylko PIN) | „Użyj odcisku palca lub blokady ekranu” (Odcisk palca i dowolna blokada ekranu spełniają wymagania) |
Biometryczna blokada ekranu LUB klasy 2 | „Użyj twarzy” (Twarz, odcisk palca i dowolna blokada ekranu spełniają wymagania; twarz jest zarejestrowana i zastępuje PIN) | „Użyj swojej twarzy lub kodu PIN, aby kontynuować” (Twarz, odcisk palca i dowolna blokada ekranu spełniają wymagania; twarz i kod PIN są zarejestrowane) | „Użyj danych biometrycznych lub blokady ekranu” (Twarz, odcisk palca i dowolna blokada ekranu spełniają wymagania) |
Walidacja
Twoja implementacja biometryczna musi przejść następujące testy:
- Menedżer biometryczny CTS
- CTS BiometricPrompt (poczytalność, szczegółowe testowanie opiera się na weryfikatorze)
- Sekcja testu biometrycznego CtsVerifier: należy przejść indywidualnie dla każdej modalności obsługiwanej przez urządzenie
Ponadto, jeśli Twoje urządzenie obsługuje biometrię, która ma AOSP HIDL ( odcisk palca@2.1 , odcisk palca@2.2 , twarz1.0 ), musi przejść odpowiedni test VTS ( odcisk palca , twarz )