Funkcje

Zadbaj o dobrą organizację dzięki kolekcji Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.

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

Prymitywy kryptograficzne

Keystore udostępnia następujące kategorie operacji:

  • Generowanie kluczy
  • Import i eksport kluczy asymetrycznych (bez zawijania kluczy)
  • Import surowych kluczy symetrycznych (bez zawijania kluczy)
  • Szyfrowanie asymetryczne 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, zapewniając, że klucz nie może być 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 interfejs API: generowanie liczb losowych. Jest to używane wewnętrznie do generowania kluczy, wektorów inicjujących (IV), losowego wypełniania i innych elementów bezpiecznych protokołów, które wymagają losowości.

Niezbędne prymitywy

Wszystkie implementacje Keymaster zapewniają:

  • RPA
    • Obsługa kluczy 2048, 3072 i 4096-bitowych
    • Obsługa publicznego wykładnika F4 (2^16+1)
    • Tryby wypełniania dla podpisywania RSA:
      • RSASSA-PSS ( PaddingMode::RSA_PSS )
      • RSASSA-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_SIGN )
    • Tryby skrótu do podpisywania RSA:
      • SHA-256
    • Tryby dopełniania dla szyfrowania/deszyfrowania RSA:
      • Niewyściełany
      • RSAES-OAEP ( PaddingMode::RSA_OAEP )
      • RSAES-PKCS1-v1_5 ( PaddingMode::RSA_PKCS1_1_5_ENCRYPT )
  • ECDSA
    • Obsługiwane są klucze 224, 256, 384 i 521-bitowe przy użyciu odpowiednio krzywych NIST P-224, P-256, P-384 i P-521
    • Tryby skrótu 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 jednorazowych innych niż 96 bitów.
    • Tryby PaddingMode::NONE i PaddingMode::PKCS7 są obsługiwane w trybach CBC i ECB. Bez dopełnienia szyfrowanie w trybie CBC lub ECB 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.

SHA1 i inni członkowie rodziny SHA2 (SHA-224, SHA384 i SHA512) są zdecydowanie zalecane dla implementacji Keymaster. Keystore udostępnia je w oprogramowaniu, jeśli sprzętowa implementacja Keymaster ich nie zapewnia.

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

  • Mniejsze rozmiary kluczy dla RSA
  • Arbitralne publiczne wykładniki RSA

Kontrola dostępu do kluczy

Klucze sprzętowe, których nigdy nie można wydobyć z urządzenia, nie zapewniają dużego bezpieczeństwa, jeśli atakujący może ich użyć do woli (chociaż są one bezpieczniejsze niż klucze, które można wydobyć). Dlatego bardzo ważne jest, aby Keystore egzekwował kontrolę dostępu.

Kontrole dostępu są zdefiniowane jako „lista autoryzacji” par tag/wartość. Tagi autoryzacji są 32-bitowymi liczbami całkowitymi, a wartości są różnych typów. Niektóre tagi 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 osoba dzwoniąca określa listę autoryzacji. Implementacja Keymaster będąca podstawą magazynu kluczy modyfikuje listę, aby określić dodatkowe informacje, takie jak to, czy klucz ma ochronę przed wycofywaniem, i zwraca „ostateczną” listę autoryzacji zakodowaną w zwróconym obiekcie BLOB klucza. Każda próba użycia klucza do jakiejkolwiek operacji kryptograficznej kończy się niepowodzeniem, jeśli ostateczna lista autoryzacji zostanie zmodyfikowana.

W przypadku Keymaster 2 i wcześniejszych zestaw możliwych tagów jest zdefiniowany w wyliczeniu keymaster_authorization_tag_t i jest na stałe ustalony (chociaż można go rozszerzyć). Nazwy miały prefiks KM_TAG . Do wskazania typu używane są cztery górne bity identyfikatorów tagów.

Keymaster 3 zmienił prefiks KM_TAG na Tag:: .

Możliwe typy to:

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ę powtarzać na liście autoryzacji. Powtórzenie wskazuje na 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 tag może być powtórzony na liście autoryzacji. Powtórzenie wskazuje na 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ę powtarzać na liście autoryzacji. Powtórzenie wskazuje na wiele autoryzowanych wartości.

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

BOOL : Prawda lub fałsz. Zakłada się, że znacznik typu BOOL jest „fałszywy”, jeśli nie istnieje, i „prawda”, 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 a oprogramowanie

Nie wszystkie bezpieczne implementacje sprzętowe zawierają te same funkcje. Aby wesprzeć różne podejścia, Keymaster rozróżnia między bezpiecznym i niezabezpieczonym wymuszaniem kontroli dostępu do świata lub wymuszeniem odpowiednio sprzętu i oprogramowania.

