9.1.4.2.3. Emissione della Key Attestation

Questa sezione descrive come il Fornitore di Wallet emette una Key Attestation.

L'uso delle Key Attestation APIs (OEM) è definito in Uso delle API di Key Attestation (OEM).

La figura illustra il Diagramma di Sequenza per l'acquisizione della Key Attestation.

Fig. 9.5 Diagramma di Sequenza per l'acquisizione della Key Attestation.

Passo 1: L'Utente avvia una nuova operazione che richiede l'acquisizione di una Key Attestation.

Passi 2-3: L'Istanza del Wallet DEVE:

  1. Verificare l'esistenza delle Cryptographic Hardware Keys. Se non esistono, è necessaria la reinizializzazione dell'Istanza del Wallet (WP_140a).

  2. Verificare l'appartenenza del Fornitore di Wallet alla federazione e recuperare i suoi metadati (WP_023).

Passi 4-6 (Recupero del Nonce): L'Istanza del Wallet richiede un nonce all'endpoint Endpoint Nonce della Soluzione Wallet del Backend del Fornitore del Wallet (WP_140b). Il nonce deve essere imprevedibile e funge da principale difesa contro gli attacchi di replay.

Il nonce DEVE garantire un utilizzo singolo entro un intervallo di tempo predeterminato.

In caso di richiesta riuscita, il Fornitore di Wallet genera e restituisce il valore del nonce all'Istanza del Wallet.

Passi 7-9 (Generazione delle chiavi di Credenziale): L'Istanza del Wallet DEVE generare una o più coppie di chiavi asimmetriche delle Credenziali da attestare (key_pub_1, key_priv_1, ..., key_pub_n, key_priv_n) solo dopo che il nonce è disponibile.

Su Android, l'Istanza del Wallet DEVE generare ciascuna coppia di chiavi tramite l'API di Key Attestation. DEVE impostare il challenge di attestazione agli ottetti UTF-8 del nonce. L'API restituisce la chiave pubblica e un key_attestation firmato per quella chiave. L'Istanza del Wallet NON DEVE usare client_data_hash come challenge. client_data_hash dipende dall'impronta JWK della chiave, e la piattaforma vincola il challenge al momento della generazione della chiave.

Su iOS, l'Istanza del Wallet DEVE generare ciascuna coppia di chiavi nel Secure Enclave. L'asserzione di integrità per ciascuna chiave è richiesta dopo il calcolo di client_data_hash.

Passo 10: L'Istanza del Wallet esegue le seguenti azioni (WP_140c):

  • Crea client_data, un oggetto JSON che include il nonce e un campo jwk_thumbprints contenente un array JSON delle impronte JWK corrispondenti alle chiavi pubbliche (key_pub_1, ..., key_pub_n).

  • Calcola client_data_hash applicando l'algoritmo SHA256 a client_data.

Di seguito è riportato un esempio non normativo dell'oggetto JSON client_data.

{
  "nonce": "i4ThI2Jhbu81i8mqyWEuDG5t",
  "jwk_thumbprints": ["vbeXJksM45xphtANnCiG6mCyuU4jfGNzopGuKvogg9c"]
}

Passi 11-12: L'Istanza del Wallet produce un valore hardware_signature firmando client_data_hash con la chiave privata dell'Hardware del Wallet, come prova di possesso delle Cryptographic Hardware Keys (WP_140d).

La Key Attestation Request NON DEVE includere un integrity_assertion di primo livello. Il Fornitore di Wallet controlla lo stato di revoca della Wallet Instance Attestation prima di emettere una Key Attestation. Su iOS, l'asserzione di integrità di ciascuna chiave è trasportata dentro keys_to_attest, perché quella piattaforma non fornisce un'API di key attestation.

Passi 13-16: L'Istanza del Wallet costruisce keys_to_attest come array JSON di JWT. L'header e i claim di ciascun JWT sono definiti in Elemento di Key Attestation.

  • Su Android, quando sono usate le API di Key Attestation (OEM), ciascun JWT trasporta il key_attestation ottenuto alla generazione della chiave in wscd_key_attestation.attestation.

  • Su iOS, l'Istanza del Wallet richiede al Servizio di Integrità del Dispositivo un integrity_assertion per ciascuna chiave, vincolato a client_data_hash, e inserisce quel valore in wscd_key_attestation.integrity_assertion.

