Ataque AlFBPPS a TLS ¿cuánta vida le queda a RC4?
Cinco criptógrafos han creado un nuevo ataque contra TLS que requiere que se capturen algunas millones de conexiones que contengan el mismo texto plano, y sólo funciona bien para los primeros 256 bytes transmitidos.
Si bien adelantan que no funciona en todas las implementaciones posibles de TLS, revelan un problema grave en el uso del algoritmo de cifrado RC4 para proteger el tráfico TLS.
RC4 es un algoritmo de cifrado simétrico, lo que significa que utiliza la misma clave para cifrar y descifrar. TLS se basa en criptografía de clave pública, sobre la base de un par de claves pública/privada y, como el cifrado de clave pública es demasiado lento para cifrar todo el tráfico de red, TLS utiliza un enfoque híbrido.
Se utiliza el par de claves pública/privada únicamente cuando se establece una conexión TLS, como una forma segura para negociar una clave de sesión aleatoria que luego se utiliza en el sistema de cifrado simétrico. Una vez que ambos extremos se ponen de acuerdo en la clave secreta, los datos reales que se quieren intercambiar sobre TLS son convencionalmente cifrados mediante criptografía simétrica.
Hay muchos sistemas de cifrado para elegir: OpenSSL, por ejemplo, soporta AES, Blowfish, DES, Triple-DES, RC4 y muchos más. Según los autores de esta última investigación, el sistema de cifrado RC4 es elegido por la mitad de todo el tráfico TLS. Así que es la parte de TLS que decidieron atacar.
Los investigadores también decidieron no nombrar el ataque con un "nombre maravilloso" y lo llamaron AlFardan-Bernstein-Paterson-Poettering-Schuldt (AlFBPPS), siendo el apellido de los autores en orden alfabético. Si bien todavía están desarrollando los detalles, los investigadores ya están trabajando con los proveedores sobre las contramedidas a implementar.
RC4 es un cifrado de flujo, por lo que básicamente se genera una llave criptográfica a través de Pseudo-Random Number Generator (PRNG) y se emite una secuencia de bytes de cifrado que se XORea con el texto plano para producir el texto cifrado.
Para descifrar el texto cifrado, se inicializa RC4 con la misma clave y el texto cifrado se XORea con la misma secuencia de bytes cifrados (XORing dos veces con el mismo valor se "anula", porque k XOR k = 0 y p XOR 0 = p.
El problema es que en RC4, el Pseudo-Random Number Generator (PRNG) no es de buena calidad. Durante más de una década se ha sabido que produce salidas anómalas estadísticamente, al menos al principio de cada secuencia de bytes cifrados. En 2001, los criptógrafos israelíes Itsik Mantin y Adi Shamir publicaron un artículo seminal titulado "Un ataque práctico sobre RC4".
AlFBPPS [PDF] fue mucho más lejos y se produjeron tablas estadísticas para la probabilidad de cada byte de salida (0..255) y para cada una de las 256 primeras posiciones de salida del cifrado RC4, con un total de 65535 (256x256) mediciones. Mediante el uso de un tamaño de muestra suficientemente grande, lograron resultados con la precisión suficiente para determinar que casi cada salida posible era parcial de alguna manera (en una distribución verdaderamente aleatoria, cada probabilidad sería 1/256).
Los autores se dieron cuenta que si se pudiera producir conexiones TLS una y otra vez y que contengan los mismos datos dentro de los primeros 256 bytes (por ejemplo, una solicitud HTTP con una cookie de sesión en las cabeceras), se podrían usar sus tablas de probabilidad para "adivinar" los bytes del cifrado.
Por ahora la cantidad de paquetes a interceptar sería de 2^32 (4 mil millones) o incluso 2^28 (260 millones) para luego procesarlos y extraer la cookie de sesión, por lo que es poco probable que sea un ataque factible en el corto plazo y The Register s encargó de publicar dichas conclusiones.
Por ejemplo, la validez de la cookie de sesión podría "vivir" un tiempo más corto que el necesario para provocar cientos de millones de conexiones redundantes TLS.
Sin embargo, el consejo es comenzar a evitar RC4 debido a que su PRNG no es tan aleatario e intentar reemplazarlo por AES-GCM.
GCM, o Galois/Counter Mode, es una forma relativamente nueva de cifrado por bloques que brinda cifrado y autenticación, todo en uno, y no sólo evita el sistema de cifrado RC4 sino también el reciente ataque Lucky Thirteen.
Cristian de la Redacción de Segu-Info
Si bien adelantan que no funciona en todas las implementaciones posibles de TLS, revelan un problema grave en el uso del algoritmo de cifrado RC4 para proteger el tráfico TLS.
RC4 es un algoritmo de cifrado simétrico, lo que significa que utiliza la misma clave para cifrar y descifrar. TLS se basa en criptografía de clave pública, sobre la base de un par de claves pública/privada y, como el cifrado de clave pública es demasiado lento para cifrar todo el tráfico de red, TLS utiliza un enfoque híbrido.
Se utiliza el par de claves pública/privada únicamente cuando se establece una conexión TLS, como una forma segura para negociar una clave de sesión aleatoria que luego se utiliza en el sistema de cifrado simétrico. Una vez que ambos extremos se ponen de acuerdo en la clave secreta, los datos reales que se quieren intercambiar sobre TLS son convencionalmente cifrados mediante criptografía simétrica.
Hay muchos sistemas de cifrado para elegir: OpenSSL, por ejemplo, soporta AES, Blowfish, DES, Triple-DES, RC4 y muchos más. Según los autores de esta última investigación, el sistema de cifrado RC4 es elegido por la mitad de todo el tráfico TLS. Así que es la parte de TLS que decidieron atacar.
Los investigadores también decidieron no nombrar el ataque con un "nombre maravilloso" y lo llamaron AlFardan-Bernstein-Paterson-Poettering-Schuldt (AlFBPPS), siendo el apellido de los autores en orden alfabético. Si bien todavía están desarrollando los detalles, los investigadores ya están trabajando con los proveedores sobre las contramedidas a implementar.
RC4 es un cifrado de flujo, por lo que básicamente se genera una llave criptográfica a través de Pseudo-Random Number Generator (PRNG) y se emite una secuencia de bytes de cifrado que se XORea con el texto plano para producir el texto cifrado.
Para descifrar el texto cifrado, se inicializa RC4 con la misma clave y el texto cifrado se XORea con la misma secuencia de bytes cifrados (XORing dos veces con el mismo valor se "anula", porque k XOR k = 0 y p XOR 0 = p.
El problema es que en RC4, el Pseudo-Random Number Generator (PRNG) no es de buena calidad. Durante más de una década se ha sabido que produce salidas anómalas estadísticamente, al menos al principio de cada secuencia de bytes cifrados. En 2001, los criptógrafos israelíes Itsik Mantin y Adi Shamir publicaron un artículo seminal titulado "Un ataque práctico sobre RC4".
Los PRNG pueden ofrecer servicios de alta calidad de aleatoriedad. Por ejemplo Mersenne Twister, produce excelentes números aleatorios desde una llave de arranque ("semilla"). Pero, si se conocen 64 salidas cualquieras y sucesivas del algoritmo para cualquier semilla dada, se puede reconstruir el estado interno del PRNG y predecir todas las salidas futuras, sin conocer la semilla. Una secuencia PRNG sólo puede reconstruirse si se conoce la clave de inicio.En particular, Mantin y Shamir examinaron el segundo byte de salida producido por el sistema de cifrado de flujo RC4, y encontraron que el valor cero se presentaba el doble de veces de lo que debería. Este resultado, por cierto, fue la base del ataque que rompió WEP, el protocolo de cifrado original utilizado en redes Wi-Fi, y obligó a su sustitución por WPA.
AlFBPPS [PDF] fue mucho más lejos y se produjeron tablas estadísticas para la probabilidad de cada byte de salida (0..255) y para cada una de las 256 primeras posiciones de salida del cifrado RC4, con un total de 65535 (256x256) mediciones. Mediante el uso de un tamaño de muestra suficientemente grande, lograron resultados con la precisión suficiente para determinar que casi cada salida posible era parcial de alguna manera (en una distribución verdaderamente aleatoria, cada probabilidad sería 1/256).
Los autores se dieron cuenta que si se pudiera producir conexiones TLS una y otra vez y que contengan los mismos datos dentro de los primeros 256 bytes (por ejemplo, una solicitud HTTP con una cookie de sesión en las cabeceras), se podrían usar sus tablas de probabilidad para "adivinar" los bytes del cifrado.
Por ahora la cantidad de paquetes a interceptar sería de 2^32 (4 mil millones) o incluso 2^28 (260 millones) para luego procesarlos y extraer la cookie de sesión, por lo que es poco probable que sea un ataque factible en el corto plazo y The Register s encargó de publicar dichas conclusiones.
Por ejemplo, la validez de la cookie de sesión podría "vivir" un tiempo más corto que el necesario para provocar cientos de millones de conexiones redundantes TLS.
Sin embargo, el consejo es comenzar a evitar RC4 debido a que su PRNG no es tan aleatario e intentar reemplazarlo por AES-GCM.
GCM, o Galois/Counter Mode, es una forma relativamente nueva de cifrado por bloques que brinda cifrado y autenticación, todo en uno, y no sólo evita el sistema de cifrado RC4 sino también el reciente ataque Lucky Thirteen.
Cristian de la Redacción de Segu-Info
0 Comments:
Publicar un comentario
Gracias por dejar un comentario en Segu-Info.
Gracias por comentar!