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. Implementacja 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.

W Androidzie 17 i nowszych wersjach zdecydowanie zalecamy implementację Weavera nawet na urządzeniach bez dedykowanego bezpiecznego elementu.

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 HAL Weaver: proces Androida specyficzny dla dostawcy, który implementuje IWeaver interfejs.
  • Zaufana aplikacja Weaver (TA): podstawowa logika działająca w bezpiecznym środowisku. Wykonuje weryfikację LSKF i wymusza ograniczenie liczby żądań. 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 miejsca, z których każde zawiera klucz i wartość o stałym rozmiarze. Każde miejsce jest identyfikowane przez swój identyfikator, czyli liczbę całkowitą z przedziału [0, numSlots - 1]. Wartość miejsca jest dostępna tylko wtedy, gdy podany klucz pasuje do zapisanego klucza.

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

  • getConfig(): pobiera liczbę miejsc, rozmiar klucza i rozmiar wartości obsługiwane przez implementację.
  • write(): zastępuje określone miejsce nową parą klucz-wartość. Ta operacja jest niepodzielna i sprawia, że poprzednie dane są trwale nieodzyskiwalne (bezpieczne usuwanie).
  • read(): próbuje pobrać wartość określonego miejsca. Ta operacja się powiedzie tylko wtedy, gdy nie jest aktywny limit czasu ograniczania liczby żądań (wymuszany przez TA) nie jest aktywny, a podany klucz dokładnie pasuje do zapisanego klucza.
  • warmUp(): w Androidzie 17 i nowszych wersjach przekazuje wskazówkę, że wkrótce może nastąpić odczyt lub zapis.

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

Użycie w Androidzie

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

  • Klucz miejsca (weaverKey): skrót LSKF użytkownika. Jeśli użytkownik nie ma blokady ekranu, używany jest ciąg domyślny.
  • Wartość miejsca (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 ograniczania liczby żądań.
  • 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 uwierzytelniającego (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.

W Androidzie 17 i nowszych wersjach LockSettingsService wywołuje metodę warmUp() Weavera, gdy użytkownik zaczyna wpisywać LSKF. Implementacje Weavera mogą używać tego sygnału do przełączania bezpiecznego sprzętu ze stanu niskiego zużycia energii, aby zmniejszyć opóźnienie w przypadku nadchodzącego żądania read().

Weaver a Gatekeeper

W przeszłości HAL Gatekeepera pełnił 2 różne role w ramach jednego wywołania verify():

  1. Weryfikacja: sprawdzanie LSKF z ograniczeniem liczby żądań wymuszanym przez TEE.
  2. Atestacja: wydawanie HardwareAuthToken w celu powiadomienia KeyMint (wcześniej Keymaster), że uwierzytelnianie LSKF zakończyło się powodzeniem.

Dlaczego przechodzimy na Weavera?

Wraz z wprowadzeniem w Androidzie 8.1 bezpiecznych tokenów resetowania kodu dostępu syntetyczne hasło stało się głównym sekretem kryptograficznym. Obie opisane powyżej role są 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ę, przy użyciu prostszego interfejsu HAL z obsługą implementacji opartych na bezpiecznym elemencie (SE).

Funkcja Weaver Gatekeeper
Bezpieczne usuwanie Bezpieczne usuwanie jest wymagane i łatwe do zaimplementowania, ponieważ the interfejs używa stałej liczby miejsc o stałym rozmiarze. Bezpieczne usuwanie nie jest wymagane i jest trudne do zaimplementowania ponieważ interfejs obsługuje nieograniczoną liczbę rejestracji.
Sprzęt Zoptymalizowany pod kątem SE, ale działa też w TEE. Praktycznie tylko TEE. Implementacja w SE nie zapewnia korzyści w zakresie bezpieczeństwa w przypadku obecnej konstrukcji.
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 błędów.
Niepodzielność Kod w LockSettingsService, który używa Weavera, wykonuje zmiany LSKF w sposób niepodzielny. Nowe dane są zapisywane w nowym miejscu Weavera, a stare miejsce jest usuwane tylko wtedy, gdy jest to bezpieczne. Kod w LockSettingsService, który używa Gatekeepera , nie wykonuje zmian LSKF w sposób niepodzielny. Jeśli podczas zmiany LSKF wystąpi błąd, wszystkie dane użytkownika mogą zostać utracone.

Kod referencyjny

AOSP zawiera 2 implementacje referencyjne Weavera:

  • W Androidzie 17 i nowszych wersjach, system/weaver/ zawiera implementację Weavera dla ogólnych bezpiecznych środowisk.
  • W Androidzie 8.1 i nowszych wersjach, external/libese/ zawiera implementację Weavera dla bezpiecznych elementów zgodnych z ISO/IEC7816-4.

Testowanie

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

atest VtsHalWeaverTargetTest

lub:

vts-tradefed run vts -m VtsHalWeaverTargetTest