Cechy

Ta strona zawiera informacje o funkcjach kryptograficznych Keystore w systemie Android 6.0 i nowszych wersjach.

Uwaga: Tagi i funkcje są napisane w stylu Keymaster 3. Aby uzyskać więcej informacji, zobacz przegląd HIDL .

Prymitywy kryptograficzne

Magazyn kluczy udostępnia następujące kategorie operacji:

• Generacja klucza
• Import i eksport kluczy asymetrycznych (bez zawijania kluczy)
• Import surowych kluczy symetrycznych (bez zawijania kluczy)
• Asymetryczne szyfrowanie i deszyfrowanie z odpowiednimi trybami dopełniania
• Asymetryczne podpisywanie i weryfikacja z trawieniem i odpowiednimi trybami dopełniania
• Szyfrowanie i deszyfrowanie symetryczne w odpowiednich trybach, w tym w trybie AEAD
• Generowanie i weryfikacja symetrycznych kodów uwierzytelniających wiadomości

Elementy protokołu, takie jak cel, tryb i dopełnienie, a także ograniczenia kontroli dostępu , są określane podczas generowania lub importowania kluczy i są trwale powiązane z kluczem, dzięki czemu klucz nie może zostać użyty w żaden inny sposób.

Oprócz powyższej listy istnieje jeszcze jedna usługa, którą zapewniają implementacje Keymaster, ale która nie jest widoczna jako API: generowanie liczb losowych. Jest to używane wewnętrznie do generowania kluczy, wektorów inicjujących (IV), losowego dopełniania i innych elementów bezpiecznych protokołów, które wymagają losowości.

Niezbędne prymitywy

Wszystkie wdrożenia Keymaster zapewniają:

• RSA
  • Obsługa kluczy 2048, 3072 i 4096-bitowych
  • Obsługa wykładnika publicznego F4 (2^16+1)
  • Tryby dopełniania dla podpisywania RSA:
    • RSASSA-PSS ( PaddingMode::RSA_PSS )
    • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
  • Tryby podsumowania dla podpisywania RSA:
    • SHA-256
  • Tryby dopełniania dla szyfrowania/deszyfrowania RSA:
    • Niewyściełane
    • RSAES-OAEP ( PaddingMode::RSA_OAEP )
    • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
• ECDSA
  • Obsługiwana jest obsługa kluczy 224, 256, 384 i 521-bitowych, przy użyciu odpowiednio krzywych NIST P-224, P-256, P-384 i P-521
  • Tryby podsumowania dla ECDSA:
    • Brak podsumowania (przestarzałe, zostanie usunięte w przyszłości)
    • SHA-256
• AES
  • Obsługiwane są klucze 128 i 256-bitowe
  • CBC , CTR, EBC i GCM. Implementacja GCM nie pozwala na użycie znaczników mniejszych niż 96 bitów lub długości jednorazowej innej niż 96 bitów.
  • Tryby dopełniania PaddingMode::NONE i PaddingMode::PKCS7 są obsługiwane w trybach CBC i ECB. Bez dopełnienia szyfrowanie w trybie CBC lub EBC kończy się niepowodzeniem, jeśli dane wejściowe nie są wielokrotnością rozmiaru bloku.
• HMAC SHA-256 , z dowolnym rozmiarem klucza do co najmniej 32 bajtów.

Do implementacji Keymaster zdecydowanie zaleca się SHA1 i innych członków rodziny SHA2 (SHA-224, SHA384 i SHA512). Magazyn kluczy udostępnia je w oprogramowaniu, jeśli sprzętowa implementacja Keymaster ich nie zapewnia.

Niektóre prymitywy są również zalecane w celu zapewnienia współdziałania z innymi systemami:

• Mniejsze rozmiary kluczy dla RSA
• Arbitralni wykładnicy publiczni dla RSA

Kontrola dostępu do kluczy

Klucze sprzętowe, których nigdy nie można wyodrębnić z urządzenia, nie zapewniają dużego bezpieczeństwa, jeśli osoba atakująca może z nich korzystać do woli (chociaż są bezpieczniejsze niż klucze, które można wydobyć). Dlatego ważne jest, aby magazyn kluczy egzekwował kontrolę dostępu.

