AES-CTR con PBKDF2 para IV para archivar archivos en el servidor. ¿Esta bien?

0

He intentado captar suficiente cifrado / hashing para poder implementar un almacenamiento seguro para archivos, del lado del servidor. Una vez que haya bajado a un nivel razonable, lo revisaré con un experto. No tiene sentido llamar al experto antes de que lo entienda a un nivel razonable.

Por favor, alguien podría decirme si lo estoy haciendo bien y también si hay partes redundantes que no necesito.

Aquí está mi configuración actual:

  • OpenSSL

  • AES-128 para cifrado porque es más rápido y, supuestamente, tan seguro como -256

  • Modo CTR porque no necesito autenticación (como en CGM). Y porque (creo) no necesita relleno, lo que podría abrir algunas vulnerabilidades (como CBC)

  • Todos los archivos almacenados tienen un registro de base de datos donde almaceno el IV.

  • También almaceno el recuento de iteraciones para la IV, por lo que puedo volver y recalcular con más iteraciones si es necesario.

  • IV es de 16 bytes para coincidir con el tamaño de bloque de 128 bits

  • La contraseña de cifrado está codificada y almacenada en el software del servidor. La misma contraseña para todos los archivos.

    • ¿Por cuánto tiempo debe ser esta contraseña aleatoria?
  • IV se calcula con pbkdf2. @ 100,000 iteraciones, sha256, sal aleatoria de 32 bits.

    • también se necesita una contraseña para los cálculos IV. ¿Puedo usar la misma contraseña que para el cifrado?

Pero me pregunto si pbkdf es realmente necesario en mi caso de uso. El cifrado / descifrado de archivos se realiza en el servidor de una manera basada en la cola, es decir, no hay interacción del usuario involucrada. Así que la necesidad de ralentizar el proceso de hash no parece aplicarse aquí. ¿O he entendido mal algo? Solo necesito un IV aleatorio y único, pero no necesito que tome tiempo ...

editar - >

Una solución más simple sería no usar un IV (es decir, IV = 0) y en su lugar utilizar pbkdf para crear una contraseña de cifrado única para cada archivo. El único inconveniente que puedo ver con esto es que mis archivos estarían a la vista si alguien llegara a la base de datos.

Con la solución descrita anteriormente, un atacante necesitaría el puesto IV de la base de datos y la contraseña del servidor (y, por supuesto, el archivo para descifrar).

¿Se consideraría estúpido omitir el IV y solo usar contraseñas aleatorias únicas?

< ---

edita de nuevo --- > >

Después de contemplar un poco la respuesta y los comentarios de Polinomios, me doy cuenta de que tengo que retirarme.

El mayor problema con lo anterior es que se vuelve inseguro en el momento en que guardo la contraseña en algún lugar. Sólo algunos de los archivos son realmente sensibles. Cuando los archivos sensibles necesiten cifrado, le pediré al usuario una contraseña a través de una aplicación para bloquear y desbloquear los archivos. La contraseña solo se almacenará en la memoria y dejaré que el usuario recuerde la contraseña.

Tendré algún problema cuando más de un servidor pueda servir la aplicación. Podría resolverlo al no equilibrar la carga de la ruta para la api de la contraseña, por lo que esta pequeña tarea solo es manejada por un servidor. De lo contrario, tendría que comunicar la contraseña entre los servidores para que todos la tengan en la memoria.

Phew ... Esto de seguridad realmente requiere pensar en una base de datos / servidor / tipo de aplicación regular. Será mejor que vuelva a la codificación productiva por un tiempo y vuelva a revisar esto más tarde ...

< < ---

Gracias de antemano, // Michael

    
pregunta Michael 21.04.2016 - 11:01
fuente

1 respuesta

1
  

AES-128 para el cifrado porque es más rápido y, supuestamente, tan seguro como -256

Sí y no. Si planea almacenar sus datos durante mucho tiempo y le preocupan los ataques post-cuánticos, 256 bits podría ser la mejor opción. algoritmo de Grover reduce la complejidad del tiempo de descifrar una clave de 128 bits hasta aproximadamente 2 64 , lo que probablemente sea factible. Para 256 bits, reduce el límite de seguridad a 2 operaciones 128 , lo que probablemente todavía no sea factible.

  

Modo CTR porque no necesito autenticación (como en CGM).

Nitpick: Es GCM (Modo Gallois / Contador).

CTR es una opción razonable, pero realmente estará abierto a los ataques de maleabilidad si alguien obtiene acceso de escritura. a su dispositivo. Por ejemplo, si tuviera que cifrar una imagen de disco del sistema con GRUB instalado, un atacante podría adivinar los bytes de instrucciones como ciertas posiciones en el área del cargador de arranque (es una posición conocida y el código del cargador de arranque es bastante estático entre las versons) y luego podrían realizar una copia de seguridad de su cargador de arranque. y por lo tanto su sistema operativo una vez que descifre y restaure la copia de seguridad.

  

Y porque (creo) no necesita relleno, lo que podría abrir algunas vulnerabilidades (como CBC)

Las vulnerabilidades de CBC son en su mayoría padding oracles , que en su mayoría solo se aplican en un entorno interactivo. Es casi seguro que son irrelevantes en escenarios de copia de seguridad como este. Si está buscando un buen modo de bloqueo para usar como almacenamiento, busque algo como XTS o XTX. Aunque no sé si OpenSSL los admite.

  

Todos los archivos almacenados tienen un registro de base de datos donde almaceno el IV.

Personalmente, acabo de añadir o anexar el IV a los datos del archivo cifrado.

  

También almaceno el recuento de iteraciones para la IV, por lo que puedo volver y recalcular con más iteraciones si es necesario.

Hmm. De acuerdo. No entiendo muy bien por qué necesita PBKDF2 para generar un IV en absoluto.

  

La contraseña de cifrado está codificada y almacenada en el software del servidor. La misma contraseña para todos los archivos.

Esto es masivamente inseguro. Su solución no tiene seguridad, ya que cualquier persona que comprometa el servidor puede simplemente descifrar todos los archivos.

  

IV se calcula con pbkdf2. @ 100,000 iteraciones, sha256, sal aleatoria de 32 bits.

¿Por qué? Los IV deben ser únicos y no necesitan ser aleatorios o secretos. Solo existen para garantizar que el cifrado de varios mensajes con la misma clave no sea inseguro.

  

también se necesita una contraseña para los cálculos IV. ¿Puedo usar la misma contraseña que para el cifrado?

irrelevante. Su IV debe ser un valor único para cada archivo.

  

Pero me pregunto si pbkdf es realmente necesario en mi caso de uso. El cifrado / descifrado de archivos se realiza en el servidor de una manera basada en la cola, es decir, no hay interacción del usuario involucrada. Así que la necesidad de ralentizar el proceso de hash no parece aplicarse aquí.

Realmente es irrelevante. Su IV no necesita ser secreta, y en muchos casos tampoco tiene que ser aleatoria, simplemente única.

  

¿O he entendido mal algo?

Algunas cosas, parece. Parece que ha inventado un esquema de encriptado de copia de seguridad demasiado complicado donde se podría usar algo tan simple como la herramienta de línea de comandos openssl (consulte esta pregunta de StackOverflow ). No seas Dave . Parece que tienes un conocimiento razonable de los conceptos de criptografía, pero eso no significa que debas diseñar tus propios esquemas para cualquier cosa.

    
respondido por el Polynomial 21.04.2016 - 11:24
fuente

Lea otras preguntas en las etiquetas