This article is an automated machine-translation of an article in English. We know the translation isn't perfect, but we hope it's useful for people who don't read English.

'Crack' Boffin cifrado HTTPS en Lucky Thirteen ataque

Filed Under: Featured, Privacy, Web Browsers

La seguridad de las transacciones en línea está de nuevo en el punto de mira como un par de criptógrafos británicos apuntar a TLS.

TLS o Transport Layer Security, es el sucesor de SSL, o Secure Sockets Layer.

Es el sistema que pone la S en HTTPS (que es el candado que aparece en sitios web seguros), y proporciona la seguridad para muchos otros protocolos, también.

Al igual que 2011 el infame ataque bestia , tiene un nombre maravilloso: Lucky Thirteen .

El nombre viene del hecho de que los paquetes cifrados TLS tiene trece bytes de cabecera que se consumen en uno de los cálculos criptográficos en los que se basa TLS.

→ El nombre del documento es un poco descarado - los autores con ironía en cuenta que "en cierto sentido, el trece es afortunado, pero doce habría tenido más suerte", desde 12-byte encabezados haría que su ataque sea aún más eficiente.

Para que te hagas una idea de lo que mueve a los criptógrafos, y cómo se las arreglan para extraer orden del caos, incluso cuidadosamente ideado, así es como empezó todo.

Los autores del trabajo notó que los paquetes cifrados en la mayoría de las sesiones TLS:

  • Se cifran con un cifrado de bloques segura, por lo general de AES en modo CBC, para mantener el secreto de su contenido.
  • Incluye una suma de control criptográfica fuerte, por lo general HMAC-SHA1, para evitar errores y falsificaciones.

Usted puede suponer que el uso no uno sino dos primitivas criptográficas fuertes inevitablemente aumentaría la seguridad, pero no creo que los criptógrafos de esa manera.

Nadhem AlFardan y Kenneth Paterson del Royal Holloway, un renombrado centro de investigación de seguridad de información que forma parte de la Universidad de Londres, se dio cuenta que podían usar estas dos funciones de seguridad entre sí debido a la forma en que se combinan en TLS.

Enormemente simplificada, el ataque se basa en los siguientes datos:

  • El cifrado de bloques AES encripta 16 bytes a la vez. Los paquetes de datos que no son un múltiplo de 16 bytes de longitud debe ser tabulada a cabo hasta que no lo son.
  • Las sumas de comprobación de paquetes TLS se almacenan dentro de la capa de cifrado, después los datos en bruto, pero antes de cualquier relleno necesario.

Cuando un servidor TLS recibe un paquete que es HMAC-SHA1 y AES checksummed CBS-cifrada, es necesario validarla, así:

  • Descifrar los datos recibidos, que debe ser un múltiplo de 16 bytes de longitud.
  • Identificar cualquier relleno al final de la memoria intermedia de descifrado, y tira hacia fuera.
  • Quite los últimos 20 bytes (la longitud de una suma de comprobación HMAC-SHA1) y guárdelo como referencia.
  • Calcule el HMAC-SHA1 de lo que queda en la memoria intermedia (menos relleno y suma de comprobación de referencia).

Si el computada HMAC-SHA1 suma de comprobación no coincide con la suma de comprobación de referencia, se ha producido un error o una falsificación. El servidor devolverá un mensaje de error y terminar la conexión.

Ahora imagine que usted es un MITM, o una man-in-the-middle. Usted no puede descifrar y volver a cifrar los paquetes a medida que pasan volando, pero se pueden interceptar, acortar ellos, modificarlos sutilmente, y transmitir las versiones modificadas.

Cada vez que hagas esto, te romperás la sesión TLS está atacando, pero usted puede hacerlo de una manera que sólo puede revelar información sobre lo que estaba dentro de la sesión ahora roto.

Eso no inmediatamente te daré las joyas de la corona, pero si se puede extraer algo del flujo de datos cifrados, usted ha violado la santidad de cifrado TLS que se supone que debe proporcionar.

El truco es que cuando truncar un paquete cifrado, existe la posibilidad de que el texto plano en el extremo de la corriente picado-off de datos se verá como la clase de bytes de relleno que TLS habría añadido si los datos originales habían sido más corto para empezar .

En ese caso, el servidor TLS quitarse lo que piensa que es el relleno, extraer lo que piensa que es la suma de comprobación paquete y compruebe que coincide con la suma de comprobación.

