Bóveda desde la entrada hasta la serie maestra cinco: Transit Secrets Engine

一、Motor de secretos de tránsito

• Transport Confidentiality Engine maneja el cifrado de datos en tránsito. Vault no almacena datos enviados al motor de confidencialidad. Piense también en ello como "criptografía como servicio" o "cifrado como servicio". El motor de secretos de tránsito también puede firmar y verificar datos, generar hashes y HMAC de datos y actuar como una fuente de bytes aleatorios.
• El caso de uso principal para el transporte es cifrar datos de una aplicación mientras se almacenan los datos cifrados en algún almacén de datos principal. Esto descarga la carga del cifrado/descifrado adecuado del desarrollador de la aplicación y pone la carga sobre el operador de Vault.
• Se admite la derivación de claves, lo que permite utilizar la misma clave para múltiples propósitos al derivar nuevas claves en función de los valores de contexto proporcionados por el usuario. En este modo, el cifrado convergente se puede admitir opcionalmente, lo que permite que los mismos valores de entrada produzcan el mismo texto cifrado.
• La generación de claves de datos permite que una solicitud de proceso devuelva una clave de alta entropía de una longitud de bits determinada, cifrada con una clave con nombre. Normalmente, esto también devuelve la clave en texto no cifrado para permitir el uso inmediato, pero esto se puede deshabilitar para requisitos de auditoría.

2. Gestión de conjuntos de trabajo

• El motor de Transit admite el control de versiones de claves. Las versiones de clave anteriores a la min_decryption_version especificada por la clave se archivan y las versiones de clave restantes pertenecen al conjunto de trabajo. Esta es una consideración de rendimiento para mantener las claves cargadas rápidamente, pero también una consideración de seguridad: al no permitir el descifrado de claves de versiones anteriores, se descubrió que la mayoría de los usuarios no pueden descifrar textos cifrados correspondientes a datos obsoletos (pero confidenciales), pero en emergencias min_decryption_version puede ser retrocedió para permitir el descifrado legal.
• Actualmente, este archivo se almacena en una sola entrada de almacenamiento. Para algunos backends de almacenamiento, especialmente aquellos que usan Raft o Paxos para la funcionalidad HA, las rotaciones frecuentes pueden hacer que los tamaños de las entradas de almacenamiento archivado sean más grandes de lo que puede manejar el backend de almacenamiento. Para las necesidades de rotación frecuentes, el uso de claves con nombre que correspondan a intervalos de tiempo (por ejemplo, un período de tiempo de cinco minutos al múltiplo de cinco más cercano) puede ser una buena opción, lo que permite que varias claves estén activas al mismo tiempo, en un solo lugar. Manera determinista de decidir qué tecla usar en un momento dado.

3. Pautas de rotación del NIST

• Se recomienda la rotación regular de las claves de cifrado, incluso en ausencia de compromiso. Para las claves AES-GCM, de acuerdo con las pautas de la Publicación 800-38D del NIST, la rotación debe ocurrir antes de que la versión de la clave realice aproximadamente 232 cifrados. Se recomienda que los operadores calculen la tasa de cifrado de la clave y la utilicen para determinar la frecuencia de rotación para evitar alcanzar el límite de la guía. Por ejemplo, si determina que la tasa estimada es de 40 millones de operaciones por día, es suficiente rotar el secreto cada tres meses.

Cuatro, tipo de llave

A partir de ahora, el motor de secretos de tránsito admite los siguientes tipos de clave (todos los tipos de clave también generan claves HMAC separadas):

• aes128-gcm96: AES-GCM con clave AES de 128 bits y nonce de 96 bits; admite cifrado, descifrado, derivación de claves, cifrado convergente
• aes256-gcm96: AES-GCM con clave AES de 256 bits y nonce de 96 bits; admite cifrado, descifrado, derivación de clave, cifrado convergente (predeterminado)
• chacha20-poly1305: ChaCha20-Poly1305 con clave de 256 bits; admite cifrado, descifrado, derivación de claves, cifrado convergente
• ed25519: Ed25519; soporte para firma, verificación de firma y derivación de clave
• ecdsa-p256: ECDSA usando la curva P-256; admite firmas y verificación de firmas
• ecdsa-p384: ECDSA usando la curva P-384; admite firmas y verificación de firmas
• ecdsa-p521: ECDSA que utiliza la curva P-521; admite firmas y verificación de firmas
• rsa-2048: clave RSA de 2048 bits; admite cifrado, descifrado, firma y verificación
• rsa-3072: clave RSA de 3072 bits; admite cifrado, descifrado, firma y verificación
• rsa-4096: clave RSA de 4096 bits; admite cifrado, descifrado, firma y verificación
• hmac: HMAC; admite la generación y verificación de HMAC.
• Managed_key: clave administrada; admite múltiples operaciones, según la solución de administración de claves de respaldo. Para obtener más información, consulte Claves de custodia.

