Cómo implementar AES correctamente en una aplicación de respaldo

Navega tus respuestas
4

Estoy escribiendo una aplicación de copia de seguridad que debería tener la función de cifrar la copia de seguridad. Debe cifrar datos de archivos, rutas y nombres de archivos. La aplicación se está escribiendo en C # (.NET). Target es sistemas Windows, pero potencialmente también otras plataformas bajo Mono.

Parece que AES debería usarse con una instancia de la clase RijndaelManaged. Las funciones de cifrado y descifrado pueden recibir un IV, una clave secreta y, por supuesto, los datos.

El usuario ingresará una contraseña o frase de contraseña de cualquier longitud. Se les aconsejará elegir algo razonable, como entre 8 y 50 caracteres. La contraseña será almacenada en alguna forma de hash. No estoy seguro todavía si esto será scrypt o bcrypt o algo así. Aunque la copia de seguridad se puede descifrar con esto, al menos no se sabrá la contraseña original.

  1. Cualquier expansión necesaria para obtener una clave con la que AES puede trabajar es realizada por AES, ¿verdad? ¿O necesito expandir la entrada (con alguna función segura) a una longitud de clave que AES acepta?
  2. Tanto el IV como la clave deben ser iguales durante el cifrado y el descifrado para descifrar los datos con éxito. La clave es siempre la misma. ¿Qué debería ser la IV? Supongo que el IV podría ser un número incremental, lo que haría que el cifrado aún pareciera aleatorio incluso cuando los datos y la clave son idénticos, de modo que se filtre la menor cantidad de información posible. ¿Es correcto este supuesto? ¿Eso significa que un buen IV sería el ID de archivo (todos obtienen un número único, o al menos eso podría generarse)?
  3. Se guarda un metarchivo que mapea las ID de ruta y archivo a la ruta y nombre de archivo originales. Por ejemplo, la ruta 1, el archivo 3 podría expandirse a C: \ Windows \ explorer.exe. Este metarchivo probablemente será texto simple, solo los valores (ruta y nombres de archivo) serán encriptados. ¿Cuál debería ser la IV para los valores? ¿Su identificación numérica? ¿O un valor aleatorio que se almacena en algún lugar en texto sin formato? ¿O puedo usar un IV fijo (codificado)?
  4. ¿Hay algo que deba saber al ejecutar (o intentar ejecutar) la aplicación en Mono? ¿Puedo confiar en alguna fuente de pseudoaleatoriedad para tener suficiente entropía?
  5. ¿AES proporciona integridad de forma predeterminada, o debo almacenar un MAC (o algo así) de cada parte de datos cifrados (metadatos y datos de archivos)?

Si conoce la respuesta a cualquiera de estas preguntas, ¡cualquier ayuda es muy apreciada!

    
pregunta Luc 27.01.2013 - 23:03
fuente

2 respuestas

4

Esto va a ... no hacer. AES es un ladrillo. Quieres una casa completa. No sabrá si la construcción es resistente hasta que el techo caiga sobre su cabeza.

Responderé a tus preguntas por el bien del conocimiento, pero, en realidad, no diseñes tu propio criptografía:

  1. AES trabaja con claves de 128, 192 o 256 bits. Todas las longitudes de clave son equivalentes (es decir, "no se puede romper con la tecnología existente"). Elija 128 bits si es inteligente, 256 bits si necesita apaciguar a la gente de marketing, 192 bits si solo quiere verse como un imbécil.

  2. Los requisitos de IV dependen de la forma en que utilice AES, el modo de operación que convierte AES en algo útil. Como regla, nunca reutiliza un IV con la misma clave. Nunca. Algunos modos solo necesitan eso (IV exclusivo), otros necesitan IV uniforme y aleatorio.

  3. Has usado "arreglado" y "IV" en la misma oración. Para eso serás azotado en la plaza del pueblo.

  4. .NET incluye System.Security.Cryptography.RNGCryptoServiceProvider , lo cual está bien para producir aleatoriedad de calidad criptográfica. Mono también lo tiene. La documentación de Mono reclamaciones que se utilizará en Linux /dev/random , con un retroceso en /dev/urandom si el primero no está disponible; afortunadamente, el código fuente de Mono hace lo inteligente y no implementa lo que dice la documentación: en cambio, Mono usa /dev/urandom y cambia a /dev/random solo como alternativa.

  5. AES es un algoritmo de cifrado; hace confidencialidad , no integridad . Algunos modos de operación hacen ambas cosas. Otros no lo hacen.

Por supuesto, cualquier sistema de copia de seguridad suficientemente grande y complejo perderá mucha información en todas partes (tamaño de los archivos, tamaño de los archivos nombres , fechas y patrones de modificación ...) a menos que se maneje con un mucho cuidado Es este un problema difícil. Al crear un volumen encriptado (por ejemplo, con TrueCrypt ) y escribiendo archivos en ese volumen, tendría al menos una posibilidad no microscópica de evadir los problemas más comunes. Y también le ahorraría mucho tiempo de desarrollo.

    
respondido por el Tom Leek 30.01.2013 - 01:20
fuente
4

Primero y principal; No debes implementar tus propios esquemas criptográficos. Sí, estás usando AES, pero AES es una primitiva criptográfica. Trate de encontrar una solución existente, bien probada y revisada. Probablemente usted no sea un criptógrafo entrenado, y como tal probablemente cometa errores. A la luz de ese descargo de responsabilidad, esto es lo que puedo recordar sobre AES:

  1. Si recuerdo correctamente, deberás trabajar un poco para que la clave sea 128, 192 o 256b. Generalmente en forma de hash, pero tendría que verificar esto.
  2. La IV debe ser criptográficamente aleatoria.
  3. Genere un IV único para cada nuevo cifrado y almacénelo en algún lugar.
  4. Pase, el sistema operativo debería poder proporcionar una entropía razonable; Linux suele tener / dev / random para este propósito.
  5. AES no proporciona ninguna comprobación de integridad por sí misma; como tal, tendrá que implementar su propia verificación de integridad.
respondido por el Tinned_Tuna 28.01.2013 - 00:54
fuente

Lea otras preguntas en las etiquetas

El certificado SSL no cumple con las restricciones básicas y el cumplimiento de PCI ¿Las copias de seguridad de volúmenes truecrypt con frases de acceso diferentes son un riesgo para la seguridad?