Portier

Podsystem Gatekeeper wykonuje uwierzytelnianie według wzorca/hasła urządzenia w środowisku Trusted Execution Environment (TEE). Gatekeeper rejestruje i weryfikuje hasła za pomocą HMAC z tajnym kluczem wspieranym sprzętowo. Ponadto Gatekeeper ogranicza kolejne nieudane próby weryfikacji i musi odrzucać żądania obsługi 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 tajnego klucza pochodzącego z TEE do podpisania poświadczenia uwierzytelnienia, które ma zostać wysłane do magazynu kluczy . Oznacza to, że zaświadczenie Gatekeeper powiadamia Keystore, że klucze powiązane z uwierzytelnianiem (na przykład klucze utworzone przez aplikacje) mogą zostać wydane do użytku przez aplikacje.

Architektura

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

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

Gatekeeper wymaga implementacji warstwy HAL Gatekeeper (w szczególności funkcji w hardware/libhardware/include/hardware/gatekeeper.h ) oraz komponentu Gatekeeper specyficznego dla TEE (opartego częściowo na pliku nagłówkowym system/gatekeeper/include/gatekeeper/gatekeeper.h która obejmuje czysto wirtualne funkcje do tworzenia/dostępu do kluczy i sygnatur obliczeniowych).

LockSettingsService żądanie (za pośrednictwem Bindera), które dociera do demona gatekeeperd w systemie operacyjnym Android. Demon gatekeeperd następnie wysyła żądanie, które dociera do swojego odpowiednika (strażnika) w TEE:

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

Wdrożenie HAL

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

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 (z wywołania do enroll ) musi mieć strukturę pokazaną w system/gatekeeper/include/gatekeeper/password_handle.h .
• Funkcja verify musi porównać podpis wygenerowany przez podane hasło i upewnić się, że pasuje on do zarejestrowanego uchwytu hasła.

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

Trusty i inne wdrożenia

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

Trusty używa wewnętrznego systemu IPC do przekazywania współdzielonego sekretu bezpośrednio między Keymaster a implementacją Trusty Gatekeepera ( Trusty Gatekeeper ). Ten wspólny tajny klucz służy do podpisywania tokenów AuthToken wysyłanych do Keystore w celu dostarczenia poświadczeń weryfikacji hasła. Trusty Gatekeeper żąda klucza od Keymastera przy każdym użyciu i nie utrwala wartości ani nie przechowuje jej w pamięci podręcznej. Wdrożenia mogą udostępniać ten sekret w dowolny 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ę C++ GateKeeper, 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, należy zapoznać się z funkcjami i komentarzami w system/gatekeeper/include/gatekeeper/gatekeeper.h . W przypadku TEE GateKeeper podstawowe obowiązki zgodnej implementacji obejmują:

• Przestrzeganie Gatekeeper HAL.
• Zwracane AuthTokens muszą być sformatowane zgodnie ze specyfikacją AuthToken (opisaną w Authentication ).
• TEE Gatekeeper musi mieć możliwość współdzielenia klucza HMAC z Keymasterem, żądając klucza przez TEE IPC na żądanie lub utrzymując poprawną pamięć podręczną wartości przez cały czas.

Bezpieczne identyfikatory użytkownika (SID)

Identyfikator SID użytkownika jest reprezentacją 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 wpisuje nowe hasło bez podawania poprzedniego. Jest to znane jako niezaufana ponowna rejestracja i w normalnych okolicznościach nie jest dozwolone przez platformę Android. Zaufana ponowna rejestracja ma miejsce, gdy użytkownik poda prawidłowe, poprzednie hasło; w takim przypadku identyfikator SID użytkownika jest migrowany do nowego uchwytu hasła, zachowując klucze, które były z nim powiązane.

Identyfikator SID użytkownika jest 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 skojarzone ze wszystkimi kluczami magazynu kluczy powiązanymi z uwierzytelnianiem (aby uzyskać szczegółowe informacje na temat formatu AuthToken i magazynu kluczy, zobacz Uwierzytelnianie ). Ponieważ niezaufane wywołanie funkcji enroll spowoduje zmianę identyfikatora SID użytkownika, wywołanie sprawi, ż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 w tym procesie zniszczą wrażliwe klucze chronione rootem.

Żądanie ograniczania

GateKeeper musi być w stanie bezpiecznie ograniczać próby siłowe na danych uwierzytelniających 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 wywoływał ponownie GateKeeper, dopóki nie upłynie limit czasu; GateKeeper nie powinien obsługiwać żądań, jeśli istnieje oczekujący limit czasu.

GateKeeper musi zapisać licznik niepowodzeń przed weryfikacją hasła użytkownika. Jeśli weryfikacja hasła się powiedzie, licznik niepowodzeń powinien zostać wyczyszczony. Zapobiega to atakom, które zapobiegają ograniczaniu przepustowości poprzez wyłączenie wbudowanej konsoli MMC (eMMC) po wykonaniu 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 korzystać z funkcji Replay Protected Memory Block (RPMB).