Kontrole dostępu definiuje się jako „listę autoryzacji” par tag/wartość. Tagi autoryzacyjne są 32-bitowymi liczbami całkowitymi, a wartości są różnych typów. Niektóre znaczniki mogą się powtarzać, aby określić wiele wartości. To, czy znacznik może się powtarzać, jest określone w dokumentacji znacznika . Po utworzeniu klucza obiekt wywołujący określa listę autoryzacji. Implementacja Keymaster leżąca u podstaw magazynu kluczy modyfikuje listę, aby określić dodatkowe informacje, takie jak to, czy klucz ma zabezpieczenie przed wycofaniem, i zwrócić „ostateczną” listę autoryzacji zakodowaną w zwróconym obiekcie blob klucza. Jakakolwiek próba użycia klucza do jakiejkolwiek operacji kryptograficznej zakończy się niepowodzeniem, jeśli ostateczna lista autoryzacji zostanie zmodyfikowana.

Dla Keymaster 2 i wcześniejszych zestaw możliwych tagów jest zdefiniowany w wyliczeniu keymaster_authorization_tag_t i jest na stałe ustalony (choć można go rozszerzać). Nazwy zostały poprzedzone KM_TAG . Do wskazania typu używane są cztery górne bity identyfikatorów znaczników.

Keymaster 3 zmienił przedrostek KM_TAG na Tag:: .

Możliwe typy obejmują:

ENUM : Wiele wartości tagów jest zdefiniowanych w wyliczeniach. Na przykład możliwe wartości TAG::PURPOSE są zdefiniowane w wyliczeniu keymaster_purpose_t .

ENUM_REP : To samo co ENUM , z tą różnicą, że tag może się powtórzyć na liście autoryzacji. Powtórzenie oznacza wiele autoryzowanych wartości. Na przykład klucz szyfrowania prawdopodobnie ma KeyPurpose::ENCRYPT i KeyPurpose::DECRYPT .

UINT : 32-bitowe liczby całkowite bez znaku. Przykład: TAG::KEY_SIZE

UINT_REP : To samo co UINT , z tą różnicą, że znacznik może się powtarzać na liście autoryzacji. Powtórzenie oznacza wiele autoryzowanych wartości.

ULONG : 64-bitowe liczby całkowite bez znaku. Przykład: TAG::RSA_PUBLIC_EXPONENT

ULONG_REP : To samo co ULONG , z tą różnicą, że tag może się powtórzyć na liście autoryzacji. Powtórzenie oznacza wiele autoryzowanych wartości.

DATE : Wartości daty/godziny wyrażone w milisekundach od 1 stycznia 1970. Przykład: TAG::PRIVKEY_EXPIRE_DATETIME

BOOL : Prawda czy fałsz. Zakłada się, że znacznik typu BOOL ma wartość „false”, jeśli tag nie istnieje, i „true”, jeśli jest obecny. Przykład: TAG::ROLLBACK_RESISTANT

BIGNUM : Liczby całkowite o dowolnej długości, wyrażone jako tablica bajtów w kolejności big-endian. Przykład: TAG::RSA_PUBLIC_EXPONENT

BYTES : Sekwencja bajtów. Przykład: TAG::ROOT_OF_TRUST

Egzekwowanie sprzętu i oprogramowania

Nie wszystkie bezpieczne implementacje sprzętu zawierają te same funkcje. Aby wspierać różne podejścia, Keymaster rozróżnia odpowiednio bezpieczne i niezabezpieczone egzekwowanie kontroli dostępu do świata lub egzekwowanie, odpowiednio, sprzętu i oprogramowania.

Wszystkie wdrożenia:

• Wymuś dokładne dopasowanie (nie egzekwowanie) wszystkich autoryzacji. Listy autoryzacji w kluczowych obiektach blob dokładnie odpowiadają autoryzacjom zwracanym podczas generowania kluczy, łącznie z zamawianiem. Jakakolwiek niezgodność powoduje diagnostykę błędu.
• Zadeklaruj autoryzacje, których wartości semantyczne są wymuszane.

Mechanizm API służący do deklarowania autoryzacji wymuszanych sprzętowo znajduje się w strukturze keymaster_key_characteristics_t . Dzieli listę autoryzacji na dwie podlisty, hw_enforced i sw_enforced . Bezpieczny sprzęt jest odpowiedzialny za umieszczenie odpowiednich wartości w każdym z nich, w oparciu o to, co może wymusić.

Ponadto Keystore wdraża oparte na oprogramowaniu wymuszanie wszystkich autoryzacji, niezależnie od tego, czy są one wymuszane przez bezpieczny sprzęt, czy nie.

