Cómo utilizamos el formato JWE

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

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

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

• Encabezado JOSE (protegido). En el encabezado De firma de objetos JSON y cifrado, DEBE incluir los siguientes pares de valor de clave:

  • "alg":"dir"

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

  • "enc":"A128GCM" o "enc":"A GCM"

    Se admiten estos dos algoritmos de cifrado.

  • "cisco-action": "agregar" o "cisco-action": "llenar" o "cisco-action": "activar" o "cisco-action": "desactivar"

    Esta es una clave de propiedad y cuatro valores que puede tomar. Hemos introducido esta clave para señalizar el propósito de los datos cifrados en el dispositivo de destino. Los valores se llaman después de los comandos de xAPI en el dispositivo donde está utilizando los datos cifrados.

    Lo llamamos cisco-action para mitigar posibles enfrentamientos 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 versión debe ser 1 (la versión de nuestra función de derivación clave). El valor de salt debe ser una secuencia codificada por URL base64 de al menos 4 bytes, que debe elegir al azar.

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

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

• JWE AAD (datos autenticados adicionales). Debe omitir este campo porque no es compatible con la Ser jsonización compacta.

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

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

  Hay diferentes tipos de cargas, según lo que intente hacer en el dispositivo. Los diferentes comandos xAPI esperan diferentes cargas útiles, y debe especificar el propósito de la carga útil con la clave cisco-action , de la siguiente manera:

  • 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 identidad del dispositivo.

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

• Etiqueta de autenticación JWE: Este campo contiene la etiqueta de autenticación para garantizar la integridad de todo JWE compactamente reorial

Cómo derivamos la clave de cifrado de ClientSecret

Después de la primera población del secreto, no aceptamos ni generamos 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 del cliente como entrada a una función de derivación de claves (kdf) y luego utiliza la clave derivada para el descifrado/cifrado de contenido en el dispositivo.

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

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

• Cost Hr (N) es 32768

• BlockSizeSize (r) es 8

• Paraleloización Mi (p) es 1

• La sal es una secuencia aleatoria de al menos 4 bytes; debe suministrar esta misma sal al especificar el parámetro cisco-kdf .

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

• La capacidad máxima de memoria es 64 MB

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

Ejemplo funcionad

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

La situación de ejemplo es agregar un PEM al dispositivo (imite a agregar un certificado, con una cadena muy corta en lugar de una tecla + certificado completo). El secreto de cliente en el ejemplo es ossifrage.

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

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

3. Aquí hay una llamada de ejemplo scrypt para crear la clave de cifrado de contenido (cek):

   cek=scrypt(password="ossifrage", salt=secuencia de 4 bytes, N=32768, r=8, p=1, keylength=16)

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

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

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

   {"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 elemento JWE después.

6. El segundo elemento de la JWE después está vacío, porque no estamos suministrando un archivo JWE clave de cifrado.

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

8. Utilice su herramienta de cifrado JWE para generar una carga y una etiqueta cifradas. Para este ejemplo, la carga útil no cifrada será el bloque PEM falso este es un archivo PEM

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

   • La carga útil es este es un archivo PEM

   • 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 lugar a f5lLVuWNfKfmzYCo1YJfODhQ

   Este es el cuarto elemento (texto de cifrado JWE) en el JWE después.

9. Base64url codifica la etiqueta que ha producido en el paso 8, lo que debería dar lugar a PE-wDFWGXFFBeo928cfZ1Q

   Este es el quinto elemento de la lista JWE.

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

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q

11. Si deriva los mismos valores codificados en base64url que mostramos aquí, mediante sus propias herramientas, estará en disposición de utilizarlos para asegurar el cifrado E2E e identidad verificada de sus dispositivos.

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

    Certificados de seguridad de xCommand Agregar eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q