Authentication

Android ma koncepcję uwierzytelniaczy użytkownika, które służą do odblokowywania urządzenia i ograniczania dostępu do kluczy kryptograficznych. Obejmuje to te komponenty:

• Dostawca usługi przechowywania kluczy kryptograficznych. Przechowuje klucze kryptograficzne i udostępnia standardowe procedury kryptograficzne oparte na tych kluczach. Android obsługuje Keystore oparty na sprzęcie i KeyMint (wcześniej Keymaster) w przypadku usług kryptograficznych, w tym kryptografii opartej na sprzęcie do przechowywania kluczy, która może obejmować zaufane środowisko wykonawcze (TEE) lub bezpieczny element (SE), taki jak StrongBox.
• Uwierzytelnianie użytkownika potwierdzać obecność użytkownika lub pomyślne uwierzytelnienie. Android obsługuje Gatekeeper w przypadku uwierzytelniania za pomocą kodu PIN, wzoru lub hasła oraz Fingerprint w przypadku uwierzytelniania za pomocą odcisku palca. Urządzenia z Androidem 9 i nowszym mogą używać BiometricPrompt jako pojedynczego punktu integracji odcisków palców i dodatkowych danych biometrycznych. Te komponenty przekazują swój stan uwierzytelniania do usługi magazynu kluczy za pomocą uwierzytelnionego kanału. (System Android Keystore na poziomie platformy jest również obsługiwany przez usługę Keystore).

Każdy z tych komponentów jest specyficzny dla danego dostawcy, ale implementacja dostawcy musi spełniać specyfikację interfejsu warstwy abstrakcji sprzętu (HAL) i przejść odpowiednie testy pakietu testów dostawcy (VTS).

Wdrożenia dostawców są zwykle podzielone na 2 części połączone mechanizmem komunikacji specyficznym dla dostawcy :

• Usługa HAL działa jako proces systemowy Androida, który odbiera żądania Binder z systemu Android.
• Zaufana aplikacja (TA) działa w bezpiecznym środowisku i wykonuje rzeczywiste bezpieczne operacje.

Rejestracja

Podczas pierwszego uruchomienia urządzenia po przywróceniu ustawień fabrycznych wszystkie uwierzytelnianie są przygotowane do otrzymywania rejestracji danych logowania od użytkownika. Użytkownik musi najpierw zarejestrować kod PIN, wzór lub hasło w Gatekeeperze (lub Weaverze, jeśli jest dostępny). Ta wstępna rejestracja tworzy losowo wygenerowany 64-bitowy bezpieczny identyfikator użytkownika (SID), który służy jako identyfikator użytkownika i token powiązania z materiałami kryptograficznymi użytkownika. Identyfikator SID użytkownika jest kryptograficznie powiązany z hasłem użytkownika. Pomyślne uwierzytelnienia w usłudze Gatekeeper powodują generowanie tokenów AuthToken, które zawierają identyfikator SID użytkownika dla tego hasła.

Użytkownik, który chce zmienić istniejące dane logowania, musi je przedstawić. Jeśli istniejące dane logowania zostaną zweryfikowane, identyfikator SID użytkownika powiązany z istniejącymi danymi logowania zostanie przeniesiony do nowych danych logowania, co umożliwi użytkownikowi dalszy dostęp do kluczy po zmianie danych logowania.

W niektórych sytuacjach administrator urządzenia może przeprowadzić niezaufaną rejestrację, aby zarejestrować nowe dane logowania bez przedstawiania istniejących danych logowania. Umożliwia to użytkownikowi dostęp do urządzenia, ale klucze utworzone w ramach starego identyfikatora SID użytkownika zostaną trwale utracone.

Uwierzytelnianie

W tej sekcji opisujemy typowy proces uwierzytelniania, który obejmuje interakcje między wieloma komponentami w Androidzie i środowisku bezpiecznym. Pamiętaj, że wszystkie bezpieczne komponenty mają wspólny (dla każdego uruchomienia) tajny klucz HMAC, którego używają do uwierzytelniania wiadomości innych komponentów.

Gdy użytkownik skonfiguruje dane logowania i otrzyma identyfikator SID, może rozpocząć uwierzytelnianie. Rozpoczyna się ono, gdy użytkownik poda kod PIN, wzór, hasło, odcisk palca lub inne silne dane biometryczne.

Rysunek 1. Proces uwierzytelniania

1. Użytkownik podaje metodę uwierzytelniania, a powiązana usługa wysyła żądanie do usługi HAL.
   • W przypadku kodu PIN, wzoru lub hasła aplikacja LockSettingsService wysyła żądanie do gatekeeperd.
   • Procesy uwierzytelniania oparte na biometrii zależą od wersji Androida. Na urządzeniach z Androidem w wersji 8.x lub starszej FingerprintServicewysyła żądanie do fingerprintd). Na urządzeniach z Androidem w wersji 9 lub nowszej BiometricPrompt wysyła żądanie do odpowiedniego demona biometrycznego (np. fingerprintd w przypadku odcisków palców lub faced w przypadku rozpoznawania twarzy) za pomocą odpowiedniej klasy BiometricManager, np. FingerprintManager lub FaceManager. Niezależnie od wersji uwierzytelnianie biometryczne odbywa się asynchronicznie po wysłaniu prośby.
