Atestacja klucza i identyfikatora

Magazyn kluczy to bezpieczniejsze miejsce do tworzenia, przechowywania i używania kryptograficznych w kontrolowany sposób. Gdy dostępna jest pamięć sprzętowa kluczy materiał klucza jest skuteczniejszy przed wydobyciem z urządzenia. Keymaster wymusza ograniczenia, które trudno jest obejść.

Dzieje się tak tylko wtedy, gdy klucze magazynu kluczy są w pamięci sprzętowej. W Keymaster 1 nie było możliwości aplikacji serwerów zdalnych w celu wiarygodnego sprawdzenia, czy tak jest. Demon magazynu kluczy wczytał dostępny menedżer kluczy HAL i wierzył w to, co powiedział HAL w odniesieniu do sprzętowego backendu kluczy.

Aby temu zapobiec, Keymaster wprowadził atestację kluczy w Androidzie 7.0 (Keymaster 2) oraz w wersji ID atestacji w Androidzie 8.0 (Keymaster 3).

Atestacja klucza ma na celu zapewnienie określić, czy para kluczy asymetrycznych jest wspomagana sprzętowo, jakie właściwości możesz poznać ograniczenia i ograniczenia związane z jego użyciem.

atest identyfikatora pozwala urządzeniu potwierdzać identyfikatory sprzętowe; np. numer seryjny lub IMEI.

Atestacja klucza

Aby zapewnić obsługę atestu klucza, w Androidzie 7.0 wprowadzono zestaw tagów, typów do interfejsu HAL.

Tagi

• Tag::ATTESTATION_CHALLENGE
• Tag::INCLUDE_UNIQUE_ID
• Tag::RESET_SINCE_ID_ROTATION

Typ

Keymaster 2 i starszy

typedef struct {
    keymaster_blob_t* entries;
    size_t entry_count;
} keymaster_cert_chain_t;

Metoda AttestKey

Keymaster 3

    attestKey(vec<uint8_t> keyToAttest, vec<KeyParameter> attestParams)
        generates(ErrorCode error, vec<vec<uint8_t>> certChain);

Keymaster 2 i starszy

keymaster_error_t (*attest_key)(const struct keymaster2_device* dev,
        const keymaster_key_blob_t* key_to_attest,
        const keymaster_key_param_set_t* attest_params,
        keymaster_cert_chain_t* cert_chain);

• dev to struktura urządzenia Keymaster.
• keyToAttest to klucz blob zwracany z generateKey, dla którego zostanie utworzony atest.
• attestParams to lista parametrów niezbędnych do atestacji. Obejmuje to Tag::ATTESTATION_CHALLENGE i prawdopodobnie Tag::RESET_SINCE_ID_ROTATION, a także Tag::APPLICATION_ID i Tag::APPLICATION_DATA. ostatnie 2 są niezbędne do odszyfrowania klucza blob, jeśli został określony podczas generowania kluczy.
• certChain to parametr wyjściowy, który zwraca tablicę certyfikatów. Wpis 0 jest certyfikatem atestu, co oznacza, że certyfikuje klucz z keyToAttest i zawiera atest.

Metoda attestKey jest uznawana za operację klucza publicznego na atestowany klucz, ponieważ może być wywoływany w dowolnym momencie i nie wymaga spełniania funkcji autoryzacji. Na przykład jeśli atestowany klucz wymaga użytkownika uwierzytelnianie do użycia, poświadczenie może być generowane bez użycia nazwy użytkownika uwierzytelnianie.

Certyfikat atestu

Certyfikat atestu to standardowy certyfikat X.509. rozszerzenie atestu zawierające opis atestowanego klucza. certyfikat jest podpisany certyfikowanym kluczem atestu. Klucz atestu może używać innego algorytmu niż poświadczony klucz.

Certyfikat atestu zawiera pola z tabeli poniżej i nie może nie mogą zawierać żadnych dodatkowych pól. Niektóre pola określają stałą wartość pola. wskaźnik CTS aby sprawdzić, czy treść certyfikatu jest dokładnie zdefiniowana.

Certyfikat SEQUENCE

SEQUENCE certyfikatu TBS

Rozszerzenie atestu

Rozszerzenie attestation zawiera pełny opis menedżera kluczy autoryzacje powiązane z kluczem w strukturze bezpośrednio odpowiadającej do list uwierzytelniania, które są używane w Androidzie, i do klucza HAL Keymaster. Każdy tag w lista autoryzacji jest reprezentowana przez identyfikator ASN.1 SEQUENCE wpisu, jawnie z numerem tagu keymaster, ale z deskryptorem typu (cztery wysokie bitów zamówienia) zamaskowanych.

Na przykład w Keymaster 3 właściwość Tag::PURPOSE jest zdefiniowany w type.hal jako ENUM_REP | 1. W przypadku przedłużenia atestu wartość ENUM_REP zostaje usunięta, co zostaje pozostawione w tagu 1. (W przypadku Keymaster 2 i starszych wersji KM_TAG_PURPOSE jest zdefiniowany w keymaster_defs.h.

Wartości zostały przetłumaczone w prosty sposób na typy ASN.1, jak pokazano w tej tabeli:

Schemat

Zawartość rozszerzenia atestu jest opisana według poniższego schematu ASN.1.

KeyDescription ::= SEQUENCE {
  attestationVersion         INTEGER, # KM2 value is 1. KM3 value is 2. KM4 value is 3.
  attestationSecurityLevel   SecurityLevel,
  keymasterVersion           INTEGER,
  keymasterSecurityLevel     SecurityLevel,
  attestationChallenge       OCTET_STRING,
  uniqueId                   OCTET_STRING,
  softwareEnforced           AuthorizationList,
  teeEnforced                AuthorizationList,
}

SecurityLevel ::= ENUMERATED {
  Software                   (0),
  TrustedEnvironment         (1),
  StrongBox                  (2),
}

AuthorizationList ::= SEQUENCE {
  purpose                     [1] EXPLICIT SET OF INTEGER OPTIONAL,
  algorithm                   [2] EXPLICIT INTEGER OPTIONAL,
  keySize                     [3] EXPLICIT INTEGER OPTIONAL.
  digest                      [5] EXPLICIT SET OF INTEGER OPTIONAL,
  padding                     [6] EXPLICIT SET OF INTEGER OPTIONAL,
  ecCurve                     [10] EXPLICIT INTEGER OPTIONAL,
  rsaPublicExponent           [200] EXPLICIT INTEGER OPTIONAL,
  rollbackResistance          [303] EXPLICIT NULL OPTIONAL, # KM4
  activeDateTime              [400] EXPLICIT INTEGER OPTIONAL
  originationExpireDateTime   [401] EXPLICIT INTEGER OPTIONAL
  usageExpireDateTime         [402] EXPLICIT INTEGER OPTIONAL
  noAuthRequired              [503] EXPLICIT NULL OPTIONAL,
  userAuthType                [504] EXPLICIT INTEGER OPTIONAL,
  authTimeout                 [505] EXPLICIT INTEGER OPTIONAL,
  allowWhileOnBody            [506] EXPLICIT NULL OPTIONAL,
  trustedUserPresenceRequired [507] EXPLICIT NULL OPTIONAL, # KM4
  trustedConfirmationRequired [508] EXPLICIT NULL OPTIONAL, # KM4
  unlockedDeviceRequired      [509] EXPLICIT NULL OPTIONAL, # KM4
  allApplications             [600] EXPLICIT NULL OPTIONAL,
  creationDateTime            [701] EXPLICIT INTEGER OPTIONAL,
  origin                      [702] EXPLICIT INTEGER OPTIONAL,
  rollbackResistant           [703] EXPLICIT NULL OPTIONAL, # KM2 and KM3 only.
  rootOfTrust                 [704] EXPLICIT RootOfTrust OPTIONAL,
  osVersion                   [705] EXPLICIT INTEGER OPTIONAL,
  osPatchLevel                [706] EXPLICIT INTEGER OPTIONAL,
  attestationApplicationId    [709] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdBrand          [710] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdDevice         [711] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdProduct        [712] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdSerial         [713] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdImei           [714] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdMeid           [715] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdManufacturer   [716] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  attestationIdModel          [717] EXPLICIT OCTET_STRING OPTIONAL, # KM3
  vendorPatchLevel            [718] EXPLICIT INTEGER OPTIONAL, # KM4
  bootPatchLevel              [719] EXPLICIT INTEGER OPTIONAL, # KM4
}

RootOfTrust ::= SEQUENCE {
  verifiedBootKey            OCTET_STRING,
  deviceLocked               BOOLEAN,
  verifiedBootState          VerifiedBootState,
  verifiedBootHash           OCTET_STRING, # KM4
}

VerifiedBootState ::= ENUMERATED {
  Verified                   (0),
  SelfSigned                 (1),
  Unverified                 (2),
  Failed                     (3),
}

Pola KeyDescription

keymasterVersion i attestationChallenge Zidentyfikowano pola położenie, a nie według tagu, więc tagi w zakodowanej postaci określają tylko typu pola. Pozostałe pola są domyślnie otagowane zgodnie z schemat.

Pola AuthorizationList

Wszystkie pola AuthorizationList są opcjonalne i zostały zidentyfikowane według wartości tagu keymaster z maskowanymi elementami typu. Zastosowano jawne tagowanie, więc pola zawierają również tag wskazujący ich typ ASN.1, aby ułatwić analizę.

Szczegółowe informacje o wartościach poszczególnych pól znajdziesz w types.hal o Keymaster 3 i keymaster_defs.h w wersji Keymaster 2 i starszych. Nazwy tagów Keymaster zostały przekształcone w nazwy pól przez pominięcie KM_TAG i zmianę parametru reszta wygląda jak wielbłąd, więc Tag::KEY_SIZE stał się keySize

Pola RootOfTrust

Pola RootOfTrust są określone pozycji.

Wartości VerifiedBootState

Wartości parametru verifiedBootState mają następujące znaczenie:

Wartości SecurityLevel

Wartości parametru securityLevel mają następujące znaczenie:

Unikalny identyfikator

Unikalny identyfikator to 128-bitowa wartość, która identyfikuje urządzenie, ale tylko przez ograniczony czas. Wartość jest obliczana za pomocą wzoru:

HMAC_SHA256(T || C || R, HBK)

Gdzie:

• T to „tymczasowa wartość licznika” obliczona przez podzielenie wartości Tag::CREATION_DATETIME o 2592000000, co oznacza spadek T zmienia się co 30 dni (2592000000 = 30 * 24 * 60 * 60 × 1000).
• C to wartość argumentu Tag::APPLICATION_ID
• R ma wartość 1, jeśli Tag::RESET_SINCE_ID_ROTATION to znajduje się w parametrze attest_params wywołaniu attest_key lub 0, jeśli brak tagu.
• HBK to unikalny obiekt tajny powiązany ze sprzętem, który jest znany zaufanym Środowisko wykonawcze, które nigdy nie zostało przez nie ujawnione. Obiekt tajny zawiera co najmniej 128-bitowej entropii i jest unikalne dla danego urządzenia (prawdopodobnie niepowtarzalność jest akceptowalna przy 128-bitach entropii). Wartość HBK powinna wynosić pozyskany ze scalonego materiału klucza za pomocą HMAC lub AES_CMAC.

Skróć dane wyjściowe HMAC_SHA256 do 128 bitów.

Klucze atestu certyfikaty

Dwa klucze, jeden RSA i jeden ECDSA, oraz odpowiednie łańcuchy certyfikatów i udostępniać je w bezpieczny sposób.

W Androidzie 12 wprowadzono możliwość zdalnego udostępniania kluczy, a Android 13 wymaga urządzeń go wdrożyć. Obsługa administracyjna kluczy zdalnych zapewnia urządzeniom w terenie dla poszczególnych aplikacji, certyfikaty ECDSA P256. Te certyfikaty są są krótsze niż certyfikaty udostępniane przez fabrykę.

Wiele numerów IMEI

W Androidzie 14 dodaliśmy obsługę wielu numerów IMEI Rekord atestu klucza na Androidzie. OEM może wdrożyć tę funkcję, dodając tag KeyMint dla drugiego numeru IMEI. Coraz częściej urządzenia mają wiele radia komórkowego a producenci OEM mogą teraz obsługiwać urządzenia z 2 numerami IMEI.

OEM musi mieć dodatkowy numer IMEI, jeśli jest dostępny na ich urządzeniach. przekazywane do implementacji KeyMint, tak aby implementacje mogły potwierdzają go w taki sam sposób, w jaki potwierdzają to pierwsze IMEI

Atestacja identyfikatora

Android 8.0 zapewnia opcjonalną obsługę poświadczania tożsamości w przypadku urządzeń z Keymaster 3. Atest identyfikatora pozwala urządzeniu przedstawić dowód zakupu sprzętu identyfikatorów takich jak numer seryjny czy IMEI. Chociaż jest to funkcja opcjonalna, Zdecydowanie zalecamy, aby wszystkie implementacje Keymaster 3 obsługiwały tę funkcję bo możliwość udowodnienia tożsamości urządzenia umożliwia zdalną konfigurację typu zero-touch, aby zwiększyć bezpieczeństwo (ponieważ zdalna strona może upewnij się, że dotyczy ono właściwego urządzenia, a nie urządzenia, które podszywa się pod tożsamości).

Atestacja identyfikatora polega na tworzeniu kopii identyfikatorów sprzętowych urządzenia do których ma dostęp tylko Trusted Execution Environment (TEE), opuszcza fabrykę. Użytkownik może odblokować program rozruchowy urządzenia i zmienić oprogramowania systemowego i identyfikatorów zgłaszanych przez platformy Androida. kopii identyfikatorów przechowywanych przez TEE nie można w ten sposób manipulować, zapewnienie, że atest identyfikatora urządzenia będzie zawsze poświadczać tylko jego i uniemożliwiać próby podszywania się pod inne osoby.

Główna powierzchnia interfejsu API do poświadczania identyfikatorów opiera się na istniejącym kluczu mechanizm atestu wprowadzony w programie Keymaster 2. Gdy prosisz o certyfikatu atestu dla klucza przechowywanego przez keymaster, wywołujący może zażądać że w poświadczeniu są uwzględnione identyfikatory sprzętowe urządzenia; metadanych certyfikatu. Jeśli klucz jest przechowywany w TEE, certyfikat opiera się na znanym podejściu zaufania. Odbiorca takiego certyfikatu może Sprawdź, czy certyfikat i jego zawartość, w tym sprzęt zostały zapisane przez TEE. Gdy pojawi się prośba o dołączenie sprzętu w certyfikacie atestu, TEE poświadcza jedynie identyfikatorów przechowywanych w magazynie, takich jak dane fabryczne.

Właściwości pamięci masowej

Pamięć urządzenia z identyfikatorami urządzeń musi mieć te właściwości:

• Wartości uzyskane z pierwotnych identyfikatorów urządzenia są kopiowane do: pamięci masowej, zanim urządzenie opuści fabrykę.
• Metoda destroyAttestationIds() może trwale zniszczyć tę kopię danych uzyskanych dzięki identyfikatorom. Trwałe zniszczenie oznacza zostaną całkowicie usunięte, więc nie będzie można przywrócić ustawień fabrycznych ani żadnego innego wykonująca na urządzeniu procedurę można przywrócić. Jest to szczególnie ważne, ważne w przypadku urządzeń, na których użytkownik odblokował program rozruchowy i zmienił oprogramowanie systemu i zmodyfikowało identyfikatory zwracane przez Androida. zasad.
• Obiekty RMA powinny mieć możliwość generować nowe kopie danych opartych na identyfikatorach sprzętowych. W ten sposób urządzenie, które przejdzie proces RMA, może ponownie przeprowadzić atest tożsamości. mechanizmu stosowanych w systemach RMA muszą być chronione, aby użytkownicy nie mogli same się wywoływać, ponieważ pozwoliłoby im to uzyskać atesty sfałszowanych identyfikatorów.
• Żaden kod poza zaufaną aplikacją Keymaster w TEE nie jest w stanie odczytać przechowywane w pamięci.
• Potwierdzanie manipulacji danymi pamięci masowej: jeśli jej zawartość została zmodyfikowane, TEE traktuje je tak samo, jak gdyby kopie treści został zniszczony i odrzuca wszystkie próby poświadczenia tożsamości. Ta funkcja jest wdrożona przez podpisanie lub użycie MAC pamięci masowej w sposób opisany poniżej.
• W pamięci nie są przechowywane oryginalne identyfikatory. Ponieważ zaświadczenie o identyfikatorze wiąże się z wyzwaniem, wywołujący zawsze podaje identyfikatory, potwierdzony przez Google. TEE musi tylko sprawdzić, czy wartości odpowiadają wartościom wcześniej mieliśmy. Przechowywanie bezpiecznych haszy oryginalnych wartości zamiast umożliwia tę weryfikację.

Budownictwo

Aby utworzyć implementację, która ma wymienione wyżej właściwości, zapisz parametr wartości określane jako identyfikatory w następującej konstrukcji S. Nie przechowuj innych kopii wartości identyfikatorów z wyjątkiem zwykłych miejsc w systemie, może modyfikować przez dostęp do roota:

S = D || HMAC(HBK, D)

gdzie:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC to konstrukcja HMAC z odpowiednim bezpiecznym haszem. (zalecany SHA-256)
• HBK to klucz powiązany sprzętowo nieużywany do żadnego innego celu
• ID1...IDn to pierwotne wartości identyfikatora; powiązanie zależy od implementacji, ponieważ różne urządzenia mają różne numery identyfikatorów
• || oznacza konkatenację

Dane wyjściowe HMAC mają stały rozmiar, więc żadne nagłówki ani inne struktury nie są niezbędne, aby znaleźć hasze poszczególnych identyfikatorów, czyli kod HMAC D. Dodatkowo sprawdzania podanych wartości w celu wykonania atestu, implementacje muszą zweryfikować S, wyodrębniając D z S, obliczając HMAC(HBK, D) i porównując go z wartość w S, aby sprawdzić, czy żadne indywidualne identyfikatory nie zostały zmodyfikowane/uszkodzone. Oprócz tego: implementacje muszą korzystać z porównywania w czasie rzeczywistym dla wszystkich indywidualnych identyfikatorów elementów i walidacji S. Czas porównania musi być stały niezależnie od liczby podanych identyfikatorów i prawidłowego dopasowania dowolnej części testu.

Identyfikatory sprzętu

Atest identyfikatora obsługuje te identyfikatory sprzętowe:

1. Nazwa marki wyświetlana przez aplikację Build.BRAND na Androidzie
2. Nazwa urządzenia wyświetlana przez aplikację Build.DEVICE na Androidzie
3. Nazwa produktu zwrócona przez aplikację Build.PRODUCT na Androidzie
4. Nazwa producenta wyświetlana przez aplikację Build.MANUFACTURER na Androidzie
5. Nazwa modelu wyświetlana przez funkcję Build.MODEL w Androidzie
6. Numer seryjny
7. Numery IMEI wszystkich urządzeń radiowych
8. Identyfikatory MEID wszystkich radia

Aby zapewnić obsługę poświadczania identyfikatorów urządzeń, urządzenie je potwierdza te identyfikatory. Wszystkie urządzeń z Androidem. Jest to 6 pierwszych. Są one niezbędne, do działania. Jeśli urządzenie jest wyposażone w zintegrowane radio komórkowe, musi też obsługiwać atest dotyczący identyfikatorów IMEI lub MEID urządzeń radiowych.

Poświadczanie identyfikatora jest wymagane przez wykonanie atestu klucza i dodanie parametru identyfikatorów urządzeń, które mają być potwierdzone w żądaniu. Identyfikatory są oznaczone w następujący sposób:

• ATTESTATION_ID_BRAND
• ATTESTATION_ID_DEVICE
• ATTESTATION_ID_PRODUCT
• ATTESTATION_ID_MANUFACTURER
• ATTESTATION_ID_MODEL
• ATTESTATION_ID_SERIAL
• ATTESTATION_ID_IMEI
• ATTESTATION_ID_MEID

Identyfikator do poświadczania to ciąg bajtów zakodowany w UTF-8. Ten format dotyczy identyfikatory liczbowe. Każdy identyfikator do poświadczania jest wyrażony jako Ciąg znaków zakodowany w formacie UTF-8.

Jeśli urządzenie nie obsługuje poświadczania tożsamości (lub Urządzenie destroyAttestationIds() zostało wcześniej nawiązane, więc urządzenie nie może dłuższe atestowanie identyfikatorów), każde żądanie atestu klucza, które zawiera co najmniej jeden dla tych tagów występuje błąd ErrorCode::CANNOT_ATTEST_IDS.

Jeśli urządzenie obsługuje poświadczanie tożsamości, a co najmniej jeden z powyższych tagów ma został uwzględniony w żądaniu atestu klucza, TEE weryfikuje identyfikator dostarczany z każdym z tagów odpowiada jego kopii identyfikatorów sprzętowych. Jeśli co najmniej jeden identyfikator nie pasuje, cały atest kończy się niepowodzeniem z ErrorCode::CANNOT_ATTEST_IDS Prawidłowy, jeśli ten sam tag będzie podano wiele razy. Może to być przydatne na przykład podczas potwierdzania numerów IMEI: Urządzenie może mieć wiele urządzeń radiowych z różnymi numerami IMEI. Żądanie atestu to prawidłowa, jeśli wartość podana z każdym elementem ATTESTATION_ID_IMEI jest zgodna do radia urządzenia. To samo dotyczy wszystkich pozostałych tagów.

Jeśli atest jest poprawny, atestowane identyfikatory są dodawane do rozszerzenie atestu (OID 1.3.6.1.4.1.11129.2.1.17) wydanego certyfikatu atestu; używając schematu opisanego powyżej. Zmiany w stosunku do modelu Keymaster 2 schemat atestu jest pogrubiony i z komentarzami.

Interfejs API Java

Ta sekcja ma wyłącznie charakter informacyjny. Żadne z implementatorów Keymaster implementować ani używać interfejsu Java API. Ma to pomóc we wdrażaniu jak ta funkcja jest wykorzystywana przez aplikacje. Mogą z niego korzystać komponenty systemu dlatego ważne jest, aby ta sekcja nie była traktowana jako normatywna.

// Create KeyPairGenerator and set generation parameters for an ECDSA key pair
// using the NIST P-256 curve.  "Key1" is the key alias.
KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance(
    KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
keyPairGenerator.initialize(
    new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
         .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
         .setDigests(KeyProperties.DIGEST_SHA256,
                     KeyProperties.DIGEST_SHA384,
                     KeyProperties.DIGEST_SHA512)
         // Only permit the private key to be used if the user
         // authenticated within the last five minutes.
         .setUserAuthenticationRequired(true)
         .setUserAuthenticationValidityDurationSeconds(5 * 60)
         // Request an attestation with challenge "hello world".
         .setAttestationChallenge("hello world".getBytes("UTF-8"))
         .build());
// Generate the key pair. This will result in calls to both generate_key() and
// attest_key() at the keymaster2 HAL.
KeyPair keyPair = keyPairGenerator.generateKeyPair();
// Get the certificate chain
KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
Certificate[] certs = keyStore.getCertificateChain("Key1");
// certs[0] is the attestation certificate. certs[1] signs certs[0], etc.,
// up to certs[certs.length - 1].