Sprzętowy magazyn kluczy

Dostępność zaufanego środowiska wykonawczego w systemie opartym na układzie scalonym (SoC) pozwala urządzeniom z Androidem dostarczać sprzętowe w systemie operacyjnym Android, usługach platformowych, a nawet aplikacje innych firm. Deweloperzy, którzy szukają rozszerzeń dotyczących Androida, powinni do android.security.keystore.

Przed Androidem 6.0 w Androidzie istniała prosta, wspierana sprzętowo kryptowaluta Services API udostępnianego przez wersje 0.2 i 0.3 sprzętu Keymaster Hardware Warstwa abstrakcji (HAL). Cyfrowe podpisywanie i weryfikacja w magazynie kluczy oraz generowanie i importowanie asymetrycznych par kluczy podpisywania. To jest są już wdrożone na wielu urządzeniach, ale istnieje wiele celów związanych z bezpieczeństwem, nie można łatwo osiągnąć za pomocą interfejsu Signature API. Magazyn kluczy w Androidzie 6.0 Rozszerzyliśmy interfejs Keystore API, aby zapewnić szerszy zakres możliwości.

W Androidzie 6.0 dodano magazyn kluczy symetryczne podstawowe elementy kryptograficzne, AES i HMAC oraz system kontroli dostępu do kluczy sprzętowych. Dostęp elementy sterujące są określane podczas generowania klucza i egzekwowane przez cały okres klucz. Klucze można ograniczyć tak, aby można było ich używać tylko wtedy, gdy użytkownik uwierzytelnionych i wyłącznie w określonych celach lub za pomocą określonych metod kryptograficznych, . Więcej informacji: Tagi autoryzacji oraz na stronie Funkcje.

Oprócz rozszerzenia zakresu prymitywów kryptograficznych magazyn kluczy W Androidzie 6.0 dodaliśmy te funkcje:

• schemat kontroli wykorzystania, który umożliwia ograniczenie użycia klucza w celu ograniczenia ryzyko naruszenia bezpieczeństwa w wyniku niewłaściwego użycia kluczy
• schemat kontroli dostępu umożliwiający nadawanie ograniczeń kluczy określonym użytkownikom; klientów i określonego przedziału czasu,

W Androidzie 7.0 Keymaster 2 obsługuje atest i wersję klucza i powiązania. Atestacja klucza udostępnia certyfikaty klucza publicznego ze szczegółowym opisem klucza i kontroli dostępu, aby zapewnić ich bezpieczeństwo w bezpiecznym sprzęcie którą można zdalnie zweryfikować.

Powiązanie wersji wiąże klucze z systemem operacyjnym i wersją na poziomie poprawek. Dzięki temu atakującego, który zauważy słabość w starej wersji systemu Oprogramowanie TEE nie może przywrócić na urządzeniu wersji z lukami w zabezpieczeniach ani użyć kluczy utworzona w nowszej wersji. Ponadto, gdy klucz z określoną wersją a poziom poprawek jest używany na urządzeniu, który został uaktualniony do nowszej wersji. lub wersji poprawki, klucz jest uaktualniany, zanim będzie można go użyć, a poprzedni unieważniona wersja klucza. Po uaktualnieniu urządzenia klucze „zapadkowe” wzdłuż urządzenia, ale dowolne przywrócenie urządzenia do poprzedniego sprawia, że klucze są bezużyteczne.

W Androidzie 8.0 Keymaster 3 przeszli ze starego sprzętu o strukturze C Warstwa abstrakcji (HAL) do interfejsu C++ HAL wygenerowany na podstawie definicji w nowym języku Hardware Interface Definition Language (HIDL). W ramach tej zmiany wiele typów argumentów zostało zmienionych, chociaż typy i metody mają bezpośrednio ustawione ze starymi typami i metodami struktury HAL. Zobacz Więcej informacji znajdziesz na stronie Funkcje. .

