Cifrado simétrico para protección de datos

  

Después de leer un poco, creo que usar 256 AES debería ser adecuado. ¿Es este el caso y por cuánto tiempo debemos esperar que sea lo suficientemente bueno?

¡Sí! AES-256 es un algoritmo ampliamente utilizado y estandarizado. El único cavaet es que AES-256 no es en sí mismo, todo el algoritmo. El algoritmo requiere que especifique un modo de cifrado de bloque, que es el mecanismo en el que distorsiona los bloques de datos antes del cifrado para evitar que aparezcan patrones. Recomiendo echar un vistazo a esta imagen . El modo de cifrado de bloque más común es CBC y es ideal para cifrar datos que tienen más de un bloque de longitud (más de 128 bits que, según tengo entendido, sus datos serán).

El AES-256 debidamente configurado debe estar seguro en el futuro de la computación. Actualmente se cree que el cifrado simétrico es seguro incluso en un mundo post-cuántico (a diferencia de la criptografía asimétrica, como RSA, que probablemente se derrumbará), por lo que debería dormir bien por la noche sabiendo que sus datos están seguros en el futuro.

  

Pero si todo lo que quiero hacer es verificar que el mensaje no esté dañado, ¿hay alguna razón por la que un hash (por ejemplo, SHA-256) almacenado con mi clave no cumpla con mi requisito? Probablemente me esté perdiendo algo aquí.

La diferencia clave entre las funciones hash criptográficas (resistentes a la colisión) tradicionales, como las funciones SHA-256 y HMAC, es que las funciones hash HMAC están "codificadas", lo que significa que requieren una clave secreta. HMAC-SHA256 (como ejemplo) se usa a menudo en los casos en que hay razones para creer que un atacante puede tratar de manipular los datos y volver a calcular el hash para hacer que el sistema parezca no alterado.

Digamos que tengo un archivo de texto que contiene instrucciones sobre cuándo lanzar un ataque y un segundo archivo que contiene el hash SHA-256 del primero. Escribo en el archivo "ataque al amanecer" y lo hago con SHA-256 y me desconecto. El atacante ahora inicia sesión (a través de medios fuera del alcance para discutir cómo aquí, este es un ejemplo simple) y el atacante edita el archivo de texto para decir "¡No ataque!". Pero ahora el hash SHA-256 no coincide, por lo que el atacante vuelve a calcular el hash SHA-256 del archivo que editó y reemplaza mi hash anterior. Ahora envío este archivo y su hash a mis generales. Tocan el archivo y lo ven coincidir (y por lo tanto, confían en él) y ven "¡No atacar!".

Entra la familia HMAC. En el mismo ejemplo, si usara HMAC-SHA256 para copiar mi archivo, se requeriría mi clave secreta para completar la operación. Por lo tanto, cuando el atacante editó mi archivo de texto, no conoce mi clave secreta y no puede generar un HMAC-SHA256 válido del archivo editado. Cuando se envía a los generales (ellos también tienen mi clave secreta, ya sea a través de la distribución previa o PKI) generan el hash con HMAC-SHA256 y no coinciden. Saben que el mensaje ha sido manipulado.

En pocas palabras: SHA-256 es una excelente manera de validar que la corrupción de datos no maliciosos no se produjo, ya que es resistente a las colisiones, pero cualquiera puede calcular un hash SHA-256. Si su modelo de amenaza incluye la posibilidad de una manipulación malintencionada por parte de un atacante, el uso del hash HMAC-SHA256 con una clave secreta puede garantizar que el atacante no pueda manipular los datos y volver a crear el hash para que no aparezca alterado.

  

Estoy proponiendo que utilicemos el cifrado simétrico de los datos donde hay una clave única por documento. Las claves para esto se almacenarán de manera tal que se pueda acceder al lugar donde se utilizarán los datos, pero separados de los datos cifrados. Los datos cifrados se escribirán y leerán desde el almacenamiento. Si bien esto posiblemente sea excesivo, creo que aliviará algunas de las preocupaciones que obstaculizan la adopción de esta tecnología. La idea es que incluso si algo sale mal y alguien obtiene acceso al almacenamiento de documentos, los datos no serán útiles sin el acceso a las claves. En el caso de que alguien tenga acceso a estas claves, estos documentos serán la menor de nuestras preocupaciones.

Esta es una aproximación propia de algunos enfoques estándar para administración de claves . Sus claves por documento son una versión de lo que normalmente se denomina clave de cifrado de datos (DEK). ¿Por qué se les llama por este nombre aparentemente redundante? Debido a que también hay un concepto llamado clave de cifrado de clave (KEK), un conjunto de claves (a menudo llamadas "claves maestras") que se utilizan para cifrar los DEK. Este enfoque tiene algunas ventajas significativas:

• Los DEK cifrados se pueden almacenar junto con los documentos que cifran. Solo los KEK deben almacenarse por separado y el volumen es mucho menor.
• Es posible diseñar el sistema para que las aplicaciones de primera línea nunca vean las KEK. El KEK puede residir en un módulo de seguridad de hardware / servicio dedicado que las aplicaciones cliente deben enviarles los DEK encriptados y el servicio responderá con el DEK desencriptado (por supuesto, a través de una conexión encriptada).

  

Después de leer un poco, creo que usar 256 AES debería ser adecuado. ¿Es este el caso y por cuánto tiempo debemos esperar que sea lo suficientemente bueno?

Hay un dicho que dice algo así: "Si estás escribiendo las letras A-E-S en tu código, lo estás haciendo mal". La criptografía es mucho más complicada que simplemente usar AES. Por ejemplo, habla sobre el uso de un MAC para proteger los datos, un esfuerzo en el que las personas se equivocan de manera rutinaria.

Creo que deberías traer ayuda externa para hacer todo esto. No parece que su equipo tenga el conocimiento y la experiencia para hacerlo de manera confiable. Si no soy un consultor externo, he tenido buenas experiencias con cosas como las funciones de administración de claves y almacenamiento encriptado de Amazon Web Services. Por ejemplo, Cifrado S3 del lado del cliente de AWS con AWS KMS administrado keys es una muy buena solución que es razonablemente fácil de usar. Algunos enlaces informativos:

• AWS Key Management Service
• Protección de datos mediante el cifrado del lado del cliente (AWS S3)

No sé qué características comparables pueden proporcionar otros proveedores de la nube.