Magazyn kluczy wspierany sprzętowo

Dostępność zaufanego środowiska wykonawczego w systemie na chipie (SoC) umożliwia urządzeniom z Androidem świadczenie wspieranych sprzętowo, silnych usług bezpieczeństwa dla systemu operacyjnego Android, usług platformy, a nawet aplikacji innych firm. Deweloperzy poszukujący rozszerzeń dla systemu Android powinni przejść do witryny android.security.keystore .

Przed Androidem 6.0 system Android miał już prosty, wspierany sprzętowo interfejs API usług kryptograficznych, dostarczany przez wersje 0.2 i 0.3 warstwy abstrakcji sprzętu Keymaster (HAL). Magazyn kluczy zapewniał operacje podpisywania cyfrowego i weryfikacji, a także generowanie i importowanie asymetrycznych par kluczy podpisujących. Jest to już zaimplementowane na wielu urządzeniach, ale istnieje wiele celów bezpieczeństwa, których nie można łatwo osiągnąć za pomocą samego interfejsu API podpisu. Keystore w systemie Android 6.0 rozszerzył interfejs Keystore API, aby zapewnić szerszy zakres możliwości.

W systemie Android 6.0 Keystore dodał symetryczne prymitywy kryptograficzne , AES i HMAC oraz system kontroli dostępu dla kluczy sprzętowych. Kontrole dostępu są określane podczas generowania klucza i wymuszane przez cały okres istnienia klucza. Klucze mogą zostać ograniczone do użytku dopiero po uwierzytelnieniu użytkownika i tylko do określonych celów lub z określonymi parametrami kryptograficznymi. Aby uzyskać więcej informacji, zobacz strony Tagi i funkcje autoryzacji.

Oprócz rozszerzenia zakresu prymitywów kryptograficznych, Keystore w systemie Android 6.0 dodał:

• Schemat kontroli użycia pozwalający na ograniczenie użycia klucza, aby złagodzić ryzyko naruszenia bezpieczeństwa z powodu niewłaściwego użycia kluczy
• Schemat kontroli dostępu umożliwiający ograniczenie kluczy do określonych użytkowników, klientów i określonego przedziału czasowego

W systemie Android 7.0 Keymaster 2 dodał obsługę poświadczania kluczy i wiązania wersji. Atestacja klucza zapewnia certyfikaty klucza publicznego, które zawierają szczegółowy opis klucza i jego kontroli dostępu, aby umożliwić zdalną weryfikację istnienia klucza na bezpiecznym sprzęcie i jego konfiguracji.

Powiązanie wersji wiąże klucze z systemem operacyjnym i wersją na poziomie poprawki. Gwarantuje to, że atakujący, który wykryje słabość w starej wersji systemu lub oprogramowania TEE, nie będzie mógł przywrócić urządzenia do wersji zawierającej lukę i użyć kluczy utworzonych w nowszej wersji. Ponadto, gdy klucz z daną wersją i poziomem poprawki jest używany na urządzeniu, które zostało zaktualizowane do nowszej wersji lub poziomu poprawki, klucz jest aktualizowany, zanim będzie mógł zostać użyty, a poprzednia wersja klucza unieważniona. Gdy urządzenie jest aktualizowane, klawisze „zapadają się” do przodu wraz z urządzeniem, ale każde przywrócenie urządzenia do poprzedniej wersji powoduje, że klawisze stają się bezużyteczne.

W systemie Android 8.0 Keymaster 3 przeszedł ze starej warstwy abstrakcji sprzętu (HAL) o strukturze C do interfejsu C++ HAL wygenerowanego na podstawie definicji w nowym języku definicji interfejsu sprzętowego (HIDL). W ramach zmiany zmieniło się wiele typów argumentów, chociaż typy i metody mają korespondencję jeden do jednego ze starymi typami i metodami struktury HAL. Zobacz stronę Funkcje , aby uzyskać więcej informacji.

Oprócz tej wersji interfejsu system Android 8.0 rozszerzył funkcję poświadczania Keymaster 2 o obsługę poświadczania tożsamości . Zaświadczanie identyfikatora zapewnia ograniczony i opcjonalny mechanizm silnego potwierdzania identyfikatorów sprzętowych, takich jak numer seryjny urządzenia, nazwa produktu i identyfikator telefonu (IMEI / MEID). Aby zaimplementować ten dodatek, system Android 8.0 zmienił schemat poświadczania ASN.1, aby dodać poświadczenie identyfikatora. Implementacje Keymaster muszą znaleźć bezpieczny sposób na pobieranie odpowiednich elementów danych, a także zdefiniować mechanizm bezpiecznego i trwałego wyłączania funkcji.

