Biometria

Dane biometryczne oferują wygodniejszy, ale potencjalnie mniej bezpieczny sposób potwierdzania tożsamości za pomocą urządzenia. W modelu uwierzytelniania warstwowego uwierzytelnianie podstawowe (tj. modalności oparte na czynnikach wiedzy, takie jak kod PIN, wzór i hasło) zapewnia najwyższy poziom bezpieczeństwa. Dane biometryczne znajdują się na drugim poziomie uwierzytelniania, oferując równowagę mię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 powyższym dokumencie CDD. Wszystkie trzy klasy mogą integrować się z lockscreen, ale tylko silne i słabe uwierzytelnienia mogą integrować się z interfejsami API android.hardware.biometrics. W tej tabeli opisano każdy wystawca uwierzytelnienia i obsługiwane przez niego funkcje.

Uwierzytelniający Ekran blokady Integracja BiometricPrompt Magazyn kluczy (klucz czasowy) Magazyn kluczy (klucz operacyjny)
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 (1)
  1. Ta funkcja została dodana w systemie Android 11, zobacz szczegóły

Platforma Android obejmuje obsługę uwierzytelniania biometrycznego za pomocą twarzy i odcisku palca. Android można dostosować do obsługi innych modalności biometrycznych (takich jak Iris). Jednak integracja biometryczna będzie zależeć od bezpieczeństwa biometrycznego, a nie od modalności. Aby uzyskać więcej informacji na temat specyfikacji zabezpieczeń biometrycznych, zobacz Pomiar zabezpieczeń odblokowania biometrycznego .

Źródło

Androida 11

  • Wprowadza interfejs BiometricManager.Authenticators , który zapewnia stałe, których deweloperzy mogą używać do określania typów uwierzytelniania akceptowanych przez ich aplikacje.
  • Dodaje akcjęintencji ACTION_BIOMETRIC_ENROLL , której programiści mogą użyć do nakazania użytkownikowi zarejestrowania metody uwierzytelniania spełniającej wymagania ich aplikacji.
  • Dodaje metodę AuthenticationResult #getAuthenticationType () , której deweloperzy mogą używać do sprawdzania, czy użytkownik uwierzytelnił się przy użyciu poświadczeń biometrycznych czy poświadczeń urządzenia.
  • Zapewnia dodatkową obsługę kluczy uwierzytelniania według użycia w klasie BiometricPrompt.

Android 10

  • Wprowadza 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

Android 9

  • Obejmuje integrację odcisków palców tylko dla BiometricPrompt .
  • Przestarzał klasę FingerprintManager. Jeśli aplikacje pakietowe i systemowe korzystają z tej klasy, zaktualizuj je, aby zamiast tego korzystały z BiometricPrompt i BiometricManager .
  • Zaktualizowano testy weryfikatora CTS FingerprintManager , aby przetestować BiometricPrompt przy użyciu BiometricPromptBoundKeysTest .

Realizacja

Aby zapewnić użytkownikom i programistom bezproblemową obsługę biometryczną, zintegruj swój stos biometryczny z interfejsami API BiometricPrompt , BiometricManager i ACTION_BIOMETRIC_ENROLL . Urządzenia z czujnikami biometrycznymi muszą spełniać te wymagania wytrzymałościowe .
Aby zintegrować swój stos biometryczny z BiometricManager APIs BiometricPrompt i BiometricManager :

  1. Upewnij się, że Twoja <Modality>Service jest prawidłowo zarejestrowana w BiometricService za pomocą metody IBiometricService#registerAuthenticator i implementuje interfejs IBiometricAuthenticator . Wspólne modalności (odcisk palca, twarz) wywodzą się ze wspólnej superklasy . Jeśli potrzebujesz zintegrować nieobsługiwaną modalność, postępuj zgodnie z przykładem odcisku palca / twarzy oraz wytycznymi CDD dla biometrii.
  2. Upewnij się, że nowa modalność jest poprawnie obsługiwana w SystemUI . Istnieją domyślne interfejsy użytkownika BiometricPrompt dla odcisku palca i twarzy. Powinno to obejmować wszelkie zmiany układu lub motywu wymagane dla Twojego urządzenia. Tj. odpowiednie zmiany układu dla wbudowanego czytnika linii papilarnych.