Rozważmy na przykład implementację opartą na TrustZone, która nie obsługuje wygaśnięcia klucza. Nadal można utworzyć klucz z datą ważności. Lista autoryzacji tego klucza będzie zawierać tag TAG::ORIGINATION_EXPIRE_DATETIME z datą ważności. Żądanie do magazynu kluczy dotyczące kluczowych cech spowoduje odnalezienie tego znacznika na liście sw_enforced , a bezpieczny sprzęt nie będzie wymuszał wymogu wygaśnięcia. Jednakże próby użycia klucza po jego wygaśnięciu zostaną odrzucone przez Keystore.

Jeśli urządzenie zostanie następnie zaktualizowane przy użyciu bezpiecznego sprzętu, który obsługuje wygaśnięcie, wówczas żądanie dotyczące kluczowych cech znajdzie TAG::ORIGINATION_EXPIRE_DATETIME na liście hw_enforced , a próby użycia klucza po wygaśnięciu zakończą się niepowodzeniem, nawet jeśli magazyn kluczy zostanie w jakiś sposób obalony lub ominięty .

Aby uzyskać więcej informacji na temat określania, czy klucze są wspierane sprzętowo, zobacz Atestowanie klucza .

Uprawnienia do konstruowania wiadomości kryptograficznych

Do określenia charakterystyki kryptograficznej operacji przy użyciu powiązanego klucza używane są następujące znaczniki: TAG::ALGORITHM , TAG::KEY_SIZE , TAG::BLOCK_MODE , TAG::PADDING , TAG::CALLER_NONCE i TAG::DIGEST

TAG::PADDING , TAG::DIGEST i PaddingMode::BLOCK_MODE są powtarzalne, co oznacza, że ​​z jednym kluczem może być powiązanych wiele wartości, a wartość, która ma zostać użyta, jest określana w czasie operacji.

Zamiar

Klucze mają powiązany zestaw celów, wyrażony jako jeden lub więcej wpisów autoryzacyjnych ze znacznikiem TAG::PURPOSE , który określa, w jaki sposób można ich używać. Cele są następujące:

• KeyPurpose::ENCRYPT
• KeyPurpose::DECRYPT
• KeyPurpose::SIGN
• KeyPurpose::VERIFY

Dowolny klucz może mieć dowolny podzbiór tych celów. Należy pamiętać, że niektóre kombinacje stwarzają problemy związane z bezpieczeństwem. Na przykład klucz RSA, którego można użyć zarówno do szyfrowania, jak i do podpisywania, umożliwia osobie atakującej przekonanie systemu do odszyfrowania dowolnych danych w celu wygenerowania podpisów.

Import i eksport

Keymaster obsługuje wyłącznie eksport kluczy publicznych w formacie X.509 oraz import:

• Pary kluczy publicznych i prywatnych w formacie PKCS#8 z kodowaniem DER, bez szyfrowania opartego na haśle
• Klucze symetryczne jako surowe bajty

Aby mieć pewność, że zaimportowane klucze będą mogły zostać odróżnione od bezpiecznie wygenerowanych kluczy, TAG::ORIGIN znajduje się na odpowiedniej liście autoryzacji kluczy. Na przykład, jeśli klucz został wygenerowany na bezpiecznym sprzęcie, TAG::ORIGIN o wartości KeyOrigin::GENERATED zostanie znaleziony na liście hw_enforced cech kluczy, natomiast klucz, który został zaimportowany na bezpieczny sprzęt będzie miał wartość KeyOrigin::IMPORTED .

Uwierzytelnianie użytkownika

Implementacje Secure Keymaster nie implementują uwierzytelniania użytkownika, ale zależą od innych zaufanych aplikacji, które to robią. Informacje na temat interfejsu implementowanego przez te aplikacje można znaleźć na stronie Gatekeeper .

Wymagania dotyczące uwierzytelniania użytkownika są określane za pomocą dwóch zestawów tagów. Pierwszy zestaw wskazuje, który użytkownik może używać klucza:

• TAG::ALL_USERS wskazuje, że klucz może być używany przez wszystkich użytkowników. Jeśli są obecne, TAG::USER_ID i TAG::USER_SECURE_ID nie są obecne.
• TAG::USER_ID posiada wartość numeryczną określającą ID autoryzowanego użytkownika. Należy pamiętać, że jest to identyfikator użytkownika systemu Android (w przypadku wielu użytkowników), a nie identyfikator UID aplikacji i jest on wymuszany wyłącznie przez niezabezpieczone oprogramowanie. Jeśli jest obecny, TAG::ALL_USERS nie jest obecny.
• TAG::USER_SECURE_ID ma 64-bitową wartość liczbową określającą bezpieczny identyfikator użytkownika, który jest dostarczany w bezpiecznym tokenie uwierzytelniającym w celu odblokowania użycia klucza. W przypadku powtórzenia klucz może zostać użyty, jeśli którakolwiek z wartości zostanie podana w bezpiecznym tokenie uwierzytelniającym.

Drugi zestaw wskazuje, czy i kiedy użytkownik musi zostać uwierzytelniony. Jeśli nie ma żadnego z tych tagów, ale TAG::USER_SECURE_ID jest obecny, przy każdym użyciu klucza wymagane jest uwierzytelnienie.

• NO_AUTHENTICATION_REQUIRED wskazuje, że uwierzytelnienie użytkownika nie jest wymagane, chociaż klucza nadal mogą używać tylko aplikacje działające jako użytkownicy określeni przez TAG::USER_ID .
• TAG::AUTH_TIMEOUT to wartość liczbowa określająca w sekundach, jak świeże musi być uwierzytelnienie użytkownika, aby autoryzować użycie klucza. Dotyczy to tylko operacji na kluczach prywatnych/tajnych. Operacje na kluczach publicznych nie wymagają uwierzytelniania. Limity czasu nie powodują ponownego uruchomienia; po ponownym uruchomieniu wszystkie klucze „nigdy nie są uwierzytelniane”. Limit czasu może być ustawiony na dużą wartość, aby wskazać, że wymagane jest uwierzytelnienie raz na rozruch (2^32 sekundy to ~136 lat; prawdopodobnie urządzenia z Androidem są uruchamiane ponownie częściej).

Wiązanie klienta

Powiązanie klienta, czyli powiązanie klucza z konkretną aplikacją kliencką, odbywa się poprzez opcjonalny identyfikator klienta i pewne opcjonalne dane klienta (odpowiednio TAG::APPLICATION_ID i TAG::APPLICATION_DATA ). Magazyn kluczy traktuje te wartości jako nieprzezroczyste obiekty blob, zapewniając jedynie, że te same obiekty blob prezentowane podczas generowania/importowania klucza są prezentowane przy każdym użyciu i są identyczne bajt po bajcie. Dane powiązania klienta nie są zwracane przez Keymaster. Osoba dzwoniąca musi to wiedzieć, aby móc skorzystać z klucza.

Ta funkcja nie jest dostępna dla aplikacji.

Wygaśnięcie

Magazyn kluczy obsługuje ograniczanie użycia klucza według daty. Początek ważności klucza i wygaśnięcie klucza mogą być powiązane z kluczem, a Keymaster odmówi wykonania operacji na kluczu, jeśli bieżąca data/godzina wykracza poza prawidłowy zakres. Zakres ważności klucza jest określony za pomocą tagów TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME . Rozróżnienie między „pochodzeniem” a „użyciem” opiera się na tym, czy klucz jest używany do „tworzenia” nowego zaszyfrowanego tekstu/podpisu/itp., czy też do „wykorzystania” istniejącego zaszyfrowanego tekstu/podpisu/itp. Należy pamiętać, że to rozróżnienie nie dotyczy zastosowań.

TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME są opcjonalne. W przypadku braku tagów zakłada się, że danego klucza można zawsze użyć do odszyfrowania/weryfikacji wiadomości.

Ponieważ czas zegara ściennego jest dostarczany w niezabezpieczonym świecie, jest mało prawdopodobne, że znaczniki związane z wygaśnięciem znajdą się na liście wymuszanej sprzętowo. Sprzętowe egzekwowanie wygaśnięcia wymagałoby, aby bezpieczny świat w jakiś sposób uzyskał zaufany czas i dane, na przykład za pośrednictwem protokołu odpowiedzi na wyzwanie z zaufanym zdalnym serwerem czasu.

Źródło wiązania zaufania

Magazyn kluczy wymaga, aby klucze były powiązane z głównym źródłem zaufania, czyli ciągiem bitowym dostarczanym do bezpiecznego sprzętu Keymaster podczas uruchamiania, najlepiej przez program ładujący. Ten ciąg bitowy jest kryptograficznie powiązany z każdym kluczem zarządzanym przez Keymaster.

