Cracking the Bluetooth PIN - CPH hacking and security

Aca en español para los que no se enteran de nada:

1.1. Introducción.

Debido a la reciente publicación de este método, y al interés general que ha suscitado, nos adelantamos a su publicación y lo hacemos en forma de Anexo.

Aunque no entraremos en profundidad con los algoritmos matemáticos para no hacer el artículo demasiado técnico, si que es imprescindible un perfecto conocimiento de la generación, intercambio y manejo de las claves, explicado con detalle en le capítulo 3.

1.2. El ataque básico.

Para poder realizar esta técnica, el atacante tiene que capturar y almacenar un determinado flujo de datos en el momento del emparejamiento y autenticación de dos dispositivos BlueTooth. Luego todo consiste en aplicar un algoritmo de fuerza bruta para poder saber el PIN utilizado en el emparejamiento .

Para hacer uso de esta técnica necesitamos previamente implementar los algoritmos de generación de claves, E1, E21 y E22, que son una modificación del conocido cifrado por bloques SAPHER+.

Tabla de mensajes enviados en el Emparejamiento y Autenticación

Conocidos gracias al sniffer el BD_ADRR y el IN_RAND, generamos un PIN y aplicamos estos datos a nuestra implementación de E22, con lo que conseguimos una Kinit. El atacante puede usar la Kinit para desXORear LK_RANDA y LK_RANDB (mensajes 2 y 3), y aplicarlas al algoritmo E21 para conseguir una hipotética KAB.

Ahora podemos aplicar la KAB y el AU_RANDa (mensaje 4) al algoritmo E1 para conseguir el SRES y compararlo con el SRES del mensaje 5.

Si coinciden es que ya tenemos el PIN correcto y la Clave de Linkado.
Si fuera necesario se pueden usar el valor de los mensajes 6 y 7 para asegurarnos.

Si recordamos que SRES es de 32 bits, nos encontramos con el impedimento de que solo tenemos 64 bits (SRESA y SRESB) para poder comparar nuestra salida de datos. Esto implica que el sistema solo es efectivo si el PIN es de menos de 64 bits (hasta 7 dígitos). Si el PIN es mayor, hay muchas posibilidades de tener varios candidatos, y aunque el sistema encuentre uno, es posible que no sea el correcto.

1.3. Implementacion es del Crack.

Los autores del método han desarrollado varias implementacion es de los algoritmos, desde la versión sin optimizar hasta versiones con tablas precalculadas.

A fecha de hoy el código fuente no está liberado, aunque podéis encontrar una descripción completa de los algoritmos en el documento original.

Como vemos en la siguiente tabla, los tiempos de ruptura son totalmente ridículos.

1.4. Forzando un nuevo emparejamiento .

Hasta aquí la idea no es nueva, y como podemos ver, tiene la tremenda dificultad de que hay que estar “presente” en el mismo momento en el que dos dispositivos son emparejados, y esto solo ocurre una vez, porque la Clave de Linkado una vez creada se almacena, y en las siguientes veces el proceso de emparejamiento no se realiza.

La novedad de todo esto radica en un nuevo ataque, que fuerza al protocolo de conexión a realizar un nuevo emparejamiento, y ahora ya sí que podemos llevar a acabo todo lo descrito anteriormente.

Asumimos que los dispositivos ya han sido previamente emparejados antes de establecer la nueva comunicación, con lo cual como hemos dicho se saltan el proceso de creación de KAB y pasan directamente a la Autenticación.

Hay descritos tres métodos para forzar un nuevo emparejamiento, y su eficacia depende del firmware de los dispositivos.

1.- Dado que los dispositivos pasan directamente al proceso de autenticación, el dispositivo maestro envía al esclavo un mensaje AU_RAND, y queda a la espera del SRES de retorno. Las especificacion es BlueTooth contemplan la posibilidad de que un dispositivo pierda su Clave de Linkado, y en ese caso, el esclavo manda un mensaje LMP_not_accept ed como respuesta.
De esta forma, justo después de que el maestro haya enviado el AU_RAND, el atacante inyecta un mensaje LMP_not_accept ed hacia el maestro, forzándole a descartar su Clave de Linkado y a reiniciar un nuevo emparejamiento .

2.- Al comienzo de la fase de Autenticación, el dispositivo maestro tiene que enviar un mensaje AU_RAND al dispositivo esclavo. Si antes de que haga esto, el atacante envia un mensaje IN_RAND hacia el dispositivo esclavo, este creerá que el maestro ha perdido su Clave de Linkado, y forzará un nuevo emparejamiento .

3.- Como hemos visto antes, durante la fase de Autenticación, el dispositivo maestro envía un mensaje AU_RAND al esclavo y queda a la espera de un SRES de respuesta. Si después de que el maestro haya enviado el AU_RAND, el atacante le inyecta un SRES aleatorio, forzará el reinicio de la fase de Autenticación. Después de cierto número de intentos, el maestro da como errónea la Autenticación, y forzará un nuevo emparejamiento .

Si quisiéramos hacer un ataque “on line”, la forma es grabar toda la transferencia entre los dispositivos después del proceso de emparejamiento . Mientras tanto vamos crackeando el PIN (0.06 – 0.3 seg para un PIN de 4 dígitos), descodificados toda la información guardada y seguimos descodificando “on line”.
Dado que BlueTooth transfiere a 1 Megabit/s, con un buffer de 40KB es suficiente para un PIN de 4 dígitos.

Suponiendo que tengamos el software necesario, aún así no es tan fácil el ataque.

El re-emparejamiento es un ataque activo, y requiere inyectar datos en un momento determinado, con lo que necesitaremos un dispositivo BlueTooth “preparado” para poder llevar acabo las inyecciones en su momento preciso, ya que normalmente esto no nos será posible.

Si el dispositivo esclavo verifica la BD_ADDR del maestro, necesitaremos poder spoofear la BD_ADDR, que también requiere un dispositivo BlueTooth “preparado”.

Y por último, si el ataque tiene éxito, los usuarios tienen que meter de nuevo el PIN, lo que puede levantar sospechas.