Merci pour votre commentaire.

Comment nous utilisons le format JWE

Cette section décrit comment nous pensons que le JWE sera créé en entrée sur les appareils, afin que vous puissiez créer votre propre outil pour créer des blobs à partir de vos certificats et de vos clés.

Consultez JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 et JSON Web Signature (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Nous utilisons la sérialisation compacte d'un document JSON pour créer des blobs JWE. Les paramètres que vous devez inclure lors de la création des blobs JWE sont les suivants :

• JOSE Header (protégé). Dans l'en-tête JSON Object Signing and Encryption, vous DEVEZ inclure les paires clé-valeur suivantes :

  • « alg » :"dir »

    L'algorithme direct est le seul que nous prenons en charge pour crypter la charge utile, et vous devez utiliser le secret client initial de l'appareil.

  • « enc » :"A128GCM » ou « enc » :"A256GCM »

    Nous prenons en charge ces deux algorithmes de cryptage.

  • « cisco-action » : « ajouter » ou « cisco-action » : « remplir » ou « cisco-action » : « activer » ou « cisco-action » : « désactiver »

    Il s'agit d'une clé propriétaire qui peut prendre quatre valeurs. Nous avons introduit cette clé pour indiquer à l'appareil cible l'objectif des données cryptées. Les valeurs sont nommées d'après les commandes xAPI de l'appareil sur lequel vous utilisez les données cryptées.

    Nous l'avons baptisée cisco-action pour atténuer les conflits potentiels avec les futures extensions de JWE.

  • « cisco-kdf » : {« version » : « 1 », « salt » : « Base64URLEncodedRandom4+octets »}

    Une autre clé propriétaire. Nous utilisons les valeurs que vous fournissez comme entrées pour la dérivation des clés sur l'appareil. La version doit être 1 (la version de notre fonction de dérivation clé). La valeur de salt doit être une séquence d'au moins 4 octets codée en URL en base64, que vous devez choisir au hasard.

• Clé cryptée JWE. Ce champ est vide. L'appareil le dérive du ClientSecret initial.

• Vecteur d'initialisation JWE. Vous devez fournir un vecteur d'initialisation codé en base64url pour déchiffrer la charge utile. L'IV DOIT être une valeur aléatoire de 12 octets (nous utilisons la famille de chiffrement AES-GCM, qui exige que l'IV fasse 12 octets).

• JWE AAD (données authentifiées supplémentaires). Vous devez omettre ce champ car il n'est pas pris en charge dans la sérialisation compacte.

• JWE Ciphertext : Il s'agit de la charge utile cryptée que vous souhaitez garder secrète.

  La charge utile est PEUT-ÊTRE vide. Par exemple, pour réinitialiser le secret client, vous devez le remplacer par une valeur vide.

  Il existe différents types de charges utiles, selon ce que vous essayez de faire sur l'appareil. Les différentes commandes xAPI s'attendent à des charges utiles différentes, et vous devez spécifier l'objectif de la charge à l'aide de la touche cisco-action, comme suit :

  • Avec « cisco-action » :"populate », le texte chiffré est le nouveau ClientSecret.

  • Avec « « cisco-action » :"add », le texte chiffré est un blob PEM contenant le certificat et sa clé privée (concaténés).

  • Avec « « cisco-action » :"activate », le texte chiffré est l'empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous activons pour vérifier l'identité de l'appareil.

  • Avec « « cisco-action » :"deactivate », le texte chiffré est l'empreinte digitale (représentation hexadécimale de sha-1) du certificat que nous désactivons pour vérifier l'identité de l'appareil.

• Balise d'authentification JWE : ce champ contient la balise d'authentification qui permet de vérifier l'intégrité de l'intégralité du blob JWE sérialisé de manière compacte

Comment dérive-t-on la clé de cryptage à partir du ClientSecret

Une fois le secret renseigné pour la première fois, nous ne l'acceptons pas et ne le publions pas en texte brut. C'est pour empêcher d'éventuelles attaques par dictionnaire par quelqu'un qui pourrait accéder à l'appareil.

Le logiciel de l'appareil utilise le secret du client comme entrée d'une fonction de dérivation de clé (KDF), puis utilise la clé dérivée pour le déchiffrement/chiffrement du contenu sur l'appareil.

Cela signifie pour vous que votre outil de production de blobs JWE doit suivre la même procédure pour obtenir la même clé de chiffrement/déchiffrement à partir du secret client.

