Seguridad del cifrado de la capa de enlace Bluetooth Low Energy (BLE)

14

¿El cifrado de la capa de enlace de Bluetooth Low Energy (BLE) es seguro contra un atacante que escucha una conexión BLE aleatoria entre dos dispositivos, pero no ha escuchado a escondidas la primera conexión entre los dos dispositivos?

Fondo: cuando los dos dispositivos están emparejados inicialmente, obtienen una clave a largo plazo mediante un protocolo de intercambio de claves. Cualquier persona que pueda escuchar esa pareja inicial puede aprender la clave a largo plazo, pero para los propósitos de esta pregunta, asuma que el adversario no escuchó esa pareja inicial (por ejemplo, porque el adversario no estaba cerca). Luego, los dos dispositivos utilizan esta clave a largo plazo para cifrar los datos enviados en todas las conexiones futuras. BLE utiliza AES-CCM para el cifrado de capa de enlace, que debería ser seguro si la clave a largo plazo es impredecible.

Sin embargo, en WOOT 2013, Mark Ryan publicó un artículo que especulaba sobre un posible ataque contra BLE. En su ataque, el atacante inyecta un mensaje forjado LL_REJECT_IND en un dispositivo. Aparentemente, esto hará que el destinatario olvide la clave de largo plazo actual y obligue a un nuevo intercambio de clave para obtener una nueva clave de largo plazo. El atacante puede espiar este nuevo intercambio de claves, aprender la nueva clave a largo plazo y descifrar todo el tráfico posterior. Al menos, eso es lo que Ryan especuló.

¿Este ataque realmente funciona? ¿Es inseguro el cifrado de capa de enlace de BLE, incluso si el atacante no capturó el emparejamiento inicial entre los dos dispositivos?

Referencia: Mike Ryan, " Bluetooth: con poca energía tiene poca seguridad ", WOOT 2013. enlace

    
pregunta D.W. 17.09.2015 - 04:18
fuente

1 respuesta

13

El ataque realmente funciona. He estado jugando con el Ubertooth One que adquirí en DEF CON hace cinco años y lo he probado con una variedad de dispositivos IoT que implementan el estándar BLE. El artículo de Mike Ryan es correcto.

Del libro, "Abusing the Internet of Things", el autor discute el trabajo de Mike Ryan y su implementación con Ubertooth One.

ubertooth-btle -f -c ble.pcap

El autor también discute el uso de la aplicación LightBlue para iOS para solucionar problemas, ya que puede copiar dispositivos Bluetooth y emularlos. Se necesita algo de trabajo con BLE porque utiliza muchos canales, por lo que se recomienda activar y desactivar las interfaces durante la evaluación de captura de red.

Los datos cifrados BLE estándar utilizan un protocolo de intercambio de claves al seleccionar una clave temporal basada en AES (TK). Mike Ryan lanzó la herramienta crackle para atacar con fuerza esta clave.

crackle -i ble.pcap -o decrypted-ble.pcap

Esta técnica no es efectiva contra el modo OOB (clave opcional de 128 bits también definida por BLE), sin embargo, como se ve en ubertooth mailing list , el equipo de desarrollo está trabajando para recopilar muestras y solucionar las posibilidades de romper el modo OOB.

Un conocido blog sobre tecnologías de pago y la infraestructura asociada también han sido especular sobre la desaparición de la seguridad de Bluetooth, incluidos algunos comentarios sobre la interrupción del modo BLE OOB. 29/12/15 actualización: hay más discusión sobre BT 2.1. También me encontré con btproxy, que con suerte será compatible con BTLE pronto. Otro tutorial que encontré se titula Detección y descifrado de Bluetooth con el UbertoothOne .

Sin embargo, (como se ve en el libro, "Hacking Exposed Wireless, 3rd Edition") la idea de reparar Bluetooth se publicó por primera vez en el documento "Cracking the Bluetooth PIN" de Yaniv Shaked y Avishai Wool ( enlace ). Un adversario puede usar un "ataque de reparación" para manipular el estado de emparejamiento almacenado entre dos dispositivos suplantando el BD_ADDR de uno de los dos dispositivos.

La herramienta bdaddr es la implementación principal de esta técnica.

gcc -obdaddr -lbluetooth bdaddr.c
hciconfig hci0
sudo bdaddr -i hci0 <new bdaddr>
(asks to reset device now)
sudo bccmd -d hci0 warmreset
(check that it changed)
hciconfig hci0
sudo hcitool cc <bdaddr of target to repair to>
sudo hcitool enc <bdaddr target again> enable

Para volver a una pizarra limpia

sudo bccmd -d hci0 coldreset
hciconfig hci0
    
respondido por el atdre 17.09.2015 - 05:34
fuente

Lea otras preguntas en las etiquetas