Funkcje

Ta strona zawiera informacje o funkcjach kryptograficznych Android Keystore, które są udostępniane przez implementację KeyMint (lub Keymaster).

Elementy podstawowe kryptografii

Keystore udostępnia te kategorie operacji:

• tworzenie kluczy, które powoduje powstanie materiału klucza prywatnego lub tajnego, dostępnego tylko dla bezpiecznego środowiska; Klucze można tworzyć na te sposoby:
  • Generowanie nowych kluczy
  • Importowanie niezaszyfrowanego materiału klucza
  • Importowanie zaszyfrowanego materiału klucza
• Potwierdzenie klucza: tworzenie klucza asymetrycznego generuje certyfikat zawierający część klucza publicznego pary kluczy. Ten certyfikat zawiera opcjonalnie również informacje o metadanych klucza i stanie urządzenia, wszystkie podpisane przez klucz łańcucha z powrotem do zaufanego głównego klucza.
• Operacje kryptograficzne:
  • Szyfrowanie i odszyfrowywanie symetryczne (AES, 3DES)
  • Odszyfrowywanie asymetryczne (RSA)
  • Podpis asymetryczny (ECDSA, RSA)
  • Symetryczne podpisywanie i weryfikacja (HMAC)
  • Uzgadnianie klucza asymetrycznego (ECDH)

Pamiętaj, że Keystore i KeyMint nie obsługują operacji na kluczach publicznych w przypadku kluczy asymetrycznych.

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 zapewnia, że nie można go używać w inny sposób.

Obiekty podstawowe i tryby, które musi obsługiwać implementacja KeyMint, są opisane w specyfikacji interfejsu HAL (IKeyMintDevice).

Podstawowa implementacja KeyMint musi generować liczby losowe, aby obsługiwać generowanie kluczy i tworzenie losowych wypełnień lub wektorów inicjalizacji (IV). W tym celu system Android co jakiś czas udostępnia dodatkowe dane entropijne implementacji KeyMint.

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 kluczowe znaczenie ma to, 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 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).

Obsługiwane wartości tagów są zdefiniowane w pliku Tag.aidl. Każda z nich jest powiązana z TagType, który wskazuje typ powiązanej wartości (np. liczba całkowita lub bajty) oraz czy można ją powtórzyć, aby określić wiele obsługiwanych wartości.

Gdy KeyMint tworzy klucz, wywołujący określa listę autoryzacji dla tego klucza. Ta lista jest modyfikowana przez Keystore i KeyMint, aby dodać dodatkowe ograniczenia, a implementacja KeyMint koduje ostateczną listę autoryzacji w zwracanym kluczu blob. Zaszyfrowana lista autoryzacji jest powiązana kryptograficznie z kluczem blob, więc każda próba zmodyfikowania listy autoryzacji (w tym jej uporządkowania) powoduje, że klucz blob staje się nieprawidłowy i nie można go używać do operacji kryptograficznych.

Egzekwowanie zasad za pomocą sprzętu a oprogramowania

Nie wszystkie chronione implementacje sprzętowe mają te same funkcje. Aby obsługiwać różne podejścia, KeyMint rozróżnia bezpieczne i niebezpieczne egzekwowanie kontroli dostępu, czyli odpowiednio sprzętowe i programowe egzekwowanie.

Jest on dostępny w interfejsie KeyMint API w polu securityLevel typu KeyCharacteristics. Bezpieczne urządzenie odpowiada za umieszczanie autoryzacji w KeyCharacteristics z odpowiednim poziomem zabezpieczeń, w zależności od tego, co może wymusić. Te informacje są też dostępne w rekordach uwierzytelniania kluczy asymetrycznych: kluczowe cechy klucza SecurityLevel::TRUSTED_ENVIRONMENT lub SecurityLevel::STRONGBOX są widoczne na liście hardwareEnforced, a cechy klucza SecurityLevel::SOFTWARE lub SecurityLevel::KEYSTORE na liście softwareEnforced.

Na przykład ograniczenia dotyczące przedziału dat i czasu, w którym można używać klucza, nie są zwykle wymuszane przez bezpieczne środowisko, ponieważ nie ma ono zaufanego dostępu do informacji o dacie i czasie. W związku z tym autoryzacje takie jak Tag::ORIGINATION_EXPIRE_DATETIME są wymuszane przez Keystore na Androidzie i miałyby wartość SecurityLevel::KEYSTORE.

Więcej informacji o tym, jak sprawdzić, czy klucze i ich autoryzacje są obsługiwane przez sprzęt, znajdziesz w artykule Potwierdzenie autentyczności klucza.