Les appareils utilisent Scrypt pour la dérivation des clés (voir https://en.wikipedia.org/wiki/Scrypt), avec les paramètres suivants :

• CostFactor (N) est de 32 768

• BlockSizeFactor (r) est de 8

• Le facteur de parallélisation (p) est de 1

• Le sel est une séquence aléatoire d'au moins 4 octets ; vous devez fournir le même sel lorsque vous spécifiez le paramètre cisco-kdf.

• La longueur des clés est soit de 16 octets (si vous sélectionnez l'algorithme AES-GCM 128), soit de 32 octets (si vous sélectionnez l'algorithme AES-GCM 256)

• La capacité de mémoire maximale est de 64 Mo

Cet ensemble de paramètres est la seule configuration de scrypt compatible avec la fonction de dérivation des clés des appareils. Ce fichier KDF sur les appareils s'appelle « version » :"1 », c'est la seule version actuellement prise en charge par le paramètre cisco-kdf.

Exemple concret

Voici un exemple que vous pouvez suivre pour vérifier que votre processus de cryptage JWE fonctionne de la même manière que celui que nous avons créé sur les appareils.

L'exemple de scénario consiste à ajouter un blob PEM à l'appareil (cela ressemble à l'ajout d'un certificat, avec une chaîne très courte au lieu d'un certificat complet et d'une clé). Dans l'exemple, le secret du client est l'ossifrage.

1. Choisissez un code de chiffrement. Cet exemple utilise le A128GCM (AES avec clés 128 bits en mode compteur Galois). Votre outil pourrait utiliser un A256GCM si vous préférez.

2. Choisissez un sel (il doit s'agir d'une séquence aléatoire d'au moins 4 octets). Cet exemple utilise (octets hexadécimaux) E5 E6 53 08 03 F8 33 F6. Encodez la séquence en Base64URL pour obtenir 5EZTCap4M_Y (supprimez le remplissage en base64).

3. Voici un exemple d'appel de script pour créer la clé de chiffrement du contenu (cek) :

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

   La clé dérivée doit être de 16 octets (hexadécimal) comme suit : 95 9e ba 6d d1 22 05 78 fe 6a 9d 22 78 ff ac que base64url code en LZ66bdeiaqv4_MQDINJ_RA.

4. Choisissez une séquence aléatoire de 12 octets à utiliser comme vecteur d'initialisation. Cet exemple utilise (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83, que base64url code en NLd3v9Te68TkPwd.

5. Créez l'en-tête JOSE avec une sérialisation compacte (suivez le même ordre de paramètres que nous utilisons ici), puis encodez-le en base64url :

   {"alg » :"dir », « cisco-action » :"ajouter », « cisco-kdf » : {"salt » :"5EZTCap4M_Y », « version » :"1"}, « enc » :"A128GCM «}

   L'en-tête JOSE codé en base64 URL est EYJHBGCIOIJKAxiilcjjaxNjby1hy3rpb24ioijHzgqilcjjaXNjby1rzgyionsIc2FSDCi6ijvlWLrdQva0Tv9ZiiWidmVyc2LvBiI6ijIfswizW5jIIQTeyoEdDtsJ9

   Ce sera le premier élément du blob JWE.

6. Le deuxième élément du blob JWE est vide, car nous ne fournissons pas de clé de cryptage JWE.

7. Le troisième élément du blob JWE est le vecteur d'initialisation nLnd3v9Te68TkPwd.

8. Utilisez votre outil de cryptage JWE pour générer une charge utile et un tag cryptés. Pour cet exemple, la charge utile non chiffrée sera le faux blob PEM, il s'agit d'un fichier PEM

   Les paramètres de cryptage à utiliser sont les suivants :

   • La charge utile est un fichier PEM

   • Le chiffrement est AES 128 GCM

   • L'en-tête JOSE codé en base64url en tant que données authentifiées supplémentaires (AAD)

   Base64URL encode la charge utile cryptée, ce qui devrait donner F5LLVUWnFKFmZyCo1YJFODHQ

   Il s'agit du quatrième élément (JWE Ciphertext) du blob JWE.

9. Base64URL code le tag que vous avez produit à l'étape 8, ce qui devrait donner PE-WDFWGxFFBeo928CFZ1Q

   Il s'agit du cinquième élément du blob JWE.

10. Concaténez les cinq éléments du blob JWE avec des points (JoseHeader.. IV.CipherText.Tag) pour obtenir :

    EYJHBGCIOIJkaXIILCJJaxNJby1HY3RPB24ioijHZGQILCJJaxNjby1RZGYionsIc2FSDCi6ijVLWLrdQva0Tv9ziiWidmVyc2LvII6iJEifswizW5JIJOIqteyoeddtsj.. 9NLnd3v9te68TkPWD.F5LLVUDtsj. wnfkfmzyco1yjfodhq.pe-wdfwgxffbeo928cfz1Q

11. Si vous avez dérivé les mêmes valeurs encodées en base64url que celles indiquées ici, en utilisant vos propres outils, vous êtes prête à les utiliser pour sécuriser le cryptage E2E et vérifier l'identité de vos appareils.

12. Cet exemple ne fonctionnera pas vraiment, mais en principe, la prochaine étape serait d'utiliser le blob JWE que vous avez créé ci-dessus comme entrée de la commande qui ajoute le certificat sur l'appareil :

    Certificats de sécurité de commande Ajoutez EyjHBGCIoijkaxiilcjjaxNjby1hy3rpb24ioijhzgqilcjjaXNjby1rzgyionsIc2FSDCi6ijvlWLrdQva0tv9ziiWidmVyc2LvBii6iJEifswizw5jijIIqteyoeddtsj. 9nLnd3v9te68TkWD.F5LLVUWNFKFMZYCO1YJFODHQ.PE-WDFWGXFFBeO928CFZ1Q