Sprzętowy magazyn kluczy

Dostępność zaufanego środowiska wykonywania w systemie na chipie (SoC) umożliwia urządzeniom z Androidem udostępnianie mocnych zabezpieczeń sprzętowych systemowi operacyjnemu Android, usługom platformy, a nawet aplikacjom innych firm. Deweloperzy, którzy szukają rozszerzeń przeznaczonych na Androida, powinni użyć android.security.keystore.

Przed Androidem 6.0 system ten miał już proste interfejsy API usług szyfrowania oparte na sprzęcie, udostępniane przez wersje 0.2 i 0.3 interfejsu Keymaster Hardware Abstraction Layer (HAL). Magazyn kluczy zapewnia operacje podpisywania cyfrowego i weryfikacji oraz generowanie i importowanie par kluczy asymetrycznych. Jest to już zaimplementowane na wielu urządzeniach, ale jest wiele celów związanych z bezpieczeństwem, których nie da się łatwo osiągnąć tylko za pomocą interfejsu API podpisów. Keystore w Androidzie 6.0 rozszerza interfejs Keystore API, aby zapewnić szerszy zakres funkcji.

W Androidzie 6.0 Keystore dodano symetryczne algorytmy kryptograficzne, AES i HMAC oraz system kontroli dostępu do kluczy opartych na sprzęcie. Uprawnienia dostępu są określane podczas generowania klucza i stosowane przez cały czas jego ważności. Klucze mogą być ograniczone do użytku tylko po uwierzytelnieniu użytkownika i tylko do określonych celów lub z określonymi parametrami kryptograficznymi. Więcej informacji znajdziesz na stronie Tagi autoryzacji.

Oprócz rozszerzenia zakresu prymitywnych funkcji kryptograficznych Keystore w Androidzie 6.0 zawiera:

• Schemat kontroli użycia, który umożliwia ograniczenie użycia kluczy w celu zmniejszenia ryzyka naruszenia bezpieczeństwa spowodowanego niewłaściwym użyciem kluczy.
• schemat kontroli dostępu umożliwiający ograniczenie kluczy do określonych użytkowników, klientów i zdefiniowanego zakresu czasu;

W Androidzie 7.0 Keymaster 2 obsługuje potwierdzanie klucza i wiązanie wersji. Potwierdzenie ważności klucza zapewnia certyfikaty kluczy publicznych zawierające szczegółowy opis klucza i jego kontroli dostępu, aby umożliwić zdalne sprawdzanie istnienia klucza na bezpiecznym sprzęcie oraz jego konfiguracji.

Powiązanie z wersją: klucze są powiązane z systemem operacyjnym i poziomem poprawek. Dzięki temu atakujący, który odkryje słabość w starszej wersji systemu lub oprogramowania TEE, nie będzie mógł przywrócić urządzenia do wersji podatnej na ataki i używać kluczy utworzonych w nowszej wersji. Dodatkowo, gdy klucz z danej wersji i poziomu poprawki jest używany na urządzeniu, które zostało uaktualnione do nowszej wersji lub poziomu poprawki, klucz jest uaktualniany przed użyciem, a poprzednia wersja klucza staje się nieważna. Gdy urządzenie jest aktualizowane, klucze „przeskakują” do nowej wersji wraz z urządzeniem, ale przywrócenie urządzenia do poprzedniej wersji powoduje, że klucze stają się bezużyteczne.

W Androidzie 8.0 Keymaster 3 przeszedł ze starego interfejsu HAL opartego na C do interfejsu HAL w C++ wygenerowanego na podstawie definicji w nowym języku definiowania interfejsu sprzętowego (HIDL). W ramach tej zmiany wiele typów argumentów zostało zmienionych, ale typy i metody są zgodne ze starymi typami i metodami struktury HAL.

Oprócz tej aktualizacji interfejsu w Androidzie 8.0 rozszerzono funkcję uwierzytelniania Keymaster 2, aby obsługiwała uwierzytelnianie tożsamości. Poświadczenie toczących tożsamości to ograniczony i opcjonalny mechanizm zapewniający silne uwierzytelnianie za pomocą identyfikatorów sprzętowych, takich jak numer seryjny urządzenia, nazwa produktu i identyfikator telefonu (IMEI / MEID). Aby wdrożyć tę funkcję, w Androidzie 8.0 zmieniono schemat uwierzytelniania ASN.1, aby dodać uwierzytelnianie tożsamości. Implementacje Keymaster muszą znaleźć bezpieczny sposób na pobranie odpowiednich elementów danych, a także zdefiniować mechanizm bezpiecznego i trwałego wyłączania funkcji.

W Androidzie 9 aktualizacje obejmowały:

• Aktualizacja do Keymaster 4
• Obsługa wbudowanych elementów zabezpieczeń
• Obsługa importowania bezpiecznych kluczy
• Obsługa szyfrowania 3DES
• Zmiany w wiązaniu wersji, dzięki którym pliki boot.img i system.img mają oddzielnie ustawione wersje, co umożliwia niezależne aktualizacje

Słowniczek

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

AndroidKeystore to interfejs API i komponent Android Framework używany przez aplikacje do uzyskiwania dostępu do funkcji Keystore. Jest ona implementowana jako rozszerzenie standardowych interfejsów API Java Cryptography Architecture i składa się z kodu Java, który działa w ramach własnego obszaru procesu aplikacji. AndroidKeystore obsługuje żądania aplikacji dotyczące zachowania magazynu kluczy, przekazując je do demona magazynu kluczy.

Damon Keystore to demon systemu Androida, który zapewnia dostęp do wszystkich funkcji Keystore za pomocą interfejsu Binder API. Jest odpowiedzialny za przechowywanie „fragmentów klucza”, które zawierają rzeczywisty materiał klucza tajnego. Są one zaszyfrowane, więc Keystore może je przechowywać, ale nie może 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 do celów koncepcyjnych).

Keymaster TA (zaufana aplikacja) to oprogramowanie działające w bezpiecznym kontekście, najczęściej w TrustZone na procesorze 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 składnik systemu Androida odpowiedzialny za uwierzytelnianie użytkownika, zarówno za pomocą hasła, jak i odcisków palców. Nie jest to część Keystore, ale jest istotna, ponieważ wiele operacji na kluczach w Keystore wymaga uwierzytelnienia użytkownika. LockSettingsService współpracuje z usługami typu Gatekeeper TA i Fingerprint TA, aby uzyskać tokeny uwierzytelniania, które przekazuje demonowi keystore. Są one ostatecznie wykorzystywane przez aplikację Keymaster TA.

