Uwierzytelnianie

Android wykorzystuje koncepcję kluczy kryptograficznych bramkowanych przez uwierzytelnianie użytkownika, które wymagają następujących komponentów:

• Dostawca usług przechowywania i przechowywania kluczy kryptograficznych. Przechowuje klucze kryptograficzne i zapewnia standardowe procedury kryptograficzne na podstawie tych kluczy. System Android obsługuje sprzętowy magazyn kluczy i Keymaster do usług kryptograficznych, w tym sprzętową kryptografię do przechowywania kluczy, która może obejmować zaufane środowisko wykonawcze (TEE) lub bezpieczny element (SE), taki jak Strongbox.
• Uwierzytelniacze użytkownika. Potwierdź obecność użytkownika i/lub pomyślne uwierzytelnienie. Android obsługuje funkcję Gatekeeper do uwierzytelniania za pomocą kodu PIN/wzoru/hasła oraz czytnika linii papilarnych do uwierzytelniania odcisków palców. Urządzenia dostarczane z systemem Android 9 i nowszym mogą używać BiometricPrompt jako pojedynczego punktu integracji odcisków palców i dodatkowych danych biometrycznych. Komponenty te komunikują swój stan uwierzytelnienia z usługą magazynu kluczy za pośrednictwem uwierzytelnionego kanału. ( System Android Keystore na poziomie frameworka jest również wspierany przez usługę magazynu kluczy.)

Komponenty Gatekeeper, Fingerprint i Biometric współpracują z Keystore i innymi komponentami, aby obsługiwać użycie tokenów uwierzytelniających wspieranych sprzętowo (AuthTokens).

Zapisy

Podczas pierwszego uruchomienia urządzenia po przywróceniu ustawień fabrycznych wszystkie uwierzytelniacze są przygotowane na otrzymanie rejestracji poświadczeń od użytkownika. Użytkownik musi najpierw zarejestrować PIN/wzór/hasło w Gatekeeper. 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 wiążący dla materiału kryptograficznego użytkownika. Ten identyfikator SID użytkownika jest kryptograficznie powiązany z hasłem użytkownika; pomyślne uwierzytelnienie w Gatekeeper skutkuje AuthTokens, które zawierają identyfikator SID użytkownika dla tego hasła.

Użytkownik chcący zmienić dane uwierzytelniające musi przedstawić istniejące dane uwierzytelniające. Jeśli istniejące poświadczenie zostanie pomyślnie zweryfikowane, identyfikator SID u��ytkownika powiązany z istniejącym poświadczeniem zostanie przeniesiony do nowego poświadczenia, umożliwiając użytkownikowi dalszy dostęp do kluczy po zmianie poświadczenia. Jeśli użytkownik nie przedstawi istniejącego poświadczenia, nowe poświadczenie zostanie zarejestrowane z całkowicie losowym identyfikatorem SID użytkownika. Użytkownik może uzyskać dostęp do urządzenia, ale klucze utworzone pod starym identyfikatorem SID użytkownika zostaną trwale utracone. Nazywa się to rejestracją niezaufaną .

W normalnych okolicznościach środowisko Androida nie pozwala na niezaufaną rejestrację, więc większość użytkowników nigdy nie zobaczy tej funkcji. Jednak wymuszone resetowanie hasła dokonane przez administratora urządzenia lub osobę atakującą może spowodować taką sytuację.

Uwierzytelnianie

Gdy użytkownik skonfiguruje poświadczenie i otrzyma identyfikator SID, może rozpocząć uwierzytelnianie, które rozpoczyna się w momencie podania przez użytkownika kodu PIN, wzoru, hasła lub odcisku palca. Wszystkie komponenty TEE mają wspólny tajny klucz, którego używają do wzajemnego uwierzytelniania wiadomości.

1. Użytkownik udostępnia metodę uwierzytelniania, a powiązana usługa wysyła żądanie do powiązanego demona.
   • Aby uzyskać PIN, wzór lub hasło, LockSettingsService wysyła żądanie do gatekeeperd .
   • Przepływy uwierzytelniania opartego na danych biometrycznych zależą od wersji Androida. Na urządzeniach z Androidem 8.x i starszym FingerprintService wysyła żądanie fingerprintd ). Na urządzeniach z systemem Android 9 i nowszym BiometricPrompt wysyła żądanie do odpowiedniego demona biometrycznego (na przykład fingerprintd w przypadku odcisków palców lub faced ) przy użyciu odpowiedniej klasy Biometric Manager , takiej jak FingerprintManager lub FaceManager . Niezależnie od wersji, uwierzytelnianie biometryczne następuje asynchronicznie po wysłaniu żądania.
