Comment nous utilisons le format JWE

Cette section décrit comment nous nous attendons à ce que le JWE soit créé en entrée des périphériques, afin que vous puissiez créer votre propre outil pour créer les objets blob à partir de vos certificats et clés.

Reportez-vous à Chiffrement Web JSON (JWE)https://datatracker.ietf.org/doc/html/rfc7516et Signature Web JSON (JWS)https://datatracker.ietf.org/doc/html/rfc7515.

Nous utilisons le 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 :

• En-tête JOSE (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 chiffrer la charge utile, et vous devez utiliser le secret client initial du périphérique.

  • "enc":"A128GCM" ou "enc":"A256GCM"

    Nous prenons en charge ces deux algorithmes de chiffrement.

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

    Il s'agit d'une clé propriétaire et de quatre valeurs qu'elle peut prendre. Nous avons introduit cette clé pour signaler le but des données chiffrées au périphérique cible. Les valeurs sont nommées d'après les commandes xAPI sur le périphérique sur lequel vous utilisez les données chiffrées.

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

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

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

• Clé chiffrée JWE . Ce champ est vide. Le périphérique le dérive de la ClientSecret.

• Vecteur d'initialisation JWE . Vous devez fournir un vecteur d'initialisation codé en base64url pour déchiffrer la charge utile. Le IV DOIT être une valeur aléatoire de 12 octets (nous utilisons la famille de chiffrement AES-GCM, qui nécessite que l'IV soit long de 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.

• Texte chiffré JWE : Il s’agit de la charge utile chiffrée que vous souhaitez garder secrète.

  La charge utile 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, en fonction de ce que vous essayez de faire sur le périphérique. Différentes commandes xAPI s'attendent à des charges utiles différentes, et vous devez spécifier le but de la charge utile avec le cisco-action clé, comme suit :

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

  • Avec " "cisco-action":"add" le texte chiffré est un blob PEM portant 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 la vérification de l'identité du périphérique.

  • 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 qu'il ne soit pas utilisé pour la vérification de l'identité du périphérique.

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

Comment nous dérivons la clé de chiffrement du ClientSecret

Après le premier remplissage du secret, nous n'acceptons ni ne sortons le secret sous forme de texte brut. Ceci permet d'éviter les attaques potentielles par dictionnaire par une personne qui pourrait accéder au périphérique.

Le logiciel du périphérique utilise la clé secrète 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 le périphérique.

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

Les périphériques utilisent crypter pour la dérivation de clé (voirhttps://en.wikipedia.org/wiki/Scrypt ), avec les paramètres suivants :

• Le facteur de coût (N) est 32768

• BlockSizeFactor (r) est 8

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

• Salt est une séquence aléatoire d'au moins 4 octets ; vous devez fournir ce même salt lorsque vous spécifiez le cisco-kdf AUTOOC.

• 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 crypter qui est compatible avec la fonction de dérivation de clé sur les périphériques. Ce kdf sur les périphériques est appelé "version":"1", qui est la seule version actuellement prise par le cisco-kdf AUTOOC.

Exemple de travail

Voici un exemple que vous pouvez suivre pour vérifier que votre processus de chiffrement JWE fonctionne de la même manière que le processus que nous avons créé sur les périphériques.

L’exemple de scénario consiste à ajouter un blob PEM au périphérique (imite l’ajout d’un certificat, avec une chaîne très courte au lieu d’une clé cert + complète). La clé secrète du client dans l'exemple est ossifrage.

1. Choisissez un chiffrement de chiffrement. Cet exemple utilise A128GCM(AES avec clés 128 bits en mode compteur Galois). Votre outil pourrait utiliser 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. Base64url encode la séquence à obtenir 5eZTCAP4M_Y(supprimez le remplissage base64).

3. Voici un exemple scrypt appelez 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 (hex) comme suit : 95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac vers laquelle base64url encode 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 vers laquelle base64url encode NLNd3V9Te68tkpWD.

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":"add","cisco-kdf":{"salt":"5eZTCAP4M_Y","version":"1"},"enc":"A128GCM"}

   L'en-tête JOSE encodé en base64url est eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   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 clé de chiffrement JWE .

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

8. Utilisez votre outil de chiffrement JWE pour produire une charge utile chiffrée et une balise. Pour cet exemple, la charge utile non chiffrée sera le faux blob PEM this is a PEM file

   Les paramètres de chiffrement que vous devez utiliser sont :

   • La charge utile est this is a PEM file

   • 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 chiffrée, ce qui devrait entraîner f5lLVuWNfKfmzYCo1YJfODhQ

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

9. Base64url encode la balise que vous avez produite à l'étape 8, ce qui devrait entraîner 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 :

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Si vous avez dérivé les mêmes valeurs encodées en base64url que celles que nous montrons ici, en utilisant vos propres outils, vous êtes prêt à les utiliser pour sécuriser le cryptage E2E et vérifier l’identité de vos périphériques.

12. Cet exemple ne fonctionnera pas réellement, mais en principe, votre prochaine étape consisterait à utiliser le blob JWE que vous avez créé ci-dessus comme entrée de la commande x sur le périphérique qui ajoute le certificat :

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