Portier

Podsystem Gatekeeper przeprowadza uwierzytelnianie za pomocą wzorca / hasła urządzenia w Trusted Execution Environment (TEE). Gatekeeper rejestruje i weryfikuje hasła za pośrednictwem HMAC z zabezpieczonym sprzętowo tajnym kluczem. Ponadto Gatekeeper ogranicza kolejne nieudane próby weryfikacji i musi odmawiać obsługi żądań na podstawie określonego limitu czasu i określonej liczby kolejnych nieudanych prób.

Gdy użytkownicy weryfikują swoje hasła, Gatekeeper używa wspólnego klucza tajnego pochodzącego z TEE do podpisania poświadczenia uwierzytelnienia i wysłania go do magazynu kluczy wspieranego sprzętowo . Oznacza to, że poświadczenie Gatekeeper powiadamia Keystore, że klucze powiązane z uwierzytelnianiem (na przykład klucze utworzone przez aplikacje) mogą zostać zwolnione do użytku przez aplikacje.

Architektura

Gatekeeper składa się z trzech głównych elementów:

  • gatekeeperd (demon Gatekeeper). Usługa segregatora C ++ zawierająca logikę niezależną od platformy i odpowiadająca interfejsowi Java GateKeeperService .
  • Warstwa abstrakcji sprzętu Gatekeeper (HAL) . Interfejs HAL w hardware/libhardware/include/hardware/gatekeeper.h oraz moduł implementujący.
  • Gatekeeper (TEE) . Odpowiednik TEE gatekeeperd . Oparta na TEE implementacja Gatekeepera.

Gatekeeper wymaga implementacji Gatekeeper HAL (szczególnie funkcji w hardware/libhardware/include/hardware/gatekeeper.h ) i specyficznego dla TEE komponentu Gatekeeper (opartego częściowo na pliku nagłówkowym system/gatekeeper/include/gatekeeper/gatekeeper.h który obejmuje czyste funkcje wirtualne do tworzenia / uzyskiwania dostępu do kluczy i podpisów komputerowych).

LockSettingsService żądanie (za pośrednictwem programu Binder), które dociera do demona gatekeeperd w systemie operacyjnym Android. Następnie demon gatekeeperd wysyła żądanie, które dociera do swojego odpowiednika (Gatekeeper) w TEE:

Przepływ przez strażników
Rysunek 1. Przepływ danych wysokiego poziomu do uwierzytelniania przez GateKeeper

Demon gatekeeperd zapewnia interfejsom API platformy Android dostęp do warstwy HAL i uczestniczy w raportowaniu uwierzytelnień urządzeń do magazynu kluczy. Demon gatekeeperd działa we własnym procesie i jest niezależny od serwera systemowego.

Wdrożenie HAL

Demon gatekeeperd używa warstwy HAL do interakcji z odpowiednikiem TEE demona gatekeeperd w celu uwierzytelnienia hasła. Implementacja HAL musi mieć możliwość podpisywania (rejestrowania) i weryfikowania obiektów blob. Oczekuje się, że wszystkie implementacje będą zgodne ze standardowym formatem tokena uwierzytelniania (AuthToken) generowanego po każdej pomyślnej weryfikacji hasła. Aby uzyskać szczegółowe informacje na temat zawartości i semantyki AuthToken, zobacz format AuthToken .

Implementacje pliku nagłówkowego hardware/libhardware/include/hardware/gatekeeper.h muszą implementować funkcje enroll i verify :

  • Funkcja enroll pobiera obiekt blob hasła, podpisuje go i zwraca podpis jako uchwyt. Zwrócony obiekt BLOB (od wywołania do enroll ) musi mieć strukturę pokazaną w system/gatekeeper/include/gatekeeper/password_handle.h .
  • Funkcja verify musi porównać podpis utworzony przez podane hasło i upewnić się, że jest zgodny z zarejestrowanym uchwytem hasła.

Klucz używany do rejestracji i weryfikacji nigdy nie może się zmieniać i powinien być możliwy do ponownego wyprowadzenia przy każdym uruchomieniu urządzenia.

Trusty i inne realizacje

System operacyjny Trusty jest zaufanym systemem operacyjnym Google typu open source dla środowisk TEE i zawiera zatwierdzoną implementację GateKeepera. Jednak można użyć dowolnego systemu operacyjnego TEE do implementacji Gatekeepera, o ile TEE ma dostęp do klucza sprzętowego i bezpiecznego, monotonicznego zegara, który tyka podczas wstrzymania .

