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

Android wykorzystuje koncepcję uwierzytelniania użytkowników, która służy do odblokowywania urządzenia i kontrolowania dostępu do kluczy kryptograficznych. Obejmuje to te komponenty:

Dostawca usług i przechowywania kluczy kryptograficznych. Keystore na Androidzie zapewnia usługi kryptograficzne oparte na sprzęcie dla aplikacji. System Android Keystore na poziomie platformy jest obsługiwany przez usługę systemową keystore2. Jest ono oparte na implementacji KeyMint (wcześniej Keymaster) konkretnego dostawcy, która zapewnia, że materiały kluczowe są dostępne tylko w środowisku zabezpieczonym sprzętowo, takim jak zaufane środowisko wykonawcze (TEE) lub element zabezpieczeń (SE).
Uwierzytelnianie użytkownika. potwierdzenie prawidłowego uwierzytelnienia użytkownika; Android obsługuje te komponenty uwierzytelniania:
- Gatekeeper do uwierzytelniania za pomocą kodu PIN, wzoru lub hasła w TEE.
- (Opcjonalnie) Weaver do uwierzytelniania za pomocą kodu PIN, wzoru lub hasła w elementach zabezpieczonych.
- Odcisk palca do uwierzytelniania odciskiem palca.
- inne metody uwierzytelniania biometrycznego. Urządzenia z Androidem 9 lub nowszym mogą używać BiometricPrompt jako jednego punktu integracji odcisków palców i dodatkowych danych biometrycznych.
Te komponenty przekazują stan uwierzytelniania usłudze keystore2 za pomocą tokenów uwierzytelniania (AuthTokens) opartych na sprzęcie .

Każdy z tych komponentów jest specyficzny dla dostawcy, ale jego implementacja musi spełniać wymagania specyfikacji interfejsu Hardware Abstraction Layer (HAL) i przejść odpowiednie zestawy testów dostawcy (VTS).

Wdrożenia dostawców są zwykle podzielone na 2 części połączone mechanizmem komunikacji właściwym dla danego dostawcy :

Usługa HAL działa jako proces systemowy Androida i odbiera żądania Bindera z systemu Androida.
Zaufana aplikacja działa w bezpiecznym środowisku, wykonując rzeczywiste operacje zabezpieczone.

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 (lub Weaver, jeśli jest dostępna). Ta początkowa rejestracja tworzy losowo wygenerowany 64-bitowy bezpieczny identyfikator 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 Gatekeeper powoduje utworzenie tokenów uwierzytelniania zawierających identyfikator SID użytkownika dla tego hasła.

Użytkownik, który chce zmienić dotychczasowe dane uwierzytelniające, musi je podać. Jeśli dotychczasowe dane logowania zostaną zweryfikowane, identyfikator SID użytkownika powiązany z tych danych zostanie przeniesiony do nowych danych, co umożliwi użytkownikowi dalsze korzystanie z kluczy po zmianie danych logowania.

W niektórych sytuacjach administrator urządzenia może wykonać rejestrację z niezaufanego urządzenia, aby zarejestrować nowe dane logowania bez przedstawiania istniejących danych. Dzięki temu użytkownik będzie mieć dostęp do urządzenia, ale klucze utworzone na podstawie starego identyfikatora SID użytkownika zostaną trwale utracone.

Uwierzytelnianie

W tej sekcji opisujemy typowy proces uwierzytelniania, który obejmuje interakcje między wieloma komponentami zarówno w Androidzie, jak i w bezpiecznym środowisku. Pamiętaj, że wszystkie bezpieczne komponenty mają wspólny tajny klucz HMAC (na potrzeby uruchamiania), którego używają do uwierzytelniania wiadomości wysyłanych do siebie nawzajem.

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, odcisk palca lub inną silną metodę biometryczną. Proces uwierzytelniania

