Od 27 marca 2025 r. zalecamy używanie android-latest-release zamiast aosp-main do kompilowania i wspołtworzenia AOSP. Więcej informacji znajdziesz w artykule o zmianach w AOSP.

Ta strona została przetłumaczona przez Cloud Translation API.

Authentication
Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

Android używa koncepcji kluczy kryptograficznych chronionych uwierzytelnianiem użytkownika, która wymaga tych komponentów:

Dostawca usług i przechowywania kluczy kryptograficznych. przechowuje klucze kryptograficzne i zapewnia standardowe procedury szyfrowania dla tych kluczy; Android obsługuje sprzętowy Keystore i Keymaster do usług kryptograficznych, w tym szyfrowanie sprzętowe do przechowywania kluczy, które może obejmować zaufane środowisko wykonawcze (TEE) lub element zabezpieczeń (SE), np. Strongbox.
Uwierzytelnianie użytkownika. potwierdzenie obecności użytkownika lub uwierzytelnienia. Android obsługuje Gatekeeper do uwierzytelniania za pomocą kodu PIN, wzoru lub hasła oraz odcisków palców do uwierzytelniania odciskiem palca. Urządzenia z Androidem 9 lub nowszym mogą używać BiometricPrompt jako jednego punktu integracji danych odcisków palców i innych danych biometrycznych. Te komponenty przekazują stan uwierzytelniania usłudze magazynu kluczy przez uwierzytelniony kanał. (system Keystore Androida na poziomie frameworku jest również obsługiwany przez usługę Keystore).

Komponenty Gatekeeper, Fingerprint i Biometric współpracują z Keystore i innymi komponentami, aby obsługiwać tokeny uwierzytelniania (AuthTokens) oparte na sprzęcie.

Rejestracja

Podczas pierwszego uruchamiania urządzenia po przywróceniu ustawień fabrycznych wszystkie uwierzytelniacze są gotowe do rejestrowania danych logowania użytkownika. Użytkownik musi najpierw zarejestrować kod PIN, wzór lub hasło w usłudze Gatekeeper. Ta początkowa rejestracja tworzy losowo wygenerowany 64-bitowy identyfikator zabezpieczeń użytkownika (SID), który służy jako identyfikator użytkownika i token zabezpieczający materiały kryptograficzne użytkownika. Ten identyfikator SID użytkownika jest powiązany z jego hasłem za pomocą kryptografii. Pomyślne uwierzytelnienie w Gatekeeperze powoduje, że tokeny uwierzytelniające zawierają identyfikator SID użytkownika dla tego hasła.

Użytkownik, który chce zmienić dane uwierzytelniające, musi podać dotychczasowe dane uwierzytelniające. Jeśli dotychczasowe dane logowania zostaną zweryfikowane, identyfikator SID użytkownika powiązany z dotychczasowymi danymi logowania zostanie przeniesiony do nowych danych logowania, co umożliwi użytkownikowi korzystanie z kluczy dostępu po zmianie danych logowania. Jeśli użytkownik nie poda istniejących danych logowania, nowe dane zostaną zarejestrowane z losowym identyfikatorem SID użytkownika. Użytkownik może uzyskać dostęp do urządzenia, ale klucze utworzone przy użyciu starego identyfikatora SID użytkownika zostaną trwale utracone. Nazywamy to niewiarygodnym rejestrowaniem.

W normalnych warunkach platforma Android nie zezwala na rejestrację niesprawdzonych aplikacji, więc większość użytkowników nigdy nie zobaczy tej funkcji. Może się tak zdarzyć, jeśli administrator urządzenia lub osoba przeprowadzająca atak zresetuje hasło.

Uwierzytelnianie

Gdy użytkownik skonfiguruje dane logowania 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 mają wspólny klucz tajny, którego używają do uwierzytelniania wiadomości.

Rysunek 1. Proces uwierzytelniania