Autoryzacja tworzenia wiadomości kryptograficznych

Te tagi służą do definiowania właściwości kryptograficznych operacji wykonywanych przy użyciu powiązanego klucza:

• Tag::ALGORITHM
• Tag::KEY_SIZE
• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::CALLER_NONCE
• Tag::DIGEST
• Tag::MGF_DIGEST

Te tagi można powtarzać, co oznacza, że z jednym kluczem można powiązać wiele wartości:

• Tag::BLOCK_MODE
• Tag::PADDING
• Tag::DIGEST
• Tag::MGF_DIGEST

Wartość do użycia 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 są zdefiniowane w KeyPurpose.aidl.

Pamiętaj, że niektóre kombinacje wartości celu 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 podpisów.

Import klucza

KeyMint obsługuje importowanie:

• pary kluczy asymetrycznych 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 KeyMint 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. Pierwszy zestaw określa, które metody uwierzytelniania umożliwiają użycie klucza:

• Tag::USER_SECURE_ID zawiera 64-bitową wartość liczbową, która określa bezpieczne ID użytkownika. Jest ona przekazywana w bezpiecznym tokenie uwierzytelniania, aby umożliwić korzystanie z 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.

• Tag::NO_AUTHENTICATION_REQUIRED oznacza, że nie jest wymagane uwierzytelnianie użytkownika, chociaż dostęp do klucza jest nadal ograniczony do aplikacji, której ona podlega (oraz do aplikacji, do których ta aplikacja przyznaje dostęp).
• Tag::AUTH_TIMEOUT to wartość liczbowa określająca w sekundach, jak świeże musi być uwierzytelnienie użytkownika, aby autoryzować użycie klucza. Limity czasu nie są przenoszone na ponowne uruchamianie; po ponownym uruchomieniu wszystkie uwierzytelniania są nieważne. Czas oczekiwania można ustawić na dużą wartość, aby wskazać, że uwierzytelnianie jest wymagane raz na uruchomienie (2^32 sekund to około 136 lat; 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 KeyMint. 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 KeyMint 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 zastosuje 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. Dzięki temu można je 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 („silne”) 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 KeyMint jako klucz powiązany z biometryką, który wymaga uwierzytelnienia biometrycznego, które zostało pomyślnie wykonane w ciągu ostatnich 15 sekund, i zeruje zwykłe kopie wszystkich tych kluczy.
• Jeśli użytkownik ma biometryczne dane klasy 1 („wygodne”), klasy 2 („słabe”) lub aktywnego zaufanego agenta odblokowywania, Keystore przechowuje superklucze w zaszyfrowanym pliku tekstowym. 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, klucze super UnlockedDeviceRequired użytkownika. W przypadku odblokowania za pomocą kodu PIN, wzoru lub hasła odszyfrowuje kopię tych kluczy przechowywaną w bazie danych. W przeciwnym razie sprawdza, czy została zapisana kopia tych kluczy zaszyfrowana kluczem powiązanym z biometryką, i 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, co jest wymuszane przez KeyMint (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. KeyMint 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 obsługuje ograniczanie użycia klucza według daty. Z kluczem można powiązać datę rozpoczęcia ważności i datę wygaśnięcia klucza, a Keystore 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 „utworzeniem” a „użyciem” zależy od tego, czy klucz jest używany do „utworzenia” nowego szyfrogramu/podpisu itp., czy do „użycia” istniejącego szyfrogramu/podpisu itp. Pamiętaj, że to rozróżnienie nie jest widoczne w przypadku aplikacji.

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

Czas zegarowy jest dostarczany przez niechroniony świat, dlatego tagi związane z wygaśnięciem znajdują się na liście wymuszonej przez oprogramowanie.

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 KeyMint podczas uruchamiania, najlepiej przez bootloader. Ten ciąg bitów jest powiązany kryptograficznie z każdym kluczem zarządzanym przez KeyMint.

Źródło zaufania składa się z hasza 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 KeyMint utworzonych przez poprzedni system nie będzie można użyć, dopóki nie przywrócisz poprzedniego zaufanego elementu domennego i nie uruchomisz systemu podpisanego tym kluczem. Celem jest zwiększenie wartości kontroli dostępu do kluczy wymuszanych przez oprogramowanie, uniemożliwiając używanie kluczy KeyMint przez system operacyjny zainstalowany przez atakującego.

Ponowne ustawienie generatora liczb losowych

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

Jako podstawowego źródła 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ł nasion jest nieprzewidywalny.