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.

- 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 dogatekeeperd
. - Przepływy uwierzytelniania oparte na danych biometrycznych zależą od wersji systemu Android. Na urządzeniach z systemem Android 8.x lub starszym
FingerprintService
żądanie dofingerprintd
). Na urządzeniach z systemem Android 9 lub nowszymBiometricPrompt
żądanie do odpowiedniego demona biometrycznego (na przykład pobranegofingerprintd
w przypadku odcisków palców lubfaced
w twarz) przy użyciu odpowiedniej klasyBiometric Manager
, takiej jakFingerprintManager
lubFaceManager
. Niezależnie od wersji uwierzytelnianie biometryczne odbywa się asynchronicznie po wysłaniu żądania.
- W przypadku kodu PIN, wzoru lub hasła
- 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.
- W przypadku uwierzytelniania za pomocą kodu PIN/wzoru/hasła
- 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.) - 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.
Pole | Rodzaj | Wymagany | Opis |
---|---|---|---|
Wersja tokena uwierzytelniania | 1 bajt | TAk | Pogrupuj tag dla wszystkich poniższych pól. |
Wyzwanie | 64-bitowa liczba całkowita bez znaku | Nie | Losowa liczba całkowita zapobiegająca atakom typu powtórka. Zwykle identyfikator żądanej operacji kryptograficznej. Obecnie używany przez transakcyjne autoryzacje odcisków palców. Jeśli jest obecny, AuthToken jest ważny tylko dla operacji kryptograficznych zawierających to samo wyzwanie. |
Identyfikator SID użytkownika | 64-bitowa liczba całkowita bez znaku | TAk | Niepowtarzalny identyfikator użytkownika powiązany kryptograficznie ze wszystkimi kluczami powiązanymi z uwierzytelnianiem urządzenia. Aby uzyskać szczegółowe informacje, zobacz Strażnik . |
Identyfikator uwierzytelniania (ASID) | 64-bitowa liczba całkowita bez znaku w kolejności sieci | Nie | Identyfikator używany do powiązania z określoną zasadą uwierzytelniania. Wszystkie uwierzytelniające mają własną wartość ASID, którą mogą zmieniać zgodnie z własnymi wymaganiami. |
Typ uwierzytelniania | 32-bitowa liczba całkowita bez znaku w porządku sieciowym | TAk |
|
Znak czasu | 64-bitowa liczba całkowita bez znaku w kolejności sieci | TAk | Czas (w milisekundach) od ostatniego uruchomienia systemu. |
AuthToken HMAC (SHA-256) | 256-bitowy obiekt BLOB | TAk | Klucz SHA-256 MAC wszystkich pól z wyjątkiem pola HMAC. |
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.