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ług przechowywania i obsługi kluczy kryptograficznych Przechowuje klucze kryptograficzne i udostępnia standardowe procedury kryptograficzne oparte na tych kluczach. Android obsługuje magazyn kluczy oparty na sprzęcie i KeyMint (wcześniej Keymaster) na potrzeby 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ętowej (HAL) i przejść odpowiednie testy zestawu 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 mechanizmy uwierzytelniające są przygotowane do otrzymywania rejestracji danych logowania od użytkownika. Użytkownik musi najpierw zarejestrować kod PIN, wzór lub hasło w usłudze Gatekeeper (lub w usłudze Weaver, jeśli jest dostępna). Początkowa 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 powiązany kryptograficznie 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 tymi danymi 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 bezpiecznym środowisku. 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 FingerprintService wysył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 biometrii 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 komponentowi TEE biometrycznemu. 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 niego).

Proces uwierzytelniania nie wymaga bezpośredniej komunikacji między aplikacjami TA w środowisku bezpiecznym: tokeny uwierzytelniania są przesyłane 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 tokena uwierzytelniania

Format AuthToken jest określony w specyfikacji AIDL w 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 udostępnionego hasła: 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ędzy procesami (IPC) (zależnego od platformy) do udostępniania klucza HMAC.

W obu przypadkach klucz HMAC nigdy nie może być udostępniany poza 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. Usługi Fingerprint 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.