Aby zintegrować swój stos biometryczny z interfejsem API ACTION_BIOMETRIC_ENROLL:

  1. Zmodyfikuj BiometricEnrollActivity , aby przedstawić przepływ rejestracji. Pamiętaj, że Twój biometria może być prezentowana tylko wtedy, gdy spełnia wymaganą siłę. Jeśli Twoje urządzenie obsługuje więcej niż jedno, ta akcja powinna przedstawić listę, z której użytkownik może wybrać.
Architektura biometrycznaPrompt
Rysunek 1. Architektura BiometricPrompt

Wytyczne dotyczące wdrażania HAL

Postępuj zgodnie z poniższymi wytycznymi biometrycznymi HAL, aby upewnić się, że dane biometryczne nie zostaną ujawnione i zostaną usunięte , gdy użytkownik zostanie usunięty z urządzenia:

  • Upewnij się, że surowe dane biometryczne lub pochodne (takie jak szablony) nigdy nie są dostępne spoza bezpiecznego izolowanego środowiska (takiego jak TEE lub Secure Element). Wszystkie przechowywane dane muszą być zaszyfrowane kluczem specyficznym dla urządzenia , znanym tylko TEE (Trusted Execution Environment). Jeśli sprzęt to obsługuje, ogranicz dostęp do sprzętu do bezpiecznego izolowanego środowiska i chroń go za pomocą polityki SELinux. Uczyń kanał komunikacyjny (na przykład SPI, I2C) dostępnym tylko dla bezpiecznego izolowanego środowiska z jawną polityką SELinux dla wszystkich plików urządzeń.
  • Pozyskiwanie, rejestracja i rozpoznawanie danych biometrycznych musi odbywać się w bezpiecznym, odizolowanym środowisku, aby zapobiec naruszeniom danych i innym atakom. Wymóg ten dotyczy tylko biometrii Klasy 3 (dawniej Silna) i Klasy 2 (dawniej Słaba) .
  • Aby chronić się przed atakami typu powtórka, podpisuj szablony biometryczne za pomocą prywatnego klucza specyficznego dla urządzenia. W przypadku Advanced Encryption Standard (AES) należy co najmniej podpisać szablon z bezwzględną ścieżką systemu plików, grupą i identyfikatorem biometrycznym, tak aby pliki szablonów nie działały na innym urządzeniu lub dla kogokolwiek 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 musisz 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 używają tej ścieżki, muszą zostać oczyszczone po usunięciu użytkownika. CDD wymaga, aby dane biometryczne i pliki pochodne były przechowywane w postaci zaszyfrowanej — zwłaszcza, jeśli nie jest to TEE. jest wycierany. Zobacz LockSettingsService.removeBiometricsForUser()

Dostosowywanie

Jeśli Twoje urządzenie obsługuje wiele danych biometrycznych, użytkownik powinien mieć możliwość określenia wartości domyślnej w ustawieniach. Twoja implementacja BiometricPrompt powinna preferować biometrię klasy 3 (dawniej Silna) jako domyślną, chyba że użytkownik wyraźnie ją zastąpi, wówczas musi zostać wyświetlony komunikat ostrzegawczy wyjaśniający ryzyko związane z biometrią (na przykład Twoje zdjęcie może odblokować urządzenie )

Walidacja

Twoja implementacja biometryczna musi przejść następujące testy:

  • Menedżer biometryczny CTS
  • CTS BiometricPrompt (poczytalność, dogłębne testy opierają się na weryfikatorze)
  • Sekcja CtsVerifier Biometric Test : musi 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 )