Authentication

Android ma koncepcję uwierzytelniaczy użytkownika, które służą do odblokowywania urządzenia i blokowania dostępu do kluczy kryptograficznych. Obejmuje to te komponenty:

  • Dostawca usług i pamięci masowej kluczy kryptograficznych. Magazyn kluczy Androida zapewnia aplikacjom usługi kryptograficzne obsługiwane sprzętowo. System Magazynu kluczy Androida na poziomie platformy jest obsługiwany przez usługę systemową keystore2. To z kolei opiera się na implementacji KeyMint (wcześniej Keymaster) dostawcy, która zapewnia, że materiał klucza jest dostępny tylko w bezpiecznym środowisku wspieranym sprzętowo, takim jak zaufane środowisko wykonawcze (TEE) lub bezpieczny element (SE), np. StrongBox.
  • Uwierzytelnianie użytkowników. potwierdzać pomyślne uwierzytelnienie 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 bezpiecznym elemencie.
    • Odcisk palca – uwierzytelnianie odciskiem palca.
    • Inne metody uwierzytelniania biometrycznego. Urządzenia z Androidem 9 lub nowszym mogą używać BiometricPrompt jako pojedynczego punktu integracji dla odcisków palców i dodatkowych danych biometrycznych.
    Te komponenty przekazują swój stan uwierzytelniania do usługi keystore2 za pomocą tokenów uwierzytelniania (AuthTokens) wspieranych sprzętowo.

Każdy z tych komponentów jest specyficzny dla dostawcy, ale implementacja dostawcy musi spełniać specyfikację interfejsu warstwy abstrakcji sprzętowej (HAL) i przejść odpowiednie testy pakietu testów dostawcy (VTS).

Implementacje dostawców są zwykle podzielone na 2 części połączone mechanizmem komunikacji dostawcy :

  • Usługa HAL działa jako proces systemowy Androida, który odbiera żądania Binder z systemu Android.
  • Zaufana aplikacja (TA) działa w bezpiecznym środowisku i wykonuje rzeczywiste bezpieczne operacje.

Rejestracja

Po pierwszym uruchomieniu urządzenia po przywróceniu ustawień fabrycznych wszystkie uwierzytelniacze są przygotowane do otrzymywania od użytkownika rejestracji danych logowania. 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 wiążący dla materiału kryptograficznego użytkownika. Ten identyfikator SID użytkownika jest kryptograficznie powiązany z hasłem użytkownika. Udane uwierzytelnienia w Gatekeeperze generują tokeny AuthToken, które zawierają identyfikator SID użytkownika dla tego hasła.

Użytkownik, który chce zmienić istniejące dane logowania, musi je podać. Jeśli istniejące dane logowania zostaną pomyślnie zweryfikowane, identyfikator SID użytkownika powiązany z istniejącymi danymi logowania zostanie przeniesiony do nowych danych logowania, co umożliwi użytkownikowi dalszy dostęp do kluczy po zmianie danych logowania.

W niektórych sytuacjach administrator urządzenia może przeprowadzić niezaufaną rejestrację, aby zarejestrować nowe dane logowania bez podawania dotychczasowych. Dzięki temu użytkownik może uzyskać dostęp do urządzenia, ale klucze utworzone w ramach starego identyfikatora SID użytkownika zostaną trwale utracone.

Uwierzytelnianie

W tej sekcji opisano 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 współdzielą (przy każdym uruchomieniu) tajny klucz HMAC, którego używają do uwierzytelniania swoich wiadomości.

Gdy użytkownik skonfiguruje dane logowania i zostanie mu przypisany identyfikator SID, może rozpocząć uwierzytelnianie, które zaczyna się, gdy użytkownik poda kod PIN, wzór, hasło, odcisk palca lub inne silne dane biometryczne. Proces uwierzytelniania