Użytkownik podaje metodę uwierzytelniania, a powiązana usługa wysyła żądanie do powiązanego demona.
- W przypadku kodu PIN, wzoru lub hasła LockSettingsService wysyła żądanie do gatekeeperd.
- Procesy uwierzytelniania na podstawie danych biometrycznych zależą od wersji Androida. Na urządzeniach z Androidem 8.x lub starszym FingerprintService wysyła żądanie do fingerprintd. Na urządzeniach z Androidem 9 lub nowszym BiometricPrompt wysyła żądanie do odpowiedniego demona biometrycznego (na przykład fingerprintd w przypadku odcisków palców lub faced w przypadku twarzy) za pomocą odpowiedniej klasy BiometricManager, takiej jak FingerprintManager lub FaceManager. Niezależnie od wersji uwierzytelnianie biometryczne odbywa się asynchronicznie po wysłaniu żądania.
Demon wysyła dane do swojego odpowiednika, który generuje token autoryzacji:
- W przypadku uwierzytelniania za pomocą kodu PIN, wzoru lub hasła gatekeeperd wysyła hasz kodu PIN, wzoru lub hasła do Gatekeepera w TEE. Jeśli uwierzytelnianie w TEE przebiegnie pomyślnie, bramka w TEE wyśle token uwierzytelniający zawierający odpowiadający identyfikator SID użytkownika (podpisany kluczem HMAC tokenu uwierzytelniającego) do odpowiednika w systemie operacyjnym Android.
- W przypadku uwierzytelniania odciskiem palca fingerprintd nasłuchuje zdarzeń odcisku palca i wysyła dane do Fingerprint w TEE. Jeśli uwierzytelnianie w TEE się powiedzie, Fingerprint w TEE wyśle AuthToken (podpisany kluczem HMAC AuthToken) do swojego odpowiednika w systemie operacyjnym Android.
- W przypadku innych rodzajów uwierzytelniania biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzenia biometrycznego i przesyła je do odpowiedniego komponentu TEE.
Demon otrzymuje podpisany AuthToken i przekazuje go do usługi keystore za pomocą rozszerzenia interfejsu Binder usługi keystore. (gatekeeperd informuje też usługę magazynu kluczy, gdy urządzenie zostanie ponownie zablokowane i gdy zmieni się hasło do urządzenia).
Usługa klucza przechowuje tokeny uwierzytelniające i przekazuje je do Keymastera, który weryfikuje je za pomocą klucza udostępnionego bramce i obsługiwanego komponentu TEE biometrycznego. Keymaster ufa sygnaturze czasowej w tokenie jako ostatniemu czasie uwierzytelniania i na jej podstawie podejmuje decyzję o wypuszczeniu klucza (aby zezwolić aplikacji na użycie klucza).

Format AuthToken

Aby zapewnić udostępnianie tokenów i zgodność w różnych językach i komponentach, format AuthToken opisano w hw_auth_token.h. Jest to prosty protokół serializacji z polami o stałym rozmiarze.

Pole	Typ	Wymagane	Opis
Wersja AuthToken	1 bajt	Tak	Tag grupowy dla wszystkich pól poniżej.
Wyzwanie	64-bitowa liczba całkowita bez znaku	Nie	Losowa liczba całkowita zapobiegająca atakom polegającym na odtwarzaniu pakietów. Zwykle identyfikator żądanej operacji kryptograficznej. Obecnie używane przez autoryzacje transakcji. Jeśli jest obecny, AuthToken jest ważny tylko w przypadku 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. Więcej informacji znajdziesz w artykule na temat Gatekeeper.
Identyfikator uwierzytelniania (ASID)	64-bitowa liczba całkowita bez znaku w kolejności sieciowej	Nie	Identyfikator używany do wiązania z konkretną zasadą uwierzytelniania. Wszystkie authenticatory mają własny identyfikator ASID, który mogą zmieniać zgodnie ze swoimi wymaganiami.
Typ weryfikatora	32-bitowa liczba całkowita bez znaku w kolejności sieciowej	Tak	0x00 to strażnik dostępu. 0x01 to odcisk palca.
Sygnatura czasowa	64-bitowa liczba całkowita bez znaku w kolejności sieciowej	Tak	Czas (w milisekundach) od ostatniego uruchomienia systemu.
AuthToken HMAC (SHA-256)	256-bitowy blob	Tak	Kluczowy kod MAC SHA-256 wszystkich pól z wyjątkiem pola HMAC.

Proces uruchamiania urządzenia

Podczas każdego uruchamiania urządzenia klucz HMAC AuthToken musi zostać wygenerowany i udostępniony wszystkim komponentom TEE (Gatekeeper, Keymaster i obsługiwane elementy zaufania biometrycznego). Dlatego, aby zapewnić dodatkową ochronę przed atakami typu replay, klucz HMAC musi być generowany losowo za każdym razem, gdy urządzenie się restartuje.

Protokół udostępniania klucza HMAC wszystkim komponentom jest funkcją implementacji zależną od platformy. Klucz nigdy nie może być udostępniany poza TEE. Jeśli system operacyjny TEE nie ma wewnętrznego mechanizmu komunikacji między procesami (IPC) i musi przesyłać dane przez niesprawdzoną platformę, musi to zrobić za pomocą bezpiecznego protokołu wymiany kluczy.

System operacyjny Trusty, który działa obok Androida, jest przykładem TEE, ale można też użyć innych TEE. Trusty używa wewnętrznego systemu IPC do bezpośredniej komunikacji między Keymasterem a Gatekeeperem lub odpowiednim biologicznym elementem zaufania. Klucz HMAC jest przechowywany tylko w Keymasterze. Fingerprint i Gatekeeper proszą o klucz z Keymastera przy każdym użyciu i nie przechowują ani nie przechowują w pamięci podręcznej jego wartości.

Niektóre TEE nie mają infrastruktury IPC, więc nie ma komunikacji między apletami w TEE. Umożliwia to również usłudze klucza publicznego szybkie odrzucanie żądań, które z pewnością się nie udadzą, ponieważ zna ona tabelę uwierzytelniania w systemie, co pozwala zaoszczędzić na potencjalnie kosztownym przesyłaniu danych do TEE.