Encriptación AES y almacenamiento de claves?

Question

Hace unos años, cuando me presentaron por primera vez a ASP.net y .NET Framework, construí un sistema de almacenamiento de archivos en línea muy simple. Este sistema utiliza el cifrado Rijndael para almacenar los archivos cifrados en el disco duro del servidor, y un HttpHandler para descifrar y enviar esos archivos al cliente.

Siendo uno de mis primeros proyectos con ASP.net y bases de datos, sin entender mucho sobre cómo funciona todo (además de caer en el same trap described by Jeff Atwood on this subject), decidí almacenar llaves y IVs recién generados junto con cada entrada de archivo en la base de datos.

Para hacer las cosas un poco más claras, el cifrado era solo para proteger los archivos del acceso directo al servidor, y las claves no se generaban mediante contraseñas ingresadas por el usuario.

Mi pregunta es, suponiendo que no quiero para mantener una clave para todos los archivos, cómo debería que almacenar claves de cifrado para la mejor seguridad? ¿Qué se considera la mejor práctica? (es decir: en un servidor diferente, en un archivo de texto sin formato, encriptado).

Además, ¿para qué sirve el vector de inicialización en este tipo de algoritmo de cifrado? ¿Debería ser constante en un sistema?

Answer 1

Las claves deben protegerse y mantenerse en secreto, así de simple. La implementación no es Los sistemas de gestión de claves se venden por grandes cantidades de dinero a través de proveedores confiables, ya que la solución del problema es difícil.

Ciertamente no desea utilizar la misma clave para cada usuario, cuanto más se usa una tecla, más fácil es romperla o, al menos, tener algunas pérdidas de información. AES es un cifrado de bloques, divide los datos en bloques y envía los resultados del último bloque de cifrado al bloque siguiente. Un vector de inicialización es la alimentación inicial en el algoritmo, porque en el punto de partida no hay nada con lo que comenzar. Usar IV aleatorios con la misma clave disminuye el riesgo de filtraciones de información; debe ser diferente para cada dato cifrado.

La forma de almacenar las claves depende de cómo esté diseñado su sistema. Acabo de terminar un KMS donde las claves se mantienen alejadas del sistema principal y las funciones para cifrar y descifrar están expuestas a través de WCF. Envía texto sin formato y obtiene una referencia a una clave y el texto cifrado de vuelta; de esta forma, el KMS es responsable de toda la criptografía del sistema. Esto puede ser excesivo en su caso. Si el usuario ingresa una contraseña en su sistema, puede usarla para generar un par de claves. Este par de llaves se podría usar para cifrar un almacén de claves para ese usuario: XML, SQL, lo que sea, y se usaría para descifrar cada clave que se usa para proteger los datos.

Sin saber más acerca de cómo se configura su sistema, o si su propósito es difícil recomendar otra cosa que no sea "Las claves deben estar protegidas, las claves y los IV no deben reutilizarse".

Answer 2

Como una muy buena soltution, podría almacenar la clave/IV par en una tabla:

ID     Key   IV 
skjsh-38798-1298-hjj FHDJK398720== HFkjdf87923== 

Al guardar un valor cifrado, guardar el ID y un valor aleatorio de sal junto con él.

Luego, cuando necesite descifrar el valor, busque el par clave/iv usando el ID y la sal almacenada con los datos.

Desea asegurarse de tener un buen modelo de seguridad en el almacenamiento de claves. Si fue con SQL Server, no conceda derechos SELECT al usuario que accede a la base de datos desde la aplicación.No le gustaría dar acceso a alguien a toda la mesa.

Answer 3

Hay un muy buen artículo sobre esto en http://web.archive.org/web/20121017062956/http://www.di-mgt.com.au/cryptoCreditcard.html que cubre los problemas de IV y salazón y los problemas con ECB mencionados anteriormente.

Todavía no acaba de cubrir "¿Por dónde almacenar la clave", es cierto, pero después de leer y digerir que, no va a ser un gran salto a una solución de esperar ....