Oprócz tej wersji interfejsu Android 8.0 rozszerzył funkcja atestu na potrzeby obsługi Atest tożsamości. Atest identyfikatora zapewnia ograniczony i opcjonalny mechanizm silnego poświadczania do identyfikatorów sprzętu, takich jak numer seryjny urządzenia, nazwa produktu i numer telefonu Identyfikator (IMEI / MEID). Aby wdrożyć to uzupełnienie, w Androidzie 8.0 zmienił się ASN.1 schemat atestu do dodania atestu identyfikatora. Implementacje Keymaster muszą: znaleźć jakiś bezpieczny sposób na pobieranie odpowiednich elementów danych, a także zdefiniować mechanizm bezpiecznego i trwałego wyłączania danej funkcji.

Aktualizacje Androida 9 obejmują:

• Zaktualizuj do Keymaster 4
• Obsługa osadzonych elementów zabezpieczonych
• Obsługa importowania bezpiecznych kluczy
• Obsługa szyfrowania 3DES
• Zmieniono wiązanie wersji w taki sposób, aby pliki Boot.img i system.img osobno ustawiaj wersje, aby umożliwić niezależne aktualizacje

Słowniczek

Oto krótkie omówienie komponentów magazynu kluczy i ich relacji.

AndroidKeystore to interfejs API i komponent Android Framework przez aplikacje, aby uzyskać dostęp do funkcji magazynu kluczy. Jest ona wdrażana jako rozszerzenie standardowy interfejs Java Cryptography Architecture API i składa się z kodu w Javie, działa w swoim własnym obszarze procesów aplikacji. AndroidKeystore realizuje zadania z aplikacji do działania magazynu kluczy, przesyłając je do demona magazynu kluczy.

Daemon Keystore to demon Androida, który: dostęp do wszystkich funkcji magazynu kluczy za pomocą interfejsu API Binder. Odpowiada za przechowywanie „kluczowych blobów”, które zawierają zaszyfrowany materiał klucza obiektu tajnego, dzięki czemu magazyn kluczy może go przechowywać, nie należy ich używać ani ujawniać.

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

Keymaster TA (zaufana aplikacja) to oprogramowanie działające w w bezpiecznym kontekście, najczęściej w TrustZone na układzie SoC ARM, który zapewnia wszystkie do bezpiecznych operacji magazynu kluczy, ma dostęp do surowego materiału klucza, weryfikuje wszystkie warunki kontroli dostępu do kluczy itd.

LockSettingsService to komponent systemu Android odpowiedzialny za do uwierzytelniania użytkowników przy użyciu hasła i odcisku palca. Nie jest częścią Magazyn kluczy, który ma znaczenie, ponieważ wiele operacji na kluczach magazynu kluczy wymaga użytkownika uwierzytelnianie. LockSettingsService komunikuje się ze strażnikiem. TA i Odcisk palca TA w celu uzyskania tokenów uwierzytelniania, które przekazuje które są wykorzystywane przez narzędzie Keymaster TA. aplikacji.

Kolejnym komponentem jest Gatekeeper TA (zaufana aplikacja). działające w bezpiecznym kontekście, który odpowiada za uwierzytelnianie użytkownika haseł i generowania tokenów uwierzytelniania, które są używane do potwierdzania dostępu do konta Keymaster TA. uwierzytelnianie określonego użytkownika w określonym momencie obecnie się znajdujesz.

Kolejnym komponentem jest Fingerprint TA (zaufana aplikacja). działające w bezpiecznym kontekście, który jest odpowiedzialny za uwierzytelnianie użytkownika odciski palców i generowanie tokenów uwierzytelniających używanych do uwierzytelniania Keymasterem TA, że w określonym momencie przeprowadzono uwierzytelnianie określonego użytkownika w odpowiednim czasie.

Architektura

Interfejs Android Keystore API i podstawowa wersja HAL Keymaster HAL zapewnia podstawowy, ale wystarczający zestaw prymityw kryptograficznych, który umożliwia implementacji protokołów za pomocą kluczy wspieranych sprzętowo, z kontrolą dostępu.