La suma de comprobación no coincide, por supuesto, pero no me importa.

Lo que importa es el tiempo que el servidor TLS necesita para responder con el mensaje de error cuando se da cuenta de que el paquete no es válido.

Debido a la forma en que HMAC-SHA1 obras, se necesitan cuatro unidades de tiempo de CPU en CHECKSUM los primeros 55 bytes de datos, además de una unidad de tiempo adicional por cada porción adicional de 64 bytes (o parte de éstos, en el extremo).

Los autores se dieron cuenta que al hacer una de dos bytes a modificar parte de un paquete cifrado y truncar ella, tuvieron la oportunidad de aproximadamente uno de cada 65.000 que el servidor acabaría pensando erróneamente que el mensaje se rellena, desnudando el relleno y lo que era la suma de comprobación a la izquierda.

A menos que el código de servidor TLS ha sido cuidadosamente diseñado para consumir la misma cantidad de tiempo, independientemente del contenido de los paquetes desencriptados, esto tomaría cuatro quintas partes del tiempo de procesamiento de un paquete untweaked.

Esto sucedería porque el paquete ajustado había engañado a la suma de comprobación del servidor en 55 bytes o menos de datos, no 56 o más.

Si los investigadores pudieran medir con fiabilidad este aumento de velocidad en función del tiempo la rapidez de respuesta del servidor error volvió, entonces, basado en el truco, ahora podían calcular dos bytes del paquete original.

Por tratando sistemáticamente todos los posibles ajustes de dos bytes (2 16 o 65.536 de ellos), y suponiendo que la medición perfecta sincronización, podrían garantizar a extraer dos de los bytes codificados.

Una vez que los dos primeros bytes están agrietados, otros 14 bytes se puede quebrar, un byte a la vez, al tratar de los 256 ajustes posibles de cada byte, para un total de "ajustar costos" de 2 16 + 14x2 8.

Y ese es el ataque Lucky Thirteen, en breve grotescamente operacional, si no teórico, términos.

No es un ataque terriblemente práctico, sobre todo porque medidas perfectas de tiempo son imposibles:

  • Cada intento de modificar provoca una sesión TLS para terminar, que puede ser a la vez notable y consume mucho tiempo.
  • Cada sesión ajustado necesita tener el mismo texto claro en la ubicación del mismo paquete para el que pellizca para hacer exhaustivamente.
  • Los autores necesitan 2 7 repeticiones de un conjunto exhaustivo de 2 16 ajustes (que son ocho millones de sesiones TLS dud!) Para producir datos de tiempo suficiente estadísticamente significativas para un resultado fiable.

Ah, y que estaba bajo circunstancias ideales de la red, con el equipo del cliente TLS, el servidor y MITM en la LAN dedicada mismo.

Sin embargo, es un resultado importante porque, como se mencionó anteriormente, pincha algunos de la santidad criptográfico que TLS se supone que proporcionan.

Soluciones y mitigación, que los diseñadores de protocolos futuros podrían tener en cuenta, son:

  • Diseñe y escriba su código por lo que no es mensurable más rápido o más lento cuando se producen errores, incluso si esto significa realizar cálculos redundantes.
  • Utilice un cifrado de flujo no, un cifrado de bloques, para evitar la necesidad de relleno de texto claro.
  • Suma de comprobación de los datos después del cifrado, en lugar de cifrar la suma de comprobación. Esto asegura que la cantidad de datos a ser la suma de comprobación no depende del texto plano.
  • Usa un algoritmo de encriptación autenticada, como AES-GCM , que combina la suma de comprobación y cifrado.

Curiosamente, la mitigación de última enlistados anteriormente (utilizar el cifrado autenticado) ya está previsto en TLS versión 1.2, que salió hace casi cinco años .

Lamentablemente, como los autores de fuera Lucky Thirteen punto, TLS 1.2 es todavía "no ha apoyado ampliamente en las implementaciones."

De acuerdo con el SSL-Pulse proyecto, menos del 12% de los sitios web que encuestó en enero de 2013 apoyó TLS 1.2, y la mayoría de los navegadores (Internet Explorer en Windows 7 y 8 es una excepción notable) no lo incluyen, ya sea.

Probablemente el momento de avanzar!

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog