Implementar reuniones de confianza cero

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 JSON Web Encryption (JWE) https://datatracker.ietf.org/doc/html/rfc7516 y JSON Web Signature (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 debes incluir al crear los blobs JWE son:

• Cabecera JOSE (protegida). 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": "A256GCM"

    Se admiten estos dos algoritmos de cifrado.

  • "cisco-action": "add" o "cisco-action": "populate" 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.

    La hemos llamado cisco-action para mitigar posibles conflictos con futuras extensiones 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 de claves). El valor de salt debe ser una secuencia codificada en base64 URL de al menos 4 bytes, que usted debe elegir al azar.

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

• Vector de inicialización 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, es necesario sobrescribirlo con un valor vacío.

  Hay diferentes tipos de cargas, según lo que intente hacer en el dispositivo. Diferentes comandos xAPI esperan diferentes cargas útiles, y debe especificar el propósito de la carga útil con la clave cisco-action , 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 contiene el certificado y su clave privada (concatenados).

  • 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 no se utilice en 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 obtenemos la clave de cifrado a partir 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 proporcionar esta misma sal cuando especifique 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 "version": "1", que es la única versión que actualmente toma 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. Este ejemplo utiliza A128GCM (AES con claves de 128 bits en modo contador de Galois). Su herramienta podría utilizar A256GCM si lo prefiere.

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

3. He aquí un ejemplo de llamada a scrypt para crear la clave de cifrado de contenido (cek):

   cek=scrypt(contraseña="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 como lZ66bdEiAQV4_mqdInj_rA.

4. Elija una secuencia aleatoria de 12 bytes para usar como vector de inicialización. Este ejemplo utiliza (hex) 34 b3 5d dd 5f 53 7b af 2d 92 95 83 que base64url codifica como 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 en 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 de la mancha 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 sin cifrar va a ser el falso blob PEM esto es un archivo PEM

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

   • Payload es se trata de un archivo PEM

   • El cifrado es AES 128 GCM

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

   Base64url codificar la carga útil cifrada, que debe resultar en f5lLVuWNfKfmzYCo1YJfODhQ

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

9. Base64url codificar la etiqueta que ha producido en el paso 8, lo que debería resultar en 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:

    eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRDQVA0TV9ZIwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..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:

    xCommand Security Certificates Añadir eyJhbGciOiJkaXIiLCJjaXNjby1hY3Rpb24iOiJhZGQiLCJjaXNjby1rZGYiOnsic2FsdCI6IjVlWlRQVA0TV9ZIiwidmVyc2lvbiI6IjEifSwiZW5jIjoiQTEyOEdDTSJ..9NLNd3V9Te68tkpWD.f5lLVuWNfKfmzYCo1YJfODhQ.PE-wDFWGXFFBeo928cfZ1Q