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

Nazwa pola (patrz RFC 5280). Wartość
Certyfikat tbs SEKWENCJA certyfikatu TBS
algorytm podpisu Algorytm algorytmu używany do podpisywania klucza:
ECDSA w przypadku kluczy EC, RSA dla kluczy RSA.
signatureValue BITSTRING, podpis obliczony na podstawie certyfikatu ASN.1 zakodowanego w formacie DER w formacie tbsCertificate.

SEQUENCE certyfikatu TBS

Nazwa pola (patrz RFC 5280). Wartość
version INTEGER 2 (oznacza certyfikat w wersji 3)
serialNumber LICZBA CAŁKOWITA 1 (stała wartość: taka sama dla wszystkich certyfikatów)
signature algorytm algorytmu używany do podpisywania klucza: ECDSA dla kluczy EC, RSA dla kluczy RSA.
issuer Taki sam jak w polu tematu zbiorczego klucza atestu.
validity SEKWENCJA z dwóch dat, zawierająca wartości funkcji Tag::ACTIVE_DATETIME i Tag:USAGE_EXPIRE_DATETIME. Wartości te są podawane w milisekundach od 1 stycznia 1970 r. Poprawną instrukcję znajdziesz w dokumencie RFC 5280 daty w certyfikatach.
Jeśli Tag::ACTIVE_DATETIME nie występuje, użyj wartości Tag::CREATION_DATETIME Jeśli Nie podano Tag::USAGE_EXPIRE_DATETIME, użyj daty ważności daty zbiorczego certyfikatu klucza atestu.
subject CN = "Android Keystore Key" (stała wartość: taka sama dla wszystkich certyfikatów)
subjectPublicKeyInfo SubjectPublicKeyInfo zawierający atestowany klucz publiczny.
extensions/Key Usage cyfrowy podpis: ustaw, jeśli klucz ma przeznaczenie KeyPurpose::SIGN lub KeyPurpose::VERIFY Pozostałe bity nie są ustawione.
extensions/CRL Distribution Points Wartość do ustalenia
extensions/"attestation" identyfikator OID to 1.3.6.1.4.1.11129.2.1.17; czy treści są zdefiniowane w tagu Sekcja Rozszerzenie atestu poniżej. Jak zawsze rozszerzeń certyfikatu X.509, zawartość jest reprezentowana jako OCTET_STRING zawierający kodowanie DER atestu SEQUENCE.

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:

Typ komponentu Keymaster Typ ASN.1
ENUM LICZBA CAŁKOWITA
ENUM_REP ZESTAW LICZBY CAŁKOWITEJ
UINT LICZBA CAŁKOWITA
UINT_REP ZESTAW LICZBY CAŁKOWITEJ
ULONG LICZBA CAŁKOWITA
ULONG_REP ZESTAW LICZBY CAŁKOWITEJ
DATE INTEGER (milisekundy od 1 stycznia 1970 00:00:00 GMT)
BOOL NULL (w kluczu keymaster, tag „obecny” oznacza „prawda”, „brak” oznacza „fałsz”.
tak samo jest w przypadku kodowania ASN.1).
BIGNUM Obecnie nie używa się, więc nie zdefiniowano mapowania
BYTES OCET_STRING

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.

Nazwa pola Typ Wartość
attestationVersion LICZBA CAŁKOWITA Wersja schematu atestu: 1, 2 lub 3.
attestationSecurity Poziom zabezpieczeń Poziom bezpieczeństwa tego atestu. Można pobrać oprogramowanie, zaświadczeń kluczy obsługiwanych sprzętowo. Takie atesty nie mogą być wiarygodne, jeśli System Android jest zhakowany.
keymasterVersion LICZBA CAŁKOWITA Wersja urządzenia Keymaster: 0, 1, 2, 3 lub 4.
keymasterSecurity Poziom zabezpieczeń Poziom zabezpieczeń implementacji Keymaster.
attestationChallenge OCET_STRING Wartość Tag::ATTESTATION_CHALLENGE określona w żądaniu atestu.
uniqueId OCET_STRING Opcjonalny unikalny identyfikator, obecny, jeśli klucz ma Tag::INCLUDE_UNIQUE_ID
softwareEnforced Lista autoryzacji Opcjonalne autoryzacje Keymastera, które nie są wymuszane przez TEE, jeśli dowolne.
teeEnforced Lista autoryzacji Opcjonalnie: autoryzacje Keymaster wymuszane przez TEE, jeśli takie istnieją.

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.

Nazwa pola Typ Wartość
verifiedBootKey OCET_STRING Bezpieczny hasz klucza używanego do weryfikacji obrazu systemu. SHA-256 zalecane.
deviceLocked WARTOŚĆ LOGICZNA Wartość „prawda”, jeśli program rozruchowy jest zablokowany. Oznacza to, że tylko podpisane obrazy mogą i musi zostać sprawdzona podczas uruchamiania.
verifiedBootState VerifiedBootState Stan weryfikacji podczas uruchamiania.
verifiedBootHash OCET_STRING Skrót wszystkich danych chronionych przez weryfikację podczas uruchamiania. Urządzenia, które używają implementacji zweryfikowanego rozruchu na Androidzie, ta wartość zawiera skrót struktury VBMeta, czyli metody weryfikacji rozruchu do struktury metadanych. Więcej informacji na temat obliczania tej wartości znajdziesz w sekcji Podsumowanie VBMeta

Wartości VerifiedBootState

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

Wartość Znaczenie
Verified Wskazuje pełny łańcuch zaufania rozciągający się od programu rozruchowego do zweryfikowanego partycje, w tym program rozruchowy, partycję rozruchową oraz wszystkie partycji.
W tym stanie wartość verifiedBootKey jest haszem umieszczonego czyli „niezmienny certyfikat” zapisany w pamięci ROM.
Ten stan odpowiada stanowi rozruchu zielonego zgodnie z opisem w . i weryfikacja procesu uruchamiania.
SelfSigned Wskazuje, że partycja rozruchowa została zweryfikowana przy użyciu umieszczonego a podpis jest ważny. Program rozruchowy wyświetli ostrzeżenie, odcisku cyfrowego klucza publicznego, aby można było kontynuować proces rozruchu.
W tym stanie wartość verifiedBootKey jest haszem samodzielnego podpisywania certyfikat.
Ten stan odpowiada żółtemu stanowi rozruchu, zgodnie z . i weryfikacja procesu uruchamiania.
Unverified Wskazuje, że urządzenie można dowolnie modyfikować. Integralność urządzenia pozostawia się pod kątem użytkowników, którzy są poza zakresem. Program rozruchowy wyświetla użytkownikowi ostrzeżenie przed kontynuowaniem procesu uruchamiania.
W tym stanie wartość verifiedBootKey jest pusta.
Ten stan odpowiada pomarańczowem stanowi uruchamiania zgodnie z opisem w . i weryfikacja procesu uruchamiania.
Failed Wskazuje, że urządzenie nie przeszło weryfikacji. Brak certyfikatu atestu rzeczywiście zawiera tę wartość, ponieważ w tym stanie program rozruchowy zatrzymuje się. Jest dla pełnego obrazu.
Ten stan odpowiada stanowi rozruchu czerwonego, zgodnie z opisem w . i weryfikacja procesu uruchamiania.

Wartości SecurityLevel

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

Wartość Znaczenie
Software kod, który tworzy odpowiedni element lub nim zarządza (zaświadczenie lub jest zaimplementowany w systemie Android i można go zmienić, przejętych.
TrustedEnvironment kod, który tworzy odpowiedni element lub nim zarządza (zaświadczenie lub jest zaimplementowany w zaufanym środowisku TEE (Trusted Execution Environment). Może to być zmienia się, jeśli TEE jest zaatakowany, ale jest bardzo odporny na zdalne i umiarkowanie odporny na naruszenia zabezpieczeń przez bezpośredni atak sprzętowy.
StrongBox kod, który tworzy odpowiedni element lub nim zarządza (zaświadczenie lub ) jest zaimplementowany w dedykowanym sprzętowym module zabezpieczeń. Może to być jest zmieniana, jeśli sprzętowy moduł zabezpieczeń został zaatakowany, ale jest znacznie są odporne na zdalne kompromisy oraz wysoce odporne na kompromisy bezpośrednie ataku sprzętowego.

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.