W systemie Android 9 aktualizacje obejmowały:

• Aktualizacja do Keymastera 4
• Obsługa wbudowanych bezpiecznych elementów
• Obsługa bezpiecznego importu kluczy
• Obsługa szyfrowania 3DES
• Zmiany w powiązaniu wersji, tak aby boot.img i system.img miały oddzielnie ustawione wersje, aby umożliwić niezależne aktualizacje

Słowniczek

Oto krótki przegląd komponentów Keystore i ich relacji.

AndroidKeystore to interfejs API platformy Android i komponent używany przez aplikacje do uzyskiwania dostępu do funkcji Keystore. Jest zaimplementowany jako rozszerzenie standardowych interfejsów API Java Cryptography Architecture i składa się z kodu Java działającego we własnej przestrzeni procesów aplikacji. AndroidKeystore spełnia żądania aplikacji dotyczące zachowania magazynu kluczy, przekazując je do demona magazynu kluczy.

Demon magazynu kluczy to demon systemu Android, który zapewnia dostęp do wszystkich funkcji magazynu kluczy za pośrednictwem interfejsu API Bindera . Odpowiada za przechowywanie „kluczowych obiektów blob”, które zawierają rzeczywisty materiał klucza tajnego, zaszyfrowany, aby Keystore mógł je przechowywać, ale nie mógł ich używać ani ujawniać.

keymasterd to serwer HIDL, który zapewnia dostęp do Keymaster TA. (Ta nazwa nie jest znormalizowana i służy do celów koncepcyjnych.)

Keymaster TA (zaufana aplikacja) to oprogramowanie działające w bezpiecznym kontekście, najczęściej w TrustZone na ARM SoC, które zapewnia wszystkie bezpieczne operacje Keystore, ma dostęp do surowego materiału klucza, weryfikuje wszystkie warunki kontroli dostępu do kluczy itp.

LockSettingsService to komponent systemu Android odpowiedzialny za uwierzytelnianie użytkownika, zarówno hasło, jak i odcisk palca. Nie jest częścią magazynu kluczy, ale ma znaczenie, ponieważ wiele operacji na kluczach magazynu kluczy wymaga uwierzytelnienia użytkownika. LockSettingsService współdziała z usługą Gatekeeper TA i Fingerprint TA, aby uzyskać tokeny uwierzytelniania, które udostępnia demonowi magazynu kluczy i które są ostatecznie używane przez aplikację Keymaster TA.

