Funkcje

Ta strona zawiera informacje o funkcjach kryptograficznych Keystore w Androidzie 6.0 lub nowszym.

Elementy podstawowe kryptografii

Keystore udostępnia te kategorie operacji:

  • Generowanie kluczy
  • importowanie i eksportowanie kluczy asymetrycznych (bez owijania klucza);
  • importowanie nieprzetworzonych kluczy symetrycznych (bez owijania klucza);
  • szyfrowanie i odszyfrowywanie asymetryczne z odpowiednimi trybami wypełniania;
  • podpisywanie i weryfikowanie asymetryczne z wykorzystaniem funkcji digest i odpowiednich trybów wypełniania
  • szyfrowanie i odszyfrowywanie symetryczne w odpowiednich trybach, w tym trybie AEAD;
  • generowanie i weryfikacja kodów uwierzytelniania wiadomości symetrycznych;

Elementy protokołu, takie jak cel, tryb i wypełnienie, a także ograniczenia kontroli dostępu, są określane podczas generowania lub importowania kluczy i są na stałe powiązane z kluczem, co gwarantuje, że nie można go używać w inny sposób.

Oprócz wymienionych powyżej usług implementacje Keymaster oferują jeszcze jedną usługę, która nie jest udostępniana jako interfejs API: generowanie liczb losowych. Jest on używany wewnętrznie do generowania kluczy, wektorów inicjujących (IV), losowego wypełniania i innych elementów protokołów bezpiecznych, które wymagają losowości.

Elementy podstawowe

Wszystkie implementacje Keymaster zapewniają:

  • RSA
    • Obsługa kluczy 2048-, 3072- i 4096-bitowych
    • Obsługa publicznego wykładnika F4 (2^16+1)
    • Tryby wypełniania danych do 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 wypełniania danych do szyfrowania i odszyfrowania RSA:
      • Bez wypełnienia
      • 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, odpowiednio dla krzywych NIST P-224, P-256, P-384 i P-521.
    • Tryby podsumowania dla ECDSA:
      • Brak digest (wycofane, zostanie usunięte w przyszłości)
      • SHA-256
  • AES
    • Obsługiwane są klucze 128- i 256-bitowe
    • CBC, CTR, ECB i GCM. Implementacja GCM nie zezwala na używanie tagów krótszych niż 96 bitów ani losowych ciągów znaków o długości innej niż 96 bitów.
    • Tryby wypełniania PaddingMode::NONE i PaddingMode::PKCS7 są obsługiwane w trybach CBC i ECB. W trybie bez wypełniania CBC lub ECB szyfrowanie nie działa, jeśli dane wejściowe nie są wielokrotnością rozmiaru bloku.
  • HMAC SHA-256 z dowolnym rozmiarem klucza do co najmniej 32 bajtów.

W przypadku implementacji Keymaster zdecydowanie zalecamy użycie algorytmu SHA1 oraz innych członków rodziny SHA2 (SHA-224, SHA384 i SHA512). Keystore udostępnia je w oprogramowaniu, jeśli implementacja Keymaster na poziomie sprzętowym ich nie udostępnia.

Niektóre prymity są też zalecane ze względu na interoperacyjność z innymi systemami:

  • Mniejsze rozmiary kluczy RSA
  • dowolne publiczne wykładniki w elastycznych reklamach w wyszukiwarce,

Kontrola dostępu do klucza

Klucze sprzętowe, których nie można wyodrębnić z urządzenia, nie zapewniają dużej ochrony, jeśli atakujący może ich używać według uznania (chociaż są bezpieczniejsze niż klucze, które można wyodrębnić). Dlatego tak ważne jest, aby Keystore stosował kontrolę dostępu.

