Uwierzytelnianie

System Android wykorzystuje koncepcję kluczy kryptograficznych bramkowanych przez uwierzytelnianie użytkownika, która wymaga następujących składników:

• Dostawca usług przechowywania i przechowywania kluczy kryptograficznych. Przechowuje klucze kryptograficzne i zapewnia standardowe procedury kryptograficzne na tych kluczach. Android obsługuje wspierane sprzętowo Keystore i Keymaster dla usług kryptograficznych, w tym kryptografię wspieraną sprzętowo do przechowywania kluczy, która może zawierać środowisko Trusted Execution Environment (TEE) lub Secure Element (SE), takie jak Strongbox.
• Uwierzytelniacze użytkowników. Potwierdź obecność użytkownika i/lub pomyślne uwierzytelnienie. Android obsługuje Gatekeeper do uwierzytelniania PIN/wzorem/hasłem oraz Fingerprint do uwierzytelniania odcisków palców. Urządzenia dostarczane z systemem Android 9 lub nowszym mogą używać BiometricPrompt jako pojedynczego punktu integracji dla odcisków palców i dodatkowych danych biometrycznych. Te składniki komunikują swój stan uwierzytelniania z usługą magazynu kluczy za pośrednictwem uwierzytelnionego kanału. (System Android Keystore na poziomie struktury jest również wspierany przez usługę keystore).

Składniki Gatekeeper, Fingerprint i Biometric współpracują z Keystore i innymi składnikami w celu obsługi tokenów uwierzytelniania wspieranych sprzętowo (AuthTokens).

Zapisy

Podczas pierwszego rozruchu urządzenia po przywróceniu ustawień fabrycznych wszystkie uwierzytelniające są przygotowane do odbierania rejestracji poświadczeń od użytkownika. Użytkownik musi najpierw zarejestrować kod PIN/wzór/hasło w Gatekeeperze. Ta początkowa rejestracja tworzy losowo generowany 64-bitowy bezpieczny identyfikator użytkownika (SID), który służy jako identyfikator użytkownika i jako token powiązania dla materiału kryptograficznego użytkownika. Ten identyfikator SID użytkownika jest kryptograficznie powiązany z hasłem użytkownika; pomyślne uwierzytelnienia do Gatekeeper dają w wyniku AuthTokens, które zawierają identyfikator SID użytkownika dla tego hasła.

Użytkownik, który chce zmienić poświadczenie, musi przedstawić istniejące poświadczenie. 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 zachowanie dostępu 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 zostają trwale utracone. Jest to tak zwana niezaufana rejestracja .

W normalnych okolicznościach platforma Android nie zezwala na niezaufaną rejestrację, więc większość użytkowników nigdy nie zobaczy tej funkcji. Jednak może to spowodować wymuszenie resetowania hasła przez administratora urządzenia lub osobę atakującą.

Uwierzytelnianie

Gdy użytkownik skonfiguruje poświadczenia i otrzyma identyfikator SID użytkownika, może rozpocząć uwierzytelnianie, które rozpoczyna się, gdy użytkownik poda kod PIN, wzór, hasło lub odcisk palca. Wszystkie komponenty TEE współdzielą tajny klucz, którego używają do wzajemnego uwierzytelniania wiadomości.

1. Użytkownik udostępnia metodę uwierzytelniania, a skojarzona usługa wysyła żądanie do skojarzonego demona.
   • W przypadku kodu PIN, wzoru lub hasła LockSettingsService żądanie do gatekeeperd .
   • Przepływy uwierzytelniania oparte na danych biometrycznych zależą od wersji systemu Android. Na urządzeniach z systemem Android 8.x lub starszym FingerprintService żądanie do fingerprintd ). Na urządzeniach z systemem Android 9 lub nowszym BiometricPrompt żądanie do odpowiedniego demona biometrycznego (na przykład pobranego fingerprintd w przypadku odcisków palców lub faced w twarz) przy użyciu odpowiedniej klasy Biometric Manager , takiej jak FingerprintManager lub FaceManager . Niezależnie od wersji uwierzytelnianie biometryczne odbywa się asynchronicznie po wysłaniu żądania.
2. Demon wysyła dane do swojego odpowiednika, który generuje AuthToken:
   • W przypadku uwierzytelniania za pomocą kodu PIN/wzoru/hasła gatekeeperd wysyła kod PIN, wzór lub skrót hasła do Gatekeepera w TEE. Jeśli uwierzytelnianie w TEE powiedzie się, 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ń związanych z odciskiem palca i wysyła dane do odcisku palca w TEE. Jeśli uwierzytelnianie w TEE powiedzie się, odcisk palca w TEE wysyła token 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 AuthToken i przekazuje go do usługi magazynu kluczy za pośrednictwem rozszerzenia interfejsu Binder usługi magazynu kluczy. ( gatekeeperd również powiadamia usługę magazynu kluczy o ponownym zablokowaniu urządzenia i zmianie hasła urządzenia.)
4. Usługa magazynu kluczy przekazuje tokeny AuthToken do Keymaster i weryfikuje je za pomocą klucza udostępnionego Gatekeeperowi i obsługiwanego komponentu biometrycznego TEE. Keymaster ufa sygnaturze czasowej w tokenie jako ostatniej godzinie uwierzytelniania i opiera decyzję o wydaniu klucza (aby umożliwić aplikacji użycie klucza) na sygnaturze czasowej.

Format tokena uwierzytelniania

Aby zapewnić udostępnianie tokenów i zgodność między językami i składnikami, format AuthToken jest opisany w hw_auth_token.h . Format jest prostym protokołem serializacji z polami o stałym rozmiarze.

Przepływ rozruchu urządzenia

Przy każdym uruchomieniu urządzenia klucz AuthToken HMAC musi zostać wygenerowany i udostępniony wszystkim komponentom TEE (Gatekeeper, Keymaster i obsługiwane trustlety biometryczne). Dlatego w celu dodatkowej ochrony przed atakami typu powtórka klucz HMAC musi być generowany losowo przy każdym ponownym uruchomieniu urządzenia.

Protokół udostępniania tego klucza HMAC ze wszystkimi komponentami jest funkcją implementacji zależną od platformy. Klucza nie wolno 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, przesyłanie musi odbywać się za pomocą bezpiecznego protokołu wymiany kluczy.

System operacyjny Trusty , który działa obok Androida, jest przykładem TEE, ale zamiast tego można użyć innych TEE. Trusty wykorzystuje wewnętrzny system IPC do bezpośredniej komunikacji między Keymasterem i Gatekeeperem lub odpowiednim trustletem biometrycznym. Klucz HMAC jest przechowywany wyłącznie w Keymaster; Fingerprint i Gatekeeper żądają klucza od Keymastera przy każdym użyciu i nie utrwalają ani nie buforują wartości.

Ponieważ niektóre TEE nie posiadają infrastruktury IPC, nie ma komunikacji między apletami w TEE. Pozwala to również usłudze magazynu kluczy na szybkie odrzucanie żądań, które są skazane na niepowodzenie, ponieważ ma wiedzę o tabeli uwierzytelniania w systemie, oszczędzając potencjalnie kosztowny IPC w TEE.