Gatekeeper TA (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, który jest odpowiedzialny za uwierzytelnianie haseł użytkowników i generowanie tokenów uwierzytelniających używanych do udowodnienia Keymasterowi TA, że uwierzytelnienie zostało wykonane dla konkretnego użytkownika w określonym momencie.

Fingerprint TA (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, który jest odpowiedzialny za uwierzytelnianie odcisków palców użytkowników i generowanie tokenów uwierzytelniających używanych do udowodnienia Keymaster TA, że uwierzytelnienie zostało wykonane dla konkretnego użytkownika w określonym momencie.

Architektura

Interfejs API magazynu kluczy systemu Android i bazowa warstwa HAL Keymaster zapewniają podstawowy, ale odpowiedni zestaw prymitywów kryptograficznych, aby umożliwić implementację protokołów przy użyciu kluczy z kontrolą dostępu i sprzętem.

Keymaster HAL to dostarczona przez producenta OEM, dynamicznie ładowana biblioteka używana przez usługę Keystore do świadczenia usług kryptograficznych wspieranych sprzętowo. Aby zapewnić bezpieczeństwo, implementacje HAL nie wykonują żadnych wrażliwych operacji w przestrzeni użytkownika, a nawet w przestrzeni jądra. Poufne operacje są delegowane do bezpiecznego procesora, do którego dostęp uzyskuje się za pośrednictwem interfejsu jądra. Powstała architektura wygląda tak:

Rysunek 1. Dostęp do Keymaster

W urządzeniu z systemem Android „klient” warstwy HAL Keymaster składa się z wielu warstw (np. aplikacji, struktury, demona Keystore), ale można to zignorować na potrzeby tego dokumentu. Oznacza to, że opisany interfejs API Keymaster HAL jest niskopoziomowy, używany przez składniki wewnętrzne platformy i nie jest udostępniany programistom aplikacji. Interfejs API wyższego poziomu jest opisany w witrynie Android Developer .

Celem Keymaster HAL nie jest implementacja algorytmów wrażliwych na bezpieczeństwo, ale tylko porządkowanie i rozbieranie żądań do bezpiecznego świata. Format przewodu jest zdefiniowany przez implementację.

Kompatybilność z poprzednimi wersjami

HAL Keymaster 1 jest całkowicie niekompatybilny z wcześniej wydanymi warstwami HAL, np. Keymaster 0.2 i 0.3. Aby ułatwić współdziałanie na urządzeniach z systemem Android 5.0 lub starszym, które zostały uruchomione ze starszymi warstwami HAL Keymaster, Keystore udostępnia adapter, który implementuje warstwę HAL Keymaster 1 z wywołaniami istniejącej biblioteki sprzętowej. Wynik nie może zapewnić pełnego zakresu funkcjonalności w Keymaster 1 HAL. W szczególności obsługuje tylko algorytmy RSA i ECDSA, a całe wymuszenie autoryzacji klucza jest wykonywane przez adapter w świecie niezabezpieczonym.

Keymaster 2 jeszcze bardziej uprościł interfejs HAL, usuwając metody get_supported_* i umożliwiając metodzie finish() przyjmowanie danych wejściowych. Zmniejsza to liczbę podróży w obie strony do TEE w przypadkach, gdy dane wejściowe są dostępne jednocześnie, i upraszcza implementację deszyfrowania AEAD.

W systemie Android 8.0 Keymaster 3 przeszedł ze starej struktury C HAL do interfejsu HAL C++ wygenerowanego na podstawie definicji w nowym języku definicji interfejsu sprzętowego (HIDL). Implementacja warstwy HAL nowego stylu jest tworzona przez utworzenie podklasy wygenerowanej klasy IKeymasterDevice i zaimplementowanie czystych metod wirtualnych. W ramach zmiany zmieniło się wiele typów argumentów, chociaż typy i metody mają korespondencję jeden do jednego ze starymi typami i metodami struktur HAL.

Przegląd HIDL

Język definicji interfejsu sprzętowego (HIDL) zapewnia niezależny od języka implementacji mechanizm określania interfejsów sprzętowych. Narzędzia HIDL obecnie obsługują generowanie interfejsów C++ i Java. Oczekuje się, że większość realizatorów Trusted Execution Environment (TEE) uzna narzędzia C++ za wygodniejsze, więc ten dokument omawia tylko reprezentację C++.

Interfejsy HIDL składają się z zestawu metod, wyrażonych jako:

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Istnieją różne wstępnie zdefiniowane typy, a warstwy HAL mogą definiować nowe typy wyliczeniowe i strukturalne. Aby uzyskać więcej informacji na temat HIDL, zobacz sekcję Odniesienie .

Przykładowa metoda z Keymaster 3 IKeymasterDevice.hal to:

generateKey(vec<KeyParameter> keyParams)
        generates(ErrorCode error, vec<uint8_t> keyBlob,
                  KeyCharacteristics keyCharacteristics);

Jest to odpowiednik następującego z HAL keymaster2:

keymaster_error_t (*generate_key)(
        const struct keymaster2_device* dev,
        const keymaster_key_param_set_t* params,
        keymaster_key_blob_t* key_blob,
        keymaster_key_characteristics_t* characteristics);

W wersji HIDL argument dev jest usuwany, ponieważ jest niejawny. Argument params nie jest już strukturą zawierającą wskaźnik odwołujący się do tablicy obiektów key_parameter_t , ale vec (wektor) zawierający obiekty KeyParameter . Zwracane wartości są wymienione w klauzuli „ generates ”, w tym wektor wartości uint8_t dla obiektu BLOB klucza.

Metoda wirtualna C++ generowana przez kompilator HIDL to:

Return<void> generateKey(const hidl_vec<KeyParameter>& keyParams,
                         generateKey_cb _hidl_cb) override;

Gdzie generateKey_cb jest wskaźnikiem funkcji zdefiniowanym jako:

std::function<void(ErrorCode error, const hidl_vec<uint8_t>& keyBlob,
                   const KeyCharacteristics& keyCharacteristics)>

Oznacza to, że generateKey_cb to funkcja, która pobiera wartości zwracane wymienione w klauzuli generate. Klasa implementacji warstwy HAL zastępuje tę metodę generateKey i wywołuje wskaźnik funkcji generateKey_cb w celu zwrócenia wyniku operacji do obiektu wywołującego. Zauważ, że wywołanie wskaźnika funkcji jest synchroniczne . Wywołujący wywołuje generateKey , a generateKey wywołuje dostarczony wskaźnik funkcji, który jest wykonywany do końca, zwracając kontrolę do implementacji generateKey , która następnie wraca do wywołującego.

Aby zapoznać się ze szczegółowym przykładem, zobacz domyślną implementację w hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp . Domyślna implementacja zapewnia kompatybilność wsteczną dla urządzeń ze starym stylem keymaster0, keymaster1 lub keymaster2 HALS.

Kontrola dostępu

Najbardziej podstawową zasadą kontroli dostępu do magazynu kluczy jest to, że każda aplikacja ma własną przestrzeń nazw. Ale dla każdej reguły jest wyjątek. Magazyn kluczy ma kilka map zakodowanych na sztywno, które umożliwiają niektórym składnikom systemu dostęp do niektórych innych przestrzeni nazw. Jest to bardzo tępy instrument, ponieważ daje jednemu komponentowi pełną kontrolę nad inną przestrzenią nazw. I jeszcze kwestia komponentów dostawcy jako klientów Keystore. Obecnie nie mamy możliwości ustanowienia przestrzeni nazw dla komponentów dostawcy, na przykład suplikanta WPA.

Aby dostosować się do komponentów dostawców i uogólnić kontrolę dostępu bez zakodowanych na stałe wyjątków, Keystore 2.0 wprowadza domeny i przestrzenie nazw SELinux.

Domeny magazynu kluczy

Dzięki domenom Keystore możemy oddzielić przestrzenie nazw od identyfikatorów UID. Klienci uzyskujący dostęp do klucza w magazynie kluczy muszą określić domenę, przestrzeń nazw i alias, do których chcą uzyskać dostęp. Na podstawie tej krotki i tożsamości dzwoniącego możemy określić, do którego klucza dzwoniący chce uzyskać dostęp i czy ma odpowiednie uprawnienia.

Wprowadzamy pięć parametrów domeny, które regulują sposób dostępu do kluczy. Kontrolują semantykę parametru przestrzeni nazw deskryptora klucza i sposób wykonywania kontroli dostępu.

• DOMAIN_APP : domena aplikacji obejmuje starsze zachowanie. Interfejs SPI Java Keystore używa domyślnie tej domeny. Gdy ta domena jest używana, argument przestrzeni nazw jest ignorowany i zamiast tego używany jest identyfikator UID wywołującego. Dostęp do tej domeny jest kontrolowany przez etykietę Keystore do klasy keystore_key w polityce SELinux.
• DOMAIN_SELINUX : Ta domena wskazuje, że przestrzeń nazw ma etykietę w polityce SELinux. Parametr namespace jest wyszukiwany i tłumaczony na kontekst docelowy, a następnie przeprowadzane jest sprawdzanie uprawnień dla wywołującego kontekstu SELinux dla klasy keystore_key . Po ustanowieniu uprawnienia dla danej operacji do wyszukiwania klucza używana jest pełna krotka.
• DOMAIN_GRANT : domena grant wskazuje, że parametr przestrzeni nazw jest identyfikatorem grantu. Parametr alias jest ignorowany. Testy SELinux są wykonywane podczas tworzenia grantu. Dalsza kontrola dostępu sprawdza tylko, czy UID wywołującego jest zgodny z UID beneficjenta żądanego przydziału.
• DOMAIN_KEY_ID : ta domena wskazuje, że parametr przestrzeni nazw jest unikalnym identyfikatorem klucza. Sam klucz mógł zostać utworzony za pomocą DOMAIN_APP lub DOMAIN_SELINUX . Sprawdzanie uprawnień jest wykonywane po załadowaniu domain i namespace z bazy danych kluczy w taki sam sposób, jak gdyby obiekt BLOB został załadowany przez domenę, przestrzeń nazw i krotkę aliasów. Uzasadnieniem dla domeny id klucza jest ciągłość. Podczas uzyskiwania dostępu do klucza przez alias, kolejne wywołania mogą działać na różnych kluczach, ponieważ nowy klucz mógł zostać wygenerowany lub zaimportowany i powiązany z tym aliasem. Kluczowy identyfikator jednak nigdy się nie zmienia. Zatem używając klucza według identyfikatora klucza po jego jednokrotnym załadowaniu z bazy danych Keystore przy użyciu aliasu, można być pewnym, że jest to ten sam klucz, o ile identyfikator klucza nadal istnieje. Ta funkcja nie jest dostępna dla twórców aplikacji. Zamiast tego jest używany w interfejsie SPI Android Keystore, aby zapewnić bardziej spójne środowisko, nawet jeśli jest używany jednocześnie w niebezpieczny sposób.
• DOMAIN_BLOB : domena obiektu BLOB wskazuje, że obiekt wywołujący samodzielnie zarządza obiektem BLOB. Jest to używane w przypadku klientów, którzy muszą uzyskać dostęp do magazynu kluczy przed zamontowaniem partycji danych. Kluczowy obiekt BLOB znajduje się w polu blob deskryptora klucza.

Korzystając z domeny SELinux, możemy dać komponentom dostawcy dostęp do bardzo specyficznych przestrzeni nazw Keystore, które mogą być współdzielone przez komponenty systemu, takie jak okno dialogowe ustawień.

Polityka SELinux dla keystore_key

Etykiety przestrzeni nazw są konfigurowane przy użyciu pliku keystore2_key_context .
Każdy wiersz w tych plikach odwzorowuje numeryczny identyfikator przestrzeni nazw na etykietę SELinux. Na przykład,

# wifi_key is a keystore2_key namespace intended to be used by wpa supplicant and
# Settings to share keystore keys.
102            u:object_r:wifi_key:s0

Po skonfigurowaniu w ten sposób nowej przestrzeni nazw kluczy, możemy dać do niej dostęp, dodając odpowiednią politykę. Na przykład, aby umożliwić wpa_supplicant pobieranie i używanie kluczy w nowej przestrzeni nazw, dodamy następującą linię do hal_wifi_supplicant.te :

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Po skonfigurowaniu nowej przestrzeni nazw AndroidKeyStore może być używany prawie jak zwykle. Jedyna różnica polega na tym, że należy określić identyfikator przestrzeni nazw. W przypadku ładowania i importowania kluczy z i do Keystore identyfikator przestrzeni nazw jest określany przy użyciu AndroidKeyStoreLoadStoreParameter . Na przykład,

import android.security.keystore2.AndroidKeyStoreLoadStoreParameter;
import java.security.KeyStore;

KeyStore keystore = KeyStore.getInstance("AndroidKeyStore");
keystore.load(new AndroidKeyStoreLoadStoreParameter(102));

Aby wygenerować klucz w danej przestrzeni nazw, identyfikator przestrzeni nazw musi być podany za pomocą KeyGenParameterSpec.Builder#setNamespace():

import android.security.keystore.KeyGenParameterSpec;
KeyGenParameterSpec.Builder specBuilder = new KeyGenParameterSpec.Builder();
specBuilder.setNamespace(102);

Poniższe pliki kontekstowe mogą służyć do konfigurowania przestrzeni nazw Keystore 2.0 SELinux. Każda partycja ma inny zarezerwowany zakres 10 000 identyfikatorów przestrzeni nazw, aby uniknąć kolizji.

/system/etc/selinux/keystore2_key_contexts, /plat_keystore2_key_contexts

/system_ext/etc/selinux/system_ext_keystore2_key_contexts, /system_ext_keystore2_key_contexts

/product/etc/selinux/product_keystore2_key_contexts, /product_keystore2_key_contexts

/vendor/etc/selinux/vendor_keystore2_key_contexts, /vendor_keystore2_key_contexts

Klient żąda klucza, żądając domeny SELinux i żądanej wirtualnej przestrzeni nazw, w tym przypadku "wifi_key" , za pomocą swojego numerycznego identyfikatora.

Powyżej zdefiniowano następujące przestrzenie nazw. Jeśli zastępują zasady specjalne, poniższa tabela wskazuje UID, któremu odpowiadały.

Dostęp do wektorów

Klasa SELinux keystore_key nieco się zestarzała, a niektóre uprawnienia, takie jak verify lub sign , straciły na znaczeniu. Oto nowy zestaw uprawnień, keystore2_key , które Keystore 2.0 będzie egzekwować.

Dodatkowo, w klasie bezpieczeństwa SELinux keystore2 podzieliliśmy zestaw niespecyficznych dla klucza uprawnień do magazynu kluczy: