Poświadczenie

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

  • Dostawca usług i przechowywania kluczy kryptograficznych. Przechowuje klucze kryptograficzne i zapewnia standardowe procedury kryptograficzne na wierzchu tych kluczy. Android obsługuje sprzętowy magazyn kluczy i narzędzie Keymaster dla usług kryptograficznych, w tym sprzętową kryptografię do przechowywania kluczy, która może obejmować Trusted Execution Environment (TEE) lub Secure Element (SE), na przykład Strongbox.
  • Autoryzatory użytkownika. Potwierdź obecność użytkownika i / lub pomyślne uwierzytelnienie. Android obsługuje Gatekeeper do uwierzytelniania za pomocą kodu PIN / wzoru / hasła oraz odcisku palca 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 przekazują swój stan uwierzytelniania z usługą magazynu kluczy za pośrednictwem uwierzytelnionego kanału. (System Android Keystore na poziomie platformy jest również obsługiwany przez usługę magazynu kluczy).

Składniki Gatekeeper, Fingerprint i Biometric współpracują z Keystore i innymi składnikami, aby obsługiwać sprzętowe tokeny uwierzytelniania (AuthTokens).

Rekrutacja

Przy pierwszym uruchomieniu urządzenia po przywróceniu ustawień fabrycznych wszystkie podmioty uwierzytelniające są przygotowane do otrzymania rejestracji poświadczeń od użytkownika. Użytkownik musi najpierw zarejestrować kod PIN / wzór / hasło w Gatekeeper. 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 wiążący token dla materiału kryptograficznego użytkownika. Ten identyfikator SID użytkownika jest kryptograficznie powiązany z hasłem użytkownika; pomyślne uwierzytelnienia w Gatekeeper skutkują 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 utrzymanie 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 zostaną trwale utracone. Jest to znane jako 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 wymuszone resetowanie haseł przez administratora urządzenia lub osobę atakującą może spowodować taką sytuację.

Poświadczenie

Po skonfigurowaniu poświadczenia i otrzymaniu identyfikatora SID użytkownika użytkownik 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.

Przepływ uwierzytelniania
Rysunek 1. Przebieg uwierzytelniania
  1. Użytkownik zapewnia 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 Androidem 8.xi starszym usługa FingerprintService żądanie do fingerprintd ). Na urządzeniach z Androidem 9 i nowszym BiometricPrompt żądanie do odpowiedniego demona biometrycznego (na przykład fingerprintd dla 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 następuje asynchronicznie po wysłaniu żądania.
  2. Demon wysyła dane do swojego odpowiednika, który generuje AuthToken:
    • W celu uwierzytelnienia za pomocą kodu PIN / wzoru / hasła gatekeeperd wysyła kod PIN, wzór lub skrót hasła do Gatekeeper 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 fingerprintd nasłuchuje zdarzeń związanych z odciskami palców i wysyła dane do linii papilarnych w TEE. Jeśli uwierzytelnianie w TEE powiedzie się, odcisk palca w TEE wysyła AuthToken (podpisany kluczem HMAC AuthToken) do swojego odpowiednika w systemie operacyjnym Android.
    • W przypadku innego uwierzytelnienia biometrycznego odpowiedni demon biometryczny nasłuchuje zdarzenia biometrycznego i wysyła je do odpowiedniego składnika biometrycznego TEE.
  3. Demon otrzymuje podpisany AuthToken i przekazuje go do usługi magazynu kluczy za pośrednictwem rozszerzenia do interfejsu Binder usługi magazynu kluczy. ( gatekeeperd powiadamia również usługę magazynu kluczy o ponownym gatekeeperd urządzenia i zmianie hasła urządzenia).
  4. Usługa magazynu kluczy przekazuje AuthTokens do Keymaster i weryfikuje je za pomocą klucza współdzielonego z Gatekeeperem i obsługiwanego biometrycznego komponentu TEE. Keymaster ufa sygnaturze czasowej w tokenie jako ostatnim czasie uwierzytelniania i opiera decyzję o wydaniu klucza (aby zezwolić aplikacji na użycie klucza) na podstawie sygnatury czasowej.

Format AuthToken

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 AuthToken 1 bajt tak Znacznik grupowy dla wszystkich poniższych pól.
Wyzwanie 64-bitowa liczba całkowita bez znaku Nie Losowa liczba całkowita zapobiegająca atakom powtórkowym. 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 Niepowtarzający się identyfikator użytkownika powiązany kryptograficznie ze wszystkimi kluczami związanymi z uwierzytelnianiem urządzenia. Aby uzyskać szczegółowe informacje, zobacz Gatekeeper .
Identyfikator uwierzytelniającego (ASID) 64-bitowa liczba całkowita bez znaku w porządku sieciowym Nie Identyfikator używany do powiązania z określoną polityką uwierzytelniającą. Wszystkie osoby uwierzytelniające mają własną wartość ASID, którą mogą zmieniać zgodnie z własnymi wymaganiami.
Typ uwierzytelniacza 32-bitowa liczba całkowita bez znaku w porządku sieciowym tak
  • 0x00 to Gatekeeper.
  • 0x01 to odcisk palca.
Znak czasu 64-bitowa liczba całkowita bez znaku w porządku sieciowym tak Czas (w milisekundach) od ostatniego uruchomienia systemu.
AuthToken HMAC (SHA-256) 256-bitowy obiekt BLOB tak Kluczowane SHA-256 MAC dla wszystkich pól z wyjątkiem pola HMAC.

Przebieg 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ługiwanym trustletom biometrycznym). W związku z tym, aby zapewnić dodatkową ochronę przed atakami typu replay, klucz HMAC musi być generowany losowo przy każdym ponownym uruchomieniu urządzenia.

Protokół udostępniania tego klucza HMAC wszystkim komponentom jest funkcją implementacji zależną od platformy. Nigdy nie wolno udostępniać klucza 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, transfer musi odbywać się za pośrednictwem bezpiecznego protokołu wymiany kluczy.

System operacyjny Trusty , który działa obok Androida, jest przykładem TEE, ale zamiast niego można użyć innych TEE. Trusty używa wewnętrznego systemu IPC do bezpośredniej komunikacji między Keymasterem a Gatekeeperem lub odpowiednim biometrycznym trustletem. Klucz HMAC jest przechowywany wyłącznie w Keymaster; Fingerprint i Gatekeeper żądają klucza od Keymaster 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. Umożliwia to również usłudze magazynu kluczy szybkie odrzucanie żądań, które są skazane na niepowodzenie, ponieważ posiada wiedzę o tabeli uwierzytelniania w systemie, oszczędzając potencjalnie kosztownego IPC w TEE.