Cómo utilizamos el formato JWE

Esta sección describe cómo esperamos que se cree el JWE como entrada en los dispositivos, de modo que puede crear su propia herramienta para crear los blobs a partir de sus certificados y claves.

Consulte Cifrado web JSON (JWE) https://datatracker.ietf.org/doc/html/rfc7516 y Firma web JSON (JWS) https://datatracker.ietf.org/doc/html/rfc7515.

Utilizamos la Serialización compacta de un documento JSON para crear blobs de JWE. Los parámetros que debe incluir al crear los blobs de JWE son:

• Encabezado JOSE (protegido). En el encabezado Signing and Encryption (Firma y cifrado de objetos JSON), DEBE incluir los siguientes pares de valores de clave:

  • "alg":"dir"

    El algoritmo directo es el único que admitimos para cifrar la carga útil, y debe utilizar el secreto de cliente inicial del dispositivo.

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

    Admitimos estos dos algoritmos de cifrado.

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

    Esta es una clave patentada y cuatro valores que puede tomar. Introdujimos esta clave para indicar el propósito de los datos cifrados al dispositivo de destino. Los valores reciben el nombre de los comandos xAPI del dispositivo en el que está utilizando los datos cifrados.

    Lo hemos nombrado cisco-action para mitigar posibles choques con futuras extensiones de JWE.

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

    Otra clave de propiedad. Utilizamos los valores que proporciona como entradas para la derivación de claves en el dispositivo. La version debe ser 1 (la versión de nuestra función de derivación de claves). El valor de salt debe ser una secuencia base64 codificada por URL de al menos 4 bytes, que debe elegir al azar.

• Clave cifrada de JWE. Este campo está vacío. El dispositivo lo deriva del ClientSecret inicial.

• Vector de inicialización de JWE. Debe proporcionar un vector de inicialización codificada base64url para descifrar la carga útil. El valor IV DEBE ser un valor aleatorio de 12 bytes (estamos utilizando la familia de cifrado AES-GCM, que requiere que el valor IV tenga una longitud de 12 bytes).

• JWE AAD (datos autenticados adicionales). Debe omitir este campo porque no se admite en la serialización compacta.

• Texto cifrado de JWE: Esta es la carga útil cifrada que desea mantener en secreto.

  La carga útil PUEDE estar vacía. Por ejemplo, para restablecer el secreto de cliente, debe sobrescribirlo con un valor vacío.

  Hay diferentes tipos de cargas útiles, según lo que esté tratando de hacer en el dispositivo. Los diferentes comandos de xAPI esperan diferentes cargas útiles, y debe especificar el propósito de la carga útil con la cisco-action clave, como se indica a continuación:

  • Con "cisco-action":"populate" el texto cifrado es el nuevo ClientSecret.

  • Con ""cisco-action":"add" el texto cifrado es un blob PEM que lleva el certificado y su clave privada (concatenada).

  • Con ""cisco-action":"activate" el texto cifrado es la huella digital (representación hexadecimal de sha-1) del certificado que estamos activando para la verificación de la identidad del dispositivo.

  • Con ""cisco-action":"deactivate" el texto cifrado es la huella digital (representación hexadecimal de sha-1) del certificado que estamos desactivando para que se utilice para la verificación de identidad del dispositivo.

• Etiqueta de autenticación de JWE: Este campo contiene la etiqueta de autenticación para determinar la integridad de todo el blob JWE serializado compactly

Cómo derivamos la clave de cifrado de la ClientSecret

Después de la primera población del secreto, no aceptamos ni mostramos el secreto como texto sin formato. Esto es para evitar posibles ataques de diccionario por parte de alguien que podría acceder al dispositivo.

El software del dispositivo utiliza el secreto de cliente como entrada a una función de derivación de claves (kdf) y, a continuación, utiliza la clave derivada para el descifrado/cifrado de contenido en el dispositivo.

Lo que esto significa para usted es que su herramienta para producir blobs JWE debe seguir el mismo procedimiento para derivar la misma clave de cifrado/descifrado del secreto de cliente.

