Weaver

Wprowadzona w Androidzie 8.1 warstwa abstrakcji sprzętowej (HAL) Weaver (IWeaver.aidl) zapewnia bezpieczny interfejs do uwierzytelniania użytkowników za pomocą czynnika wiedzy o ekranie blokady (LSKF), takiego jak kod PIN, wzór lub hasło.

Weaver zastępuje funkcję weryfikacji LSKF w Gatekeeperze. Gatekeeper jest jednak nadal używany do generowania tokenów uwierzytelniania sprzętowego.

W Androidzie 9 i nowszych wersjach, CDD 9.11.2 wymaga, aby urządzenia obsługujące StrongBox miały dedykowany bezpieczny sprzęt, który obsługuje bezpieczne uwierzytelnianie użytkowników. Wdrożenie HAL Weaver przy użyciu tego bezpiecznego sprzętu spełnia wymaganie „bezpiecznego uwierzytelniania użytkowników”.

Na urządzeniach bez dedykowanego bezpiecznego elementu (SE), Weaver można nadal implementować w zaufanym środowisku wykonawczym (TEE), takim jak Trusty.

Komponenty

Weaver składa się z 3 komponentów:

  • Interfejs Weaver AIDL (IWeaver): formalna specyfikacja HAL. W Androidzie 13 i starszych wersjach zamiast AIDL używano HIDL.
  • Usługa warstwy abstrakcji sprzętowej (HAL) Weaver: proces Androida specyficzny dla dostawcy, który implementuje IWeaver interfejs.
  • Zaufana aplikacja Weaver (TA): Podstawowa logika działająca w bezpiecznym środowisku. Przeprowadza weryfikację LSKF i wymusza ograniczenie szybkości. Usługa HAL komunikuje się z TA za pomocą bezpiecznego kanału specyficznego dla implementacji.

Interfejs

Interfejs Weavera to tablica o stałym rozmiarze zawierająca trwałe sloty, z których każdy zawiera klucz i wartość o stałym rozmiarze. Każdy slot jest identyfikowany przez swój identyfikator, czyli liczbę całkowitą z przedziału [0, numSlots - 1]. Wartość slotu jest dostępna tylko wtedy, gdy podany klucz pasuje do zapisanego klucza.

Interfejs Weavera składa się z tych elementów:

  • getConfig(): pobiera liczbę slotów, rozmiar klucza i rozmiar wartości obsługiwane przez implementację.
  • write(): zastępuje określony slot nową parą klucz-wartość. Ta operacja jest niepodzielna i sprawia, że poprzednie dane są trwale nieodzyskiwalne (bezpieczne usunięcie).
  • read(): próbuje pobrać wartość określonego slotu. Ta operacja się powiedzie tylko wtedy, gdy nie jest aktywny limit czasu ograniczenia szybkości (wymuszany przez TA) nie jest aktywny, a podany klucz dokładnie pasuje do zapisanego klucza.

Pełną specyfikację interfejsu znajdziesz w pliku IWeaver.aidl.

Użycie w Androidzie

Gdy dostępna jest implementacja Weavera, LockSettingsService na serwerze systemu Android używa jej do ochrony danych użytkownika. W przypadku każdego użytkownika na urządzeniu LockSettingsService zarządza slotem Weavera:

  • Klucz slotu (weaverKey): skrót LSKF użytkownika. Jeśli użytkownik nie ma blokady ekranu, używany jest ciąg domyślny.
  • Wartość slotu (weaverSecret): losowo wygenerowany sekret kryptograficzny o wysokiej entropii.

Wartość weaverSecret można pobrać tylko w jeden z tych sposobów:

  • Podanie prawidłowego weaverKey do TA Weavera w ramach jego zasad ograniczenia szybkości.
  • Naruszanie bezpieczeństwa środowiska, w którym działa TA Weavera. Ma to być bardzo trudne.

LockSettingsService używa zarówno klucza weaverKey, jak i wartości weaverSecret do szyfrowania syntetycznego hasła użytkownika. Ponieważ syntetyczne hasło chroni zaszyfrowany za pomocą klucza poświadczeń (CE) magazyn użytkownika na potrzeby szyfrowania opartego na plikach (FBE) oraz klucze powiązane z uwierzytelnianiem użytkownika w magazynie kluczy Androida, dane pozostają niedostępne, dopóki Weaver nie udostępni sekretu.

Weaver a Gatekeeper

W przeszłości HAL Gatekeepera pełnił 2 odrębne role w ramach jednego wywołania verify():

  1. Weryfikacja: sprawdzanie LSKF z ograniczeniem szybkości wymuszanym przez TEE.
  2. Atestowanie: wydawanie tokena HardwareAuthToken w celu powiadomienia KeyMint (wcześniej Keymaster), że uwierzytelnianie LSKF się powiodło.

Dlaczego przechodzimy na Weavera?

Wraz z wprowadzeniem bezpiecznych tokenów resetowania hasła w Androidzie 8.1 „syntetyczne hasło” stało się głównym sekretem kryptograficznym. Obie opisane powyżej role są teraz obsługiwane przez oddzielne rejestracje Gatekeepera – jedną dla LSKF pod adresem userId + 100000 i jedną dla syntetycznego hasła pod adresem userId.

Weaver został wprowadzony, aby przejąć pierwszą rolę, używając prostszego interfejsu HAL z obsługą implementacji opartych na bezpiecznym elemencie (SE).

Funkcja Weaver Gatekeeper
Bezpieczne usuwanie Bezpieczne usuwanie jest wymagane i łatwe do wdrożenia, ponieważ interfejs używa stałej liczby slotów o stałym rozmiarze. Bezpieczne usuwanie nie jest wymagane i jest trudne do wdrożenia ponieważ interfejs obsługuje nieograniczoną liczbę rejestracji.
Sprzęt Zoptymalizowany pod kątem SE, ale działa też w TEE. Działa tylko w TEE. Wdrożenie go w SE nie zapewnia korzyści w zakresie bezpieczeństwa w obecnej wersji.
Obsługa błędów Bardziej przejrzyste kody błędów Niejednoznaczne kody błędów. W rezultacie ekran blokady nie rozróżnia nieprawidłowych LSKF od niezwiązanych z nimi awarii.
Niepodzielność Kod w LockSettingsService, który używa Weavera, wykonuje zmiany LSKF niepodzielnie. Nowe dane są zapisywane w nowym slocie Weavera, a stary slot jest usuwany tylko wtedy, gdy jest to bezpieczne. Kod w LockSettingsService, który używa Gatekeepera , nie wykonuje zmian LSKF niepodzielnie. Jeśli podczas zmiany LSKF wystąpi problem, wszystkie dane użytkownika mogą zostać utracone.

Kod referencyjny

Kod referencyjny implementacji Weavera w bezpiecznych elementach zgodnych z ISO/IEC7816-4 jest dostępny w AOSP: external/libese/.

Testowanie

Aby sprawdzić implementację Weavera, użyj VtsHalWeaverTargetTest: 

atest VtsHalWeaverTargetTest

lub:

vts-tradefed run vts -m VtsHalWeaverTargetTest