Rysunek 1. Proces uwierzytelniania

  1. 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 prośbę do gatekeeperd.
    • Procesy uwierzytelniania biometrycznego 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) przy użyciu odpowiedniej klasy BiometricManager, np. FingerprintManager lub FaceManager. Niezależnie od wersji uwierzytelnianie biometryczne odbywa się asynchronicznie po wysłaniu żądania.
  2. Usługa HAL wysyła dane do odpowiedniej aplikacji TA, która generuje token AuthToken:
    • W przypadku uwierzytelniania za pomocą kodu PIN, wzoru lub hasła gatekeeperd wysyła kod PIN, wzór lub hasło do aplikacji Gatekeeper TA w TEE za pomocą usługi Gatekeeper HAL. Jeśli uwierzytelnianie w TEE się powiedzie, Gatekeeper TA wyemituje token AuthToken zawierający odpowiedni identyfikator SID użytkownika (podpisany udostępnionym kluczem HMAC).
    • W przypadku uwierzytelniania odciskiem palca fingerprintd nasłuchuje zdarzeń związanych z odciskiem palca i wysyła dane do aplikacji zaufanej odcisku palca w TEE za pomocą HAL odcisku palca. Jeśli uwierzytelnianie w TEE się powiedzie, TA odcisku palca wygeneruje AuthToken (podpisany kluczem HMAC AuthToken).
    • W przypadku innego uwierzytelniania biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzenia biometrycznego i wysyła je do odpowiedniej usługi HAL i TA.
  3. Wynikowy podpisany token AuthToken jest przekazywany do usługi systemowej keystore2 przez interfejs Binder.
  4. Usługa keystore2 dołącza tokeny AuthToken do żądania, aby KeyMint (wcześniej Keymaster) mógł wykonywać operacje kryptograficzne. Usługa HAL KeyMint przekazuje je do TA KeyMint, który weryfikuje je za pomocą klucza HMAC udostępnionego Gatekeeperowi i obsługiwanym komponentom biometrycznym TEE. KeyMint ufa sygnaturze czasowej w tokenie jako ostatniemu czasowi uwierzytelniania i na podstawie sygnatury czasowej decyduje, czy zezwolić na użycie klucza.

Proces uwierzytelniania nie wymaga bezpośredniej komunikacji między aplikacjami zaufanymi w bezpiecznym środowisku: tokeny AuthToken są przesyłane z aplikacji zaufanej uwierzytelniającej do usługi keystore2 na Androidzie, która z kolei przekazuje je do aplikacji zaufanej KeyMint. Dzięki temu usługa keystore2 może też szybko odrzucać żądania, które na pewno się nie powiodą, ponieważ ma informacje o dostępnych w systemie tokenach AuthToken, co pozwala uniknąć potencjalnie kosztownego wywołania IPC do TEE.

Format tokenu AuthToken

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

Proces uruchamiania urządzenia

Przy każdym uruchomieniu urządzenia należy wygenerować klucz HMAC AuthToken i udostępnić go wszystkim komponentom TEE (Gatekeeper, KeyMint i obsługiwane aplikacje zaufane do biometrii). Aby zapobiec atakom typu replay, klucz HMAC musi być generowany losowo przy każdym ponownym uruchomieniu urządzenia.

Istnieją 2 typowe sposoby uzyskiwania przez asystentów dostępu do tego udostępnionego klucza HMAC:

  • Umowa dotycząca wspólnego obiektu tajnego: usługa keystore2 wykonuje wielokierunkowy protokół uzgadniania kluczy podczas uruchamiania urządzenia, co umożliwia bezpieczne wyprowadzanie klucza HMAC między uczestniczącymi aplikacjami zaufanymi. Jednak uczestniczące aplikacje TA muszą mieć dostęp do wspólnego wstępnie udostępnionego klucza tajnego.
  • Dostęp bezpośredni: aplikacje TA, które znajdują się w tym samym bezpiecznym środowisku, mogą używać wewnętrznego mechanizmu komunikacji między procesami (zależnego od platformy) do udostępniania klucza HMAC.

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

Przykładem TEE jest system operacyjny Trusty, który działa obok Androida, ale można używać innych TEE. Trusty używa wewnętrznego systemu IPC do bezpośredniej komunikacji między KeyMint a Gatekeeperem lub odpowiednią biometryczną aplikacją zaufaną. Klucz HMAC jest przechowywany wyłącznie w KeyMint. Fingerprint i Gatekeeper żądają klucza od KeyMint przy każdym użyciu i nie przechowują ani nie zapisują w pamięci podręcznej jego wartości.

Niektóre środowiska TEE nie mają infrastruktury IPC, więc nie ma komunikacji między apletami w TEE. Dzięki temu usługa magazynu kluczy może szybko odrzucać żądania, które nie zostaną zrealizowane, ponieważ ma informacje o tabeli uwierzytelniania w systemie, co pozwala uniknąć potencjalnie kosztownego wywołania IPC w TEE.