Attestazione chiave e ID

L'archivio chiavi fornisce una posizione più sicura per creare, archiviare e utilizzare crittografie in modo controllato. Quando è disponibile l'archiviazione delle chiavi con supporto hardware utilizzato, il materiale della chiave è più sicuro contro l'estrazione dal dispositivo e Keymaster applica restrizioni difficili da sovvertire.

Questo è vero solo, tuttavia, se le chiavi dell'archivio chiavi sono note di archiviazione con supporto hardware. In Keymaster 1, non c'era modo per le app o server remoti per verificare in modo affidabile se questo è il caso. Il daemon dell'archivio chiavi aveva caricato il keymaster HAL disponibile e credeva a ciò che diceva l'HAL con per quanto riguarda il supporto hardware delle chiavi.

Per risolvere il problema, Keymaster ha introdotto l'attestazione della chiave in Android 7.0 (Keymaster 2) e nell'ID in Android 8.0 (Keymaster 3).

L'attestazione chiave ha lo scopo di fornire un modo determinare se una coppia di chiavi asimmetrica è supportata da hardware, quali proprietà della chiave e quali vincoli vengono applicati al suo utilizzo.

L'attestazione dell'ID consente al dispositivo di fornire prova dei suoi identificatori hardware, come il numero di serie o il codice IMEI.

Attestazione chiave

Per supportare l'attestazione chiave, Android 7.0 ha introdotto un insieme di tag, tipi e all'HAL.

Tag

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

Digitare

Keymaster 2 e versioni precedenti

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

Metodo AttestKey

Keymaster 3

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

Keymaster 2 e versioni precedenti

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 è la struttura principale dei dispositivi.
• keyToAttest è il blob chiave restituito da generateKey per il quale verrà creata l'attestazione.
• attestParams è un elenco di tutti i parametri necessari l'attestazione. Sono inclusi Tag::ATTESTATION_CHALLENGE e forse Tag::RESET_SINCE_ID_ROTATION, oltre a Tag::APPLICATION_ID e Tag::APPLICATION_DATA. La gli ultimi due sono necessari per decriptare il blob della chiave se sono stati specificati durante la generazione delle chiavi.
• certChain è il parametro di output, che restituisce un array di certificati. La voce 0 è il certificato di attestazione, ovvero certifica la chiave da keyToAttest e contiene dell'attestazione.

Il metodo attestKey è considerato un'operazione di chiave pubblica sul chiave attestata, perché può essere chiamata in qualsiasi momento e non deve soddisfare vincoli di autorizzazione. Ad esempio, se la chiave attestata richiede un utente dell'autenticazione per l'uso, un'attestazione può essere generata senza che autenticazione.

Certificato di attestazione

Il certificato di attestazione è un certificato X.509 standard, con un'intestazione facoltativa di attestazione contenente una descrizione della chiave attestata. La sia firmato con una chiave di attestazione certificata. Chiave di attestazione potrebbe utilizzare un algoritmo diverso rispetto alla chiave attestata.

Il certificato di attestazione contiene i campi della tabella seguente e non può contenere eventuali campi aggiuntivi. Alcuni campi specificano un valore fisso. CTS convalidano che il contenuto del certificato sia esattamente come definito.

Certificato SEQUENCE

SEQUENCE certificato TBS

Estensione attestazione

L'estensione attestation contiene una descrizione completa del keymaster autorizzazioni associate alla chiave, in una struttura che corrisponde agli elenchi di autorizzazioni usati in Android e nel keymaster HAL. Ogni tag in un elenco di autorizzazioni è rappresentato da un ASN.1 SEQUENCE voce, in modo esplicito con il numero tag keymaster, ma con il descrittore del tipo (quattro alti pezzi di ordine) mascherati.

Ad esempio, in Keymaster 3, Tag::PURPOSE è definito in type.hal come ENUM_REP | 1. Per l'estensione attestazione, il valore ENUM_REP viene rimosso, lasciando il tag 1. (Per Keymaster 2 e versioni precedenti, KM_TAG_PURPOSE è definito in keymaster_defs.h.)

I valori sono tradotti in modo diretto in tipi ASN.1, secondo questa tabella:

Schema

I contenuti dell'estensione di attestazione sono descritti dal seguente schema 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),
}

Campi KeyDescription

keymasterVersion e attestationChallenge vengono identificati in base alla posizione, anziché al tag, quindi i tag nel formato codificato specificano solo tipo di campo. I campi rimanenti sono implicitamente contrassegnati come specificato nel .

Campi AuthorizationList

AuthorizationList campi sono tutti facoltativi e sono stati identificati in base al valore del tag keymaster, con il tipo di bit nascosto. Viene utilizzata la codifica esplicita, in modo che i campi contengano anche un tag che indica e il relativo tipo di ASN.1, per facilitarne l'analisi.

Per informazioni dettagliate sui valori di ciascun campo, consulta types.hal per Keymaster 3 e keymaster_defs.h per Keymaster 2 e versioni precedenti. Nomi tag keymaster sono stati trasformati in nomi di campo omettendo KM_TAG Prefisso e modifica resto della cassa a cammello, quindi Tag::KEY_SIZE è diventato keySize.

Campi RootOfTrust

I campi RootOfTrust sono identificati in termini di posizione.

Valori VerifiedBootState

I valori di verifiedBootState hanno i seguenti significati:

Valori SecurityLevel

I valori di securityLevel hanno i seguenti significati:

ID univoco

L'ID univoco è un valore a 128 bit che identifica il dispositivo, ma solo per un per un periodo di tempo limitato. Il valore viene calcolato con:

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

Dove:

• T è il "valore del contatore temporale", calcolato dividendo il valore valore di Tag::CREATION_DATETIME per 2592000000, eliminando qualsiasi resto. T modifiche ogni 30 giorni (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C è il valore di Tag::APPLICATION_ID
• R è 1 se Tag::RESET_SINCE_ID_ROTATION è nel parametro attest_params alla chiamata attest_key oppure 0 se non è presente.
• HBK è un secret univoco associato all'hardware noto al Trusted ambiente di esecuzione e mai rivelato da questo. Il secret contiene almeno è di 128 bit di entropia ed è univoca per ogni dispositivo (probabilistico l'univocità è accettabile date i 128 bit di entropia). HBK deve essere derivati dal materiale delle chiavi fuse tramite HMAC o AES_CMAC.

Troncare l'output HMAC_SHA256 a 128 bit.

Chiavi di attestazione e certificati

Due chiavi, una RSA, una ECDSA e le corrispondenti catene di certificati, sono in modo sicuro nel dispositivo.

Android 12 introduce il Remote Key Provisioning, mentre Android 13 richiede dei dispositivi implementarla. Remote Key Provisioning fornisce ai dispositivi sul campo certificati di attestazione ECDSA P256 per applicazione. Questi certificati sono più breve rispetto ai certificati forniti dal produttore.

Più IMEI

Android 14 aggiunge il supporto per più IMEI nel Record di attestazione della chiave Android. Gli OEM possono implementare questa funzionalità aggiungendo un tag KeyMint per un secondo IMEI. Sta diventando sempre più comune che i dispositivi dispongano di più segnali radio cellulari e gli OEM ora supportano i dispositivi con due IMEI.

Gli OEM devono avere un codice IMEI secondario, se presente sui loro dispositivi, per di cui è stato eseguito il provisioning alle implementazioni KeyMint in modo che possano lo attesta nello stesso modo in cui attesta il primo IMEI

Attestazione ID

Android 8.0 include il supporto facoltativo per l'attestazione dell'ID per i dispositivi con Keymaster 3. L'attestazione dell'ID consente al dispositivo di fornire prova dell'hardware come il numero di serie o il codice IMEI. Sebbene sia una funzionalità facoltativa, vivamente consigliato che tutte le implementazioni di Keymaster 3 lo forniscano perché la capacità di dimostrare l'identità del dispositivo consente casi d'uso come il vero la configurazione remota zero-touch per maggiore sicurezza (perché il lato remoto può assicurarsi di parlare con il dispositivo giusto, non di effettuare lo spoofing dell'identità).

L'attestazione dell'ID funziona creando copie degli identificatori hardware del dispositivo a cui solo il Trusted Execution Environment (TEE) può accedere prima del dispositivo lascia la fabbrica di produzione. Un utente può sbloccare il bootloader del dispositivo e modificare software di sistema e gli identificatori segnalati dai framework Android. La le copie degli identificatori conservati dal TEE non possono essere manipolate in questo modo, garantendo che l'attestazione dell'ID dispositivo attesti esclusivamente lo stato identificatori hardware originali che contrastano i tentativi di spoofing.

La piattaforma API principale per l'attestazione degli ID si basa sulla chiave esistente meccanismo di attestazione introdotto con Keymaster 2. Quando si richiede un di attestazione di una chiave conservata dal keymaster, il chiamante potrebbe richiedere che gli identificatori hardware del dispositivo siano inclusi nell'attestazione metadati del certificato. Se la chiave si trova nel TEE, il certificato fino a una radice di attendibilità nota. Il destinatario di questo certificato può verificare che il certificato e i suoi contenuti, compreso l'hardware identificatori, sono stati scritti dal TEE. Quando ti viene chiesto di includere l'hardware identificatori nel certificato di attestazione, il TEE attesta solo archiviati nello spazio di archiviazione, come popolato nello stabilimento.

Proprietà di archiviazione

Lo spazio di archiviazione che contiene gli identificatori del dispositivo deve avere le seguenti proprietà:

• I valori derivati dagli identificatori originali del dispositivo vengono copiati in lo spazio di archiviazione prima che il dispositivo lasci la fabbrica.
• Il metodo destroyAttestationIds() può eliminare definitivamente di questa copia dei dati derivanti da identificatori. Per distruzione permanente si intende i dati vengono rimossi completamente, pertanto né un ripristino dei dati di fabbrica eseguita sul dispositivo, puoi ripristinarlo. In particolare importante per i dispositivi in cui un utente ha sbloccato il bootloader e modificato il software di sistema e ha modificato gli identificatori restituiti da Android i modelli di machine learning.
• Le strutture RMA devono poter generare nuove copie dei dati derivati da identificatori hardware. In questo modo, Il dispositivo che supera l'RMA può eseguire nuovamente l'attestazione dell'ID. La usati dai servizi RMA devono essere protetti affinché gli utenti non possano di richiamarli autonomamente, in quanto ciò gli consentirebbe di ottenere attestazioni di ID falsificati.
• Nessun codice, a parte l'app attendibile Keymaster nel TEE, è in grado di leggere i dati derivati dall'identificatore e conservati nello spazio di archiviazione.
• Lo spazio di archiviazione è a prova di manomissione: se i contenuti dello spazio di archiviazione sono stati modificato, il TEE lo considera come se le copie dei contenuti avessero è stata eliminata e rifiuta tutti i tentativi di attestazione dell'ID. Questo è implementato firmando o eseguendo il MAC dello spazio di archiviazione come descritto qui sotto.
• Lo spazio di archiviazione non contiene gli identificatori originali. Poiché l'attestazione dell'ID comporta una sfida, il chiamante fornisce sempre gli identificatori delle risorse. Il TEE deve solo verificare che corrispondano ai valori che in origine. Archiviazione di hash sicuri dei valori originali anziché dei consentono questa verifica.

Edilizia

Per creare un'implementazione con le proprietà elencate sopra, archivia Valori derivati dall'ID nella seguente costruzione S. Non archiviare altre copie di i valori ID, ad eccezione delle normali posizioni all'interno del sistema, dove un proprietario possono modificare tramite rooting:

S = D || HMAC(HBK, D)

dove:

• D = HMAC(HBK, ID1) || HMAC(HBK, ID2) || ... || HMAC(HBK, IDn)
• HMAC è la costruzione HMAC con un hash sicuro appropriato (valore consigliato SHA-256)
• HBK è una chiave associata all'hardware che non viene utilizzata per altri scopi
• ID1...IDn sono i valori ID originali; associazione di un a un certo indice dipende dall'implementazione, dispositivi diversi avranno numeri diversi di identificatori
• || rappresenta la concatenazione

Poiché gli output HMAC hanno dimensioni fisse, non vengono visualizzate intestazioni o altre strutture necessari per poter trovare i singoli hash ID, o HMAC di D. Inoltre, verificare i valori forniti per eseguire l'attestazione, le implementazioni devono convalidare S estraendo D da S, calcolando HMAC(HBK, D) e confrontandolo con il valore in S per verificare che nessun singolo ID sia stato modificato/corrotto. Inoltre, le implementazioni devono usare confronti a tempo costante per tutti i singoli ID e la convalida di S. Il tempo di confronto deve essere costante indipendentemente da il numero di documenti di identità forniti e la corretta corrispondenza di qualsiasi parte del test.

Identificatori hardware

L'attestazione dell'ID supporta i seguenti identificatori hardware:

1. Nome del brand, come restituito da Build.BRAND in Android
2. Nome del dispositivo, come restituito da Build.DEVICE in Android
3. Nome del prodotto restituito da Build.PRODUCT in Android
4. Nome del produttore restituito da Build.MANUFACTURER in Android
5. Nome del modello, come restituito da Build.MODEL in Android
6. Numero di serie
7. IMEI di tutte le radio
8. MEID di tutte le radio

Per supportare l'attestazione dell'ID dispositivo, un dispositivo attesta questi identificatori. Tutti dispositivi con Android dispongono delle prime sei, che sono necessarie per questo la tua funzionalità. Se il dispositivo dispone di radio cellulari integrati, Deve inoltre supportare l'attestazione dei codici IMEI e/o MEID dei segnali radio.

L'attestazione dell'ID viene richiesta eseguendo un'attestazione della chiave e includendo identificatori dei dispositivi da attestare nella richiesta. Gli identificatori sono codificati come segue:

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

L'identificatore da attestare è una stringa di byte codificata in UTF-8. Questo formato si applica anche identificatori numerici. Ogni identificatore da attestare è espresso come Stringa con codifica UTF-8.

Se il dispositivo non supporta l'attestazione dell'ID (o Hai già chiamato destroyAttestationIds() e il dispositivo non può attestare più a lungo i suoi ID), qualsiasi richiesta di attestazione chiave che includa uno o più di questi tag non funzionano con ErrorCode::CANNOT_ATTEST_IDS.

Se il dispositivo supporta l'attestazione dell'ID e uno o più tag sopra riportati hanno stato incluso in una richiesta di attestazione della chiave, il TEE verifica l'identificatore fornita con ciascuno dei tag corrisponde alla sua copia degli identificatori hardware. Se uno o più identificatori non corrispondono, l'intera attestazione ha esito negativo con ErrorCode::CANNOT_ATTEST_IDS. È valido che lo stesso tag vengono fornite più volte. Può essere utile, ad esempio, per l'attestazione dei codici IMEI: Un dispositivo potrebbe avere più segnali radio con più codici IMEI. Una richiesta di attestazione è valido se il valore fornito con ogni ATTESTATION_ID_IMEI corrisponde uno dei segnali radio del dispositivo. Lo stesso vale per tutti gli altri tag.

Se l'attestazione ha esito positivo, gli ID attestati vengono aggiunti alla richiesta estensione attestazione (OID 1.3.6.1.4.1.11129.2.1.17) del certificato di attestazione rilasciato, utilizzando lo schema sopra. Modifiche rispetto a Keymaster 2 schema di attestazione sono in grassetto con i commenti.

API Java

Questa sezione è solo informativa. Gli implementatori Keymaster non sono neppure implementare o utilizzare l'API Java. Viene fornita per aiutare gli utenti che implementano l'implementazione a comprendere il modo in cui la funzionalità viene utilizzata dalle applicazioni. I componenti di sistema potrebbero utilizzarla in modo diverso ed è per questo che è fondamentale che questa sezione non venga trattata come normativa.

// 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].