2. Demon wysyła dane do swojego odpowiednika, który generuje AuthToken:
   • W celu uwierzytelnienia za pomocą PIN-u/wzoru/hasła, gatekeeperd wysyła PIN, wzór lub skrót hasła do Gatekeepera w TEE. Jeśli uwierzytelnienie w TEE zakończy się pomyślnie, Gatekeeper w TEE wysyła AuthToken zawierający odpowiedni identyfikator SID użytkownika (podpisany kluczem AuthToken HMAC) do swojego odpowiednika w systemie operacyjnym Android.
   • W przypadku uwierzytelniania odcisków palców, fingerprintd nasłuchuje zdarzeń odcisków palców i wysyła dane do odcisku palca w TEE. Jeśli uwierzytelnienie w TEE zakończy się pomyślnie, Fingerprint w TEE wysyła AuthToken (podpisany kluczem AuthToken HMAC) do swojego odpowiednika w systemie operacyjnym Android.
   • W przypadku innego uwierzytelniania biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzenia biometrycznego i wysyła je do odpowiedniego komponentu biometrycznego TEE.
3. Demon odbiera podpisany token AuthToken i przekazuje go do usługi magazynu kluczy poprzez rozszerzenie interfejsu Binder usługi magazynu kluczy. ( gatekeeperd powiadamia również usługę magazynu kluczy, gdy urządzenie zostanie ponownie zablokowane i gdy zmieni się hasło urządzenia.)
4. Usługa magazynu kluczy przekazuje tokeny AuthTokens do Keymaster i weryfikuje je przy użyciu klucza udostępnionego Gatekeeperowi i obsługiwanego biometrycznego komponentu TEE. Keymaster traktuje sygnaturę czasową w tokenie jako czas ostatniego uwierzytelnienia i opiera decyzję o wydaniu klucza (aby umożliwić aplikacji użycie klucza) na sygnaturze czasowej.

Format tokenu uwierzytelniania

Aby zapewnić współdzielenie tokenów i zgodność między językami i komponentami, format AuthToken opisano w hw_auth_token.h . Format to prosty protokół serializacji z polami o stałym rozmiarze.

Przebieg uruchamiania urządzenia

Przy każdym uruchomieniu urządzenia należy wygenerować klucz AuthToken HMAC i udostępnić go wszystkim komponentom TEE (Gatekeeper, Keymaster i obsługiwane zaufane certyfikaty biometryczne). Dlatego też, aby zapewnić dodatkową ochronę przed atakami poprzez powtórzenie, klucz HMAC musi być generowany losowo przy każdym ponownym uruchomieniu urządzenia.

Protokół udostępniania tego klucza HMAC wszystkim komponentom jest funkcją implementacji zależną od platformy. Klucza nie wolno nigdy udostępniać poza TEE. Jeśli system operacyjny TEE nie ma mechanizmu wewnętrznej komunikacji międzyprocesowej (IPC) i musi przesyłać dane przez niezaufany system operacyjny, transfer musi odbywać się za pośrednictwem bezpiecznego protokołu wymiany kluczy.

Przykładem TEE jest system operacyjny Trusty , który działa obok Androida, ale zamiast niego można używać innych TEE. Trusty korzysta z wewnętrznego systemu IPC do bezpośredniej komunikacji pomiędzy Keymasterem a Gatekeeperem lub odpowiednim zaufanym zaufaniem biometrycznym. Klucz HMAC jest przechowywany wyłącznie w Keymaster; Odcisk palca i Gatekeeper żądają klucza od Keymastera przy każdym użyciu i nie utrwalają ani nie buforują wartości.

Ponieważ niektóre TEE nie mają infrastruktury IPC, pomiędzy apletami w TEE nie zachodzi żadna komunikacja. Umożliwia to również usłudze magazynu kluczy szybkie odrzucanie żądań, które są skazane na niepowodzenie, ponieważ posiada ona wiedzę o tabeli uwierzytelniania w systemie, oszczędzając potencjalnie kosztowny IPC w TEE.