Element główny zaufania składa się z klucza publicznego używanego do weryfikacji podpisu na obrazie rozruchowym i stanu blokady urządzenia. Jeśli klucz publiczny zostanie zmieniony, aby umożliwić użycie innego obrazu systemu lub jeśli zmieni się stan blokady, żaden z kluczy chronionych przez Keymaster utworzonych przez poprzedni system nie będzie użyteczny, chyba że zostanie przywrócony poprzedni katalog główny zaufania i system podpisany tym kluczem jest uruchamiany. Celem jest zwiększenie wartości kontroli dostępu do kluczy wymuszonej przez oprogramowanie poprzez uniemożliwienie systemowi operacyjnemu zainstalowanemu przez osobę atakującą użycia kluczy Keymaster.

Samodzielne klucze

Niektóre bezpieczne urządzenia Keymaster mogą zdecydować się na wewnętrzne przechowywanie materiału klucza i zwracanie uchwytów, a nie zaszyfrowanie materiału klucza. Mogą też zaistnieć inne przypadki, w których kluczy nie można użyć, dopóki nie będzie dostępny inny niezabezpieczony lub zabezpieczony komponent systemu światowego. Keymaster HAL pozwala wywołującemu zażądać, aby klucz był „samodzielny” za pośrednictwem znacznika TAG::STANDALONE , co oznacza, że ​​nie są wymagane żadne inne zasoby poza obiektem blob i działającym systemem Keymaster. Tagi powiązane z kluczem można sprawdzić, aby sprawdzić, czy klucz jest samodzielny. Obecnie zdefiniowano tylko dwie wartości:

• KeyBlobUsageRequirements::STANDALONE
• KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Ta funkcja nie jest dostępna dla aplikacji.

Prędkość

Po utworzeniu maksymalną prędkość użytkowania można określić za pomocą TAG::MIN_SECONDS_BETWEEN_OPS . Implementacje TrustZone odmawiają wykonywania operacji kryptograficznych na tym kluczu, jeśli operacja została wykonana mniej niż TAG::MIN_SECONDS_BETWEEN_OPS sekund wcześniej.

Prostym podejściem do wdrażania ograniczeń prędkości jest tabela kluczowych identyfikatorów i znaczników czasu ostatniego użycia. Ta tabela będzie prawdopodobnie miała ograniczony rozmiar, ale pomieści co najmniej 16 wpisów. W przypadku, gdy tabela jest pełna i nie można zaktualizować ani odrzucić żadnych wpisów, należy zabezpieczyć implementacje sprzętowe „bezpieczne w przypadku awarii”, preferując odrzucanie wszystkich operacji na klawiszach ograniczonych szybkością do czasu wygaśnięcia jednego z wpisów. Dopuszczalne jest, że wszystkie wpisy wygasają po ponownym uruchomieniu.

Klucze można również ograniczyć do n zastosowań na rozruch za pomocą TAG::MAX_USES_PER_BOOT . Wymaga to również tabeli śledzenia, która mieści co najmniej cztery klucze i również jest odporna na awarie. Należy pamiętać, że aplikacje nie będą mogły tworzyć kluczy ograniczonych do każdego rozruchu. Ta funkcja nie jest dostępna za pośrednictwem magazynu kluczy i jest zarezerwowana dla operacji systemowych.

Ta funkcja nie jest dostępna dla aplikacji.

Ponowne wysyłanie generatora liczb losowych

Ponieważ bezpieczny sprzęt generuje liczby losowe dla materiału klucza i wektorów inicjujących (IV), a sprzętowe generatory liczb losowych mogą nie zawsze być w pełni godne zaufania, Keymaster HAL zapewnia interfejs umożliwiający klientowi zapewnienie dodatkowej entropii, która zostanie zmieszana z losową wygenerowane liczby.

Użyj sprzętowego generatora liczb losowych jako głównego źródła początkowego. Dane początkowe dostarczane za pośrednictwem zewnętrznego interfejsu API nie mogą być jedynym źródłem losowości używanym do generowania liczb. Co więcej, zastosowana operacja mieszania musi zapewniać, że losowy wynik będzie nieprzewidywalny, jeśli którekolwiek ze źródeł materiału siewnego jest nieprzewidywalne.

Ta funkcja nie jest dostępna dla aplikacji, ale jest używana przez platformę, która regularnie zapewnia dodatkową entropię pobieraną z instancji Java SecureRandom do bezpiecznego sprzętu.