Biblioteka Keymaster HAL to dostarczana przez OEM, dynamicznie ładowana biblioteka, używana przez magazyn kluczy, który zapewnia wspierane sprzętowo usługi kryptograficzne. Aby zachować zabezpieczeń, wdrożenia HAL nie wykonują żadnych poufnych operacji użytkownika, a nawet w przestrzeni jądra. Operacje o charakterze wrażliwym są delegowane do do bezpiecznego procesora, do których dostęp jest uzyskiwany za pomocą interfejsu jądra. Uzyskana architektura będzie wyglądała tak:

Rysunek 1. Dostęp do Keymaster

Na urządzeniu z Androidem „klient” platformy Keymaster HAL składa się z wielowarstwowe (np. aplikacja, platforma, demon magazynu kluczy), które można zignorować do celów tego dokumentu. Oznacza to, że opisana zawartość HAL Keymaster Interfejs API jest niskiego poziomu, używany przez wewnętrzne komponenty platformy i nie jest dostępny dla aplikacji dla programistów. Interfejs API wyższego poziomu opisano na stronie dla deweloperów aplikacji na Androida.

Celem interfejsu HAL Keymaster nie jest wdrażanie funkcji ale tylko do wysyłania i usuwania żądań do bezpiecznego świata. jest zdefiniowany przez wdrożenie.

Zgodność z poprzednimi wersjami wersje

Klucz HAL Keymaster 1 jest całkowicie niezgodny z wcześniej opublikowane HAL, np. Keymaster 0.2 i 0.3. Ułatwianie na urządzeniach z Androidem 5.0 lub starszym, które zostały udostępnione do starszych list HAL Keymaster, magazyn kluczy zawiera adapter, który udostępnia Keymaster 1 HAL z wywołaniami istniejącej biblioteki sprzętowej. Wynik nie może zapewniają pełny zakres funkcji w programie Keymaster 1 HAL. W szczególności obsługuje wyłącznie algorytmy RSA i ECDSA, a wszystkie mechanizmy autoryzacji kluczy jest przeprowadzany przez adapter w niezabezpieczonym świecie.

Keymaster 2 dodatkowo uprościł interfejs HAL, usuwając Metody get_supported_* i zezwalanie na finish() . Zmniejsza to liczbę lotów w obie strony do TEE w w przypadkach, gdy dane wejściowe są dostępne w całości, i upraszcza implementację Odszyfrowywanie AEAD.

W Androidzie 8.0 Keymaster 3 przeszli ze starej struktury C Interfejs HAL do interfejsu C++ HAL wygenerowany na podstawie definicji w nowym interfejsie Hardware Interface Definition Language (HIDL). HAL w nowym stylu przez podklasyfikację wygenerowanego IKeymasterDevice i implementowanie tylko środowiska wirtualnego . W wyniku tych zmian zmieniły się wiele typów argumentów. chociaż typy i metody mają bezpośredni związek i metody struktury HAL.

Omówienie HIDL

Język HIDL (Hardware Interface Definition Language) zapewnia niezależnego od języka mechanizmu do określania interfejsów sprzętowych. HIDL Obecnie narzędzie obsługuje generowanie interfejsów C++ i Java. To normalne że większość zaufanych osób wdrażających środowisko wykonawcze Z tego względu w tym dokumencie omówiono tylko wersję C++.

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

  methodName(INPUT ARGUMENTS) generates (RESULT ARGUMENTS);

Istnieją różne wstępnie zdefiniowane typy, a HAL może definiować nowe wyliczane i typów struktur. Więcej informacji na temat HIDL znajdziesz w sekcji z materiałami referencyjnymi.

Przykładowa metoda z IKeymasterDevice.hal Keymaster 3:

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

