¿Cifrando contenido usando la misma clave secreta que el hash?

Question

¿Cifrando contenido usando la misma clave secreta que el hash?

#1 de Tom Leek (1 votos)

0

OK: estoy intentando diseñar un sistema que pueda proporcionar contenido personalizado / diferenciado a un costo mínimo para el servidor.

Uno de los diseños que estoy explorando actualmente es donde la solicitud está firmada de alguna manera usando un par clave / valor donde el valor es secreto, por ejemplo:

Original URL: /posts/foo?format=json

Secret pair (known to server and client):
    ABCDE: 12345

Hash: HMAC('/posts/foo?format=json', '12345')

Actual URL: /posts/foo?format=json&ABCDE=<hash>

(Un método más seguro sería incluirlo en un encabezado HTTP, pero ignoremos eso por ahora).

Obviamente, una acción no segura tendría que tener un nonce (para evitar la repetición), pero esperaba no exigir un nonce para las solicitudes GET, y en su lugar simplemente devolver el contenido cifrado simétricamente usando '12345' (el valor secreto) como clave.

Esto significa que el hash para una URL en particular podría ser precomputado por el servidor, y podría simplemente devolver el contenido cifrado (en caché). Si el contenido incluía un resumen del mensaje (nuevamente usando 12345 ), esto podría ser a prueba de falsificaciones en conexiones inseguras.

¿Existen implicaciones de seguridad negativas para verificar el uso de un hash como este, o el uso de esta clave simétrica como secreto?

(Editado: reemplazó "sha1" con algo de HMAC)

web-application cryptography encryption

pregunta cloudfeet 13.12.2013 - 13:07

fuente

1 respuesta

Lea otras preguntas en las etiquetas web-application cryptography encryption

¿Es una buena idea codificar una cadena y usarla como frase de contraseña? Conexión de fábrica SSL de Java al servidor SSL (solo con clave pública y certificado)

score 1 · Answer 1

Al leerlo, su pregunta se reduce a: ¿es seguro usar la misma clave para el cifrado simétrico de algunos datos y un MAC en otros datos?

Es posible construir un ejemplo (algo artificial) donde dicho uso no es seguro. Por ejemplo, el cifrado simétrico podría ser un cifrado de flujo personalizado donde el flujo consiste en valores HMAC calculados sobre el valor sucesivo de un contador; en ese caso, el MAC que utiliza la misma clave podría interactuar con el cifrado y la información de fugas. Sin embargo, con los algoritmos de cifrado "normales" y HMAC, los riesgos son bajos. No se podría decir lo mismo si el MAC era CBC-MAC : usando la misma clave para el cifrado en el modo CBC, y para CBC-MAC, es un pecado mortal.

En general , es mejor si cada clave individual cumple un propósito único. El método genérico, aquí, es tener una "clave maestra" K y derivar a partir de esa clave, utilizando un solo sentido Key Derivation Function , una clave para el cifrado y otra clave para el MAC. En la práctica, esto puede ser tan simple como el hash K con SHA-256, y dividir la salida de 256 bits en dos mitades de 128 bits; la primera mitad se usará para el cifrado, la segunda mitad para el MAC. Esto es seguro basado en algunas suposiciones parciales de unidireccional sobre SHA-256, suposiciones que son bastante razonables.

SSL utiliza su propio KDF, que se denomina, en la especificación SSL, el "PRF" .

Si la clave secreta es algo débil, es decir, se deriva de una contraseña , entonces los atacantes que observan el intercambio pueden usar lo que vieron para ejecutar un ataque de diccionario sin conexión, es decir, probar contraseñas potenciales; esto es "fuera de línea" en el sentido de que los atacantes hacen eso en sus propias máquinas y no tienen que hablar con el servidor honesto para cada intento. Los ataques de diccionario sin conexión son un problema. Ejecutar el protocolo dentro de SSL es una buena manera de frustrar tales escuchas ilegales.

Si no hay SSL, los mismos atacantes podrían activarse y modificar los datos cifrados devueltos por el servidor. Por lo tanto, el sistema de cifrado también debe incluir su propio MAC. Se recomienda que la combinación de MAC y cifrado sea complicada, por lo que los modos que hacen el trabajo correctamente (como GCM ) son altamente recomendables .

Más maliciosamente, los atacantes también podrían cometer errores falsos. Si envía su GET a través de HTTP simple, un atacante activo podría interceptarlo y devolver una respuesta 404 falsa: ya que no hay datos cifrados en un 404 (de hecho, el punto del 404 es afirmar que no hay datos) , el cliente no tiene nada que verificar y no puede rechazar el mensaje 404 como falso. Dependiendo de para qué use su protocolo, esto puede provocar problemas de seguridad. Para protegerse contra los atacantes activos, todas las respuestas del servidor deben ser autenticadas, incluyendo las respuestas negativas (404). Pero, en ese momento, estás a punto de reinventar SSL ...

En una vena similar, un atacante activo podría devolver una respuesta anterior del servidor. Supongamos que en algún momento, el bloque de datos D₁ se almacenó en el servidor y se pudo obtener con un GET. Más adelante, el bloque de datos se actualiza con D₂ . Sin embargo, la clave no ha cambiado y la solicitud GET del cliente sigue siendo la misma. Un atacante activo podría sustituir el D₂ del servidor por una copia de D₁ , como se interceptó previamente.

Esto se puede evitar usando un nonce - un cliente cliente , enviado por el cliente; el servidor debe calcular dinámicamente un MAC sobre lo que devuelve, y la entrada de MAC debe incluir el nonce del cliente. En ese punto:

el protocolo ya no es tan liviano como se podría esperar;
esto realmente parece un SSL hecho en casa.

Resumen: no es fácil superar a SSL. SSL es relativamente complejo, pero esa complejidad es (en su mayoría) intrínseca a la dureza del problema en cuestión. Un protocolo de comunicación que resista las imitaciones, alteraciones y ataques de repetición, deberá incluir una serie de elementos criptográficos afinados, y no será más sencillo ni más barato de operar que SSL.

Si puede organizar que su cliente y servidor compartan una clave secreta común de alta entropía, entonces conjuntos de cifrado TLS PSK le dará un buen rendimiento y la menor complejidad posible (sin certificado, sin criptografía asimétrica).