Riesgos de seguridad del cifrado simétrico con compresión para datos de base de datos

2

Me gustaría comprimir los datos antes de cifrarlos y almacenarlos en una base de datos MySQL para reducir especialmente los requisitos de ancho de banda. En el futuro, la base de datos puede ser accesible a través de una interfaz web.

Varios comentarios sobre la inseguridad de la compresión de texto sin formato antes del cifrado, relacionados con infracciones de seguridad como CRIME o BREACH, hacen que no esté seguro de cómo hacerlo. Además, algunos argumentan que la compresión antes del cifrado es en realidad una buena práctica de seguridad. Me doy cuenta de que los ataques como CRIME o BREACH son escenarios específicos, pero me preocupa que mi aplicación esté demasiado cerca (o eventualmente se acerque demasiado) a un escenario similar donde la compresión pueda representar un riesgo de seguridad (el contenido de la base de datos puede ser robado, comprometido etc). Tampoco soy lo suficientemente experto como para comprender completamente todos los aspectos, detalles y matices de CRIME o BREACH.

Después de leer esta discusión sobre el tema, con la recomendación de rellenar el texto plano con un nonce aleatorio antes de la compresión, me pregunto si la siguiente implementación (en PHP) hará el trabajo de manera segura:

    $plaintext = gzcompress ($plaintext . openssl_random_pseudo_bytes (64));
    $cipher_text = openssl_encrypt ($plaintext, 'aes-256-cbc', $key, 0, $iv);

La integridad de los datos se garantiza mediante un procedimiento de firma / verificación HMAC en el texto y la clave del cifrado.

¿Es esta una implementación segura?

¿Habría algún beneficio en el hecho de que el nonce sea de longitud aleatoria, y luego agregar la información de longitud al final del relleno para eliminar el relleno después del descifrado? ¿O debería ser la longitud del nonce en relación con la longitud del texto sin formato (que normalmente sería de al menos 512 bytes)?

NOTA: por lo que puedo decir, mi aplicación específica y la solución propuesta no parecen ser respondidas por el posible duplicado sugerido en los comentarios.

    
pregunta azenz 27.10.2015 - 08:45
fuente

1 respuesta

1

CRIME y BREACH dependen del atacante para controlar parte de los datos y luego ver cómo cambia la longitud de los datos cifrados. En el caso de una aplicación web, el atacante a menudo puede controlar parte de los datos pero no sabe cuánto espacio necesitan los datos después de la compresión y el cifrado.

  

Los contenidos de DB pueden ser robados

Para hacer que estos ataques basados en compresión funcionen, el atacante debe poder controlar la entrada a la base de datos y luego robar la base de datos una y otra vez después de cada cambio en la entrada controlada por el atacante. Si el atacante es capaz de robar la base de datos una y otra vez, es posible que tenga otros problemas graves (como que el atacante tenga acceso directo a la clave de cifrado) y el cifrado probablemente no le ayude de todos modos.

  

servidor comprometido, etc.

El servidor debe estar comprometido de manera que el atacante pueda controlar partes de la entrada a la base de datos y pueda leer la entrada encriptada o al menos determinar su tamaño. Este es un escenario muy específico y en la mayoría de los casos, el atacante probablemente estará más profundo en el sistema y tendrá acceso a las claves de cifrado de todos modos. O ese atacante no está tan profundo en el sistema y no tiene acceso a los datos cifrados o al tamaño de los datos cifrados.

  

... También me pregunto si mi solución propuesta protegerá de hecho los datos cifrados contra ataques relacionados con la compresión

No, no lo hará. Como está agregando un número fijo de bytes aleatorios al principio, en efecto solo agregará una cadena que en la mayoría de los casos no se puede comprimir más. Y, por lo tanto, solo agrega una longitud fija al contenido comprimido que no dificulta este tipo de ataques. Una mejor manera sería agregar una cantidad aleatoria de datos, pero esto también ralentizará el ataque.

Para una discusión más detallada, consulte ¿Se puede frustrar BREACH simplemente agregando una especie de" sal "en la página comprimida? .

    
respondido por el Steffen Ullrich 27.10.2015 - 09:24
fuente

Lea otras preguntas en las etiquetas