Come viene utilizzato il formato JWE

In questa sezione viene descritto come ci si aspetta che il JWE venga creato come input per i dispositivi, in modo che sia possibile creare il proprio strumento per creare i blobs dai certificati e dalle chiavi.

Fare riferimento a Crittografia Web JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 e Firma Web JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Viene utilizzata la serializzazione compatta di un documento JSON per creare blobs JWE. I parametri che è necessario includere quando si creano i blobs JWE sono:

• Intestazione JOSE (protetta). Nell'intestazione JSON Object Signing and Encryption, è NECESSARIO includere le seguenti coppie chiave-valore:

  • "alg":"dir"

    L'algoritmo diretto è l'unico supportato per la crittografia del payload e devi utilizzare la chiave privata del client iniziale del dispositivo.

  • "enc":"A128GCM" o "enc":"A256GCM"

    Questi due algoritmi di crittografia sono supportati.

  • "cisco-action": "add" o "cisco-action": "populate" o "cisco-action": "activate" o "cisco-action": "deactivate"

    Si tratta di una chiave proprietaria e di quattro valori che può assumere. Abbiamo introdotto questa chiave per segnalare lo scopo dei dati crittografati al dispositivo di destinazione. I valori hanno il nome dei comandi xAPI sul dispositivo in cui si utilizzano i dati crittografati.

    Lo abbiamo denominato cisco-action per attenuare potenziali conflitti con estensioni JWE future.

  • "cisco-kdf": { "version": "1", "salt": "base64URLEncodedRandom4+Bytes" }

    Un'altra chiave proprietaria. I valori forniti vengono utilizzati come input per la derivazione chiave sul dispositivo. Il valore version deve essere 1 (la versione della funzione di derivazione chiave). Il valore di salt deve essere una sequenza codificata per URL base64 di almeno 4 byte, che è necessario scegliere casualmente.

• Chiave crittografata JWE. Questo campo è vuoto. Il dispositivo lo ricava dal ClientSecret iniziale.

• Vettore di inizializzazione JWE. È necessario fornire un vettore di inizializzazione codificato base64url per la decrittografia del payload. IV DEVE essere un valore casuale di 12 byte (stiamo utilizzando la famiglia di crittografia AES-GCM, che richiede che IV sia lungo 12 byte).

• JWE AAD (ulteriori dati autenticati). È necessario omettere questo campo poiché non è supportato nella serializzazione compatta.

• Testo cifrato JWE: Questo è il payload crittografato che si desidera mantenere segreto.

  Il payload POTREBBE essere vuoto. Ad esempio, per reimpostare la chiave privata del client, è necessario sovrascriverla con un valore vuoto.

  Esistono diversi tipi di payload, a seconda di ciò che si sta tentando di fare sul dispositivo. Comandi xAPI diversi prevedono payload diversi e devi specificare lo scopo del payload con la cisco-action chiave, come segue:

  • Con "cisco-action":"populate" il testo cifrato è il nuovo ClientSecret.

  • Con ""cisco-action":"add" il testo cifrato è un blob PEM che trasporta il certificato e la relativa chiave privata (concatenata).

  • Con ""cisco-action":"activate" il testo cifrato è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo attivando per la verifica dell'identità del dispositivo.

  • Con ""cisco-action":"deactivate" il testo cifrato è l'impronta digitale (rappresentazione esadecimale di sha-1) del certificato che stiamo disattivando per la verifica dell'identità del dispositivo.

• Tag autenticazione JWE: Questo campo contiene il tag di autenticazione per accertare l'integrità dell'intero blob serializzato in modo compatto di JWE

Come si ricava la chiave di crittografia dal ClientSecret

Dopo la prima popolazione del segreto, non accettiamo o visualizziamo il segreto come testo normale. Questo è per prevenire potenziali attacchi nel dizionario da parte di qualcuno che potrebbe accedere al dispositivo.

Il software del dispositivo utilizza la chiave privata client come input per una funzione di derivazione chiave (kdf) e quindi utilizza la chiave derivata per la decrittografia/crittografia del contenuto sul dispositivo.

Questo significa che il tuo strumento per produrre blobs JWE deve seguire la stessa procedura per ottenere la stessa chiave di crittografia/decrittografia dalla chiave privata del client.