Kontrole dostępu są definiowane jako „lista autoryzacji” par tagów i wartości. Tagi autoryzacji to 32-bitowe liczby całkowite, a ich wartości mają różne typy. Niektóre tagi można powtarzać, aby określić większą liczbę wartości. Możliwość powtarzania tagu jest określona w interfejsie HAL KeyMint (wcześniej Keymaster). Podczas tworzenia klucza wywołujący określa listę autoryzacji. Implementacja Keymaster w Keystore modyfikuje listę, aby podać dodatkowe informacje, takie jak to, czy klucz ma ochronę przed cofnięciem, i zwrócić „ostateczną” listę autoryzacji zakodowaną w zwróconym pliku danych 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 starszych zestaw możliwych tagów jest zdefiniowany w enumeracji keymaster_authorization_tag_t i jest stały (chociaż można go rozszerzyć). Nazwy miały prefiks KM_TAG. Typ określają 4 najstarsze bity identyfikatorów tagów.

Keymaster 3 zmienił prefiks KM_TAG na Tag::.

Możliwe typy:

ENUM: wiele wartości tagów jest zdefiniowanych w układach. Na przykład możliwe wartości atrybutu TAG::PURPOSE są zdefiniowane w typie wyliczeniowym keymaster_purpose_t.

ENUM_REP: to samo co ENUM, z tym że tag może być powtórzony na liście autoryzacji. Powtórzenie wskazuje na wiele autoryzowanych wartości. Na przykład klucz szyfrowania ma prawdopodobnie wartości 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 tym ż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 tym że tag może być powtórzony 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: wartość true lub false. Tag typu BOOL ma wartość „false” (fałsz), jeśli go nie ma, i „true” (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 formacie big-endian. Przykład: TAG::RSA_PUBLIC_EXPONENT

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

Egzekwowanie zasad za pomocą sprzętu a oprogramowania

Nie wszystkie implementacje zabezpieczeń sprzętowych zawierają te same funkcje. Aby obsługiwać różne podejścia, Keymaster rozróżnia bezpieczne i niebezpieczne egzekwowanie kontroli dostępu do świata, czyli egzekwowanie sprzętowe i oprogramowanie.

Wszystkie implementacje:

  • Wymuszanie dopasowania dokładnego (nie wymuszanie) wszystkich autoryzacji. Listy autoryzacji w plikach kluczy dokładnie odpowiadają autoryzacjom zwróconym podczas generowania kluczy, w tym ich kolejności. Każda niezgodność powoduje diagnostykę błędu.
  • Zadeklaruj autoryzacje, których wartości semantyczne są wymuszane.

Mechanizm interfejsu API do deklarowania autoryzacji na podstawie sprzętu znajduje się w strukturze keymaster_key_characteristics_t. Dzieli listę autoryzacji na 2 listy podrzędne: hw_enforced i sw_enforced. Bezpieczny sprzęt odpowiada za umieszczanie odpowiednich wartości w każdym z nich na podstawie tego, co może wymusić.

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

Rozważ na przykład implementację opartą na TrustZone, która nie obsługuje wygaśnięcia klucza. Klucz z datą ważności może zostać utworzony. Lista autoryzowanych kluczy zawiera tag TAG::ORIGINATION_EXPIRE_DATETIME z datą ważności. Żądanie wysłane do Keystore w celu uzyskania informacji o charakterystyce klucza znajduje ten tag na liście sw_enforced, a bezpieczny sprzęt nie wymusza wymagań dotyczących wygaśnięcia. Jednak próby użycia klucza po upływie jego ważności są odrzucane przez Keystore.

Jeśli urządzenie zostanie następnie zaktualizowane o bezpieczne komponenty sprzętowe, które obsługują wygaśnięcie, żądanie dotyczące klucza znajdzieTAG::ORIGINATION_EXPIRE_DATETIME na liściehw_enforced, a próby użycia klucza po wygaśnięciu nie będą skuteczne, nawet jeśli magazyn kluczy zostanie zmanipulowany lub omiń.

Więcej informacji o tym, jak określić, czy klucze są obsługiwane przez sprzęt, znajdziesz w artykule Weryfikacja kluczy.

Autoryzacja tworzenia wiadomości kryptograficznych

Do definiowania właściwości kryptograficznych operacji korzystających z powiązanego klucza służą te tagi: TAG::ALGORITHM, TAG::KEY_SIZE, TAG::BLOCK_MODE, TAG::PADDING, TAG::CALLER_NONCE i TAG::DIGEST.

Parametry TAG::PADDING, TAG::DIGEST i PaddingMode::BLOCK_MODE są powtarzalne, co oznacza, że do jednego klucza można przypisać wiele wartości, a wartość, której należy użyć, jest określana w momencie wykonania operacji.

Cel

Klucze mają powiązany zestaw celów wyrażony za pomocą co najmniej 1 wejścia autoryzacji z tagiem TAG::PURPOSE, który określa sposób ich użycia. Cele te to:

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

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

Importowanie i eksportowanie

Keymaster obsługuje eksportowanie kluczy publicznych w formacie X.509 oraz importowanie:

  • pary kluczy publicznych i prywatnych w formacie PKCS#8 zakodowanym w formacie DER bez szyfrowania za pomocą hasła;
  • Klucze symetryczne jako nieprzetworzone bajty

Aby można było odróżnić zaimportowane klucze od wygenerowanych w bezpiecznym trybie, na odpowiedniej liście autoryzacji kluczy znajduje się wartość TAG::ORIGIN. Jeśli na przykład klucz został wygenerowany na bezpiecznym sprzęcie, TAG::ORIGIN z wartością KeyOrigin::GENERATED znajduje się na liście hw_enforced kluczowych właściwości, a klucz zaimportowany na bezpieczny sprzęt ma wartość KeyOrigin::IMPORTED.

Uwierzytelnianie użytkowników

Implementacje Secure Keymaster nie implementują uwierzytelniania użytkownika, ale polegają na innych zaufanych aplikacjach, które to robią. Interfejs implementowany przez te aplikacje znajdziesz na stronie Gatekeeper.

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

  • TAG::ALL_USERS oznacza, że klucz może używać każdy użytkownik. Jeśli występuje, TAG::USER_ID i TAG::USER_SECURE_ID nie występują.
  • TAG::USER_ID ma wartość liczbową, która określa identyfikator autoryzowanego użytkownika. Pamiętaj, że jest to identyfikator użytkownika Androida (w przypadku wielu użytkowników), a nie identyfikator UID aplikacji. Jest on stosowany tylko w niebezpiecznym oprogramowaniu. Jeśli występuje, TAG::ALL_USERS nie występuje.
  • TAG::USER_SECURE_ID ma 64-bitową wartość liczbową, która określa bezpieczny identyfikator użytkownika podany w bezpiecznym tokenie uwierzytelniania, aby umożliwić użycie klucza. Jeśli klucz jest powtarzany, można go użyć, jeśli dowolna z wartości jest podana w tokenie bezpiecznego uwierzytelniania.

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

  • NO_AUTHENTICATION_REQUIRED oznacza, że nie jest wymagane uwierzytelnianie użytkownika, ale klucz może być używany tylko przez aplikacje działające jako użytkownicy wskazani 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 z kluczem prywatnym/tajnym. Operacje dotyczące kluczy publicznych nie wymagają uwierzytelniania. Limity czasu nie są przenoszone na ponowne uruchomienie; po ponownym uruchomieniu wszystkie klucze nigdy nie są uwierzytelniane. Czas oczekiwania można ustawić na dużą wartość, aby wskazać, że uwierzytelnianie jest wymagane raz na uruchamianie (2^32 sekund to około 136 lat; prawdopodobnie urządzenia z Androidem są uruchamiane częściej).

Wymagaj odblokowania urządzenia

Klucze z TAG::UNLOCKED_DEVICE_REQUIRED można używać tylko wtedy, gdy urządzenie jest odblokowane. Szczegółowe informacje o semantyce znajdziesz w  KeyProtection.Builder#setUnlockedDeviceRequired(boolean).

UNLOCKED_DEVICE_REQUIRED jest wymuszane przez Keystore, a nie przez Keymaster. W Androidzie 12 i nowszych Keystore chroni klucze UNLOCKED_DEVICE_REQUIRED za pomocą kryptografii, gdy urządzenie jest zablokowane. Dzięki temu w większości przypadków nie można ich użyć, nawet jeśli Keystore zostanie naruszony, gdy urządzenie jest zablokowane.

Aby to osiągnąć, Keystore „superszyfruje” wszystkie klucze UNLOCKED_DEVICE_REQUIRED przed zapisaniem ich w bazie danych. W miarę możliwości chroni klucze superszyfrowania (superklucze) podczas blokowania urządzenia w taki sposób, aby można je było odzyskać tylko po odblokowaniu urządzenia. (Używamy terminu „superszyfrowanie”, ponieważ ten poziom szyfrowania jest stosowany oprócz poziomu szyfrowania, który Keymaster stosuje już do wszystkich kluczy.)

Każdy użytkownik (w tym profile) ma 2 klucze superadministratora powiązane z kontem UNLOCKED_DEVICE_REQUIRED:

  • Symetryczny superklucz UnlockedDeviceRequired. To jest klucz AES-256-GCM. Szyfruje klucze UNLOCKED_DEVICE_REQUIRED, które są importowane lub generowane, gdy urządzenie jest odblokowane dla użytkownika.
  • Asymetryczny superklucz UnlockedDeviceRequired. To para kluczy ECDH P‑521. Szyfruje klucze UNLOCKED_DEVICE_REQUIRED, które są importowane lub generowane, gdy urządzenie jest zablokowane dla użytkownika. Klucze zaszyfrowane za pomocą tego klucza asymetrycznego są ponownie szyfrowane za pomocą klucza symetrycznego przy pierwszym użyciu (co może nastąpić tylko wtedy, gdy urządzenie jest odblokowane).

Keystore generuje te superklucze w momencie tworzenia użytkownika i przechowuje je w swojej bazie danych, szyfrowanej za pomocą syntetycznego hasła użytkownika. Dzięki temu można je odzyskać, używając kodu PIN, wzoru lub hasła.

Keystore przechowuje te superklucze w pamięci podręcznej, co pozwala mu działać na kluczach UNLOCKED_DEVICE_REQUIRED. Jednak próbuje zapisać w pamięci podręcznej tajne części tych kluczy tylko wtedy, gdy urządzenie jest odblokowane. Gdy urządzenie jest zablokowane dla użytkownika, Keystore w miarę możliwości zeroizuje kopię w pamięci podręcznej tych tajnych części superkluczy. W szczególności, gdy urządzenie jest zablokowane dla użytkownika, Keystore wybiera i zastosowuje jeden z 3 poziomów ochrony dla superkluczy UnlockedDeviceRequired użytkownika:

  • Jeśli użytkownik ma włączone tylko zabezpieczenie za pomocą kodu PIN, wzorca lub hasła, Keystore zeroizuje tajne części superkluczy w pamięci podręcznej. Oznacza to, że superklucze można odzyskać tylko za pomocą zaszyfrowanej kopii w bazie danych, którą można odszyfrować tylko za pomocą kodu PIN, wzoru lub hasła.
  • Jeśli użytkownik ma tylko dane biometryczne klasy 3 („mocne”) oraz włączony kod PIN, wzór lub hasło, Keystore umożliwia odzyskanie superkluczy za pomocą dowolnych zarejestrowanych danych biometrycznych klasy 3 (zwykle odcisku palca) jako alternatywy dla kodu PIN, wzoru lub hasła. W tym celu generuje nowy klucz AES-256-GCM, szyfruje nim tajne części superkluczy, importuje klucz AES-256-GCM do Keymastera jako klucz powiązany z biometryką, który wymaga pomyślnego uwierzytelnienia biometrycznego w ciągu ostatnich 15 sekund, i zeruje zwykłe kopie wszystkich tych kluczy.
  • Jeśli użytkownik ma klucz biometryczny klasy 1 („wygodny”), klucz biometryczny klasy 2 („słaby”) lub aktywnego zaufanego agenta odblokowywania, Keystore przechowuje superklucze w prostym tekście w pamięci podręcznej. W takim przypadku zabezpieczenia kryptograficzne kluczy UNLOCKED_DEVICE_REQUIRED nie są zapewniane. Użytkownicy mogą uniknąć korzystania z mniej bezpiecznych metod, nie włączając tych metod odblokowania. Najczęstsze metody odblokowywania, które zaliczają się do tych kategorii, to rozpoznawanie twarzy na wielu urządzeniach oraz odblokowywanie za pomocą sparowanego zegarka.

Gdy urządzenie jest odblokowane dla użytkownika, Keystore odzyskuje, jeśli to możliwe, superklucze użytkownika UnlockedDeviceRequired. W przypadku odblokowania za pomocą kodu PIN, wzoru lub hasła odszyfrowuje kopię tych kluczy przechowywaną w bazie danych. W przeciwnym razie sprawdza, czy istnieje zapisana kopia tych kluczy zaszyfrowana kluczem powiązanym z danymi biometrycznymi, i jeśli tak, próbuje je odszyfrować. Ta operacja powiedzie się tylko wtedy, gdy użytkownik został uwierzytelniony za pomocą danych biometrycznych klasy 3 w ciągu ostatnich 15 sekund, zgodnie z wymaganiami Keymaster (a nie Keystore).

Powiązanie klienta

Powiązanie klienta, czyli powiązanie klucza z konkretną aplikacją klienta, odbywa się za pomocą opcjonalnego identyfikatora klienta i niektórych opcjonalnych danych klienta (odpowiednio TAG::APPLICATION_ID i TAG::APPLICATION_DATA). Keystore traktuje te wartości jako nieprzezroczyste bloby, zapewniając tylko, że te same bloby przedstawione podczas generowania lub importowania klucza są przedstawiane w przypadku każdego użycia i są identyczne bajt po bajcie. Keymaster nie zwraca danych wiązania klienta. Aby móc użyć kluczyka, dzwoniący musi go znać.

Ta funkcja nie jest dostępna w aplikacjach.

Wygaśnięcie

Keystore umożliwia ograniczenie użycia klucza według daty. Z kluczem można powiązać datę rozpoczęcia ważności i datę wygaśnięcia klucza. Keymaster odmawia wykonywania operacji na kluczu, jeśli bieżąca data i godzina wykraczają poza zakres ważności. Zakres ważności klucza jest określany za pomocą tagów TAG::ACTIVE_DATETIME, TAG::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME. Rozróżnienie między „wytworzeniem” a „używaniem” zależy od tego, czy klucz jest używany do „wytworzenia” nowego szyfrogramu/podpisu itd., czy do „używania” istniejącego szyfrogramu/podpisu itd. Pamiętaj, że to rozróżnienie nie jest widoczne w aplikacjach.

Tagi TAG::ACTIVE_DATETIME, TAG::ORIGINATION_EXPIRE_DATETIME i TAG::USAGE_EXPIRE_DATETIME są opcjonalne. Jeśli tagi są nieobecne, zakłada się, że klucz może być zawsze używany do odszyfrowywania lub weryfikowania wiadomości.

Czas zegarowy jest dostarczany przez niechroniony świat, więc mało prawdopodobne jest, aby tagi związane z wygaśnięciem znajdowały się na liście kontrolowanej przez sprzęt. Wymuszanie wygaśnięcia sprzętowego wymagałoby, aby bezpieczny świat w jakiś sposób uzyskał zaufane dane i czas, na przykład za pomocą protokołu odpowiedzi na wyzwanie z zaufanym zdalnym serwerem czasu.

Wiązanie z źródłem zaufania

Keystore wymaga, aby klucze były powiązane z rootem zaufania, czyli ciągiem bitów udostępnianym urządzeniu Keymaster podczas uruchamiania, najlepiej przez bootloader. Ten ciąg bitów jest powiązany kryptograficznie z każdym kluczem zarządzanym przez Keymaster.

Źródło zaufania składa się z klucza publicznego używanego do weryfikacji podpisu obrazu rozruchowego 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 Keymastera utworzonych przez poprzedni system nie będzie można użyć, chyba że przywrócisz poprzedni zaufanego administratora i uruchomisz system podpisany tym kluczem. Celem jest zwiększenie wartości kontroli dostępu do kluczy wymuszanych przez oprogramowanie poprzez uniemożliwienie używania kluczy Keymaster przez system operacyjny zainstalowany przez atakującego.

Klucze samodzielne

Niektóre urządzenia zabezpieczające Keymaster mogą przechowywać materiał klucza wewnętrznie i zwracać uchwyty zamiast zaszyfrowanego materiału klucza. Mogą też występować inne przypadki, w których kluczy nie można używać, dopóki nie będzie dostępne inne niechronione lub chronione środowisko systemu. Interfejs HAL Keymaster umożliwia wywołującemu poproszenie o to, aby klucz był „samodzielny” (za pomocą tagu TAG::STANDALONE), co oznacza, że nie są wymagane żadne zasoby inne niż blob i uruchomiony system Keymaster. Tagi powiązane z kluczem można sprawdzić, aby sprawdzić, czy klucz jest samodzielny. Obecnie zdefiniowane są tylko 2 wartości:

  • KeyBlobUsageRequirements::STANDALONE
  • KeyBlobUsageRequirements::REQUIRES_FILE_SYSTEM

Ta funkcja nie jest dostępna w aplikacjach.

Prędkość

Podczas tworzenia można określić maksymalną prędkość użytkowania za pomocą parametru TAG::MIN_SECONDS_BETWEEN_OPS. Implementacje TrustZone odmawiają wykonywania operacji kryptograficznych z użyciem tego klucza, jeśli operacja została wykonana mniej niż TAG::MIN_SECONDS_BETWEEN_OPS sekund wcześniej.

Prostym podejściem do wdrażania limitów szybkości jest tabela identyfikatorów kluczy i daty ostatniego użycia. Ta tabela ma ograniczony rozmiar, ale mieści co najmniej 16 elementów. Jeśli tabela jest pełna i nie można zaktualizować ani odrzucić żadnych wpisów, chronione implementacje sprzętowe „zabezpieczają się”, odrzucając wszystkie operacje na kluczach z ograniczoną prędkością, dopóki nie wygaśnie jeden z wpisów. Dopuszczalne jest, aby wszystkie wpisy wygasały po ponownym uruchomieniu.

Klucze mogą być też ograniczone do n użyć na uruchomienie z TAG::MAX_USES_PER_BOOT. Wymaga to też tabeli śledzenia, która zawiera co najmniej 4 klucze i działa w trybie awaryjnym. Pamiętaj, że aplikacje nie mogą tworzyć kluczy ograniczonych na czas rozruchu. Ta funkcja nie jest dostępna w Keystore i jest zarezerwowana do operacji systemowych.

Ta funkcja nie jest dostępna w aplikacjach.

Ponowne ustawienie generatora liczb losowych

Ponieważ bezpieczny sprzęt generuje losowe liczby dla klucza i wektorów inicjalizacji (IV), a generatory losowych liczb na sprzęcie nie zawsze są w pełni godne zaufania, interfejs Keymaster HAL umożliwia klientowi dostarczenie dodatkowej entropii, która jest mieszana z wygenerowanymi losowymi liczbami.

Jako główne źródło danych wyjściowych użyj sprzętowego generatora liczb losowych. Dane początkowe udostępniane przez zewnętrzny interfejs API nie mogą być jedynym źródłem losowości używanej do generowania liczb. Ponadto użyta operacja mieszania musi zapewnić, aby losowy wynik był nieprzewidywalny, jeśli którykolwiek z źródeł danych nasion jest nieprzewidywalny.

Ta funkcja nie jest dostępna dla aplikacji, ale jest używana przez framework, który regularnie dostarcza dodatkowej entropii do bezpiecznego sprzętu z użyciem instancji Java SecureRandom.