AES128 y IV para la aplicación criptográfica

1

Tenemos algunas columnas en algunas tablas que son sensibles y nos gustaría protegerlas "de todos modos". Además, dado que Azure SQL exige el cifrado a nivel de aplicación, tenemos que rodar el nuestro. Habría una 'clave maestra' de AES128 para toda la aplicación (= bits secretos, almacenados / a los que se accede de forma segura solo mediante el binario de la aplicación en tiempo de ejecución). Cada fila de cada tabla usaría su propia IV específica de fila.

Estoy buscando razones sólidas para que alguien quiera votar en contra de AES128 como un cifrado adecuado para lo anterior (creo que lo es).

    
pregunta DeepSpace101 24.01.2013 - 09:05
fuente

1 respuesta

4
  • Estás compartiendo IV: las celdas de una fila dada usarán el mismo IV. Esto es malo . No hagas eso.

  • Usted usa CBC; este es un modo que se sabe que tiene algunos problemas de seguridad (en particular, es sensible a "cuán aleatoria" es la IV), e involucrará relleno (ya que CBC encripta solo bloques completos , debe extender los elementos de datos al siguiente tamaño, que es un múltiplo del tamaño de bloque).

  • Si modifica una de las celdas cifradas, debe volver a cifrarla. Si usa la misma clave y el mismo IV, entonces ha perdido (por seguridad). Por lo tanto, debes alterar el IV para esa celda. Si usa el mismo IV para toda la fila (lo que es malo), también debe volver a cifrar las otras celdas de la fila.

  • Se necesita MAC si los posibles atacantes modifican los datos existentes ; no lo es si se asume que los atacantes son solo pasivos. Tenga en cuenta que un atacante podría modificar los datos cifrados para observar cómo reacciona su sistema e intentar deducir cosas sobre los datos cifrados. Como regla general, está mejor con un MAC que sin él.

Por lo tanto, sugeriría que modifiques tu esquema a lo siguiente:

  • Utilice un modo de cifrado autenticado con datos asociados que combina el cifrado y la integridad, como EAX o GCM .
  • Usuario, un IV por celda, almacenado en la propia celda. EAX y GCM no necesitan un random IV, solo un IV que nunca se repite (para una clave dada), por lo que podría usar un contador simple: mantenga un contador global de todo el sistema, incrementado cada vez necesita cifrar un nuevo valor de celda (cuando asigna una celda, y también cuando reemplaza el contenido de la celda); almacene el contador en la propia celda (de esa manera, un contador de 64 bits será suficiente, sin necesidad de ir a un valor completo de 128 bits).
  • Los modos AEAD incluyen una verificación de integridad que se calcula sobre los datos que están cifrados y algunos datos adicionales que puede elegir (los "datos adicionales" se utilizan para el cálculo pero no se almacenan en el cifrado Como resultado, debe proporcionarlo nuevamente al descifrarlo, de modo que pueda verificarse el MAC integrado). Codifique en esa "información adicional" los números de fila y columna para la celda. De esa manera, un atacante malvado activo no podrá intercambiar el contenido de la celda de manera silenciosa (el MAC solo estará bien si el contenido de la celda aún está donde debería estar).

Además, no te dejes llevar por la fantasía de "llave maestra giratoria". La única razón por la que tendría que cambiar la clave maestra es en caso de que fuera robada; y, en ese caso, debe cambiarlo de inmediato para toda la base de datos . No hay necesidad de una transición gradual y sin problemas: esta es una situación de emergencia. Por lo tanto, no es necesario mantener un número de versión para la clave maestra. Un identificador para el algoritmo criptográfico, por otro lado, es una buena idea; puede caber en un solo byte (o incluso menos que eso).

Cifre los datos binarios, no una codificación Base64 de los mismos. La encriptación salida será de todos modos binaria. La aplicación de Base64 en la entrada solo hará que los datos sean un 33% más grandes, sin ninguna razón.

    
respondido por el Thomas Pornin 24.01.2013 - 13:48
fuente

Lea otras preguntas en las etiquetas