encriptación de sobre (usando KMS) vs ECDH

Question

encriptación de sobre (usando KMS) vs ECDH

#1 de John Deters (1 votos)

2

en el trabajo, he implementado un cifrado de sobre básico al enviar mensajes a un cliente. Estoy usando AWS KMS y tengo una clave maestra allí. Obtengo una clave de datos, cifro el mensaje con AES-GCM y envío el mensaje con la clave de datos cifrados, IV, etiqueta, etc. El cliente llama a AWS KMS para descifrar la clave de datos para descifrar el mensaje. He implementado esto mirando los documentos de AWS. Estoy almacenando en caché la clave de datos por un tiempo para volver a utilizarla antes de generar una nueva.

Un colega, que es mejor en criptografía que yo, piensa que esto no es seguro debido al envío de la clave con el mensaje, que esto podría llevar a descubrir la clave maestra. Él recomienda ECDH que tiene una mejor distribución de claves, utilizando un secreto compartido con claves privadas / públicas para generar la clave AES. El problema con esto es que necesito almacenar un par de claves pública / privada en algún lugar, y ambos métodos necesitan acceso a un secreto (clave KMS o clave privada).

Estoy buscando otras opiniones sobre qué tan seguros son estos métodos diferentes. ¿Cuáles son las diferencias realmente en la vulnerabilidad?

Editar: Aclaración: La clave maestra es una clave específica creada solo para cifrar claves de datos para estos mensajes a un cliente específico, nada más. Documentos de AWS que utilicé: enlace

encryption vulnerability aws

pregunta KTrum 18.11.2018 - 12:59

fuente

1 respuesta

Lea otras preguntas en las etiquetas encryption vulnerability aws

¿Qué tiene que ocurrir para que un pirata informático controle el tráfico de mi LAN? Períodos en la enumeración de plataforma común WFN (NIST Interagency Report 7695)

score 1 · Answer 1

Matemáticamente, es correcto que si su clave de datos se genera correctamente utilizando un generador de números pseudoaleatorios criptográficamente seguro, la clave maestra no se puede revertir de un mensaje (suponiendo que AES no se haya roto). "Cuna" a un atacante que intenta adivinar la clave maestra. Permite un ataque de "texto plano conocido".

Considere el caso en el que un adversario cree que tiene parte de su llave maestra. Puede usar cualquier mensaje interceptado de este sistema como prueba para ver si sus suposiciones son correctas. O puede desenrollar el algoritmo, en caso de que tal ataque contra AES sea conocido.

Este esquema no sigue el principio de "una clave debe usarse para un solo propósito". Debido a que la clave maestra aún vive en cada mensaje, cada clave de datos ahora comparte su clave maestra con todas las demás claves.

Dicho esto, no estoy lo suficientemente familiarizado con KMS de AWS para saber cómo está configurado su sistema, pero todos los sistemas KMS con los que trabajo realizan la administración de claves otorgando permiso a los usuarios individuales para acceder solo a las claves de sus aplicaciones. Ningún usuario tendrá acceso al uso de la clave maestra real del sistema para cifrar directamente una clave de datos. Por lo tanto, es posible que su descripción no esté completa, y que se refiera a una clave maestra simplemente se refiera a una clave específica de la aplicación. En ese caso, la filtración de su clave no conducirá a la filtración de las otras claves en su KMS. Las otras claves de su organización no se verían comprometidas incluso si su clave fuera.

Incluso en ese caso, todavía consideraría seguir el consejo de su colega y cambiarlo para usar una solución de clave asimétrica como la que describió para intercambiar claves, en lugar de cifrar las claves de datos directamente con la clave maestra. Aún puede hacer que el remitente y el destinatario utilicen el KMS para descifrar las claves privadas, ya que las claves privadas nunca se envían con los mensajes. Elimina el ataque de texto simple conocido contra la clave maestra.