Jest to odpowiednik tego z interfejsu 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 to domyślnie. Argument params nie jest już obiektem struct zawierającym wskaźnik odwołujący się do tablicy obiektów key_parameter_t, ale vec (wektor) zawierający KeyParameter obiektów. zwracane wartości są wymienione w kolumnie „generates” klauzulę, w tym wektor uint8_t wartości klucza blob.

Wirtualna metoda w języku C++ wygenerowana przez kompilator HIDL:

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 przyjmuje zwracane wartości. wymienione w klauzuli generującej. Klasa implementacji HAL zastępuje tę metoda generateKey i wywołuje funkcję generateKey_cb wskaźnik do zwrócenia wyniku operacji elementowi wywołującemu. Zwróć uwagę na funkcję wywołanie wskaźnika jest synchroniczne. Rozmówca dzwoni generateKey i generateKey wywołuje podany wskaźnik funkcji, który wykonuje działanie do zakończenia, zwracając element sterujący do funkcji implementacji generateKey, która następnie wraca do elementu wywołującego.

Szczegółowy przykład znajdziesz w sekcji domyślnej implementacji hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp Domyślna implementacja zapewnia zgodność wsteczną na urządzeniach z w starszym stylu keymaster0, keymaster1 lub keymaster2 HALS.

Kontrola dostępu

Podstawowa zasada kontroli dostępu do magazynu kluczy jest taka, że każda aplikacja ma lub mają własną przestrzeń nazw. Każda reguła ma jednak wyjątek. Magazyn kluczy ma zakodowane na stałe mapy, które umożliwiają niektórym komponentom systemu dostęp do innych przestrzeni nazw. To bardzo tępy instrument, ponieważ składa się pełną kontrolę nad inną przestrzenią nazw. Kolejna kwestia jako klienty do magazynu kluczy. Obecnie nie ma możliwości stworzenia na potrzeby komponentów dostawcy, np. dostawcy WPA.

Aby uwzględnić komponenty dostawców i uogólnić kontrolę dostępu bez zakodowanych na stałe wyjątków, Keystore 2.0 wprowadza domeny, a SELinux przestrzeni nazw.

Domeny magazynu kluczy

Dzięki domenom magazynu kluczy możemy oddzielić przestrzenie nazw od identyfikatorów UID. Klienci uzyskiwanie dostępu do klucza w magazynie kluczy musi określać domenę, przestrzeń nazw i alias do których chcą uzyskać dostęp. Na podstawie tej krotki i tożsamości rozmówcy może określić, do którego klawisza chce uzyskać dostęp i czy ma on odpowiednie uprawnień.

Wprowadzamy 5 parametrów domeny, które określają sposób uzyskiwania dostępu do kluczy. Kontrolują semantykę parametru przestrzeni nazw deskryptora klucza oraz jak działa kontrola dostępu.

