¿Cuándo usar HMAC junto con AES?

16

Uno de mis clientes desea proporcionar una URL a cada uno de sus clientes para registrarse en un sistema. Esta URL contendría un parámetro de cadena de consulta con algunos datos (por ejemplo, código, correo electrónico y nombre) de sus clientes encriptados usando AES con CBC, similar a esto (IV está en negrita):

www.website.com/register?key= 44a74fb9fad889496e970c604e54fdab a367c6e5802252822ce071c35d7f108aea43e6de925cf93dd3d477297419

Cuando un usuario ingresa a esta página, la descifra y comprueba si los datos son válidos (por ejemplo, si el código del cliente es válido en una base de datos externa y si no está registrado) para mostrarle el formulario de registro .

He visto a algunas personas que utilizan HMAC junto con AES para cifrar datos, pero no sé si esto es necesario en un caso como este. Mi pregunta es: ¿Es esto lo suficientemente seguro? ¿Debo usar algo como HMAC junto con el texto sin formato antes de cifrarlo con AES para autenticar los datos?

    
pregunta Guilherme Sehn 14.07.2014 - 23:06
fuente

1 respuesta

31

AES es cifrado ; está destinado a mantener confidencialidad . El cifrado no mantiene por sí mismo la integridad : un atacante que puede acceder a los datos cifrados puede modificar los bytes, lo que afecta los datos de texto claro (aunque el cifrado dificulta un poco la tarea para el atacante, no es tan infeasible como se suele suponer).

Para obtener integridad , necesita un MAC , y HMAC es un buen algoritmo de MAC .

En muchas situaciones donde el cifrado es obligatorio, también se debe mantener la integridad, por lo que, como regla general, AES "solo" no es suficiente. En su caso, los atacantes potenciales son los propios clientes; Cada cliente puede intentar alterar la URL para acceder a los datos de otra persona, o para poder registrarse con otro nombre, o lo que sea. Como lo entiendo, su "cliente" quiere seguir siendo el maestro de registro; Él quiere decidir qué cliente puede registrarse y bajo qué nombre. La integridad comprobada es por lo tanto necesaria.

Hay varias formas de combinar el cifrado basado en AES con HMAC; La mayoría de ellos son malos. Consulte esta pregunta para una discusión sobre el tema. Para hacer la historia corta:

  • Si puede, use GCM o algún otro modo que haga todo el trabajo duro de combinar cifrado y MAC de forma segura.

  • Si no puede usar GCM (por falta de soporte en su marco de programación del lado del servidor), entonces debe hacer las cosas a la antigua:

    • Hash la clave K con SHA-256 para obtener 256 bits de "material clave". Divida eso en dos mitades: 128 bits para cifrado ( K e ), 128 bits para MAC ( K m ).
    • Genera un IV aleatorio de 128 bits. Necesitas uno nuevo cada vez que cifres, y quieres generarlo con un PRNG fuerte ( /dev/urandom ).
    • Rellene los datos (relleno PKCS # 5 habitual) para que su longitud sea un múltiplo del tamaño de bloque AES (16 bytes).
    • Cifre los datos con AES en modo CBC, usando el IV generado justo arriba, y Ke como clave. Llamemos a C el texto cifrado resultante.
    • Calcule HMAC / SHA-256 con la tecla Km sobre la concatenación de IV y C , en esa orden Llame a M el valor resultante. Es crucial que el IV sea parte de la entrada de HMAC.
    • Concatenar IV , C y M , en ese orden. Esta es su "clave de registro".
    • Al recibir una solicitud de registro, primero verifique el HMAC (volviéndolo a calcular), luego (y solo entonces) continúe con el paso de descifrado.

Por supuesto, todo esto supone que hay una clave K , que su cliente puede usar para generar las claves de registro para los clientes, y que su servidor también sabe para verificar y descifrar solicitudes de registro entrantes. Al igual que con todas las teclas, tenga cuidado con el lugar donde lo almacena.

    
respondido por el Thomas Pornin 14.07.2014 - 23:25
fuente

Lea otras preguntas en las etiquetas