Descargar el artículo en formato pdf:
http://gospel.endorasoft.es/bluetooth/seguridad-bluetooth/Files/Identificacion.Dispositivos.Bluetooth.pdf

1. Introducción

Cuando realizamos algún escaneo de dispositivos Bluetooth con ayuda de herramientas comerciales o, mismamente, con el asistente  de conexiones Bluetooth de Windows, observamos que los dispositivos detectados son mostrados mediante iconos representativos de su naturaleza, ya sean PCs, PDAs, Teléfonos móviles, Manos libres, etc.

Nos preguntamos, ¿cómo será posible conocer el tipo de dispositivo del que se trata? La respuesta es: a través de los DIACs (The General- and Device-Specific Inquiry Access Codes)

2. Class of Device/Service

Cada dispositivo Bluetooth incorpora en la cabecera de nivel de Banda Base (Baseband 1.1) de sus paquetes un campo Class of Device/Service. Este campo se compone de 3 octetos organizados con el siguiente formato (en little endian):
- 11 últimos bits reservados para las Service Classes.
- 11 siguientes bits reservados para las Device Classes.
       - 6 últimos bits reservados para las Major Device Classes.
       - 5 siguientes bits reservados para las Minor Device Classes.
- 2 primeros bits para el campo Format Type, por defecto a 0.

El siguiente esquema resume lo explicado:


Con el fin de poder obtener información del campo Class of Device/Service, los 3 octetos se traducen a un string binario de 24 bits cuya ordenación de 1s y 0s permite identificar los servicios ofrecidos por el dispositivo, así como la naturaleza del mismo.

3. Service Classes (Clases de servicios)

El campo reservado para las Service Classes permite identificar los servicios soportados por el dispositivo. Este campo se compone de 11 bits, del 13 al 23. Cada servicio Bluetooth está asociado a un bit en concreto, de forma que si un determinado bit del campo está a 1, entonces el dispositivo soporta ese servicio Bluetooth. La correspondencia entre nº de bit y servicio se recoge en la siguiente tabla:

4. Device Classes (Clases de Dispositivos)

El campo reservado para las Device Classes permite identificar la naturaleza del dispositivo. Este campo se compone 2 subcampos: Major Device Classes y Minor Device Classes

4.1 Major Device Classes

El campo reservado para las Major Device Classes permite identificar el tipo genérico de dispositivo. Este campo se compone de 5 bits, del 8 al 12. Cada tipo genérico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos genéricos de dispositivos se recoge en la siguiente tabla:

4.2 Minor Device Classes

El campo reservado para las Minor Device Classes permite identificar el tipo específico de dispositivo. Este campo se compone de 6 bits, del 7 al 2. Cada tipo específico de dispositivo está asociado a una representación concreta de bits dentro del campo. La correspondencia entre bits y tipos específicos de dispositivos, dentro de cada tipo genérico, se recoge en la siguientes tablas:

Computer Major Class

Phone Major Class

Audio/Video Major Class

Peripheral Major Class

Imaging Major Class


Wereable Major Class

Toy Major Class


Referencias
https://www.bluetooth.org/foundry/assignnumb/document/baseband
http://trifinite.org/trifinite_stuff_btclass.html

Alguien puede estar pensando... ¿y para que qué puede servir esto de conocer el tipo de dispositivo?

Surgen algunas aplicaciones prácticas:

1) Permite obtener información más detallada sobre el dispositivo detectado.
Ya sabemos que pocas veces el nombre del dispositivo Bluetooth permite identificarlo, ya que este puede ser personalizado por el usuario. Asimismo, la dirección MAC nos permite conocer el fabricante del chipset, pero eso no acota las posibilidades; por ejemplo: Dell fabrica PCs de sobremesa, laptops, PDAs, etc.
Gracias al campo Device Class (suponiendo que este no haya sido falseado), podemos conocer de primera mano el dispositivo remoto con el que nos enfrentamos.

2) Permite realizar escaneos de víctimas filtrando los dispositivos que no nos interesan.
Si , por ejemplo, estamos interesados en llevar a cabo un ataque Bluebug, sólo nos sirven teléfonos móviles y el resto de dispositivos son descartables. En base al campo Device Class podemos filtrar los contenidos de hci_inquiry obteniendo únicamente los dispositivos que cumplan tener un dev_class correspondiente a un dispositivo 'Cellular'.
Puede que a priori no importe contar con dispositivos no vulnerables a Bluebug, pero si estamos realizando un ataque masivo en un ambiente con muchos dispositivos Bluetooth a nuestro alrededor se agradece disponer de la información lo menos viciada posible.

3) Engañar aquellos dispositivos que sólo permiten el emparejamiento con aquellos que cumplen un determinado tipo específico (o genérico) de Device Class.
Por ejemplo, algunos Manos libres están diseñados de forma que sólo es posible emparejarse desde un teléfono móvil y rechazan paquetes con origen otros dispositivos con el campo Device Class no admitido por defecto (por ejemplo, un PC).
Sabiendo como funcionan los DIACs (The General- and Device-Specific Inquiry Access Codes), podemos configurar nuestro equipo atacante falseando el campo Device Class y suplantando la identidad de un teléfono móvil. De esta forma, podemos ser capaces de conectarnos a ese dispositivo Manos libres y explotar vulnerabilidades (véase Car Whisperer).

Son sólo algunas ventajas...