I dispositivi utilizzano scrypt per la derivazione della chiave (vedere https://en.wikipedia.org/wiki/Scrypt), con i seguenti parametri:

• CostFactor (N) è 32768

• BlockSizeFactor (r) è 8

• Fattore di parallelizzazione (p) è 1

• Salt è una sequenza casuale di almeno 4 byte; occorre fornire lo stesso valore salt quando si specifica il cisco-kdf parametro.

• La lunghezza della chiave è 16 byte (se si seleziona l'algoritmo AES-GCM 128) o 32 byte (se si seleziona l'algoritmo AES-GCM 256)

• Il limite massimo di memoria è 64 MB

Questo set di parametri è l'unica configurazione di scrypt compatibile con la funzione di derivazione dei tasti sui dispositivi. Questo kdf sui dispositivi è denominato "version":"1", che è l'unica versione attualmente utilizzata dal cisco-kdf parametro.

Esempio di lavoro

Di seguito è riportato un esempio che è possibile seguire per verificare che il processo di crittografia JWE funzioni come quello creato sui dispositivi.

Nello scenario di esempio si sta aggiungendo un blob PEM al dispositivo (imita l'aggiunta di un certificato, con una stringa molto breve anziché un certificato + chiave completo). La chiave privata del client nell'esempio è ossifrage.

1. Scegliere una crittografia. Questo esempio utilizza A128GCM (AES con chiavi a 128 bit in modalità contatore Galois). Il tuo strumento potrebbe utilizzare A256GCM se preferisci.

2. Scegliere un sale (deve essere una sequenza casuale di almeno 4 byte). Questo esempio utilizza (byte esadecimali)E5 E6 53 08 03 F8 33 F6. Base64url codifica la sequenza per ottenere 5eZTCAP4M_Y (rimuovere l'imbottitura base64).

3. Di seguito è riportata una scrypt chiamata di esempio per creare la chiave di crittografia del contenuto (cek):

   cek=scrypt(password="ossifrage", salt=4-byte-sequence, N=32768, r=8, p=1, keylength=16)

   La chiave derivata deve essere di 16 byte (esadecimale) come segue:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac quale base64url codifica a lZ66bdEiAQV4_mqdInj_rA.

4. Scegliere una sequenza casuale di 12 byte da utilizzare come vettore di inizializzazione. In questo esempio viene utilizzato (esadecimale) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 quale base64url codifica a NLNd3V9Te68tkpWD.

5. Creare l'intestazione JOSE con serializzazione compatta (seguire lo stesso ordine di parametri che usiamo qui), quindi base64url la codifica:

   {"alg":"dir","cisco-action":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

   L'intestazione JOSE codificata base64url è eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   Questo sarà il primo elemento del blob JWE.

6. Il secondo elemento del blob JWE è vuoto, perché non viene fornita una chiave di crittografia JWE.

7. Il terzo elemento del blob JWE è il vettore di inizializzazione NLNd3V9Te68tkpWD.

8. Utilizzare lo strumento di crittografia JWE per produrre un payload e un tag crittografati. Per questo esempio, il payload non crittografato sarà il falso blob PEM this is a PEM file

   I parametri di crittografia che si devono utilizzare sono:

   • Payload this is a PEM file

   • La crittografia è AES 128 GCM

   • L'intestazione JOSE codificata base64url come AAD (Additional Authenticated Data)

   Base64url codifica il payload crittografato, che dovrebbe risultare in f5lLVuWNfKfmzYCo1YJfODhQ

   Questo è il quarto elemento (JWE Ciphertext) nel blob JWE.

9. Base64url codifica il tag prodotto nel passaggio 8, che dovrebbe risultare in PE-wDFWGXFFBeo928cfZ1Q

   Questo è il quinto elemento del blob JWE.

10. Concatenare i cinque elementi del blob JWE con puntini (JOSEheader..IV.Ciphertext.Tag) per ottenere:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Se hai derivato gli stessi valori codificati base64url che mostriamo qui, utilizzando i tuoi strumenti, sei pronto a utilizzarli per proteggere la crittografia E2E e verificare l'identità dei tuoi dispositivi.

12. Questo esempio in realtà non funziona, ma in linea di principio il tuo passo successivo è quello di utilizzare il blob JWE creato sopra come input per il comando xcommand sul dispositivo che aggiunge il certificato:

    xCommand Security Certificates Add eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q