Portier

Podsystem Gatekeeper przeprowadza uwierzytelnianie według wzoru urządzenia/hasła w zaufanym środowisku wykonawczym (TEE). Gatekeeper rejestruje i weryfikuje hasła za pośrednictwem HMAC z tajnym kluczem sprzętowym. Dodatkowo Gatekeeper ogranicza kolejne nieudane próby weryfikacji i musi odmówić obsługi żądań w oparciu o określony limit czasu i określoną liczbę kolejnych nieudanych prób.

Gdy użytkownicy weryfikują swoje hasła, Gatekeeper wykorzystuje wspólny sekret uzyskany z TEE do podpisania poświadczenia uwierzytelnienia i wysłania go do magazynu kluczy wspieranego sprzętowo . Oznacza to, że zaświadczenie strażnika powiadamia magazyn kluczy, że klucze powiązane z uwierzytelnianiem (na przykład klucze utworzone przez aplikacje) mogą zostać udostępnione do użytku przez aplikacje.

Architektura

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

• gatekeeperd (demon strażnika). Usługa segregatora 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 i moduł implementujący.
• Strażnik (TEE) . Odpowiednik gatekeeperd w TEE. Implementacja Gatekeepera oparta na TEE.

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

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

Rysunek 1. Wysoki poziom przepływu danych do uwierzytelnienia 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 w ramach własnego procesu i jest niezależny od serwera systemowego.

Implementacja HAL-a

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 uwierzytelniającego (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 z hasłem, 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 utworzony przez podane hasło i upewnić się, że jest zgodny z zarejestrowanym uchwytem hasła.

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

Trusty i inne wdrożenia

System operacyjny Trusty to zaufany system operacyjny Google o otwartym kodzie źródłowym dla środowisk TEE i zawiera zatwierdzoną implementację GateKeeper. Można jednak użyć dowolnego systemu operacyjnego TEE do wdrożenia Gatekeepera, pod warunkiem, że TEE ma dostęp do klucza sprzętowego i bezpiecznego, monotonicznego zegara tykającego w stanie zawieszenia .

Trusty korzysta z wewnętrznego systemu IPC do przekazywania wspólnego sekretu bezpośrednio pomiędzy Keymasterem a implementacją Gatekeepera Trusty ( Trusty Gatekeeper ). Ten wspólny sekret służy do podpisywania tokenów AuthToken wysyłanych do magazynu kluczy w celu zapewnienia poświadczeń weryfikacji hasła. Trusty Gatekeeper żąda klucza od Keymastera przy każdym użyciu i nie utrwala ani nie buforuje wartości. 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 programie GateKeeper.

Android zapewnia ogólną implementację GateKeepera w języku C++, która do ukończenia wymaga jedynie dodania procedur specyficznych dla urządzenia. Aby zaimplementować TEE Gatekeepera z kodem specyficznym dla urządzenia dla Twojego TEE, zapoznaj się z funkcjami i komentarzami w system/gatekeeper/include/gatekeeper/gatekeeper.h . W przypadku TEE GateKeepera podstawowe obowiązki związane z wdrożeniem zgodnym z przepisami obejmują:

• Przestrzeganie Gatekeepera HAL.
• Zwracane AuthTokeny muszą być sformatowane zgodnie ze specyfikacją AuthToken (opisaną w Uwierzytelnianiu ).
• TEE Gatekeeper musi być w stanie udostępnić klucz HMAC firmie Keymaster, wysyłając żądanie klucza za pośrednictwem TEE IPC na żądanie lub utrzymując przez cały czas prawidłową pamięć podręczną wartości.

Bezpieczne identyfikatory użytkownika (SID)

Identyfikator SID użytkownika to reprezentacja użytkownika w formacie TEE (bez silnego połączenia z identyfikatorem użytkownika systemu Android). Identyfikator SID jest generowany za pomocą kryptograficznego generatora liczb pseudolosowych (PRNG) za każdym razem, gdy użytkownik zarejestruje nowe hasło bez podawania poprzedniego. Nazywa się to niezaufaną ponowną rejestracją i w normalnych okolicznościach nie jest dozwolone w systemie Android. Zaufana ponowna rejestracja ma miejsce, gdy użytkownik poda ważne, poprzednie hasło; w tym przypadku identyfikator SID użytkownika jest migrowany do nowego uchwytu hasła, zachowując powiązane z nim klucze.

Identyfikator SID użytkownika jest zapisywany w HMAC wraz z hasłem w uchwycie hasła podczas rejestrowania hasła.

Identyfikatory SID użytkownika są zapisywane w AuthToken zwracanym przez funkcję verify i powiązane ze wszystkimi kluczami magazynu kluczy związanymi z uwierzytelnianiem (więcej informacji 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 sprawi, że klucze powiązane z tym hasłem staną się bezużyteczne. Osoby atakujące mogą zmienić hasło do urządzenia, jeśli kontrolują system operacyjny Android, ale przy okazji zniszczą chronione przez roota, wrażliwe klucze.

Poproś o ograniczenie przepustowości

GateKeeper musi być w stanie bezpiecznie dławić próby użycia siły na poświadczeniach użytkownika. Jak pokazano w hardware/libhardware/include/hardware/gatekeeper.h , warstwa HAL umożliwia zwrócenie limitu czasu w milisekundach. Limit czasu informuje klienta, aby nie wywoływał ponownie GateKeepera przed upływem limitu czasu; GateKeeper nie powinien obsługiwać żądań, jeśli upłynął limit czasu oczekiwania.

GateKeeper musi zapisać licznik błędów przed zweryfikowaniem hasła użytkownika. Jeżeli weryfikacja hasła powiedzie się, licznik błędów powinien zostać wyczyszczony. Zapobiega to atakom uniemożliwiającym dławienie poprzez wyłączenie wbudowanej karty MMC (eMMC) po wykonaniu wywołania verify . Funkcja enroll weryfikuje również hasło użytkownika (jeśli zostało podane) i musi być ograniczane w ten sam sposób.

Jeśli jest to obsługiwane przez urządzenie, zdecydowanie zaleca się zapisanie licznika błędów 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 bloku pamięci Replay Protected Memory Block (RPMB).