Wszystkie realizacje:

  • Egzekwuj dokładne dopasowanie (nie egzekwowanie) wszystkich autoryzacji. Listy autoryzacji w kluczowych obiektach blob dokładnie odpowiadają autoryzacji zwracanej podczas generowania klucza, w tym porządkowania. Każda niezgodność powoduje diagnostykę błędu.
  • Zadeklaruj uprawnienia, których wartości semantyczne są wymuszane.

Mechanizm API 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ą wygaśnięcia. Żądanie do magazynu kluczy o charakterystykę klucza spowoduje znalezienie tego tagu na liście sw_enforced , a bezpieczny sprzęt nie wymusza wymogu wygaśnięcia. Jednak próby użycia klucza po wygaśnięciu będą odrzucane przez Keystore.

Jeśli urządzenie zostanie następnie zaktualizowane przy użyciu bezpiecznego sprzętu, który obsługuje wygaśnięcie, żądanie charakterystyki klucza znajdzie TAG::ORIGINATION_EXPIRE_DATETIME 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 obrócony lub pominięty .

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

Uprawnienia do tworzenia wiadomości kryptograficznych

Następujące znaczniki służą do definiowania charakterystyk kryptograficznych operacji przy użyciu powiązanego klucza: 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 ​​wiele wartości może być skojarzonych z jednym kluczem, a wartość, która ma być użyta, jest określona w czasie operacji.

Zamiar

Klucze mają skojarzony zestaw celów, wyrażony jako jeden lub więcej wpisów autoryzacji ze znacznikiem TAG::PURPOSE , który definiuje sposób ich użycia. Cele to:

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

Każdy klucz może mieć dowolny podzbiór tych celów. Zauważ, że niektóre kombinacje powodują problemy z bezpieczeństwem. Na przykład klucz RSA, który może być używany zarówno do szyfrowania, jak i do podpisywania, umożliwia atakującemu przekonanie systemu do odszyfrowania dowolnych danych w celu wygenerowania podpisów.

Importuj i eksportuj

Keymaster obsługuje tylko eksport kluczy publicznych w formacie X.509 oraz import:

  • Pary kluczy publicznych i prywatnych w formacie PKCS#8 zakodowanym DER, bez szyfrowania opartego na hasłach
  • Klucze symetryczne jako surowe bajty

Aby zapewnić, że importowane klucze można odróżnić 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 klucza, podczas gdy klucz zaimportowany na bezpieczny sprzęt będzie miał wartość KeyOrigin::IMPORTED .

Uwierzytelnianie użytkownika

Implementacje Secure Keymaster nie implementują uwierzytelniania użytkowników, ale zależą od innych zaufanych aplikacji, które to robią. Aby zapoznać się z interfejsem implementowanym przez te aplikacje, zobacz stronę Gatekeeper .

Wymagania dotyczące uwierzytelniania użytkowników 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 ma wartość liczbową określającą ID autoryzowanego użytkownika. Zwróć uwagę, że jest to identyfikator użytkownika Androida (dla wielu użytkowników), a nie UID aplikacji i jest wymuszany tylko 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 podany w bezpiecznym tokenie uwierzytelniania w celu odblokowania użycia klucza. Jeśli zostanie powtórzony, klucz może zostać użyty, jeśli dowolna z wartości jest podana w bezpiecznym tokenie uwierzytelniania.

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

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

Wiązanie klienta

Wiązanie klienta, skojarzenie klucza z konkretną aplikacją kliencką, odbywa się za pomocą opcjonalnego identyfikatora klienta i niektórych opcjonalnych danych klienta (odpowiednio TAG::APPLICATION_ID i TAG::APPLICATION_DATA ). Magazyn kluczy traktuje te wartości jako nieprzezroczyste obiekty blob, zapewniając tylko, że te same obiekty blob prezentowane podczas generowania/importowania klucza są prezentowane dla każdego użycia i są identyczne bajt po bajcie. Dane powiązania klienta nie są zwracane przez Keymaster. Dzwoniący musi go znać, aby użyć klucza.

Ta funkcja nie jest dostępna dla aplikacji.

Wygaśnięcie

Keystore obsługuje ograniczanie użycia klucza według daty. Początek ważności klucza i data wygaśnięcia klucza mogą być powiązane z kluczem, a Keymaster odmawia 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 ::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME . Rozróżnienie między „pochodzeniem” a „użytkowaniem” opiera się na tym, czy klucz jest używany do „pochodzenia” nowego zaszyfrowanego tekstu/podpisu/itd., czy do „używania” istniejącego zaszyfrowanego tekstu/podpisu/itd. Zauważ, że to rozróżnienie nie jest widoczne dla aplikacji.