Rysunek 1. Proces uwierzytelniania

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 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 (np. 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.
Usługa HAL wysyła dane do usługi TA, która generuje token autoryzacji:
- W przypadku uwierzytelniania za pomocą kodu PIN, wzoru lub hasła gatekeeperd wysyła do usługi Gatekeeper HAL w TEE hasz kodu PIN, wzoru lub hasła za pomocą usługi Gatekeeper HAL. Jeśli uwierzytelnianie w TEE przebiegnie pomyślnie, gatekeeper TA wyemituje token uwierzytelniający zawierający odpowiadający identyfikator SID użytkownika (podpisany wspólnym kluczem HMAC).
- W przypadku uwierzytelniania odciskiem palca fingerprintd nasłuchuje zdarzeń odcisku palca i wysyła dane do interfejsu sterującego odciskiem palca w TEE za pomocą interfejsu sterującego Fingerprint HAL. Jeśli uwierzytelnianie w TEE się powiedzie, element Fingerprint TA wyemituje AuthToken (podpisany kluczem HMAC AuthToken).
- W przypadku innych metod uwierzytelniania biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzeń biometrycznych i przesyła je do odpowiedniej usługi HAL i TA.
Wygenerowany podpisany token AuthToken jest przekazywany do usługi systemowej keystore2 za pomocą interfejsu Binder.
Usługa keystore2 dołącza tokeny autoryzacji do żądania KeyMint (wcześniej Keymaster) w celu wykonania operacji kryptograficznych. Usługa KeyMint HAL przekazuje je do usługi KeyMint TA, która weryfikuje je za pomocą klucza HMAC udostępnionego bramce i obsługiwanym komponentom TEE biometrycznego. KeyMint ufa sygnaturze czasowej w tokenie jako ostatniemu czasowi uwierzytelniania. Na jej podstawie decyduje, czy zezwolić na użycie klucza.

Proces uwierzytelniania nie wymaga bezpośredniej komunikacji między TA w bezpiecznym środowisku: tokeny uwierzytelniania są przesyłane z TA uwierzytelniania do usługi keystore2 w Androidzie, która przekazuje je TA KeyMint. Umożliwia to też usłudze keystore2 szybkie odrzucanie żądań, które z pewnością się nie udadzą, ponieważ usługa zna dostępne tokeny autoryzacji w systemie, co pozwala zaoszczędzić na potencjalnie kosztownej komunikacji między procesorami.

Format AuthToken

Format tokena autoryzacji jest określony w specyfikacji AIDL w HardwareAuthToken.aidl.

Proces uruchamiania urządzenia

Podczas każdego uruchamiania urządzenia klucz HMAC AuthToken musi zostać wygenerowany i udostępniony wszystkim komponentom TEE (Gatekeeper, KeyMint/Keymaster i obsługiwanym komponentom szyfrowania biometrycznego). Aby zapobiec atakom typu replay, klucz HMAC musi być generowany losowo za każdym razem, gdy urządzenie jest ponownie uruchamiane.

Istnieją 2 najczęstsze sposoby, w jakich administratorzy pomocy technicznej uzyskują dostęp do tego udostępnionego klucza HMAC:

Ustalanie wspólnych kluczy tajnych: usługa keystore2 przeprowadza wielokierunkowy protokół uzgadniania kluczy podczas uruchamiania urządzenia, co umożliwia bezpieczne wyprowadzenie klucza HMAC między uczestniczącymi w tym procesie usługami TA. Uczestniczący w programie trenerzy asystujący muszą jednak mieć dostęp do wspólnego, udostępnionego wcześniej sekretu.
Dostęp bezpośredni: komponenty typu „trusted application” znajdujące się w tym samym bezpiecznym środowisku mogą używać wewnętrznego mechanizmu komunikacji między procesami (który zależy od platformy) do udostępniania klucza HMAC.

W obu przypadkach klucz HMAC nigdy nie może być dostępny poza TEE.

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