Trusty używa wewnętrznego systemu IPC do przekazywania wspólnego sekretu bezpośrednio między Keymasterem a Trusty implementacją Gatekeepera ( Trusty Gatekeeper ). To wspólne hasło służy do podpisywania AuthTokens wysyłanych do Keystore w celu zapewnienia poświadczeń weryfikacji hasła. Trusty Gatekeeper żąda klucza od Keymaster przy każdym użyciu i nie utrwala ani nie buforuje wartości. Implementacje mogą udostępniać ten sekret w jakikolwiek sposób, który nie zagraża bezpieczeństwu.

Klucz HMAC używany do rejestrowania i weryfikowania haseł jest uzyskiwany i przechowywany wyłącznie w GateKeeper.

Android zapewnia ogólną implementację GateKeepera w języku C ++, która wymaga tylko dodania procedur specyficznych dla urządzenia, aby była kompletna. Aby wdrożyć TEE Gatekeeper z kodem specyficznym dla urządzenia dla TEE, zapoznaj się z funkcjami i komentarzami w system/gatekeeper/include/gatekeeper/gatekeeper.h . system/gatekeeper/include/gatekeeper/gatekeeper.h W przypadku TEE GateKeeper do podstawowych obowiązków zgodnej implementacji należy:

  • Przestrzeganie HAL strażnika bram.
  • Zwracane AuthTokens muszą być sformatowane zgodnie ze specyfikacją AuthToken (opisaną w sekcji Uwierzytelnianie ).
  • TEE Gatekeeper musi mieć możliwość współdzielenia klucza HMAC z Keymaster poprzez żądanie klucza przez TEE IPC na żądanie lub utrzymywanie ważnej pamięci podręcznej wartości przez cały czas.

Bezpieczne identyfikatory użytkowników (SID)

Identyfikator SID użytkownika to reprezentacja TEE użytkownika (bez silnego połączenia z identyfikatorem użytkownika Androida). Identyfikator SID jest generowany za pomocą kryptograficznego generatora liczb pseudolosowych (PRNG) za każdym razem, gdy użytkownik rejestruje nowe hasło bez podawania poprzedniego. Jest to znane jako niezaufana ponowna rejestracja i nie jest dozwolone przez platformę Android w normalnych okolicznościach. Zaufana ponowna rejestracja ma miejsce, gdy użytkownik poda prawidłowe, poprzednie hasło; w tym przypadku identyfikator SID użytkownika jest migrowany do nowego uchwytu hasła, zachowując klucze, które zostały z nim powiązane.

Identyfikator SID użytkownika jest zapisywany w postaci HMAC wraz z hasłem w uchwycie hasła, gdy hasło jest rejestrowane.

Identyfikatory SID użytkowników są zapisywane w AuthToken zwracanym przez funkcję verify i są powiązane ze wszystkimi kluczami magazynu kluczy powiązanymi z uwierzytelnianiem (szczegółowe informacje na temat formatu AuthToken i magazynu kluczy można znaleźć w sekcji Uwierzytelnianie ). Ponieważ niezaufane wywołanie funkcji enroll zmieni identyfikator SID użytkownika, wywołanie spowoduje, że klucze powiązane z tym hasłem będą bezużyteczne. Atakujący mogą zmienić hasło do urządzenia, jeśli kontrolują system operacyjny Android, ale przy okazji zniszczą poufne klucze chronione przez roota.

Poproś o ograniczenie przepustowości

GateKeeper musi być w stanie bezpiecznie ograniczać próby brutalnej siły na poświadczeniach użytkownika. Jak pokazano w hardware/libhardware/include/hardware/gatekeeper.h , warstwa HAL zapewnia zwracanie limitu czasu w milisekundach. Limit czasu informuje klienta, aby nie dzwonił ponownie do GateKeepera, dopóki nie upłynie limit czasu; GateKeeper nie powinien obsługiwać żądań, jeśli jest oczekiwany limit czasu.

GateKeeper musi zapisać licznik błędów przed zweryfikowaniem hasła użytkownika. Jeśli weryfikacja hasła powiedzie się, licznik błędów powinien zostać wyczyszczony. Zapobiega to atakom, które zapobiegają ograniczaniu przepustowości, wyłączając wbudowaną konsolę MMC (eMMC) po wysłaniu wywołania verify . Funkcja enroll weryfikuje również hasło użytkownika (jeśli zostało podane) i musi być ograniczana w ten sam sposób.

Jeśli jest obsługiwane przez urządzenie, zdecydowanie zaleca się zapisanie licznika awarii w celu bezpiecznego przechowywania. Jeśli urządzenie nie obsługuje szyfrowania opartego na plikach lub jeśli bezpieczne przechowywanie jest zbyt wolne, implementacje mogą bezpośrednio używać funkcji Replay Protected Memory Block (RPMB).