TAG::ACTIVE_DATETIME , TAG::ORIGINATION_EXPIRE_DATETIME ::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME są opcjonalne. Jeśli tagi są nieobecne, zakłada się, że dany klucz może być zawsze użyty do odszyfrowania/weryfikacji wiadomości.

Ponieważ czas na zegarze ściennym jest dostarczany przez świat niezabezpieczony, jest mało prawdopodobne, że tagi związane z wygaśnięciem ważności znajdą się na liście wymuszonych 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 wezwania odpowiedzi z zaufanym zdalnym serwerem czasu.

Wiążący korzeń zaufania

Keystore wymaga, aby klucze były powiązane z korzeniem zaufania, który jest ciągiem bitów dostarczanym do bezpiecznego sprzętu Keymaster podczas uruchamiania, najlepiej przez bootloader. Ten ciąg bitów jest kryptograficznie powiązany z każdym kluczem zarządzanym przez Keymaster.

Korzeń 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 utworzony przez poprzedni system nie będzie nadawał się do użytku, chyba że zostanie przywrócony poprzedni rdzeń zaufania i system który jest podpisany przez ten klucz jest uruchamiany. Celem jest zwiększenie wartości kontroli dostępu do kluczy wymuszanych przez oprogramowanie, uniemożliwiając systemowi operacyjnemu zainstalowanemu przez atakującego korzystanie z kluczy Keymaster.

Samodzielne klawisze

Niektóre bezpieczne urządzenia Keymaster mogą zdecydować się na wewnętrzne przechowywanie materiału klucza i zwracanie uchwytów zamiast zaszyfrowanego materiału klucza. Lub mogą istnieć inne przypadki, w których klucze nie mogą być używane, dopóki nie będzie dostępny inny niezabezpieczony lub bezpieczny światowy składnik systemu. Keymaster HAL umożliwia wywołującemu żądanie, aby klucz był „samodzielny” za pośrednictwem tagu TAG::STANDALONE , co oznacza, że ​​nie są wymagane żadne inne zasoby niż obiekt blob i działający system Keymaster. Tagi skojarzone z kluczem mogą być sprawdzane w celu sprawdzenia, czy klucz jest samodzielny. Obecnie zdefiniowane są tylko dwie wartości:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Ta funkcja nie jest dostępna dla aplikacji.

Prędkość

Po utworzeniu maksymalną szybkość użycia można określić za pomocą TAG::MIN_SECONDS_BETWEEN_OPS . Implementacje TrustZone odmawiają wykonywania operacji kryptograficznych za pomocą tego klucza, jeśli operacja została wykonana mniej niż TAG::MIN_SECONDS_BETWEEN_OPS sekundy wcześniej.

Prostym podejściem do implementacji ograniczeń prędkości jest tabela kluczowych identyfikatorów i sygnatur czasowych ostatniego użycia. Ta tabela prawdopodobnie będzie miała ograniczony rozmiar, ale pomieści co najmniej 16 wpisów. W przypadku, gdy tablica jest pełna i żadne wpisy nie mogą zostać zaktualizowane lub odrzucone, implementacje sprzętu zabezpieczającego „fail safe”, preferując odrzucanie wszystkich operacji na klawiszach o ograniczonej prędkości do czasu wygaśnięcia jednego z wpisów. Dopuszczalne jest, aby wszystkie wpisy wygasały po ponownym uruchomieniu.

Klawisze można również ograniczyć do n użyć na rozruch za pomocą TAG::MAX_USES_PER_BOOT . Wymaga to również stołu śledzącego, który mieści co najmniej cztery klucze, a także jest bezpieczny w razie awarii. Pamiętaj, że aplikacje nie będą mogły tworzyć kluczy ograniczonych do rozruchu. Ta funkcja nie jest ujawniana przez Keystore i jest zarezerwowana dla operacji systemowych.

Ta funkcja nie jest dostępna dla aplikacji.

Ponowne wysiewanie 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 losowymi wygenerowane liczby.

Użyj sprzętowego generatora liczb losowych jako podstawowego źródła nasion. Dane źródłowe dostarczane przez zewnętrzny interfejs API nie mogą być jedynym źródłem losowości używanej do generowania liczb. Ponadto zastosowana operacja mieszania musi zapewnić, że losowe wyjście jest nieprzewidywalne, jeśli którekolwiek ze źródeł nasion jest nieprzewidywalne.

Ta funkcja nie jest widoczna dla aplikacji, ale jest używana przez platformę, która regularnie zapewnia dodatkową entropię, pobieraną z instancji Java SecureRandom, na bezpieczny sprzęt.