2. Usługa HAL wysyła dane do odpowiedniego modułu TA, który generuje token AuthToken:
   • W przypadku uwierzytelniania za pomocą kodu PIN, wzoru lub hasła gatekeeperd wysyła skrót kodu PIN, wzoru lub hasła do zaufanego środowiska wykonawczego (TEE) za pomocą usługi Gatekeeper HAL. Jeśli uwierzytelnianie w TEE się powiedzie, Gatekeeper TA wyemituje AuthToken zawierający odpowiedni identyfikator SID użytkownika (podpisany za pomocą wspólnego klucza HMAC).
   • W przypadku uwierzytelniania odciskiem palca fingerprintd nasłuchuje zdarzeń związanych z odciskiem palca i wysyła dane do zaufanego środowiska wykonawczego za pomocą interfejsu HAL odcisku palca. Jeśli uwierzytelnianie w TEE się powiedzie, aplikacja TA odcisku palca wyemituje token AuthToken (podpisany kluczem HMAC tokena AuthToken).
   • W przypadku innych metod uwierzytelniania biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzenia biometrycznego i wysyła je do odpowiedniej usługi HAL biometrycznej i TA.
3. Demon otrzymuje podpisany token AuthToken i przekazuje go do usługi magazynu kluczy za pomocą rozszerzenia interfejsu Binder usługi magazynu kluczy. (gatekeeperd powiadamia też usługę magazynu kluczy, gdy urządzenie zostanie ponownie zablokowane i gdy zmieni się hasło do urządzenia).
4. Usługa Keystore przekazuje tokeny uwierzytelniania do KeyMint i weryfikuje je za pomocą klucza udostępnionego usłudze Gatekeeper i obsługiwanemu biometrycznemu komponentowi TEE. KeyMint ufa sygnaturze czasowej w tokenie jako ostatniemu czasowi uwierzytelniania i na jej podstawie podejmuje decyzję o udostępnieniu klucza (aby umożliwić aplikacji korzystanie z klucza).

Proces uwierzytelniania nie wymaga bezpośredniej komunikacji między aplikacjami TA w środowisku bezpiecznym: tokeny AuthToken przepływają z aplikacji TA uwierzytelniania do usługi keystore2 w Androidzie, która z kolei przekazuje je do aplikacji TA KeyMint. Umożliwia to też usłudze keystore2 szybkie odrzucanie żądań, które nie mogą zostać zrealizowane, ponieważ zna ona dostępne tokeny AuthToken w systemie. Pozwala to uniknąć potencjalnie kosztownego wywołania IPC do środowiska TEE.

Format AuthToken

Format AuthToken jest określony w specyfikacji AIDL na stronie HardwareAuthToken.aidl.

Proces uruchamiania urządzenia

Przy każdym uruchomieniu urządzenia należy wygenerować klucz HMAC AuthToken i udostępnić go wszystkim komponentom TEE (Gatekeeper, KeyMint i obsługiwane moduły zaufane biometrii). Dlatego w celu zwiększenia ochrony przed atakami typu replay klucz HMAC musi być losowo generowany przy każdym ponownym uruchomieniu urządzenia.

Istnieją 2 typowe sposoby uzyskania przez asystentów dostępu do tego udostępnionego klucza HMAC:

• Uzgadnianie tajnego klucza: usługa keystore2 przeprowadza wielostronny protokół uzgadniania kluczy podczas uruchamiania urządzenia, co umożliwia bezpieczne wyprowadzanie klucza HMAC między uczestniczącymi w tym procesie zaufanymi aplikacjami. Jednak uczestniczący w niej asystenci muszą mieć dostęp do wspólnego, wstępnie udostępnionego klucza tajnego.
• Bezpośredni dostęp: usługi zaufane znajdujące się w tym samym bezpiecznym środowisku mogą używać wewnętrznego mechanizmu komunikacji międzyprocesowej (zależnego od platformy) do udostępniania klucza HMAC.

W obu przypadkach klucz HMAC nigdy nie może być udostępniany poza środowiskiem TEE.

Przykładem TEE jest system operacyjny Trusty, który działa obok Androida, ale można używać innych TEE. Trusty używa wewnętrznego systemu IPC do bezpośredniej komunikacji między KeyMint a Gatekeeper lub odpowiednim trustletem biometrycznym. Klucz HMAC jest przechowywany wyłącznie w KeyMint. Czytnik linii papilarnych i Gatekeeper żądają klucza z KeyMint przy każdym użyciu i nie przechowują ani nie buforują jego wartości.

Niektóre środowiska TEE nie mają infrastruktury IPC, więc nie ma komunikacji między apletami w TEE. Umożliwia to też usłudze keystore szybkie odrzucanie żądań, które na pewno się nie powiodą, ponieważ zna ona tabelę uwierzytelniania w systemie, co pozwala uniknąć potencjalnie kosztownego IPC do TEE.