Warstwa abstrakcji sprzętowej (HAL) Weaver (IWeaver.aidl) wprowadzona w Androidzie 8.1 zapewnia bezpieczny interfejs do uwierzytelniania użytkowników za pomocą czynnika wiedzy o ekranie blokady (LSKF), takiego jak kod PIN, wzór i hasło.
Weaver zastępuje funkcję weryfikacji LSKF w usłudze Gatekeeper. Gatekeeper jest jednak nadal używany do generowania tokenów uwierzytelniania sprzętowego.
W Androidzie 9 i nowszych CDD 9.11.2 wymaga, aby urządzenia obsługujące StrongBox miały dedykowany bezpieczny sprzęt, który zapewnia bezpieczne uwierzytelnianie użytkownika. Wdrożenie interfejsu HAL Weaver przy użyciu tego bezpiecznego sprzętu spełnia wymaganie „bezpiecznego uwierzytelniania użytkownika”.
Na urządzeniach bez dedykowanego bezpiecznego elementu (SE) można wdrożyć Weavera w zaufanym środowisku wykonawczym (TEE), takim jak Trusty.
W Androidzie 17 i nowszych wersjach zdecydowanie zalecamy wdrożenie interfejsu Weaver nawet na urządzeniach bez dedykowanego bezpiecznego elementu.
Komponenty
Weaver składa się z 3 komponentów:
- Interfejs AIDL Weaver (
IWeaver): formalna specyfikacja HAL. Android 13 i starsze wersje korzystały z HIDL zamiast AIDL. - Usługa Weaver Hardware Abstraction Layer (HAL): proces Androida specyficzny dla dostawcy, który implementuje interfejs
IWeaver. - 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 zawiera tablicę o stałym rozmiarze z trwałymi miejscami, z których każde zawiera klucz i wartość o stałym rozmiarze. Każde miejsce jest identyfikowane przez identyfikator, czyli liczbę całkowitą z przedziału [0, numSlots - 1]. Wartość gniazda jest dostępna tylko wtedy, gdy podany jest klucz pasujący do przechowywanego klucza.
Interfejs Weavera składa się głównie z:
getConfig(): pobiera liczbę boksów, rozmiar klucza i rozmiar wartości obsługiwane przez implementację.write(): zastępuje określony boks nową parą klucz-wartość. Ta operacja jest niepodzielna i sprawia, że poprzednie dane stają się trwale nieodzyskiwalne (bezpieczne usuwanie).read(): Próbuje pobrać wartość określonego miejsca. Operacja zakończy się powodzeniem tylko wtedy, gdy limit czasu ograniczania szybkości (egzekwowany przez TA) nie jest aktywny, a podany klucz dokładnie pasuje do zapisanego klucza.warmUp(): w Androidzie 17 i nowszych sygnalizuje, że wkrótce może nastąpić odczyt lub zapis.
Pełną specyfikację interfejsu znajdziesz w sekcji IWeaver.aidl.
Korzystanie przez Androida
Gdy implementacja Weaver jest dostępna, LockSettingsService serwer systemowy Androida używa jej do ochrony danych użytkownika. W przypadku każdego użytkownika na urządzeniu LockSettingsService zarządza miejscem Weaver:
- Klucz gniazda (
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.
Element weaverSecret może zostać pobrany tylko przez:
- Przekazywanie prawidłowego
weaverKeydo Weaver TA w ramach zasad ograniczania liczby żądań. - naruszenie bezpieczeństwa środowiska, w którym działa Weaver TA; Ma to być bardzo trudne.
LockSettingsService używa zarówno weaverKey, jak i weaverSecret do zaszyfrowania syntetycznego hasła użytkownika. Ponieważ hasło syntetyczne chroni zaszyfrowany za pomocą danych logowania (CE) magazyn użytkownika w przypadku szyfrowania opartego na plikach (FBE) oraz klucze powiązane z uwierzytelnianiem w systemie Android Keystore, dane pozostają niedostępne, dopóki Weaver nie udostępni klucza tajnego.
W Androidzie 17 i nowszych LockSettingsServicewywołuje metodę warmUp() WeaveraLockSettingsService, gdy zaczyna się wpisywanie LSKF. Implementacje Weavera mogą używać tego sygnału, aby wyłączyć bezpieczny sprzęt ze stanu niskiego zużycia energii i zmniejszyć opóźnienie w przypadku nadchodzącego żądania read().
Weaver vs. Gatekeeper
Historycznie Gatekeeper HAL pełnił 2 różne role w ramach jednego wywołania verify():
- Weryfikacja: sprawdzanie LSKF z ograniczaniem szybkości wymuszonym przez TEE.
- Atest: wydanie
HardwareAuthToken, aby powiadomić KeyMint (wcześniej Keymaster) o tym, że uwierzytelnianie LSKF się powiodło.
Dlaczego przechodzimy na Weavera?
Wraz z wprowadzeniem w Androidzie 8.1 bezpiecznych tokenów resetowania kodu dostępu „syntetyczne hasło” stało się podstawowym kluczem kryptograficznym. Opisane powyżej 2 role są teraz obsługiwane przez oddzielne rejestracje w programie Gatekeeper: jedna dla LSKF w sekcji userId + 100000 i jedna dla hasła syntetycznego w sekcji userId.
Weaver został wprowadzony, aby przejąć pierwszą rolę, korzystając z prostszego interfejsu HAL z obsługą implementacji opartych na bezpiecznym elemencie (SE).
| Funkcja | Weaver | Strażnik dostępu |
|---|---|---|
| Bezpieczne usuwanie | Wymagane jest bezpieczne usuwanie, które jest łatwe do wdrożenia, ponieważ interfejs używa stałej liczby przedziałów o stałym rozmiarze. | Bezpieczne usuwanie nie jest wymagane i trudno je wdrożyć, ponieważ interfejs obsługuje nieograniczoną liczbę rejestracji. |
| Sprzęt | Zoptymalizowany pod kątem SE, ale działa też w TEE. | Skutecznie tylko TEE. W obecnej wersji wdrożenie tej funkcji w SE nie zapewnia korzyści związanych z bezpieczeństwem. |
| 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 kluczy LSKF od niezwiązanych z nimi błędów. |
| Atomowość | Kod w LockSettingsService, który korzysta z Weavera, wykonuje zmiany LSKF w sposób niepodzielny. Nowe dane są zapisywane w nowym slocie Weavera, a stary slot jest usuwany tylko wtedy, gdy jest to bezpieczne. |
Kod w LockSettingsService, który korzysta z Gatekeepera, nie wykonuje zmian LSKF w sposób niepodzielny. Jeśli podczas zmiany LSKF wystąpią problemy, 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 środowisk bezpiecznych. -
W Androidzie 8.1 i nowszym
external/libese/zawiera implementację Weavera dla bezpiecznych elementów zgodnych z ISO/IEC7816-4.
Testowanie
Aby sprawdzić poprawność implementacji Weavera, użyj:VtsHalWeaverTargetTest
atest VtsHalWeaverTargetTest
lub:
vts-tradefed run vts -m VtsHalWeaverTargetTest