Estas aquiContenido / Ataque práctico contra Bluetooth
Ataque práctico contra Bluetooth
Bluetooth puede haber quedado seriamente tocado después de que dos investigadores israelíes hayan publicado la forma de entrometerse en la comunicación "segura" de dispositivos de este tipo. En palabras de Bruce Schneier, no se trata de una mera ruptura teórica, sino que se trata de un ataque práctico.
Antes de poder establecer una comunicación, dos dispositivos Bluetooth han de intercambiar una clave secreta generada a partir de que en ambos se teclee idéntico PIN...
En 2004, Whitehouse ya logró llegar a la clave mediante un sniffer, pero su método tenía el inconveniente de que sólo podía aplicarse en el mismo momento en que ambos dispositivos comenzaban a comunicarse. Sin embargo el nuevo sistema engaña al dispositivo víctima haciéndole creer que ha perdido la clave, forzando así al comienzo de una nueva comunicación siempre que se desee.
Más información:
- New hack cracks 'secure' Bluetooth devices [Noticia en New Scientist]
- Cracking the Bluetooth PIN [El trabajo original]
- Attack on the Bluetooth Pairing Process [Bruce Schneier]
El bluetooth no se diseñó para ser seguro, sino para poder funcionar en un espectro radioelectrico limitado que tambien pudiera ser usado por otros dispositivos sin interferirse. El truco consiste en que cada bit (o simbolo, depende de como se implemente) se emite en una portadora distinta, variando la frecuencia de emision entre un rango predefinido.
Si usamos un analizador de espectro y lo centramos en a la frecuencia de trabajo de estos dispositivos, lo que vemos es que van apareciendo y desapareciendo portadoras en posiciones "aleatorias" dentro de la banda de paso.
El PIN que se intercambian al principio sólo sirve de semilla para el PRNG que usan ambos para decidir la frecuencia a la que se va a transmitir/recibir. De esta forma, a PIN's distintos, distintos aparatos usaran distintas frecuencias para cada simbolos, y el receptor solo debe tener una lista de los dispositivos con los que ha negociado la conexion para escuchar en una frecuencia determinada. Para el caso de que se de la casualidad de que a dos dispositivos les toque emitir en la misma frecuencia, simplemente hay que esperar al bit siguiente para que se resuelva el conflicto.
Difícilmente puede ser seguro algo cuyo protocolo de seguridad consiste en que si otro dispositivo le dice que no encuentra la clave se pone sin más a negociar otra nueva.
Lo que pasa es que un protocolo que implica que puedan cargarme en mi cuenta telefónica llamadas ajenas debería ser seguro. con independencia de donde vayan sus portadoras, algo que al usuario le importa un nabo.
Cada protocolo para lo que es. El bluetooth es para coordinar varias transmisiones de radio en un ancho de banda limitado. Cualquier implementacion sobre este debera tener en cuenta esto, y realizar las comprobaciones de identidad necesarias. Si se confia esto al diseño de un protocolo que no sirve para proporcionar seguridad, entonces se trata de una aplicacion que impepinablemente es insegura.
Pero de esto no tiene culpa bluetooth, sino los fabricantes que no implementan dichas comprobaciones. Es como decir que la modulacion FM es insegura porque cualquiera con una antena puede transmitir y captar lo que hay en el aire. No matemos al mensajero , por favor ;)
Entonces el WEP de wifi tampoco fue diseñado para proporcionar seguridad? Es que es mucho más fácil y rápido de romper.
Creo que conozco más o menos el funcionamiento de creación de claves, autenticación y cifrado de BlueTooth, algoritmos E0, E1, E21 y E22, los generadores de clave de carga útil, de keystream, los registros LSFR, etc, y me parecen demasiadas molestias para no estar orientado a la seguridad.
Lo que no acabo de entender es el ataque. Supongo que el dato necesario que tiene que esnifar aparte del BD_ADRR, es el IN_RAND, un número aleatorio de 128 bits, que se usa junto con el PIN y el BD_ADDR para sacar la Clave de incialización y posteriormente el Link Key.
Entonces según entiendo que dice ahí, con esos datos y aplicando fuerza bruta al PIN sacas el LK.
Pero lo que no entiendo es donde dice que el PIN es de 4 digitos (de ahí las 10000 posibilidades), porque que yo sepa el PIN puede ir desde 1 a 16 dígitos.
Y bueno, es cierto que la mayoría de las veces los bugs son debidos a una mala programación del firmware, que algún perfil o algún canal o alguna aplicación no implementa ninguna seguridad, etc.
Pero en este caso, una vez robada la LK, no veo forma de evitarlo. Hay que tener en cuenta que esto no se produce en la capa de aplicación, sino que lo gestiona el Link Manager, que va en un microprocesador dedicado, en la capa hardware.
A ver si alguien que lo haya mirado en profundidad se anima a postear, porque de ser todo como creo haber entendido, y si los tiempos de recorrido de los 16 bytes del PIN son tratables, me da la sensación de que esto es un bug definitivo.
Salu2.
El problema es el de siempre. La clave puede ser de hasta 128 bits (aunque segun dicen en el articulo la longitud efectiva del E0 es de 89 bits, pero no aportan mas datos :? ), pero los fabricantes han optado por utilizar claves que se pueden representar con 4 digitos. Gracias a eso los del articulo pueden recorrer todo el espacio de claves en 0'6 segundos, mas o menos como si no hubiera clave. Entre esto y que aprovechan el esquema de "clave perdida" para re-autentificarse con el maestro, es como si no hubiera nada entre las capas de seguridad.
Sigo pensando que es más un problema de implementacion que de diseño (cosa que, por supuesto, no excusa a los fabricantes, que la han metido hasta el fondo). Pero como tampoco soy un experto en las entrañas de Bluetooth, me uno a tu peticion de que venga alguien que sepa y nos lo explique ;)
Por ejemplo: mis auticulares bluetooth tienen como pin 0000,
mi teléfono tenía por defecto 1234.... y así sucesivamente.
Esto no es seguridad: es un cachondeo.
Desde mi despacho puedo acceder al bluetooth de tres coches
del aparcamiento de debajo de mi ventana.... por supuesto,
abierto y público.
No solo eso: incluso desactivando el bluetooth de mi móvil
( al menos eso dice el icono) , he comprobado empíricamente
que me detectan al entrar en algunos sitios: Parece ser que
"desactivado" quiere decir para algunos fabricantes "no aceptar conexión"
Y mientras tanto, no sé cómo convertir mi Linux en un manos
libres del móvil...
Gegen die Dummheit kämpfen selbst die Götter vergebens - Schiller
Bueno,
Me lo he mirado más a fondo, y parece que lo que dice es que muchos fabricantes ponen por defecto la longitud del PIN para el emparejamiento en 4 dígitos, por eso el artículo da esos tiempos, asumiéndolo como media.
Pero, según explica, el ataque es efetivo solo para PINs de menos de 64 bits (al disponer solo de 2x32 bits de SRES para comparar), o sea, de 7 caracteres para abajo.
Leyéndolo detenidamente se ve que es un problema de diseño, que sumado a los problemas de implementación de elección de longitud de clave, nos da como resultado esto.
Y frente a esto no se me ocurre nada efectivo a corto plazo para evitar el problema, salvo que los fabricantes obligan a poner por lo menos 8 caracteres de PIN.
Cambiando de tema, parece que Bruce Schneier ha publicado la noticia el dia 3 de este mes, pero el documento técnico está publicado desde antes, por lo menos yo lo tengo pendiente de estudio desde hace unas dos semanas, y está fechado desde antes.
Que curioso no? Por eso creía que alguíen había implementado el re-pairing según algún método de los propuestos en las especificaciones. Pero me he puesto en contacto con Yaniv Shakev, y me dice que no hay nada implementado (que va a decir? ;) ).
Salu2.