Nota: En el modo FIPS 140-2, los siguientes algoritmos no están certificados y no deben usarse: chacha20-poly1305 y ed25519.

Nota: Todos los tipos de claves admiten operaciones HMAC mediante el uso de una segunda clave generada aleatoriamente para el tiempo de creación o rotación de claves. El tipo de clave HMAC solo admite HMAC y se comporta igual que otros algoritmos en términos de operaciones HMAC, pero admite la importación de claves. De forma predeterminada, el tipo de clave HMAC utiliza una clave de 256 bits.

Las operaciones RSA utilizan uno de los siguientes métodos:

• OAEP (cifrado, descifrado) con función hash SHA-256 y MGF,
• PSS (Firma, Verificación), con una función hash configurable también utilizada para MGF, y
• PKCS#1v1.5: (firma, verificación), con función hash configurable.

5. Cifrado de fusión

• El cifrado convergente es un modo en el que el mismo conjunto de texto sin formato + contexto siempre produce el mismo texto cifrado. Lo hace derivando claves mediante una función de derivación de claves y derivando números aleatorios de forma determinista. Dado que estas propiedades son diferentes para cualquier combinación de texto sin formato y texto cifrado en un espacio clave de tamaño 2^256, el riesgo de reutilización nonce es casi cero.
• Esto tiene muchos usos prácticos. Un patrón de uso común es permitir que los valores se almacenen cifrados en la base de datos, pero con soporte limitado de búsqueda/consulta para que las filas con el mismo valor para un campo en particular puedan devolverse de una consulta.

Para adaptarse a las actualizaciones de algoritmo necesarias, históricamente se han admitido diferentes versiones de cifrado de fusión:

• La versión 1 requiere que los clientes proporcionen sus propios nonces, lo cual es muy flexible, pero potencialmente peligroso si se hace incorrectamente. Esto es solo en Vault 0.6.1, las claves no se pueden actualizar con esta versión.
• La versión 2 utiliza un enfoque algorítmico para derivar parámetros. Sin embargo, el algoritmo utilizado es vulnerable a los ataques de confirmación de texto sin formato fuera de línea, que un atacante puede aplicar por fuerza bruta si el texto sin formato es pequeño. Las claves que usan la versión 2 se pueden actualizar simplemente realizando una operación de rotación a la nueva versión de la clave; los valores existentes se pueden volver a ajustar de acuerdo con la nueva versión de la clave y usarán el algoritmo de la versión 3.
• La versión 3 utiliza un algoritmo diferente para resistir los ataques de confirmación de texto sin formato fuera de línea. Es similar a AES-SIV en que utiliza PRF para generar números aleatorios a partir de texto sin formato.

6. Despliegue

La mayoría de los motores secretos deben configurarse de antemano para realizar su función. Estos pasos generalmente los completa un operador o una herramienta de administración de configuración.

Para habilitar el motor secreto de Transit:

vault secrets enable transit
Success! Enabled the transit secrets engine at: transit/

De forma predeterminada, el motor secreto se instalará en el nombre del motor. Para habilitar el motor secreto en una ruta diferente, use el parámetro -path.

Cree una clave de cifrado con nombre:

vault write -f transit/keys/my-key
Success! Data written to: transit/keys/my-key

Por lo general, cada aplicación tiene su propia clave de cifrado.

Siete, usa

Una vez que se configura un motor secreto y un usuario/máquina tiene un token de Vault con los permisos adecuados, puede usar este motor secreto.

1. Cifre algunos datos de texto sin formato utilizando el punto final /encrypt con una clave con nombre:

Nota: **Todos los datos de texto sin formato deben estar codificados en base64. El motivo de este requisito es que Vault no requiere que el texto sin formato sea "texto". Puede ser un archivo binario como un PDF o una imagen. **El mecanismo de transporte seguro más simple para estos datos es codificarlos en base64 como parte de la carga JSON.

vault write transit/encrypt/my-key plaintext=$(echo "my secret data" | base64)
Key            Value
---            -----
ciphertext     vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
key_version    1

El texto cifrado devuelto comienza con bóveda:v1:. El primer prefijo (bóveda) lo identifica como abovedado. v1 significa que la versión 1 de la clave se usó para cifrar texto sin formato; por lo tanto, cuando gira la clave, Vault sabe qué versión usar para el descifrado. El resto es la concatenación base64 del vector de inicialización (IV) y el texto cifrado.

Tenga en cuenta que Vault no almacena dichos datos. La persona que llama es responsable de almacenar el texto cifrado. Cuando la persona que llama quiere el texto sin formato, debe devolver el texto cifrado a Vault para descifrar el valor.

La API HTTP de Vault especifica un tamaño máximo de solicitud de 32 MB para evitar ataques de denegación de servicio. Esto se puede ajustar por bloque de escucha en la configuración del servidor de Vault.

2. Descifrar una pieza de datos usando el punto final /decrypt con la clave nombrada:

vault write transit/decrypt/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
Key          Value
---          -----
plaintext    bXkgc2VjcmV0IGRhdGEK

Los datos generados están codificados en base64 (consulte la nota anterior para obtener detalles sobre por qué). Decodificarlo para obtener el texto sin formato original:

base64 --decode <<< "bXkgc2VjcmV0IGRhdGEK"
my secret data

Este descifrado también se puede programar en un comando con algunas secuencias de comandos de shell inteligentes:

vault write -field=plaintext transit/decrypt/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw== | base64 --decode
my secret data

Con las ACL, se puede restringir el uso del motor secreto de transporte para que los operadores de confianza puedan administrar las claves con nombre y las aplicaciones puedan cifrar o descifrar solo las claves con nombre a las que necesitan acceder.

3. Gire la clave de cifrado subyacente. Esto generará una nueva clave de cifrado y la agregará al conjunto de claves para la clave especificada:

vault write -f transit/keys/my-key/rotate
Success! Data written to: transit/keys/my-key/rotate

Los cifrados futuros utilizarán esta nueva clave. Los datos antiguos aún se pueden descifrar gracias al llavero.

4. Actualice los datos cifrados a una clave nueva. Vault descifrará el valor con la clave adecuada del conjunto de claves y, a continuación, cifrará el texto sin formato resultante con la clave más reciente del conjunto de claves.

vault write transit/rewrap/my-key ciphertext=vault:v1:54d6PQ5i6jOWL/61cpEB4AKsJlZoJXHAhzhoHGRwLv+GOuweyKzfZQRuLw==
Key            Value
---            -----
ciphertext     vault:v2:fhsQPtZtEns2j7ZXLn28EYWh5NF0tFk9i5fa0jq7qkNsft/ZEFlVook1pg==
key_version    2

Este proceso no revela datos de texto sin formato. Por lo tanto, una política de Vault puede otorgar a un proceso que no es de confianza la capacidad de "reempaquetar" datos cifrados, ya que el proceso no podría acceder a los datos de texto sin formato.

8. Traiga su propia llave (BYOK)

Nota: La función de importación de claves admite situaciones en las que las claves existentes deben importarse desde un HSM u otro sistema externo. Es más seguro dejar que Transit genere y gestione claves en el almacén.

Primero, la clave de envoltura debe leerse del transporte:

vault read transit/wrapping_key

La clave de envoltura será una clave pública RSA de 4096 bits.

Luego, la clave de ajuste se usa para crear una entrada de texto cifrado para el punto final de importación, como se describe a continuación. A continuación, la clave de destino se refiere a la clave que se está importando.

HSM

Si la clave se importa desde un HSM compatible con PKCS#11, hay dos casos posibles:

• Si el HSM admite el mecanismo CKM_RSA_AES_KEY_WRAP, se puede usar una clave de encapsulamiento para encapsular la clave de destino.
• De lo contrario, ambos mecanismos se pueden combinar para envolver la clave de destino. Primero, se debe generar una clave AES de 256 bits y luego usarla para encapsular la clave de destino mediante el mecanismo CKM_AES_KEY_WRAP_KWP. Luego, la clave AES debe envolverse bajo una clave de encapsulado usando MGF1 y SHA-1, SHA-224, SHA-256, SHA-384 o SHA-512 usando el mecanismo CKM_RSA_PKCS_OAEP.

El texto cifrado se construye agregando la clave de destino envuelta a la clave AES envuelta.

Los bytes de texto cifrado deben estar codificados en base64.

proceso manual

Si la clave de destino no está almacenada en un HSM o KMS, se pueden usar los siguientes pasos para construir un texto cifrado para la entrada al punto final de importación:

• Genere una clave AES temporal de 256 bits.
• Envuelve la clave de destino con una clave AES efímera con AES-KWP.

Nota: Al encapsular una clave simétrica como una clave AES o ChaCha20, encapsula los bytes sin procesar de la clave. Por ejemplo, para una clave AES de 128 bits, sería una matriz de bytes de 16 caracteres de longitud, que se envolvería directamente sin base64 u otra codificación.

Al envolver una clave asimétrica (como una clave RSA o ECDSA), envuelva el formato codificado PKCS8 de la clave en formato DER/binario sin formato. No aplique la codificación PEM a este blob, ni lo codifique en base64 antes de cifrarlo.

• Envuelva la clave AES debajo de la clave de envoltura de Vault mediante RSAES-OAEP con MGF1 y SHA-1, SHA-224, SHA-256, SHA-384 o SHA-512.
• Elimine la clave AES temporal.
• Agrega la clave de destino encapsulada a la clave AES encapsulada.
• Resultado codificado en Base64.