TA bramkotwórcy (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, który odpowiada za uwierzytelnianie haseł użytkowników i generowanie tokenów uwierzytelniania służących do potwierdzania w usłudze TA Keymaster, że uwierzytelnianie zostało wykonane dla konkretnego użytkownika w określonym momencie.

TA odcisków palców (zaufana aplikacja) to kolejny komponent działający w bezpiecznym kontekście, który odpowiada za uwierzytelnianie odcisków palców użytkownika i generowanie tokenów uwierzytelniania służących do udowodnienia TA Keymaster, że uwierzytelnianie zostało wykonane w przypadku konkretnego użytkownika w określonym momencie.

Architektura

Interfejs Keystore API na Androida i podstawowy interfejs Keymaster HAL zapewniają podstawowy, ale wystarczający zestaw prymitywnych elementów kryptograficznych, umożliwiający implementację protokołów z kluczami kontrolowanymi przez sprzęt.

Keymaster HAL to biblioteka dynamicznie wczytywana przez OEM-a, która jest używana przez usługę Keystore do świadczenia usług kryptograficznych opartych na sprzęcie. W celu zapewnienia bezpieczeństwa implementacje HAL nie wykonują żadnych operacji wrażliwych w przestrzeni użytkownika ani nawet w przestrzeni jądra. Operacje wrażliwe są delegowane do bezpiecznego procesora, do którego dostęp uzyskuje się za pomocą interfejsu jądra. Wynikowa architektura wygląda tak:

Rysunek 1. Dostęp do Keymastera

Na urządzeniu z Androidem „klient” interfejsu API Keymaster składa się z kilku warstw (np. aplikacji, platformy i demona Keystore), ale w ramach tego dokumentu można je zignorować. Oznacza to, że opisane API Keymaster HAL jest interfejsem niskiego poziomu używanym przez komponenty wewnętrzne platformy i nie jest widoczny dla deweloperów aplikacji. Interfejs API wyższego poziomu jest opisany na stronie dla deweloperów aplikacji na Androida.

Biblioteka Keymaster HAL nie służy do implementowania algorytmów wrażliwych na zagrożenia, ale tylko do serializacji i deserializacji żądań w bezpiecznym środowisku. Format danych jest zdefiniowany przez implementację.

Zgodność z poprzednimi wersjami

Interfejs HAL Keymaster 1 jest całkowicie niezgodny z poprzednio opublikowanymi interfejsami HAL, np. Keymaster 0.2 i 0.3. Aby ułatwić interoperacyjność na urządzeniach z Androidem 5.0 i starszym, które zostały uruchomione ze starszymi interfejsami Keymaster HAL, Keystore udostępnia adapter, który implementuje interfejs Keymaster 1 HAL z wywołaniami do istniejącej biblioteki sprzętowej. W efekcie nie można zapewnić pełnego zakresu funkcji w komponencie HAL Keymaster 1. W szczególności obsługuje tylko algorytmy RSA i ECDSA, a wszystkie mechanizmy autoryzacji kluczy są wykonywane przez adapter w niebezpiecznym środowisku.

Keymaster 2 jeszcze bardziej uprościł interfejs HAL, usuwając metody get_supported_* i zezwalając metodzie finish() na przyjmowanie danych wejściowych. Dzięki temu zmniejsza się liczba połączeń z TEE w przypadkach, gdy dane wejściowe są dostępne od razu, oraz upraszcza się implementację odszyfrowywania AEAD.

W Androidzie 8.0 Keymaster 3 przeszedł ze starego interfejsu HAL w języku C na interfejs HAL w C++ wygenerowany na podstawie definicji w nowym języku definiowania interfejsu sprzętowego (HIDL). Implementacja nowego stylu HAL jest tworzona przez utworzenie podklasy wygenerowanej klasy IKeymasterDevice i wdrażanie czysto wirtualnych metod. W ramach tej zmiany wiele typów argumentów zostało zmienionych, chociaż typy i metody są zgodne z typami i metodami struktury HAL.

Omówienie HIDL

Język definiowania interfejsów sprzętowych (HIDL) udostępnia mechanizm implementacji niezależny od języka, który służy do określania interfejsów sprzętowych. Narzędzia HIDL obsługują obecnie generowanie interfejsów w językach C++ i Java. Spodziewamy się, że większość implementatorów zaufanego środowiska wykonawczego (TEE) uzna narzędzia C++ za wygodniejsze, dlatego na tej stronie omawiamy tylko reprezentację w 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 HAL może definiować nowe typy wyliczeniowe i strukturalne. Więcej informacji o HIDL znajdziesz w sekcji z materiałami referencyjnymi.

Przykładowa metoda z Keymaster 3 IKeymasterDevice.hal:

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

Jest to odpowiednik tego fragmentu kodu 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 został usunięty, ponieważ jest domyślny. Argument params nie jest już strukturą zawierającą wskaźnik odwołujący się do tablicy obiektów key_parameter_t, ale vec (wektory) zawierającą obiekty KeyParameter. Wartości zwracane są wymienione w nawiasach klamrowych „generates”, w tym wektor wartości uint8_t dla klucza blob.

Metoda wirtualna w 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 wartości zwracane wymienione w nawiasach klamrowych w klauzuli generate. Klasa implementacji HAL zastępuje tę metodę generateKey i wywołuje wskazyciel funkcji generateKey_cb, aby zwrócić wynik operacji do wywołującego. Pamiętaj, że wywołanie funkcji pointer jest synchroniczne. Wywołujący wywołuje funkcję generateKey, a ta wywołuje podany wskaźnik funkcji, który wykonuje się do końca, przekazując kontrolę do implementacji funkcji generateKey, która zwraca ją do wywołującego.generateKey

Szczegółowy przykład znajdziesz w implementacji domyślnej w pliku hardware/interfaces/keymaster/3.0/default/KeymasterDevice.cpp. Domyślna implementacja zapewnia zgodność wsteczną z urządzeniami z interfejsami HAL w starym stylu keymaster0, keymaster1 lub keymaster2.

Kontrola dostępu

Najprostszą zasadą kontroli dostępu do Keystore jest to, że każda aplikacja ma swoją własną przestrzeń nazw. Ale każda reguła ma swoje wyjątki. Keystore zawiera zakodowane na stałe mapy, które umożliwiają niektórym składnikom systemu dostęp do określonych innych przestrzeni nazw. Jest to bardzo ostry instrument, ponieważ daje jednemu komponentowi pełną kontrolę nad inną przestrzenią nazw. Jest też kwestia komponentów dostawcy jako klientów Keystore. Obecnie nie mamy możliwości utworzenia przestrzeni nazw dla komponentów dostawców, np. klienta WPA.

Aby uwzględnić komponenty dostawców i uogólniać 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 odłączyć przestrzenie nazw od identyfikatorów UID. Klienci uzyskujący dostęp do klucza w Keystore muszą podać domenę, przestrzeń nazw i alias, do których chcą uzyskać dostęp. Na podstawie tej tupla 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 5 parametrów domeny, które określają sposób uzyskiwania dostępu do kluczy. Określają one semantykę parametru przestrzeni nazw w opisie klucza oraz sposób, w jaki jest wykonywana kontrola dostępu.

• DOMAIN_APP: domena aplikacji obejmuje starsze zachowanie. Domyślnie SPI Java KeyStore używa tej domeny. Gdy używasz tej domeny, argument namespace jest ignorowany, a zamiast niego używany jest identyfikator UID wywołującego. Dostęp do tej domeny jest kontrolowany przez etykietę Keystore dla klasy keystore_key w zasadach SELinux.
• DOMAIN_SELINUX: ta domena wskazuje, że przestrzeń nazw ma etykietę w zasadach SELinux. Parametr namespace jest wyszukiwany i przekształcany w kontekst docelowy, a następnie sprawdzane są uprawnienia w kontekście wywołania SELinux dla klasy keystore_key. Gdy uprawnienia do danej operacji zostaną ustalone, do wyszukiwania klucza zostanie użyty pełny tuple.
• DOMAIN_GRANT: domena grantu wskazuje, że parametr namespace jest identyfikatorem grantu. Parametr alias jest ignorowany. Kontrole SELinux są wykonywane podczas tworzenia uprawnień. Dalsze ustawienia kontroli dostępu sprawdzają tylko, czy identyfikator wywołującego jest zgodny z identyfikatorem beneficjenta żądanego uprawnienia.
• DOMAIN_KEY_ID: ta domena wskazuje, że parametr namespace jest unikalnym identyfikatorem klucza. Klucz mógł zostać utworzony za pomocą DOMAIN_APP lub DOMAIN_SELINUX. Sprawdzanie uprawnień jest wykonywane po załadowaniu z bazy danych kluczy wartości domain i namespace w taki sam sposób, jak gdyby blob został załadowany przez tupla domen, przestrzeni nazw i aliasów. Powodem utworzenia domeny identyfikatora klucza jest ciągłość. Gdy uzyskujesz dostęp do klucza za pomocą aliasu, 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. Identyfikator klucza nigdy się jednak nie zmienia. Dlatego gdy używasz klucza według identyfikatora klucza po jego załadowaniu z bazy danych Keystore za pomocą aliasu, możesz mieć pewność, że jest to ten sam klucz, o ile identyfikator klucza nadal istnieje. Ta funkcja nie jest dostępna dla deweloperów aplikacji. Zamiast tego jest on używany w interfejsie Android Keystore SPI, aby zapewnić bardziej spójne działanie nawet wtedy, gdy jest używany jednocześnie w niebezpieczny sposób.
• DOMAIN_BLOB: domena bloba wskazuje, że wywołujący zarządza blobem samodzielnie. Jest to używane w przypadku klientów, którzy muszą uzyskać dostęp do Keystore przed zamontowaniem partycji danych. Blob klucza jest zawarty w polu blob opisu klucza.

Za pomocą domeny SELinux możemy przyznać komponentom dostawcy dostęp do bardzo konkretnych przestrzeni nazw Keystore, które mogą być udostępniane przez komponenty systemu, takie jak okno ustawień.

Zasada SELinux dla keystore_key

Etykiety przestrzeni nazw są konfigurowane za pomocą pliku 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 umożliwić wpa_supplicant pobieranie i używanie kluczy w nowej przestrzeni nazw, do pliku hal_wifi_supplicant.te dodamy ten wiersz:

allow hal_wifi_supplicant wifi_key:keystore2_key { get, use };

Po skonfigurowaniu nowej przestrzeni nazw można używać AndroidKeyStore prawie tak samo jak zwykle. Jedyną różnicą jest to, że musisz podać identyfikator przestrzeni nazw. Podczas wczytywania i importowania kluczy z magazynu kluczy lub do niego identyfikator przestrzeni nazw jest określany za pomocą parametru 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ć identyfikator tej przestrzeni za pomocą elementu KeyGenParameterSpec.Builder#setNamespace():.

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

Aby skonfigurować metryki SELinux Keystore 2.0, możesz użyć tych plików kontekstu. Każda partycja ma inny zarezerwowany zakres 10 tysięcy 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 wysyła żądanie klucza, prosząc o domenę SELinux i wybraną przestrzeń nazw wirtualną (w tym przypadku "wifi_key") za pomocą jej identyfikatora numerycznego.

Zdefiniowano też te przestrzenie nazw: Jeśli zastępują one reguły specjalne, w tabeli poniżej podano identyfikatory UID, które im odpowiadają.

Wektory dostępu

Klasa SELinux keystore_key jest już dość stara, a niektóre uprawnienia, takie jak verify lub sign, straciły swoje znaczenie. Oto nowy zestaw uprawnień keystore2_key, który jest wymuszony przez Keystore 2.0.

Dodatkowo w ramach klasy zabezpieczeń SELinux keystore2 wyodrębniliśmy zestaw uprawnień klucza niebędących kluczami: