Chiave e Attestazione ID

Keystore fornisce un luogo più sicuro per creare, archiviare e utilizzare le chiavi crittografiche in modo controllato. Quando l'archiviazione delle chiavi basata su hardware è disponibile e utilizzata, il materiale della chiave è più sicuro contro l'estrazione dal dispositivo e Keymaster applica restrizioni difficili da sovvertire.

Ciò è vero, tuttavia, solo se è noto che le chiavi dell'archivio chiavi si trovano nell'archiviazione supportata dall'hardware. In Keymaster 1, non c'era modo per le app o i server remoti di verificare in modo affidabile se fosse così. Il demone keystore ha caricato l'HAL keymaster disponibile e ha creduto a qualunque cosa l'HAL dicesse rispetto al supporto hardware delle chiavi.

Per rimediare a questo, Keymaster ha introdottol'attestazione della chiave in Android 7.0 (Keymaster 2) e l'attestazione dell'ID in Android 8.0 (Keymaster 3).

L'attestazione della chiave mira a fornire un modo per determinare con certezza se una coppia di chiavi asimmetriche è supportata dall'hardware, quali sono le proprietà della chiave e quali vincoli vengono applicati al suo utilizzo.

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

Attestazione chiave

Per supportare l'attestazione della chiave, Android 7.1 ha introdotto un set di tag, tipo e metodo nell'HAL.

Tag

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

Tipo

Keymaster 2 e versioni precedenti

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

Metodo AttestKey

Maestro delle chiavi 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 del dispositivo keymaster.
• keyToAttest è il BLOB di chiavi restituito da generateKey per il quale verrà creata l'attestazione.
• attestParams è un elenco di tutti i parametri necessari per l'attestazione. Questo include Tag::ATTESTATION_CHALLENGE ed eventualmente Tag::RESET_SINCE_ID_ROTATION , così come Tag::APPLICATION_ID e Tag::APPLICATION_DATA . Gli ultimi due sono necessari per decrittografare il BLOB di chiavi se sono stati specificati durante la generazione della chiave.
• 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 l'estensione dell'attestazione.

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

Certificato di attestazione

Il certificato di attestazione è un certificato X.509 standard, con un'estensione di attestazione facoltativa che contiene una descrizione della chiave attestata. Il certificato è firmato con una chiave di attestazione certificata. La chiave di attestazione può utilizzare un algoritmo diverso rispetto alla chiave da attestare.

Il certificato di attestazione contiene i campi nella tabella seguente e non può contenere campi aggiuntivi. Alcuni campi specificano un valore di campo fisso. I test CTS convalidano che il contenuto del certificato è esattamente come definito.

SEQUENZA certificato

Certificato TBS SEQUENCE

Estensione attestazione

L'estensione attestation contiene una descrizione completa delle autorizzazioni del keymaster associate alla chiave, in una struttura che corrisponde direttamente agli elenchi di autorizzazioni utilizzati in Android e nel keymaster HAL. Ogni tag in un elenco di autorizzazioni è rappresentato da una voce ASN.1 SEQUENCE , contrassegnata esplicitamente con il numero di tag keymaster, ma con il descrittore del tipo (quattro bit di ordine elevato) mascherato.

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

I valori vengono tradotti in modo semplice nei tipi ASN.1, secondo questa tabella:

Schema

Il contenuto dell'estensione dell'attestazione è descritto 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,
  applicationId               [601] EXPLICIT OCTET_STRING 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

I campi keymasterVersion e attestationChallenge sono identificati in modo posizionale, anziché in base al tag, quindi i tag nella forma codificata specificano solo il tipo di campo. I campi rimanenti sono contrassegnati in modo implicito come specificato nello schema.

Campi AuthorizationList

I campi AuthorizationList sono tutti facoltativi e sono identificati dal valore del tag keymaster, con i bit di tipo mascherati. Viene utilizzato il tagging esplicito in modo che i campi contengano anche un tag che indica il loro tipo ASN.1, per facilitare l'analisi.

Per i dettagli sui valori di ciascun campo, vedere types.hal per Keymaster 3 e keymaster_defs.h per Keymaster 2 e versioni successive. I nomi dei tag Keymaster sono stati trasformati in nomi di campo omettendo il prefisso KM_TAG e cambiando il resto in camel case, quindi Tag::KEY_SIZE è diventato keySize .

Campi RootOfTrust

I campi RootOfTrust sono identificati in modo posizionale.

Valori VerifiedBootState

I valori 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 periodo di tempo limitato. Il valore è calcolato con:

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

Dove:

• T è il "valore del contatore temporale", calcolato dividendo il valore di Tag::CREATION_DATETIME per 2592000000, eliminando qualsiasi resto. T cambia ogni 30 giorni (2592000000 = 30 * 24 * 60 * 60 * 1000).
• C è il valore di Tag::APPLICATION_ID
• R è 1 se Tag::RESET_SINCE_ID_ROTATION è presente nel parametro attest_params della chiamata attest_key oppure 0 se il tag non è presente.
• HBK è un segreto univoco legato all'hardware noto al Trusted Execution Environment e mai rivelato da esso. Il segreto contiene almeno 128 bit di entropia ed è unico per il singolo dispositivo (l'unicità probabilistica è accettabile dati i 128 bit di entropia). HBK dovrebbe essere derivato dal materiale della chiave fusa tramite HMAC o AES_CMAC.

Tronca l'output di HMAC_SHA256 a 128 bit.

Chiavi di attestazione e certificati

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

Android 12 introduce il Remote Key Provisioning e Android 13 richiede che i dispositivi lo implementino. Remote Key Provisioning fornisce ai dispositivi sul campo certificati di attestazione ECDSA P256 per applicazione. Questi certificati hanno una durata più breve rispetto ai certificati forniti in fabbrica.

Attestato di identità

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 una prova dei suoi identificatori hardware, come il numero di serie o l'IMEI. Sebbene sia una funzionalità opzionale, si consiglia vivamente che tutte le implementazioni di Keymaster 3 ne forniscano il supporto perché essere in grado di dimostrare l'identità del dispositivo consente a casi d'uso come la vera configurazione remota zero-touch di essere più sicuri (poiché il lato remoto può essere certo che sta parlando con il dispositivo giusto, non un dispositivo che falsifica la sua identità).

L'attestazione dell'ID funziona creando copie degli identificatori hardware del dispositivo a cui solo il TEE (Trusted Execution Environment) può accedere prima che il dispositivo lasci la fabbrica. Un utente può sbloccare il bootloader del dispositivo e modificare il software di sistema e gli identificatori riportati dai framework Android. Le copie degli identificatori conservate dal TEE non possono essere manipolate in questo modo, garantendo che l'attestazione dell'ID del dispositivo attesti solo e solo gli identificatori hardware originali del dispositivo, vanificando così i tentativi di spoofing.

La superficie API principale per l'attestazione dell'ID si basa sul meccanismo di attestazione della chiave esistente introdotto con Keymaster 2. Quando si richiede un certificato di attestazione per una chiave detenuta da keymaster, il chiamante può richiedere che gli identificatori hardware del dispositivo siano inclusi nei metadati del certificato di attestazione. Se la chiave è conservata nel TEE, il certificato ricollegherà a una radice di attendibilità nota. Il destinatario di tale certificato può verificare che il certificato e il suo contenuto, inclusi gli identificatori hardware, siano stati scritti dal TEE. Quando viene richiesto di includere gli identificatori hardware nel certificato di attestazione, il TEE attesta solo gli identificatori conservati nel suo archivio, come popolato in fabbrica.

Proprietà di archiviazione

La memoria che contiene gli identificatori del dispositivo deve avere queste proprietà:

• I valori derivati ​​dagli identificatori originali del dispositivo vengono copiati nella memoria prima che il dispositivo lasci la fabbrica.
• Il metodo destroyAttestationIds() può distruggere definitivamente questa copia dei dati derivati ​​dall'identificatore. Distruzione permanente significa che i dati vengono completamente rimossi in modo che né un ripristino delle impostazioni di fabbrica né alcuna altra procedura eseguita sul dispositivo possano ripristinarli. Ciò è particolarmente importante per i dispositivi in ​​cui un utente ha sbloccato il bootloader e modificato il software di sistema e modificato gli identificatori restituiti dai framework Android.
• Le strutture RMA dovrebbero avere la capacità di generare nuove copie dei dati derivati ​​dall'identificatore hardware. In questo modo, un dispositivo che passa attraverso RMA può eseguire nuovamente l'attestazione dell'ID. Il meccanismo utilizzato dalle strutture RMA deve essere protetto in modo che gli utenti non possano invocarlo da soli, in quanto ciò consentirebbe loro di ottenere attestazioni di ID contraffatti.
• Nessun codice diverso dall'app fidata di Keymaster nel TEE è in grado di leggere i dati derivati ​​dall'identificatore conservati nella memoria.
• La conservazione è a prova di manomissione: se il contenuto della memoria è stato modificato, il TEE lo tratta come se le copie del contenuto fossero state distrutte e rifiuta tutti i tentativi di attestazione dell'identità. Ciò viene implementato firmando o contrassegnando con MAC l'archiviazione come descritto di seguito .
• La memoria non contiene gli identificatori originali. Poiché l'attestazione dell'ID comporta una sfida, il chiamante fornisce sempre gli identificatori da attestare. Il TEE deve solo verificare che questi corrispondano ai valori che avevano originariamente. L'archiviazione di hash protetti dei valori originali anziché dei valori consente questa verifica.

Costruzione

Per creare un'implementazione con le proprietà sopra elencate, archiviare i valori derivati ​​dall'ID nella seguente costruzione S. Non archiviare altre copie dei valori ID, ad eccezione delle normali posizioni nel sistema, che un proprietario del dispositivo può modificare eseguendo il rooting:

S = D || HMAC(HBK, D)

Dove:

• D = HMAC(HBK, ID 1 ) || HMAC(HBK, ID 2 ) || ... || HMAC(HBK, ID n )
• HMAC è la costruzione HMAC con un hash sicuro appropriato (consigliato SHA-256)
• HBK è una chiave legata all'hardware non utilizzata per altri scopi
• ID 1 ...ID n sono i valori ID originali; l'associazione di un particolare valore a un particolare indice dipende dall'implementazione, poiché dispositivi diversi avranno numeri diversi di identificatori
• || rappresenta la concatenazione

Poiché gli output HMAC sono di dimensioni fisse, non sono necessarie intestazioni o altre strutture per poter trovare i singoli hash ID o l'HMAC di D. Oltre a controllare 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/danneggiato. Inoltre, le implementazioni devono utilizzare confronti a tempo costante per tutti i singoli elementi ID e la convalida di S. Il tempo di confronto deve essere costante indipendentemente dal numero di ID forniti e dalla corrispondenza corretta di qualsiasi parte del test.

Identificatori hardware

L'attestazione 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, come restituito da Build.PRODUCT in Android
4. Nome del produttore, come 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 i dispositivi con Android hanno i primi sei e sono necessari per il funzionamento di questa funzione. Se il dispositivo dispone di radio cellulari integrate, il dispositivo deve supportare anche l'attestazione per gli IMEI e/o i MEID delle radio.

L'attestazione dell'ID viene richiesta eseguendo un'attestazione della chiave e includendo gli identificatori del dispositivo da attestare nella richiesta. Gli identificatori sono contrassegnati come:

• 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 con codifica UTF-8. Questo formato si applica anche agli identificatori numerici. Ogni identificatore da attestare è espresso come una stringa con codifica UTF-8.

Se il dispositivo non supporta l'attestazione dell'ID (o in precedenza era stato chiamato destroyAttestationIds() e il dispositivo non può più attestare i propri ID), qualsiasi richiesta di attestazione della chiave che include uno o più di questi tag ha esito negativo con ErrorCode::CANNOT_ATTEST_IDS .

Se il dispositivo supporta l'attestazione dell'ID e uno o più dei suddetti tag sono stati inclusi in una richiesta di attestazione della chiave, il TEE verifica che l'identificatore fornito con ciascuno dei tag corrisponda 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 per lo stesso tag da fornire più volte. Questo può essere utile, ad esempio, quando si attestano gli IMEI: un dispositivo può avere più radio con più IMEI. Una richiesta di attestazione è valida se il valore fornito con ogni ATTESTATION_ID_IMEI corrisponde a una delle radio del dispositivo. Lo stesso vale per tutti gli altri tag.

Se l'attestazione ha esito positivo, gli ID attestati vengono aggiunti all'estensione dell'attestazione (OID 1.3.6.1.4.1.11129.2.1.17) del certificato di attestazione emesso, utilizzando lo schema di cui sopra . Le modifiche rispetto allo schema di attestazione Keymaster 2 sono in grassetto , con commenti.

API Java

Questa sezione è solo informativa. Gli implementatori di Keymaster non implementano né utilizzano l'API Java. Questo viene fornito per aiutare gli implementatori a capire come la funzione viene utilizzata dalle applicazioni. I componenti del sistema possono usarlo in modo diverso, motivo per cui è fondamentale che questa sezione non sia 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].