Los dispositivos utilizan scrypt para la derivación de claves (consulte https://en.wikipedia.org/wiki/Scrypt), con los siguientes parámetros:

• El factor de coste (N) es 32768

• BlockSizeFactor (r) es 8

• El factor de paralelización (p) es 1

• sal es una secuencia aleatoria de al menos 4 bytes; debe suministrarla salt cuando especifique el cisco-kdf parámetro.

• La longitud de la clave es de 16 bytes (si selecciona el algoritmo AES-GCM 128) o de 32 bytes (si selecciona el algoritmo AES-GCM 256)

• El límite máximo de memoria es de 64 MB

Este conjunto de parámetros es la única configuración de scrypt que es compatible con la función de derivación de claves en los dispositivos. Este kdf en los dispositivos se llama "version":"1", que es la única versión que actualmente toma el parámetro cisco-kdf .

Ejemplo trabajado

A continuación, se muestra un ejemplo que puede seguir para verificar que su proceso de cifrado de JWE funcione de la misma manera que el proceso que creamos en los dispositivos.

El escenario de ejemplo es agregar un blob PEM al dispositivo (imita la adición de un certificado, con una cadena muy corta en lugar de una clave + certificado completa). El secreto de cliente en el ejemplo es ossifrage.

1. Elija un cifrado. En este ejemplo se utiliza A128GCM (AES con claves de 128 bits en el modo contador de Galois). Su herramienta podría usar A256GCM si lo prefiere.

2. Elija una sal (debe ser una secuencia aleatoria de al menos 4 bytes). Este ejemplo usa (bytes hexadecimales)E5 E6 53 08 03 F8 33 F6. Base64url codifica la secuencia para obtener 5eZTCAP4M_Y (eliminar el relleno base64).

3. A continuación, se muestra una scrypt llamada de muestra para crear la clave de cifrado de contenido (cek):

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

   La clave derivada debe ser de 16 bytes (hexadecimales) de la siguiente manera:95 9e ba 6d d1 22 01 05 78 fe 6a 9d 22 78 ff ac que base64url se codifica como lZ66bdEiAQV4_mqdInj_rA.

4. Elija una secuencia aleatoria de 12 bytes para usar como vector de inicialización. En este ejemplo se utiliza (hexadecimal) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 que base64url se codifica como NLNd3V9Te68tkpWD.

5. Cree el encabezado JOSE con serialización compacta (siga el mismo orden de parámetros que utilizamos aquí) y luego base64url lo codifica:

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

   El encabezado JOSE codificado base64url es eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ9

   Este será el primer elemento del blob JWE.

6. El segundo elemento del blob de JWE está vacío, porque no suministramos una clave de cifrado de JWE.

7. El tercer elemento del blob JWE es el vector de inicialización NLNd3V9Te68tkpWD.

8. Utilice su herramienta de cifrado JWE para producir una carga útil y una etiqueta cifradas. Para este ejemplo, la carga útil no cifrada será el falso blob PEM this is a PEM file

   Los parámetros de cifrado que debe utilizar son los siguientes:

   • La carga útil es this is a PEM file

   • El cifrado es AES 128 GCM

   • El encabezado JOSE codificado en base64url como datos autenticados adicionales (AAD)

   Base64url codifica la carga útil cifrada, lo que debería dar como resultado f5lLVuWNfKfmzYCo1YJfODhQ

   Este es el cuarto elemento (texto cifrado JWE) en el blob JWE.

9. Base64url codifica la etiqueta que produjo en el paso 8, lo que debería dar como resultado PE-wDFWGXFFBeo928cfZ1Q

   Este es el quinto elemento del blob JWE.

10. Concatena los cinco elementos del blob JWE con puntos (JOSEheader..IV.Ciphertext.Tag) para obtener:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Si ha obtenido los mismos valores codificados base64url que mostramos aquí, con sus propias herramientas, está listo para usarlos para asegurar el cifrado E2E y la identidad verificada de sus dispositivos.

12. Este ejemplo no funcionará, pero en principio su próximo paso sería utilizar el blob JWE que creó anteriormente como entrada al xcommand en el dispositivo que agrega el certificado:

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