Ciascun JWT DEVE essere firmato con la chiave privata della coppia di chiavi di Credenziale che attesta.

Passi 17-18 (Richiesta di Emissione della Key Attestation): L'Istanza del Wallet:

  • Costruisce la Key Attestation Request sotto forma di JWT. Questo JWT include keys_to_attest, hardware_signature, nonce, hardware_key_tag, cnf, platform, wallet_solution_id, wallet_solution_version e altri parametri relativi alla configurazione (vedi Tabella del Corpo della Richiesta di Key Attestation). La Key Attestation Request DEVE essere firmata utilizzando la chiave privata corrispondente alla chiave pubblica inclusa nella richiesta, tramite il parametro cnf (primo elemento di keys_to_attest) (WP_140–141).

  • Invia la Key Attestation Request all'endpoint Endpoint di Emissione della Key Attestation del Backend del Fornitore del Wallet.

L'Istanza del Wallet DEVE inviare il JWT firmato della Richiesta di Key Attestation come parametro assertion nel corpo di una richiesta HTTP all'endpoint Endpoint di Emissione della Key Attestation del Fornitore di Wallet (WP_142).

Passi 19-24: Il Backend del Fornitore del Wallet valuta la Richiesta di Key Attestation e DEVE eseguire i seguenti controlli (WP_143):

  1. La richiesta DEVE includere tutti i parametri dell'intestazione HTTP richiesti come definito in Richiesta di Emissione della Key Attestation (WP_143a).

  2. La firma della Richiesta di Key Attestation DEVE essere valida e verificabile utilizzando la jwk fornita (WP_143b).

  3. Il valore nonce DEVE essere stato generato dal Fornitore di Wallet e non essere stato utilizzato in precedenza (WP_143c).

  4. DEVE esistere un'Istanza del Wallet valida e attualmente registrata associata al hardware_key_tag (WP_143d). Il Fornitore di Wallet DEVE rifiutare la richiesta quando la Wallet Instance Attestation di quell'Istanza del Wallet è revocata.

  5. La firma di ciascun JWT in keys_to_attest DEVE essere validata utilizzando la jwk di quell'elemento. Se wscd_key_attestation.attestation è presente, il Fornitore di Wallet DEVE validarlo secondo le linee guida del produttore del dispositivo, come definito in Uso delle API di Key Attestation (OEM) (WP_143h). Il challenge incorporato in quell'attestazione DEVE essere uguale agli ottetti UTF-8 del nonce. La chiave pubblica attestata DEVE corrispondere alla JWK cnf dello stesso elemento. Se wscd_key_attestation.integrity_assertion è presente, il Fornitore di Wallet DEVE validarlo secondo le linee guida del produttore del dispositivo.

  6. Il client_data DEVE essere ricostruito utilizzando il nonce e le rispettive thumbprint JWK [key_pub_1,...,key_pub_n]. Il valore del parametro hardware_signature viene quindi convalidato utilizzando la chiave pubblica della Cryptographic Hardware Key registrata associata all'Istanza del Wallet (WP_143e).

  7. Il dispositivo in uso DEVE essere privo di difetti di sicurezza noti e soddisfare i requisiti minimi di sicurezza definiti dal Fornitore di Wallet.

  8. L'URL nel parametro iss DEVE corrispondere all'identificatore URL del Fornitore di Wallet (WP_143g).

Al completamento con successo di tutte le verifiche, il Fornitore di Wallet emette una Key Attestation valida per almeno un mese (WP_144).

Passo 25 (Risposta di Emissione della Key Attestation): Al completamento con successo, il Fornitore di Wallet DEVE restituire una risposta di conferma con codice di stato 200 e Content-Type application/json. La risposta DEVE contenere le Key Attestations firmate dal Fornitore di Wallet in formato JWT. L'Istanza del Wallet DEVE eseguire la verifica di sicurezza e integrità delle Key Attestations ricevute, insieme alla verifica di fiducia già valutata sull'Emittente (WP_030–031).

Di seguito è riportato un esempio non normativo della risposta.

HTTP/1.1 200 OK
Content-Type: application/json

{
  "key_attestation": "omppc3N1ZXJBdXRohEOhASaiBE...dElEAnFlbGVtZW50SWRl"
}