• DOMAIN_APP: domena aplikacji obejmuje działania Google Ads. Ta domena jest domyślnie używana przez interfejs dostawcy kluczy Java Keystore. Kiedy to domena jest używana, argument przestrzeni nazw jest ignorowany, a identyfikator UID elementu wywołującego to . Dostęp do tej domeny jest kontrolowany przez etykietę magazynu kluczy keystore_key w zasadzie SELinux.
• DOMAIN_SELINUX: ta domena wskazuje, że przestrzeń nazw ma etykietę w zasadzie SELinux. Sprawdzany jest parametr przestrzeni nazw. i przekształcanie w kontekst docelowy. Przeprowadzana jest też kontrola uprawnień dla klasy keystore_key wywołujące kontekst SELinux. Gdy dla danej operacji ustanowiono uprawnienia, używana jest pełna krotka przy wyszukiwaniu klucza.
• DOMAIN_GRANT: domena przyznania wskazuje, że Parametr przestrzeni nazw jest identyfikatorem przyznania. Parametr aliasu jest ignorowany. Kontrole SELinux są wykonywane po utworzeniu uwierzytelnienia. Dodatkowa kontrola dostępu sprawdza tylko, czy identyfikator UID wywołujący jest zgodny z identyfikatorem UID użytkownika, któremu przyznano dostęp.
• DOMAIN_KEY_ID: ta domena wskazuje, że Parametr przestrzeni nazw jest unikalnym identyfikatorem klucza. Możliwe, że sam klucz został utworzony korzystając z funkcji DOMAIN_APP lub DOMAIN_SELINUX. Uprawnienia sprawdzanie jest wykonywane po domain i namespace zostały wczytane z bazy danych kluczy w taki sam sposób, jak przy wczytywaniu obiektu blob według domeny, przestrzeni nazw i aliasu krotki. uzasadnienie domeny identyfikatora klucza. jest ciągłość. W przypadku uzyskiwania dostępu do klucza za pomocą aliasu kolejne wywołania mogą być wykonywane na różnych kluczy ze względu na możliwość wygenerowania lub zaimportowania nowego klucza i powiązania go do tego aliasu. Identyfikator klucza nigdy się nie zmienia. Zatem w przypadku klucza za pomocą identyfikatora klucza po wczytaniu go z bazy danych magazynu kluczy przy użyciu aliasu jednorazowo, możesz mieć pewność, że jest to ten sam klucz, o ile nadal istnieje jego identyfikator. Ten nie są widoczne dla deweloperów aplikacji. Zamiast tego jest używany w funkcji Interfejs SPI Android Keystore zapewnia bardziej spójną obsługę nawet w przypadku używania jednocześnie w niebezpieczny sposób.
• DOMAIN_BLOB: domena bloba wskazuje, że wywołujący samodzielnie zarządza obiektem blob. Jest ono używane w przypadku klientów, którzy muszą dostępu do magazynu kluczy przed podłączeniem partycji danych. Kluczowym obiektem blob jest w polu blob deskryptora klucza.

Przy użyciu domeny SELinux możemy dać komponentom dostawcy dostęp do przestrzenie nazw magazynu kluczy, które mogą być współużytkowane przez komponenty systemu, takie jak okno ustawień.

Zasada SELinux dla keystore_key

Etykiety przestrzeni nazw są konfigurowane za pomocą interfejsu keystore2_key_context .
Każdy wiersz w tych plikach mapuje 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 klucza możemy przyznać do niej dostęp dodając odpowiednią zasadę. Aby na przykład zezwolić na wpa_supplicant w celu pobrania kluczy i użycia ich w nowej przestrzeni nazw, dodaj do hal_wifi_supplicant.te ten wiersz:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Po skonfigurowaniu nowej przestrzeni nazw AndroidKeyStore może być używany prawie jako jak zwykle. Jedyną różnicą jest to, że należy określić identyfikator przestrzeni nazw. Dla: wczytuję i importuję klucze z i do magazynu kluczy, określono identyfikator przestrzeni nazw za pomocą funkcji 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, należy podać jej identyfikator przy użyciu: KeyGenParameterSpec.Builder#setNamespace():

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

Do skonfigurowania magazynu kluczy 2.0 SELinux można użyć tych plików kontekstowych przestrzeni nazw. Każda partycja ma inny zarezerwowany zakres obejmujący 10 000 przestrzeni nazw identyfikatory pozwalające 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, wysyłając żądanie domeny SELinux i żądanego wirtualnej przestrzeni nazw, w tym przypadku "wifi_key", według identyfikatora numerycznego.

Powyżej zdefiniowano następujące przestrzenie nazw. Jeśli zastąpią specjalnych reguł, w poniższej tabeli podano UID, które zostały użyte do do.

Dostęp do wektorów

Klasa SELinux keystore_key nieco się podeszła. utracone uprawnienia takie jak verify lub sign ich znaczenia. Oto nowy zestaw uprawnień: keystore2_key, które wymusi stosowanie magazynu kluczy w wersji 2.0.

Poza tym podzieliliśmy zestaw uprawnień, które nie są związane z magazynem kluczy, klasa zabezpieczeń SELinux keystore2: