Trabajo Redes y Servcios de Radio

Transcripción

Trabajo de Redes y Servicios de Radio - Bluetooth
Miguel Ángel Cuevas Cepeda y Pablo Isidoro Carrillo Álvarez
25 de mayo de 2010
Resumen
Este documento realizado para la asignatura de Redes y Servicios de Radio pretende mostrar una
panorámica sobre la Tecnología Bluetooth tanto históricamente como técnicamente. En el presente
documento podremos ver el origen de la Tecnología Bluetooth y sus principales usos, para a continuación, estudiar la tecnología desde un punto más técnico, sus tramas, protocolos, perfiles, topologías,
tipos de enlaces o la seguridad, profundizando en los aspectos más interesantes no tratados en clase.
Por último veremos algunos ejemplos prácticos así como las tramas que intercambian dispositivos que
implementan la Tecnología Bluetooth.
Índice general
1. Historia y Contexto
1.1. Qué es una WPAN . . . . . . . . . . . . . . . . . . . . . . . .
1.2. Historia de Bluetooth . . . . . . . . . . . . . . . . . . . . . .
1.2.1. Surgimiento de Bluetooth . . . . . . . . . . . . . . . .
1.2.2. Evolución de Bluetooth . . . . . . . . . . . . . . . . .
1.2.2.1. El Grupo de Interés Especial de Bluetooth[2]
1.2.2.2. Versiones . . . . . . . . . . . . . . . . . . . .
1.3. Usos y Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . .
1.3.1. Clases y Perfiles . . . . . . . . . . . . . . . . . . . . .
1.3.2. Aplicaciones . . . . . . . . . . . . . . . . . . . . . . . .
1.3.3. Diferencias en redes Bluetooth y Wi-Fi . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
3
3
3
4
4
4
5
7
7
7
9
2. Información Técnica
2.1. Topología de red . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2. Radio . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.1. Canal de radio . . . . . . . . . . . . . . . . . . . . . . . . .
2.2.2. Salto de frecuencia y salto adaptable de frecuencia (AFH) .
2.2.3. Ranuras de tiempo y paquetes. Transmisión bidireccional .
2.2.4. Protocolos de gestión de enlaces y canales. Capas de control
2.2.5. Canalización . . . . . . . . . . . . . . . . . . . . . . . . . .
2.3. Tipos de enlace . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4. Formato del paquete . . . . . . . . . . . . . . . . . . . . . . . . . .
2.5. Máquina de estados . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.6. Aplicaciones. Perfiles en Bluetooth . . . . . . . . . . . . . . . . . .
2.6.1. Advanced Audio Distribution Profile (A2DP) . . . . . . . .
2.6.2. Audio/Video Remote Control Profile (AVRCP) . . . . . . .
2.6.3. Basic Imaging Profile (BIP) . . . . . . . . . . . . . . . . . .
2.6.4. Basic Printing Profile (BPP) . . . . . . . . . . . . . . . . .
2.6.5. Common ISDN Access Profile (CIP) . . . . . . . . . . . . .
2.6.6. Cordless Telephony Profile (CTP) . . . . . . . . . . . . . .
2.6.7. Device ID Profile (DID) . . . . . . . . . . . . . . . . . . . .
2.6.8. Dial-Up Networking Profile (DUN) . . . . . . . . . . . . . .
2.6.9. Fax Profile (FAX) . . . . . . . . . . . . . . . . . . . . . . .
2.6.10. File Transfer Profile (FTP) . . . . . . . . . . . . . . . . . .
2.6.11. General Audio/Video Distribution Profile (GAVDP) . . . .
2.6.12. Generic Access Profile (GAP) . . . . . . . . . . . . . . . . .
2.6.13. Generic Object Exchange Profile (GOEP) . . . . . . . . . .
2.6.14. Hard Copy Cable Replacement Profile (HCRP) . . . . . . .
2.6.15. Hands-Free Profile (HFP) . . . . . . . . . . . . . . . . . . .
2.6.16. Human Interface Device Profile (HID) . . . . . . . . . . . .
2.6.17. Headset Profile (HSP) . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10
10
12
12
12
13
13
16
17
18
18
19
20
20
21
21
21
21
21
21
22
22
22
22
22
22
22
22
22
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
ÍNDICE GENERAL
2.6.18.
2.6.19.
2.6.20.
2.6.21.
2.6.22.
2.6.23.
2.6.24.
2.6.25.
2.6.26.
2.6.27.
2.6.28.
Intercom Profile (ICP) . . . . . . . . . . . . . . . . .
Object Push Profile (OPP) . . . . . . . . . . . . . .
Personal Area Networking Profile (PAN) . . . . . . .
Phone Book Access Profile (PBAP) . . . . . . . . . .
Serial Port Profile (SPP) . . . . . . . . . . . . . . . .
Service Discovery Profile (SDAP) . . . . . . . . . . .
SIM Access Profile (SAP, SIM) . . . . . . . . . . . .
Synchronisation Profile (SYNCH) . . . . . . . . . . .
Video Distribution Profile (VDP) . . . . . . . . . . .
Wireless Application Protocol Bearer (WAPB) . . .
Perfiles adicionales . . . . . . . . . . . . . . . . . . .
2.6.28.1. Unrestricted Digital Information (UDI). . .
2.6.28.2. Extended Service Discovery Profile (ESDP)
2.6.28.3. Video Conferencing Profile (VCP) . . . . .
2.6.28.4. Message Access Profile (MAP) . . . . . . .
3. Seguridad en Bluetooth
3.1. Modos de seguridad . . . . . . . . . . . . . . . .
3.2. Seguridad en la Conexión . . . . . . . . . . . . .
3.2.1. Emparejamiento o “Paring” . . . . . . . .
3.2.2. Autenticación . . . . . . . . . . . . . . . .
3.2.3. Autorización . . . . . . . . . . . . . . . .
3.2.4. Cifrado de datos . . . . . . . . . . . . . .
3.3. Vulnerabilidades. Ataques a dispositivos Bluetooh
3.3.1. BlueSnarf . . . . . . . . . . . . . . . . . .
3.3.2. BlueBug . . . . . . . . . . . . . . . . . . .
3.3.3. Hello Moto . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4. Ejemplos y Casos de uso práctico
4.1. Ejemplo con un móvil. Aplicación Java para bluetooth
4.2. Sniffer para Bluetooh . . . . . . . . . . . . . . . . . . .
4.2.1. Introducción . . . . . . . . . . . . . . . . . . .
4.2.2. Herramientas software necesarias . . . . . . . .
4.2.3. Comandos útiles . . . . . . . . . . . . . . . . .
4.2.3.1. Interfaz Bluetooth . . . . . . . . . . .
4.2.3.2. Lista de dispositivos. Escaner . . . . .
4.2.3.3. Sniffer de tráfico de datos . . . . . . .
4.2.3.4. Descubrimientos de servicio . . . . . .
4.2.4. Contruir nuestro propio sniffer Bluetooth . . .
4.3. Análisis de Intercambio de Tramas Bluetooth . . . . .
Miguel Ángel Cuevas Cepeda y Pablo Carrillo Álvarez
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
23
23
23
23
23
23
23
23
24
24
24
24
24
.
.
.
.
.
.
.
.
.
.
25
25
25
25
27
28
29
30
30
32
37
.
.
.
.
.
.
.
.
.
.
.
38
38
38
38
39
41
41
41
41
46
51
54
2
Capítulo 1
Historia y Contexto
En este capítulo se describe el contexto histórico - tecnológico en el que surge la tecnología Bluetooth y su evolución. Lo primero que veremos será una aproximación a que es Bluetooth.
Bluetooth es una norma que define un estándar global de comunicación inalámbrica para la transmisión de voz y datos por un enlace de radiofrecuencia. Los principales objetivos son:
Facilitar las comunicaciones entre equipos móviles y fijos.
Eliminar cables y conectores entre estos.
Ofrecer la posibilidad de crear pequeñas redes inalámbricas y facilitar la sincronización de los
datos en ellas entre nuestros equipos personales.
Para más información puede acudir a la referencia bibliografica utilizada disponible en la Biblioteca
de la Escuela de Ingenerios [1].
1.1.
Qué es una WPAN
Lo primero que debemos preguntarnos es qué es una WPAN, Wireless Personal Area Network o Red
de Área Personal Inalámbrica. Las WPAN son un tipo de redes que se despliegan entre los dispositivos
en un área de 1 metro de radio, generalmente es usada por una misma persona comunicando entre
sí sus dispositivos de forma inalámbrica, no estando destinadas a su aplicación en LANs, Local Area
Networks o Redes de Área Local. Este tipo de redes surge de la necesidad creciente de comunicación
entre los distintos aparatos electrónicos que portamos o usamos cada día como ordenadores, teléfonos
móviles, periféricos inalámbricos o manos libres para el automóvil. Este tipo de redes surge en los años
noventa y cada vez se estan popularizando más hasta tal punto que en 2007 se tenían más de mil
millones de dispositivos que trabajaban en una WPAN.
1.2.
Historia de Bluetooth
El nombre Bluetooth proviene del rey danés y noruego Harald Blàtand, la traducción al inglés
de su apellido sería Bluetooth. El rey Harald fue conocido por ser un buen comunicador y consiguió
unificar las tribus noruegas, suecas y danesas. Debido a que el propósito de esta tecnología era unir
los dispositivos entre sí y el origen noruego de la compañía que lo impulsó primero se eligió este nombre.
El logo proviene de la unión de dos runas germánicas.
3
CAPÍTULO 1. HISTORIA Y CONTEXTO
(a) Runa Hagall
(c) Logotipo de Bluetooth
(b) Runa Berkanan
Figura 1.1: Logo de Bluetooth
1.2.1.
Surgimiento de Bluetooth
La primera empresa que trabajó en Bluetooth fue Ericsson, que en 1994 encarga un estudio sobre
la viabilidad de una interfaz de conexión inalámbrica vía radio, de bajo coste y consumo reducido. El
propósito de esta interfaz era la conexión entre teléfonos móviles y accesorios para así no tener que
usar cables. El estudio partía de un proyecto que investigaba multicomunicadores conectados a una
red celular, hasta que se consiguió un enlace de corto alcance llamado MC link. Al avanzar el proyecto
se vió que este tipo de enlace podía tener muchosa más usos y aplicaciones teniendo como principal
virtud que se basaba en un chip de radio económico.
1.2.2.
Evolución de Bluetooth
1.2.2.1.
El Grupo de Interés Especial de Bluetooth[2]
En septiembre de 1998 se crea el Grupo de Interés Especial (SIG) de Bluetooth con sede en Bellevue,
Washington. El SIG de Bluetooth es una organización privada sin ánimo de lucro. El SIG de Bluetooth
no se ocupa de la fabricación ni venta de productos con esta tecnología, tan sólo del desarrollo de la
misma. Actualmente el SIG tiene más de 9000 miembros líderes en las áreas de las telecomunicaciones,
informática, industria automotriz, música, etc. . . . Los miembros del SIG impulsan el desarrollo de la
tecnología Bluetooth y la implantan y comercializan en sus productos.
Actualmente el SIG tiene oficinas en Bellevue, Washington y dependencias en Hong Kong y en
Malmo, Suecia. El equipo está formado por una pequeña plantilla de profesionales del SIG y sus ejecutivos. Además del personal propio del SIG varias empresas afiliadas prestan a sus trabajadores de forma
voluntaria y de esta forma juegan un papel importante en el desarrollo de la tecnología Bluetooth y
en la organización que la respalda. Los miembros de la organización son responsables de varios grupos
de trabajo y comités de áreas como ingeniería, calidad o marketing.
En su origen el SIG fue formado por las empresas:
Ericsson
IBM
Intel
Toshiba
Nokia
Un año después, en 1999 se unirían:
3com
Microsoft
4
Motorola
En la actualidad hay multitud de empresas pero las más activas, siendo sus miembros promotores, son:
Ericsson
Intel Corporation
Lenovo (Singapore) Pte Ltd
Microsoft Corporation
Motorola, Inc.
Nokia Corporation
Toshiba Corporation
Para poder usar el logo o la tecnología Bluetooth en tu producto debes pertenecer al SIG de Bluetooth
y al ser una tecnología abierta todos sus miembros están autorizados a usarla en sus productos y
servicios. En la actualidad existen 3 tipos de afiliación que comparten los mismos acuerdos:
Miembros promotores
Miembros asociados
Miembros adoptivos
Actualmente no se permite la afiliacion de individuos ni estudiantes y sí a las empresas.
Los beneficios por afiliarse es una licencia de uso libre de derechos de autor para fabricar productos
con esta tecnología, acceso a la información técnica y las especificaciones y la licencia para usar el
término y los logotipos de la tecnología Bluetoth.
1.2.2.2.
Versiones
Durante todo este tiempo Bluetooth ha ido evolucionando mejorando sus características y adaptándose al mercado. Originalmente la especificación fue desarrollada en 1994 por dos ingenieros de Ericsson
y se basaba en la técnica de Salto en Frecuencia de Espectro Expandido. En 1998 la especificación fue
formalizada por el SIG de Bluetooth.
1. Bluetooth v1.0 y 1.0B
Las versiones 1.0 y 1.0B del protocolo tuvieron muchos errores y los fabricantes tuvieron muchas
dificultades para conseguir que los productos fueran interoperables entre si. Por otra parte, estas
versiones exgían el envío de la dirección hardware en el proceso de conexión, haciendo imposible
a nivel de protocolo el envío anónimo, algo que era necesario para ciertos servicios planeados en
entornos Bluetooth.
2. Bluetooth v1.1
Muchos de los errores de la versión anterior fueron corregidos. Se añadió soporte para canales
no encriptados y un indicador de la potencia de la señal recibidad. Esta versión se ratificó como
estandar del IEEE 802.15.1-2002 [3].
5
3. Bluetooth v1.2
Esta versión es retrocompatible con la v1.1, y se alcanza una mayor velocidad de conexión de
hasta 721Kb/s. Sus principales avances fueron una conexión y descubrimiento más rápido, el
uso de la técnica de Salto en Frecuencia Adaptativo (AFH) que consigue mayor resistencia a las
interferencias en la señal, Conexiones Extendidas Síncronas (eSCO) que consiguen una mejora en
la calidad de los enlaces de audio y se introduce el control de flujo y un modo de retransmisión
para L2CAP. Es ratificado como estándar por el IEEE, 802.15.1-2005[3].
4. Bluetooth v2.0 + EDR
Esta versión fué lanzada en 2004 y es retrocompatible con la versión 1.2. El avance principal es la
inclusión de “Enhace Data Rate” (EDR) para una transmisión de datos más rápida. La velocidad
nominal es de 3Mbps pero en la práctica se alacanzaban tasas de 2.1Mbps.
La especificación fue publicada como “Bluetooth 2.0 + EDR” lo que implicaba que EDR era una
característica opcional
5. Bluetooth v2.1 + EDR
Esta versión fue lanzada por el SIG en 2007 y es retrocompatible con la v1.2. La característica más
importante es el Emparejamiento Simple Seguro (SPP) que mejora la experiencia de emparejar
dos dispositivos incrementando el uso y fuerza de la seguridad. También encontramos mejoras en
la gestión de energía, sobre todo un menor consumo estando en reposo.
6. Bluetooth v3.0 + HS
Esta versión fue lanzada por el SIG en abril de 2009. Soporta velocidades teóricas de 24Mbps, pero
no se usa el canal Bluetooth en sí para los datos sino sólo para la negociación y establecimiento, el
transporte de los datos se dá sobre un enlace 802.11, esto se hace usando “Alternate MAC/PHY”.
a) Alternate MAC/PHY, permite el uso de alternativas MAC y PHY para el transporte de los
datos del perfil de Bluetooth. El enlace de radio Bluetooth se sigue usando para la detección
de los dispositivos, la conexión inicial y la configuración del perfil, pero cuando se tienen
que transferir grandes cantidades de datos se usa una interfaz de alta velocidad PHY MAC
802.11 que es la que se asocia a Wi-Fi. Con esto usamos Bluetooth cuando el sistemas está
inactivo y cuando es necesario una transferencia de gran cantidad de datos se usa Wi-Fi.
b) Unicast Conectionless Data, permite un servicio de envío de datos sin establecer un canal
L2CAP explícito. Está destinado a aplicaciones de baja latencia entre la acción del usuario
y la reconexión / envío de los datos. Sólo debe utilizarse con pequeñas cantidades de datos.
c) Control mejorado de energía, actualiza el control de energía quitando el control de energía
por lazo abierto y aclara ambigüedades de la versión anterior estableciendo esquemas nuevos
de modulación para EDR y el comportamiento que se espera. También se añade un control
de alimentación en circuito cerrado y una petición para ir directamente a la máxima potencia
para evitar perdidas de conexión de los dispositivos.
7. Bluetooth v4.0
El 21 de abril de 2010 el SIG de Bluetooth completa el núcleo de la v4.0 de Bluetooth. Esta
versión incluye Classic Bluetooth, Bluetooth de alta velocidad y Bluetooth de baja energía. El
Bluetooth de alta velocidad se basa en Wi-Fi y el Classic Bluetooth se compone de los anteriores
protocolos.
a) El Bluetooth de baja energía es una mejora reciente que permite dos tipos de aplicación,
modo dual y monomodo.
En una aplicación dual, la nueva funcionalidad se integra en un controlador Classic Bluetooth existente. Como resultado tenemos una arquitectura que comparte muchos puntos con
6
Classic Bluetooth y tiene un coste mínimo. Además los fabricantes pueden usar la nueva
pila de baja energía tanto en Bluetooth v2.1 como Bluetooth 3.0, mejorando el desempeño
de Classic Bluetooth con las nuevas capacidades.
Por otra parte en un chip monomodo permitirá dispositivos muy integrados y compactos que
tendran una ligera capa de enlace con un consumo ultra bajo en el modo de inactividad,
detección de dispositivos simple, conexiones punto-multipunto de transferencia de datos
con ahorro avanzado de energía y conexiones encriptadas seguras al menor coste posible.
Además la capa de enlace de estos controladores permitirán sensores conectados a internet
para programar el tráfico de baja energía entre transmisores Bluetooth.
La tecnología Bluetooth de bajo consumo está diseñada para tener una vida de batería de hasta
un año con pilas de botón, esto se espera que pueda aplicarse en equipamiento deportivo y en
relojes.
8. Versiones futuras
Para versiones futuras se quiere diseñar canales de difusión, esto habilitaría los puntos de información Bluetooth impulsando Bluetooth en los teléfonos móviles y haciendo posibles modelos
de publicidad basados en puntos de información. También se preveen mejoras en la topología
de gestión cuando haya muchos dispositivos haciendo la gestión de estos transparente al usuario
y mejoras en la QoS haciendo que se priorice el tráfico de Audio o Video a una mayor calidad
dentro de la piconet.
1.3.
Usos y Aplicaciones
Bluetooth tiene como misión ser un protocolo de comunicación diseñado para tener un bajo consumo
y un rango de trabajo pequeño.
1.3.1.
Clases y Perfiles
Dependiendo de la potencia que se use tenemos tres clases de dispositivos, como vemos en la figura
1.1. Por otra parte estos dispositivos no necesitan estar en una línea de visión directa porque se usa
un radio enlace.
Clase
Clase 1
Clase 2
Clase 3
Potencia Máx. Permitida (dB)
20
4
0
Potencia Máx. Permitida (mW)
100
2,5
1
Intervalo
~100m
~10m
~1m
Cuadro 1.1: Clases de dispositivos Bluetooth
Para usar la tecnología Bluetooth de forma sencilla se crearon una seria de perfiles que facilitaran
la interoperatiblidad de los dispositivos y la puesta en funcionamiento de las conexiones, estos perfiles
podemos verlos detalladamente en el apartado 2.6.
1.3.2.
Aplicaciones
Teniendo en cuenta la flexibilidad que ofrecen los perfiles y las distintas clases de dispositvos
Bluetooth nos encontramos con un amplio abanico de aplicaciones. A continuación veremos algunos
ejemplos.
Manos libres para teléfonos móviles y ordenadores, esta fué una de las primeras aplicaciones, ver
figura 1.2d.
7
Redes inalámbricas entre ordenadores, este no es su propósito principal pero aún así es posible.
Transferencia de archivos y datos de contacto, calendario, mediante la tecnología OBEX, ir a
2.2.4 para más información.
Para conexiones de perífericos de forma inalámbrica y que no precisen mucho ancho de banda,
como ejemplo tenemos impresoras, ratones o teclados.
Para sustituir los cables de comunicación serie de receptores GPS, equipos médicos.
Envío de anuncios desde puntos publicitarios a dispositivos Bluetooth detectables.
Para la conexión de los controles inalámbricos en consolas de videojuegos u ordenadores.
Para conectar un teléfono móvil a un ordenador y que el ordenador pueda usarlo como modem.
Transmisión de datos a teléfonos móviles desde sensores de salud o deportivos.
Como puente inalábrico entre dos redes Industrial Ethernet (PROFINET).
Para conectar altavoces a ordenadores o teléfonos móviles de forma inalámbrica evitando cables,
ver figura 1.2a.
(b) Ratón bluetooth
(a) Altavoces Bluetooth
(c) Mando de videoconsola Bluetooth
(d) Headset Bluetooth
Figura 1.2: Ejemplos de dispositivos Bluetooth
8
1.3.3.
Diferencias en redes Bluetooth y Wi-Fi
Wi-Fi está pensado para equipos que necesitan intercambiar una gran cantidad de datos pero sin un
cableado general, es decir, de forma inalámbrica y en el entono de una Red de Área Local Inalámbrica
así que sería un entorno WLAN.
Por otra parte Bluetooth está pensado para equipos que están en continua movilidad y que se
comunican cuando están muy cerca unos de otros encajando en el perfil de la Red de Área Personal
Inalámbrica, WPAN.
Además también se diferencian en la puesta en marcha de los dos tipos de redes, Wi-Fi al ser una
red Ethernet requiere de una configuración previa para poder funcionar mientras que Bluetooth gracias
a los perfiles de uso sólo necesita detectar el dispositivo e introducir una contraseña. Por otra parte
los enlaces en Wi-Fi al ser con mayor potencia y dentro del mismo rango de frecuencias de Bluetooth
consigue una mayor fiabilidad en las transmisiones. A continuación vemos la figura 1.2 como resumen.
Bluetooth
Wi-Fi
Distancia
Corta
Larga
Frecuencia
2.4GHz
2.4GHz
Tipo de red
WPAN
WLAN
Configuración
Sencilla
Complicada
Potencia
Menor
Mayor
Ancho de Banda
Menor
Mayor
Cuadro 1.2: Tabla Bluetooth Vs Wi-Fi
9
Capítulo 2
Información Técnica
2.1.
Topología de red
Bluetooth soporta tanto comunicaciones punto a punto como punto a multipunto. Los dispositivos
Bluetooth se agrupan en lo que se conoce como piconet, que podemos ver en la figura 2.1, constituida
por equipos que se conectan sobre la marcha. Cada piconet se caracteriza por una secuencia de salto
en frecuencia diferente y tiene una capacidad de hasta 8 dispositivos, todos ellos sincronizados tanto
en tiempo como en frecuencia.
Figura 2.1: Esquema de una piconet
Dentro de una piconet, existen medios de interacción entre los dispositivos Bluetooth. El modo
más simple es la conexión punto a punto, que vemos en la figura 2.2a, en la que únicamente hay dos
extremos implicados: uno de ellos recibe el nombre de maestro (master en la figura 2.1) y el otro el de
esclavo (slave en la figura 2.1). La otra variedad es la conexión punto a multipunto, que vemos en la
figura 2.2b, donde múltiples dispositivos esclavos, hasta un máximo de 7, se conectan a un maestro.
En este caso el canal y su ancho de banda son compartidos por todo el conjunto.
10
CAPÍTULO 2. INFORMACIÓN TÉCNICA
(a) Punto a punto
(b) Punto a Multipunto
Figura 2.2: Topologías de red Bluetooth
En realidad es posible que dentro de una misma piconet haya más de 7 esclavos conectados a un
maestro, pero únicamente 7 de ellos podran estar activos simultáneamente; el resto se dice que están
aparcados (parked ). Estos tipos de dispositivos permaneceran sincronizados, en todo momento, con el
maestro, de manera que en cualquier instante uno de ellos puede entrar en funcionamiento.
A cada uno de los esclavos activos se le asigna un número de 3 bits que recibe el nombre de dirección
AMA (Active Member Address) mientras que para los esclavos aparcados la dirección es de 8 bits y se
denomina PMA (Parked Member Address). Por tanto, podra haber hasta 256 esclavos aparcados.
El solapamiento entre las áreas de cobertura de dos piconet cercanas da lugar a una scatternet
(ver figura 2.3). Cuando esto ocurre, los esclavos de una piconet pueden actuar como maestros o como
esclavos de la otra mediante un esquema TDM de multiplexación por división en el tiempo. Cada una
de las piconet opera con una secuencia de salto distinta.
11
Figura 2.3: Esquema de una scatternet
En cuanto a interferencias con otros dispositivos, hay que tener cuidado con los que operan en la
misma banda ya que se pueden interferir unos a otros.
2.2.
Radio
La capa física de radio (RF) Bluetooth opera en la banda de 2.4 GHz libre para ISM (banda de
frecuencia industrial, científica y médica), como ya hemos comentado en secciones anteriores. El sistema emplea un transmisor de salto de frecuencia para contrarrestar las interferencias y la pérdida de
intensidad, y cuenta con un gran número de portadoras de espectro ensanchado por salto de frecuencia
(FHSS).
Para minimizar la complejidad del transmisor, se utiliza una modulación de frecuencia binaria. La
tasa de transferencia de símbolos es de 1 MSps (megasímbolos por segundo), que admite una velocidad
de transmisión de 1 Mbps en el modo de transferencia básica y una velocidad de transmisión aérea
total de 2 a 3 Mbps en el modo de transferencia de datos mejorada. Estos modos se conocen como
transferencia básica y transferencia de datos mejorada, respectivamente.
2.2.1.
Canal de radio
Normalmente, varios dispositivos sincronizados por un reloj y una secuencia de salto de frecuencia
comparten el mismo canal físico de radio, el aire.
2.2.2.
Salto de frecuencia y salto adaptable de frecuencia (AFH)
Los dispositivos de una piconet utilizan una secuencia de salto de frecuencia determinada por
algoritmos en ciertos campos del reloj y de la dirección de especificación Bluetooth del maestro. La
secuencia básica de salto consiste en un ordenamiento pseudo-aleatorio de las 79 frecuencias de la
12
banda ISM. Esta secuencia puede adaptarse para excluir la sección de frecuencias utilizadas por los
dispositivos que están causando interferencias. La técnica de salto adaptable mejora la coexistencia de
la tecnología Bluetooth con los sistemas ISM estáticos (es decir, sin salto) cuando éstos se encuentran
localizados.
2.2.3.
Ranuras de tiempo y paquetes. Transmisión bidireccional
El canal físico se subdivide en unidades de tiempo denominadas ranuras. Los datos intercambiados
entre los dispositivos Bluetooth se transmiten en forma de paquetes que se emplazan en estas ranuras.
Cuando la situación lo permite, se pueden asignar varias ranuras consecutivas a un único paquete.
El salto de frecuencia se produce durante la transmisión o recepción de los paquetes. La tecnología
Bluetooth consigue la transmisión bidireccional mediante la técnica de acceso múltiple o dúplex por
división de tiempo (TDD).
2.2.4.
Protocolos de gestión de enlaces y canales. Capas de control
La pila de protocolos Bluetooth está formada por una serie de niveles funcionales cuya representación simplificada se muestra en la figura 2.4.
Figura 2.4: Pila de protocolos de Bluetooth
En primer lugar, encontramos el nivel de Radio (RF ), que especifica los parámetros relacionados
con la interfaz del medio físico como la banda de frecuencia (ver tabla 2.4), las características del
transmisor, la modulación, etc. Sobre esta capa, se sitúa el de Banda base (BaseBand ), encargado
de las tareas de bajo nivel para lo que define un controlador del enlace (LC, Link Controller ). Un
13
dispositivo Bluetooth genérico se compone de un módulo de radio, un módulo de control del enlace y
un módulo para la gestión del enlace de la entrada y salida (ver figura 2.5).
Figura 2.5: Esquema de un dispositivo Bluetooth genérico
Por otra parte, el protocolo de Gestión del Enlace (LMP, Link Manager Protocol ) contiene los
mensajes de establecimiento de las conexiones, seguridad y control. Bluetooth soporta un canal de
datos asíncrono o hasta tres canales síncronos de voz o bien un canal de voz y otro de datos simultáneos,
ver tabla 2.1.
Configuración
3 canales de voz simultáneos
Datos simétricos
Datos asimétricos
Máxima tasa binaria ascendente
64 Kbps por canal
433.9 Kbps
723.2 Kbps o 57.6 Kbps
Máxima tasa binaria descendente
64 Kbps por canal
433.9 Kbps
57.3 Kbps o 723.2 Kbps
Cuadro 2.1: Configuraciones del enlace
El protocolo L2CAP ( Logical Link Control and Adaptation Protocol ) se utiliza para pasar paquetes
con y sin orientación a la conexión a sus capas superiores incluyendo tanto al Host Controller Interface
(HCI) como directamente al gestor del enlace (LM).
Las funciones de L2CAP incluyen:
Segmentación y reensamblado de paquetes: Acepta paquetes de hasta 64KBytes de sus capas
superiores.
Multiplexación de varias fuentes de paquetes, comprobando el protocolo de las capas superiores
para así adaptarlo antes del reensamblaje.
Proporcionar una buena gestión para la transmisión unidireccional a otros dispositivos bluetooth.
14
Gestión de la calidad de servicio (QoS), del inglés Quality of service: para los protocolos de las
capas superiores. En esta fase negocia el tamaño máximo del campo de datos de las tramas. Con
ello, evita que algún dispositivo envíe paquetes tan grandes que puedan desbordar al receptor.
Sobre el nivel L2CAP, encontramos los siguientes protocolos:
SDP (Service Discovery Protocol ): Ofrece un servicio de publicación de los servicios disponibles
y sus características, ver figura 2.6.
Figura 2.6: Protocolo SDP
RFCOMM (Radio Frequency Communication) [10]: es una emulación de un puerto serie sobre
L2CAP basada en el estándar ETSI TS 0.7.10 y puede soportar hasta 60 conexiones simultáneas
entre dos dispositivos Bluetooth, aunque el número empleado depende de la capacidad de cada
dispositivo concreto.
• OBEX (abreviatura de OBject EXchange, intercambio de datos; también denominado IrOBEX )
es un protocolo de comunicaciones que facilita el intercambio de objetos binarios entre dispositivos. Es mantenido por la Infrared Data Association (IrDA) pero ha sido adoptada
también por el Bluetooth Special Interest Group y por la sección SyncML de la Open Mobile
Alliance (OMA). Una de las primeras aplicaciones populares de OBEX tuvo lugar en la
Personal Digital Assistant Palm III. Esta PDA y sus múltiples sucesoras utilizaron OBEX
para intercambiar tarjetas de negocio, datos e incluso aplicaciones.
• OBEX es similar en diseño y funcionalidad a HTTP, protocolo en el que el cliente utiliza
un transporte fiable para conectarse a un servidor y así recibir o proporcionar objetos. No
obstante, OBEX difiere en algunos puntos importantes.
◦ Transporte: HTTP funciona normalmente sobre un puerto TCP/IP. OBEX, en cambio,
es comúnmente implementado sobre una pila IrLAP/IrLMP/Tiny TP de un dispositivo
IrDA; mientras que funcionando con Bluetooth, OBEX se suele implementar sobre una
pila en Banda Base/Link Manager/L2CAP/RFCOMM. En cualquier caso, ofrece otras
posibilidades.
15
◦ Transmisiones binarias: HTTP utiliza texto legible por el ser humano, mientras que
OBEX utiliza tripletes binarios llamadas cabeceras (del inglés, headers) para intercambiar información sobre una petición o un objeto. Éstos, resultan más simples de elaborar
para dispositivos con características limitadas.
◦ Soporte para realizar sesiones: Las transacciones HTTP carecen inherentemente de estado. Generalmente, un cliente HTTP establece una conexión, efectúa una sola petición,
recibe respuesta y cierra la conexión. En OBEX, una sola conexión de transporte podría
utilizarse para efectuar varias operaciones relacionadas entre sí. De hecho, las últimas
novedades de la especificación OBEX permiten almacenar la información del estado de
una conexión intacta incluso si la conexión finalizó inesperadamente.
TCS (Telephony Control Specification) (TCS BIN o TCP): Esta especificación detalla cómo un
dispositivo con tecnología Bluetooth puede utilizarse como teléfono inalámbrico y el proceso
que debe seguir un móvil compatible para cambiar sus funciones al conectarse con una estación
base equipada con esta tecnología. Es un protocolo que opera en bits y establece la señalización
de control para el establecimiento de llamadas de voz y datos en dispositivos con tecnología
Bluetooth. También muestra la señalización de control en grupos de dispositivos Bluetooth. El
protocolo TCP admite el establecimiento de llamadas de voz y datos en configuraciones punto a
punto y multipunto. Se basa en la norma Q.931 del ITU-T y se ejecuta directamente en la capa
L2CAP.
Las especificaciones de estándar Bluetooth se recogen en la tabla de la figura 2.2.
Tecnología
Banda de frecuencia
Modulación
Potencia del transmisor
Canales máximos
Velocidad de datos
Distancia máxima
Número de dispositivos
Consumo de potencia
Espectro Ensanchado por Salto de Frecuencia (FHSS)
2.4 GHz (Banda ISM)
GFSK
1 mW para un enlace de 10 m
100 mW para un enlace de hasta 100 m
De voz: 3 por piconet
De datos: 7 por piconet
Hasta 721 Kbps por piconet
10 m
8 por piconet y hasta 10 piconets
Desde 30mA hasta 30mA transmitiendo
Cuadro 2.2: Características principales del estándar
2.2.5.
Canalización
La especificación distingue dos tipos de canales: físicos y lógicos. Los primeros hacen referencia
al modo en que se reparten los recursos del canal entre los dispositivos que forman parte de la red
(scatternet o piconet), mientras que los segundos son conexiones a nivel de protocolo que se emplean
para algún propósito específico.
Cada dispositivo Bluetooth está equipado con un microchip (transceiver ) que transmite y recibe
en la frecuenia de 2.45 GHz (2.402 GHz hasta 2.480 GHz, en saltos de 1 MHz) que esta disponible en
todo el mundo y que no require de ninguna licencia especial. En algunos países, entre ellos España,
Francia y Japón, esta banda está limitada a 23 canales en lugar de 79, también espaciados 1MHz. Ver
figura 2.3
16
Banda de guarda
Canal 0
Canal 1
Canal 2
...
...
Canal 77
Canal 78
Banda de guarda
Frecuencia (GHz)
2.400
2.402
2.403
2.404
...
...
2.479
2.480
2.481 GHz + 3.5 MHz
Cuadro 2.3: Canalización física
Cada canal se caracteriza por una secuencia pseudoaleatoria que define el modo en que se realizarán
los saltos en frecuencia. Esta secuencia es única para cada piconet y depende de la dirección del dispositivo maestro de la misma, mientras que la fase la determina el reloj del maestro. El canal queda
dividido, por tanto en slots temporales de 625 ms de duración, designados por un número del 0 a 227 -1
de acuerdo al reloj del dispositivo maestro de la piconet. En cada slot, tanto el maestro como los esclavos pueden transmitir información.
En cuanto a los canales lógico existen cinco diferente agrupados en dos categorías: control y usuario,
ver figura 2.4.
Canales de control
Canales de usuario
Acrónimo
LC
LM
UA
UI
US
Descripción
Link Control
Link Manager
User Asynchronous
User Isochronous
User Synchronous
Cuadro 2.4: Canales lógicos
2.3.
Tipos de enlace
En la comunicación entre un maestro y un esclavo se distinguen dos tipos de enlaces.
Enlaces SCO (Synchronous Connection-Oriented ): que proporcionan una comunicación punto a
punto entre el maestro y un único esclavo de la piconet. El maestro se encarga del mantenimiento
del enlace SCO y emplea para ello slots reservados a intervalos regulares de tiempo. Puesto que
se reservan slots para el enlace SCO, equivale a una conexión por conmutación de circuitos entre
el maestro y el esclavo en cuestión (por esta razón, es el que se emplea para comunicaciones de
voz). Un mismo maestro soporta tres enlaces SCO con el mismo maestro o dos enlaces SCO con
maestros diferentes. Al producirse una reserva de recursos, se supone que el enlace es fiable y no
se retransmiten los paquetes.
Enlaces ACL (Asynchronous ConnectionLess): en este caso, se trata de un enlace punto a multipunto entre el maestro y todos los esclavos que forman parte de la piconet. En los slots que
no estan reservados para enlaces SCO, el maestro puede establecer un enlace ACL por slot con
cualquier esclavo, incluidos aquellos con los que ya está enlazado a través del SCO. A diferencia
del SCO, el enlace ACL está orientado a conmutación de los paquetes intercambiados entre el
maestro y todos los esclavos activos de la piconet. Entre un maestro y un esclavo únicamente se
17
puede establecer un ACL. En este caso, para asegurar la integridad de la información se efectúan
retransmisiones de paquetes, si son necesarias.
2.4.
Formato del paquete
En cada piconet, la información se transmite fragmentada en paquetes. Cada paquete está formado
por tres bloques, el código de acceso, la cabecera y la carga útil, ver figura 2.7. El código de acceso y la
cabecera son de longitud fija (72 bits y 54 bits, respectivamente) mientras que el tamaño de la carga
útil puede variar hasta los 2745 bits.
Figura 2.7: Formato del paquete
El codigo de acceso es el mismo en cada piconet y se utiliza para distinguir los paquetes pertenecientes
a una piconet dada.
2.5.
Máquina de estados
El LC del dispositivo del dispositivo Bluetooth se caracteriza por una máquina de estados como la
de la figura 2.8, en la que se distinguen dos estados principales (STANDBY y CONNECTION) y siete
subestados (page, page scan, inquiry, inquiry scan, master response, slave response e inquiry response).
Los subestados son estados internos que se emplean para añadir esclavos a la piconet y las transiciones
de uno a otro se producen como consecuencia de comandos LMP o del envío y recepción de señales
internas.
18
Figura 2.8: Máquina de estados Bluetooth
El estado por defecto es STANDBY y en él , el dispositivo se encuentra en el modo de ahorro
de energía y únicamente el reloj nativo esta activo. El controlador dejará el estado STANDBY para
efectuar una búsqueda de dispositivos en la misma piconet y no volverá a él hasta que no pase al estado
CONNECTED como maestro o como esclavo.
2.6.
Aplicaciones. Perfiles en Bluetooth
Sobre la pila de protocolos de Bluetooth, se define una serie de perfiles que se tomarán como base
para implementar aplicaciones.
Un perfil Bluetooth es la especificación de un interfaz de alto nivel para su uso entre dispositivos
Bluetooth. Para utilizar una cierta tecnología Bluetooth un dispositivo deberá soportar ciertos perfiles.
Los perfiles son descripciones de comportamientos generales que los dispositivos pueden utilizar para
comunicarse, formalizados para favorecer un uso unificado. La forma de utilizar las capacidades de
Bluetooth se basa, por tanto, en los perfiles que soporta cada dispositivo. Los perfiles permiten la
manufactura de dispositivos que se adapten a sus necesidades.
Como mínimo, una especificación de perfil debe cubrir:
Dependencias con otros perfiles.
Formatos recomendados para la interfaz con el usuario.
Partes concretas de la pila Bluetooth que se utilizan (opciones particulares, parámetros). Puede
incluir una descripción del tipo de servicio requerido.
Algunos perfiles utilizados se puede ver en la figura 2.9. Las características de Bluetooth, la hacen
adecuada para las siguientes categorias de aplicaciones:
Conexión a otras redes como la red telefónica o una red LAN a través de otro dispositivo que
haga las veces de punto de acceso.
19
Conexión de periféricos a un PC y otras aplicaciones en las que se sustituya el cable por un
enlace inalámbrico (comunicación entre unos auriculares inalámbricos y un teléfono móvil, por
ejemplo).
Accesibilidad mutua entre dispositivos inalámbricos para, por ejemplo, transferencias de ficheros
y sincronizacion de información.
Figura 2.9: Perfiles Bluetooth
Los siguientes perfiles han sido definidos y adoptados por el SIG de Bluetooth. [4]
2.6.1.
Advanced Audio Distribution Profile (A2DP)
Distribución de audio avanzada. Define cómo se puede propagar un stream de audio (mono o estéreo) entre dispositivos a través de una conexión Bluetooth.
Inicialmente, se utilizaba en conjunción con un transceptor intermedio conectado al jack de salida
de audio por defecto, que realizaba la conversión y transmisión. Actualmente, hay dispositivos Bluetooth 2.0 que soportan esta conexión sin esta necesidad. Éstos suelen soportar también AVRCP, HSP
y HFP.
A2DP puede transmitir un stream estéreo en dos canales a una radio o unos auriculares. Este
perfil utiliza AVDTP y GAVDP. Incluye soporte obligatorio para codecs sub-band de baja complejidad
(SBC) y soporte opcional de MPEG-1, MPEG-2, AAC y ATRAC, junto con codecs definidos por el
fabricante. La mayoría de pilas implementan DRM (en concreto, el mecanismo SCMS-T). En estos
casos no pueden conectarse unos auriculares para recibir audio de alta calidad. Por ejemplo, Motorola
HT820 sólo puede hacer esto con ciertas versiones de pila Toshiba.
2.6.2.
Audio/Video Remote Control Profile (AVRCP)
Control remoto de audio/video. Diseñado para ofrecer un interfaz estándar para el control de televisores y aparatos de música entre otros, de forma que un mando único pueda agrupar todo el control.
20
Puede usarse junto con A2DP o VDP.
También permite extensiones específicas del fabricante. Su versión 1.3 permite transmitir información del estado de la fuente, por ejemplo el título de una canción.
2.6.3.
Basic Imaging Profile (BIP)
Tratamiento básico de imágenes. Diseñado para enviar imágenes, incluye capacidades de ajuste de
tamaño y conversión a formatos adecuados. También puede dividir una imagen en trozos más pequeños:
Image Push permite el envío de imágenes.
Image Pull permite la recepción de imágenes.
Advanced Image Printing sirve para imprimir imágenes con opciones avanzadas utilizando el
formato DPOF.
Automatic Archive habilita backups automáticos de todas las imágenes nuevas de un dispositivo.
Por ejemplo, un portátil puede descargar las imágenes que ha tomado una cámara desde la última
conexión.
Remote Camera permite el uso remoto de una cámara digital.
Remote Display permite enviar imágenes a otro dispositivo para su visualización (por ejemplo,
una presentación a un proyector).
2.6.4.
Basic Printing Profile (BPP)
Impresión básica. Permite el envío de texto, e-mails y otros documentos a impresoras en base a
trabajos de impresión. Es distinto a HCRP en que no requiere drivers específicos de impresora, lo que
lo hace más apto para dispositivos móviles como cámaras y teléfonos, que no pueden actualizar drivers
con sencillez.
2.6.5.
Common ISDN Access Profile (CIP)
Acceso común a ISDN. Provee acceso ilimitado a los servicios de ISDN.
2.6.6.
Cordless Telephony Profile (CTP)
Telefonía sin cables. Permite que los teléfonos inalámbricos utilicen Bluetooth. Se espera que los
teléfonos puedan utilizarlo para comunicarse con la línea de teléfono dentro de una casa, y con la red
de telefonía móvil cuando no esté disponible (fuera de casa).
2.6.7.
Device ID Profile (DID)
Identificación de dispositivo. Permite a un dispositivo ofrecer identificación más allá de la clasificación en tipo de dispositivo de acuerdo con la versión, fabricante, producto y revisión de la especificación. Podría utilizarse para permitir a un ordenador conectarse a un dispositivo y descargar los
drivers necesarios. Sus capacidades son semejantes a las de la especificación de plug and play.
2.6.8.
Dial-Up Networking Profile (DUN)
Conexión a red por dial-up o línea conmutada. El caso de uso típico es el de un portátil accediendo
a Internet por medio de la línea de un teléfono móvil. Se basa en SPP y permite un funcionamiento
razonablemente sencillo con productos existentes, en base a su similitud con los protocolos de línea
serie (serial line Internet protocol). Incluye entre otros el protocolo PPP.
21
2.6.9.
Fax Profile (FAX)
Fax. Busca ofrecer una interfaz bien definida entre un teléfono móvil o fijo y un ordenador con
software de fax. Debe darse soporte al comando AT definido en ITU T.31 o ITU T.32, definidos por
la ITU-T. No cubre llamadas de voz o datos.
2.6.10.
File Transfer Profile (FTP)
Transferencia de ficheros. Da acceso remoto a los sistemas de ficheros, permitiendo listados de
directorios y cambios a éstos, obtención, envío y borrado de ficheros. Se basa en GOEP y utiliza
OBEX como transporte.
2.6.11.
General Audio/Video Distribution Profile (GAVDP)
Distribución general de audio/video. Base de A2DP y VDP.
2.6.12.
Generic Access Profile (GAP)
Acceso genérico. Es la base para todos los demás perfiles.
2.6.13.
Generic Object Exchange Profile (GOEP)
Intercambio genérico de objetos. Sirve como base para otros perfiles de datos, y se basa a su vez
en OBEX.
2.6.14.
Hard Copy Cable Replacement Profile (HCRP)
Reemplazo de cables. Es una alternativa a una conexión cableada entre un dispositivo y una impresora, aunque no fija un estándar de comunicación con la impresora, por lo que necesita drivers
concretos para la impresora que se utiliza, lo que reduce su utilidad en dispositivos sencillos que no
suelan disponer de drivers.
2.6.15.
Hands-Free Profile (HFP)
Manos libres. Usado comúnmente para permitir la comunicación con teléfonos móviles dentro de
un coche. Utiliza SCO para transportar un canal de audio mono por medio de PCM. Su versión actual
es la 1.5. Es un perfil integrado desde hace tiempo en muchos automóviles de fábrica.
2.6.16.
Human Interface Device Profile (HID)
Dispositivo de interfaz humana. Da soporte a dispositivos tales como ratones, joysticks y teclados.
También puede utilizarse para indicadores luminosos o botones en otros tipos de dispositivos. Se ha
diseñado para ofrecer un enlace de baja latencia manteniendo bajo el consumo.
HID es un contenedor ligero del protocolo original definido para USB. Su uso simplifica la implementación del anfitrión (en concreto, el soporte de USB es reutilizable para Bluetooth en sistemas
operativos). Últimamente se ha utilizado en los mandos de las consolas Wii y PS3.
2.6.17.
Headset Profile (HSP)
Auriculares. Uno de los perfiles más comunes, que permiten el uso de los auriculares Bluetooth
(BT headsets) con los teléfono móviles. Utiliza SCO para transportar audio a 64 kbps codificado con
CVSD o PCM y un subconjunto de comandos AT de GSM 07.07 para dar facilidades sencillas como
tono, respuesta, colgado y ajuste de volumen.
22
2.6.18.
Intercom Profile (ICP)
Intercom (el “perfil del walkie-talkie”). Un perfil de control de teléfono [5] que utiliza SCO para el
transporte de audio. Propuesto para el transporte de llamadas entre dos dispositivos Bluetooth capaces
de ello.
2.6.19.
Object Push Profile (OPP)
Un perfil básico para el envío de “objetos” genéricos como fotos, tarjetas virtuales (Vcard) o citas.
Sigue el modelo push ya que el emisor es el que inicia siempre la comunicación.
Utiliza las API’s de OBEX para las operaciones de conexión y desconexión, envío, recepción y cancelación. Situándose por encima de OBEX sigue indirectamente la especificación de la pila Bluetooth.
2.6.20.
Personal Area Networking Profile (PAN)
Redes de área personal. Permite el uso del protocolo de encapsulación de Bluetooth en protocolos
de nivel de red sobre un enlace Bluetooth.
2.6.21.
Phone Book Access Profile (PBAP)
Acceso a agenda de teléfonos. Permite el envío de agendas telefónicas entre dispositivos. Puede
utilizarse, por ejemplo, para enviar desde un móvil a una pantalla (por ejemplo, de coche en un manos
libres) los datos de una llamada.
2.6.22.
Serial Port Profile (SPP)
Puerto serie. Basado en la especificación 07.10 de ETSI por medio del protocolo RFCOMM. Emula
una línea serie y provee un interfaz de reemplazo de comunicaciones basadas en RS-232, con las señales
de control típicas. Base de DUN, FAX, HSP y AVRCP.
2.6.23.
Service Discovery Profile (SDAP)
Descubrimiento de servicios.
2.6.24.
SIM Access Profile (SAP, SIM)
Acceso a SIM. Permite que los dispositivos compatibles con GSM como teléfonos puedan conectarse
a una tarjeta SIM de forma que un teléfono esclavo (como el de un coche) no necesite una tarjeta propia.
2.6.25.
Synchronisation Profile (SYNCH)
Sincronización. Se origina como parte de las especificaciones de infrarrojo pero ha sido seleccionado
para pasar a formar parte de la especificación principal. También conocido como IrMC Synchronization.
2.6.26.
Video Distribution Profile (VDP)
Distribución de vídeo. Habilita el transporte de un stream de vídeo. Puede usarse para distribuir
un vídeo grabado desde cualquier fuente a un reproductor o televisor. Debe soportar H.263, y opcionalmente MPEG-4 y los perfiles 3 y 8 de H.263.
2.6.27.
Wireless Application Protocol Bearer (WAPB)
Portador de protocolos de aplicación inalámbrica. Permite el transporte de WAP sobre PPP, a su
vez sobre Bluetooth.
23
2.6.28.
Perfiles adicionales
Los siguientes perfiles no están finalizados, pero sí propuestos por Bluetooth SIG.
2.6.28.1.
Unrestricted Digital Information (UDI).
Información digital no restringida.
2.6.28.2.
Extended Service Discovery Profile (ESDP)
Descubrimiento de servicios extendido.
2.6.28.3.
Video Conferencing Profile (VCP)
Videoconferencia. Previsto que sea compatible con 3G-324M y que trabaje sobre conexiones 3G.
2.6.28.4.
Message Access Profile (MAP)
Acceso a mensajes.
24
Capítulo 3
Seguridad en Bluetooth
3.1.
Modos de seguridad
Bluetooth define tres niveles de seguridad, que son:
Modo 1, no seguro: en este caso, no se emplea ningún mecanismo de seguridad permitiendo
conexiones desde cualquier dispositivo.
Modo 2, seguridad a nivel de servicio: el permiso se concede por servicio. Por ejemplo, un dispositivo puede conectarse a un PC para descargarse ficheros pero no para acceder a una libreta
de direcciones del PC.
Modo 3, seguridad a nivel del enlace: antes de establecer el canal de seguridad se usan los
siguientes procedimientos de seguridad:
• Uso de autentificación mediante PIN
◦ Generalmente de 4 dígitos, soportando hasta 16.
◦ Normalmente los productos tienen un PIN por defecto 0000.
◦ Posibilidad de generar un PIN de 6 dígitos en 12,5 segundos.
• Filtro por dirección de origen BD_ADDR.
• Cifrado mediante SAFER+.
3.2.
3.2.1.
Seguridad en la Conexión
Emparejamiento o “Paring”
El emparejamiento en Bluetooth es una relación de confianza. El objetivo es que dos dispositivos
se puedan comunicar si están emparejados, si hay una relación de confianza.
Cuando dos dispositivos intentan comunicarse tiene lugar el procedimientos de emparejamiento o
“paring”, este procedimiento permite crear una clave de enlace común de una forma segura. Este procedimiento requiere que el usuario de cada dispositivo introduzca un código de seguridad Bluetooth
(PIN), de hasta 16 bytes de longitud que debe ser el mismo en los dos casos.
A partir del código PIN se obtiene la clave de enlace común a través del siguiente algoritmo:
1. Se genera una clave de inicialización común Kinit de 128 bits usando el algoritmo E22 a partir del
PIN, la longitud del PIN, la dirección BD_ADDR de 48 bit y un número aleatorio IN_RAND.
Podemos ver un ejemplo en la figura 3.1.
25
CAPÍTULO 3. SEGURIDAD EN BLUETOOTH
Figura 3.1: Algoritmo E22
2. Se genera la clave de enlace Kab usando el algoritmo E21. Los dispositivos usan la clave Kinit
para intercambiar dos números aleatorios, conocidos como LK_RAND A y LK_RAND B. Estos números aleatorios son generados cada uno por uno de los dispositivos y se mandan al otro
dispositivo después de hacerles un XOR con Kinit . Como los dos dispositivos conocen Kinit cada
uno conoce ambas LK_RAND y a partir de las LK_RAND y BD_ADDR se genera Kab .
26
3. Una vez los dispositivos emparejados disponen de la clave de enlace Kab utilizan esta clave común
para autenticarse en las próximas conexiones.
3.2.2.
Autenticación
La autenticación es el proceso por el que un dispositivo Bluetooth verifica su identidad en otro
dispositivo para poder acceder a los servicios que ofrece.
Todas las funciones de nivel de enlace están basadas en el concepto de clave de enlace que es un
número pseudoaleatorio de 128 bits almacenado individualmente por cada dispositivo Bluetooth. La
autenticación se hace sin intervención del usuario y consiste en un esquema de desafío/respuesta entre
cada par de dispositivos con una clave secreta de 128 bits. Con esto podemos autentificar dispositivos
pero no usuarios.
Cuando se dispone de una clave de enlace entre dispositivos se usa para autenticarse en las siguientes
conexiones. El proceso de desafío respuesta tiene las siguientes fases:
1. Un dispositivo Reclamante transmite a un dispositivo Verificador su BD_ADDR.
2. El dispositivo Verificador generia AU_RAND (número aleatorio de 128 bits) y lo transmite al
Reclamante.
3. El Reclamante usa el algoritmo E1 para generar la respuesta de autenticación (SRES) de 32 bits,
usa la dirección BD_ADDR del Reclamante, la clave Kab almacenada y el desafío. El Verificador
por su parte hace lo mismo en paralelo.
4. El Reclamante devuelve la respuesta SRES al Verificador.
5. El Verificador comprueba que la respuesta SRES recibida por el reclamante es igual a la que ha
calculado él.
6. Si los valores del SRES coinciden el Verificador y Reclamante cambian los papeles y se repite el
proceso.
Vemos un resumen en la figura 3.3.
27
Figura 3.3: Proceso de autenticación
3.1.
En la siguiente tabla vemos las distintas entidades empleadas en el proceso de autenticación, tabla
Entidad
Dirección única del dispositivo, BD_ADDR
Clave privada de usuario para autenticación, Kab
Respuesta de autenticación, SRES
Número aleatorio, RAND
Tamaño
48 bits
128 bits
32 bits
128 bits
Cuadro 3.1: Entidades de autenticación en Bluetooth
En la especificación de Bluetooth y como medida de protección ante ataques de fuerza bruta, se
especifica que ante fallos de autenticación se debe esperar un tiempo, que aumenta de forma exponencial, entre intentos sucesivos.
3.2.3.
Autorización
La autorización es el procedimiento que determina los derechos de un dispositivo Bluetooth para
acceder a los servicios que ofrece un sistema.
El mecanismo de autorización en Bluetooth se lleva a cabo mediante niveles de confianza. Los
dispositivos tienen tres niveles de confianza que determinan la capacidad de acceso a los servicios:
Dispositivo de confianza, mantiene una relación de emparejamiento y dispone de acceso sin
restricciones a todos los servicios.
Dispositivo de confianza restringida, mantiene una relación de emparejamiento pero tiene acceso
restringido a uno o más servicios.
28
Dispositivo no confiable, es aquel que no mantiene una relación de emparejamiento. No se le
permite acceso a ningún servicio.
Si un dispositivo de confianza necesita acceder a un servicio autorizado no requiere ningún proceso de
confirmación, accede de forma transparente. En cambio si un dispositivo de confianza restringida o no
confiable intenta acceder a un servicio restringido se necesita una confirmación explícita por parte del
usuario, para permitir o denegar el acceso al dispositivo.
Para algunos servicios, como el caso del Perfil de Carga de Objetos (OBEX PUSH) es posible
conceder permisos de acceso temporal a dispositivos no emparejados previamente. En la mayoría de los
dispositivos es posible marcar los dispositivos conectados como dispositivos de confianza, así evitamos
la confirmación en cada intento de conexión.
3.2.4.
Cifrado de datos
El cifrado protege la información que se transmite en un enlace entre dispositivos Bluetooth, garantizando la confidencialidad del mensaje enviado. Si el paquete es capturado por un usuario al que no
va destinado, al no poseer la clave de descifrado el mensaje le resultará ininteligible.
La implementación del cifrado es opcional pero necesita que antes se haya producido una autenticación. Los dispositivos maestro y esclavo deben ponerse deacuerdo sobre si usar o no cifrado. Si se
quiere usar el cifrado, el maestro y el esclavo intercambian mensajes para determinar el tamaño de la
clave, si no consiguen un acuerdo se indica que no pueden usar cifrado en el enlace.
A continuación detallamos el proceso de cifrado:
El maestro genera una clave de cifrado KC de 128 bits usando el algoritmo E3, que vemos en la
figura 3.4. Este algoritmo necesita como entradas:
• Un número aleatorio de 128 bits
• La clave de enlace Kab generada durante el proceso de emparejamiento.
• El número Ciphering Offset (COF) de 96 bits basado en el valor temporal Authenticated
Ciphering Offset (ACO) calculado durante el procedimiento de autenticación.
Cuando la clave se ha generado con éxito, el maestro puede transmitir datos cifrado, para esto
el tráfico debe detenerse temporalmente en los niveles superiores a fin de evitar la recepción de
datos corruptos.
29
Hay que tener en cuenta que la clave de cifrado y la clave de autenticación son distintas y tienen
distintos propósitos. Cada vez que el cifrado se activa, se genera una nueva clave de cifrado cuyo
periodo de vida no se corresponde, necesariamente, con el de la clave de autenticación. De hecho, se
supone que la clave de autenticación tendrá un carácter más estático que la clave de cifrado.
3.3.
3.3.1.
Vulnerabilidades. Ataques a dispositivos Bluetooh
BlueSnarf
La vulnerabilidad Bluesnarf se basa en la implementación incorrecta en los primeros modelos
de teléfonos móviles Bluetooth del Perfil de Carga de Objetos (OBEX Object Push), que carecía
de mecanismos de autenticación y autorización, y que permitía descargarse mediante una operación
OBEX GET archivos de nombre conocido, como la agenda de contactos almacenada en el terminal en
telecom/pb.vcf o el calendario de citas almacenado en telecom/cal.vs.
Filename
Device info
telecom/devinfo.txt
telecom/rtc.txt
Phone Book
telecom/pb.vc
telecom/pb/luid/.vcf
telecom/pb/0.vcf
telecom/pb/info.log
telecom/pb/luid/###.log
telecom/pb/luid/cc.log
Calendar
telecom/cal.vcs
telecom/cal/luid/.vcs
telecom/cal/info.log
Description
Information hardware version, software
version, serial number , etc.
The real Time Clock Object contains the
current date and time of the device
Supported operations
GET
GET / PUT
Level 2 access (Access entire phonebook
database)
Add new entre
Own business card
Supported properties and memory info
Change log
Change counter
GET / PUT
Level 2 access
Add new entry
Supported properties and memory info
GET / PUT
PUT
GET
PUT
GET / PUT
GET
GET
GET
Cuadro 3.2: Especificación IrMC de los archivos OBEX. Fuente: Sony-Ericsson AT Commands Online
Referente (Developer Guidelines, Octubre 2004)
Hoy en día, la mayoría de teléfonos móviles Bluetooth incorporan únicamente mecanismos de autorización en el acceso al Perfil de Carga de Objetos (OBEX Object Push). Esto significa que el dispositivo
remoto debe estar incluido en la lista de dispositivos de confianza del teléfono móvil. En cualquier otro
caso, la conexión requerirá confirmación explícita por parte del usuario propietario del teléfono móvil.
A continuación se muestran el procedimiento para llevar a cabo un ataque Bluesnarf sobre un
teléfono móvil desde linux:
1. Detectar el teléfono móvil Bluetooth objetivo (vulnerable) y enumerar los perfiles que soporta.
Ver figuras 3.5 y 3.6.
2. Dado que los primeros modelos de teléfonos móviles Bluetooth no implementaban mecanismos
de autenticación y autorización en el acceso al Perfil de Carga de Objetos (OBEX Object Push),
un atacante podía extraer de forma transparente cualquier archivo disponible en el sistema de
ficheros del terminal con ayuda de cualquier aplicación que permitiera realizar operaciones OBEX
GET, como por ejemplo Obexftp.
30
Browsing 0 0 : 1A: 8 9 : 6 4 : 6 7 : 7 F . . .
S e r v i c e Name : Dial −up n e t w o r k i n g
S e r v i c e RecHandle : 0 x10026
S e r v i c e C l a s s ID L i s t :
" Dialup Networking " ( 0 x1103 )
" G e n e r i c Networking " ( 0 x1201 )
Protocol Descriptor List :
"L2CAP" ( 0 x0100 )
"RFCOMM" ( 0 x0003 )
Channel : 1
Language Base Attr L i s t :
code_ISO639 : 0 x656e
encoding :
0 x6a
b a s e _ o f f s e t : 0 x100
Profile Descriptor List :
" Dialup Networking " ( 0 x1103 )
V e r s i o n : 0 x0100
S e r v i c e Name : Voice Gateway
" H a n d s f r e e Audio Gateway" ( 0 x 1 1 1 f )
" G e n e r i c Audio " ( 0 x1203 )
"L2CAP" ( 0 x0100 )
"RFCOMM" ( 0 x0003 )
Channel : 13
encoding :
0 x6a
b a s e _ o f f s e t : 0 x100
" H a n d s f r e e " ( 0 x111e )
V e r s i o n : 0 x0105
Figura 3.5: Enumeración de los perfiles
31
S e r v i c e Name : Nokia PC S u i t e
" S e r i a l Port " ( 0 x1101 )
"L2CAP" ( 0 x0100 )
"RFCOMM" ( 0 x0003 )
Channel : 15
encoding :
0 x6a
b a s e _ o f f s e t : 0 x100
S e r v i c e Name : COM 1
" S e r i a l Port " ( 0 x1101 )
"L2CAP" ( 0 x0100 )
"RFCOMM" ( 0 x0003 )
Channel : 3
encoding :
0 x6a
b a s e _ o f f s e t : 0 x100
S e r v i c e Name : SIM ACCESS
"SIM A c c e s s " ( 0 x112d )
" G e n e r i c Telephony " ( 0 x1204 )
"L2CAP" ( 0 x0100 )
"RFCOMM" ( 0 x0003 )
Channel : 4
encoding :
0 x6a
b a s e _ o f f s e t : 0 x100
"SIM A c c e s s " ( 0 x112d )
V e r s i o n : 0 x0101
Figura 3.6: Continuación de la enumarción de los perfiles
3.3.2.
BlueBug
Bluebug es una vulnerabilidad que permite a un atacante establecer una conexión RFCOMM a
un canal oculto (no accesible por SDP) sin necesidad de autenticación y ejecutar comandos AT en el
terminal.
32
Como puede apreciarse en el esquema de la pila de protocolos Bluetooth ver figura 3.7, desde el
nivel RFCOMM se puede acceder a la capa de comandos AT. Esto significa que estableciendo una
conexión RFCOMM a un determinado canal, el atacante podría iniciar una sesión de comandos AT
con el teléfono móvil.
Figura 3.7: Pila de protocolos Bluetooth centrandose en el nivel RFCOMM
La posibilidad de ejecutar comandos AT en el teléfono móvil, permitiría a un atacante llevar a cabo
las siguientes acciones en el terminal comprometido:
Obtener información básica: Marca, modelo, IMEI,. . .
Realizar llamadas de voz, desvío de llamadas,. . .
Gestión de la agenda de contactos: Leer, escribir, borrar,. . .
Acceso a la agenda de llamadas: Últimas llamadas perdidas, recibidas o realizadas.
Gestión de mensajes SMS: Leer, escribir y enviar, borrar,. . .
Bluebug es, sin duda, una de las vulnerabilidades más peligrosas y con mayor impacto en usuarios de
teléfonos móviles Bluetooth, no sólo por la violación de privacidad que puede suponer el acceso ajeno
a la agenda de contactos o a mensajes SMS, sino por las consecuencias económicas que conlleva la
capacidad de efectuar llamadas telefónicas.
Una de las posibles soluciones a esta vulnerabilidad podría ser restringir el acceso a los comandos AT desde el interfaz Bluetooth. Sin embargo, los propios fabricantes desarrollan aplicaciones para
sincronizar un equipo PC con la agenda de contactos y la bandeja de entrada de mensajes SMS de
los teléfonos móviles. Un ejemplo de aplicación de este tipo es Nokia PC Suite. Así mismo, algunos
dispositivos Bluetooth, como los Manos Libres, requieren el control del teléfono móvil para poder colgar, descolgar e iniciar llamadas telefónicas, para lo cual requieren el uso de los comandos AT. La
solución adoptada por los fabricantes para proteger la vulnerabilidad Bluebug en los teléfonos móviles
consiste en añadir mecanismos de autenticación y autorización antes de permitir el establecimiento de
una conexión RFCOMM. De esta forma, se necesita la intervención del usuario propietario del teléfono
móvil y resulta imposible llevar a cabo un ataque de forma transparente.
33
Puesto que los teléfonos móviles actuales también implementan el juego de comandos AT, es posible
emular el ataque Bluebug estableciendo una conexión RFCOMM al teléfono móvil e iniciando una sesión
de comandos AT. Ver figura 3.8.
Figura 3.8: Comparación de modelos antiguos y modernos
1. Detectar el teléfono móvil Bluetooth objetivo (vulnerable o no) y enumerar los perfiles que
soporta. Ver figura 3.9.
2. El siguiente paso es establecer una conexión RFCOMM al canal 4. Ver figura 3.10.
3. Desde otra ventana de shell, hay que lanzar la herramienta cu, que está integrada en el paquete
Taylor UUCP y puede obtenerse en internet [7], Ver figura 3.11.
34
Figura 3.9: Vulnerabilidad con Bluebug
Figura 3.10: Vulnerabilidad Bluebug II
35
Figura 3.11: Vulnerabilidad Bluebug
Cu permite conectar con el teléfono móvil a través del interfaz rfcomm0 ya establecido e iniciar
una sesión de comandos AT. Es necesario especificar la velocidad (en bits por segundo) que utilizará
la conexión.
Como muestra la captura, se han ejecutado los siguientes comandos AT en el terminal móvil:
AT: Comando unitario para comprobar la comunicación.
AT+CGMI: Petición de identificación del fabricante (marca).
AT+CGMM: Petición de identificación del modelo de teléfono.
AT+CPBR=1: Leer la entrada 1 de la agenda de contactos.
AT+CPBS=“MC”;+CPBR=1: Seleccionar el dispositivo de memoria de llamadas perdidas (MC,
Missed Call List) y leer la entrada 1.
AT+CPBS=“DC”;+CPBR=1: Seleccionar el dispositivo de memoria de llamadas realizadas (DC,
Dialled Call List) y leer la entrada 1.
ATD679000000; :Realizar una llamada de voz a un número.
36
3.3.3.
Hello Moto
El ataque HeloMoto sólo afecta a teléfonos móviles Motorola.
La vulnerabilidad que explota HelloMoto se basa en una implementación incorrecta de la gestión
de la lista de dispositivos de confianza en los siguientes modelos Motorola: V80, v500 y v600.
El ataque se desarrolla del siguiente modo: El atacante inicia una conexión al Perfil de Carga de
Objetos (OBEX Push Object) con la intención de enviar una tarjeta de visita o vCard. De forma
automática y sin necesidad de interacción por parte del usuario propietario del teléfono móvil, el dispositivo atacante es añadido a la lista de dispositivos de confianza del terminal, aunque el proceso de
envío haya sido interrumpido por el atacante antes de llegar a su fin. Con el dispositivo incluido en la
lista de dispositivos de confianza del teléfono móvil, el atacante puede acceder a perfiles que requieran
autorización pero no autenticación, como el caso del Perfil de Pasarela de Voz (Voice Gateway Profile).
Una vez establecida la conexión con el Perfil de Pasarela de Audio, el atacante puede acceder a la
ejecución de comandos AT en el teléfono móvil comprometido.
Para poder llevar a cabo el ataque HelloMoto, existe una herramienta desarrollada en BlueZ que
se puede obtener en internet[6].
37
Capítulo 4
Ejemplos y Casos de uso práctico
4.1.
Ejemplo con un móvil. Aplicación Java para bluetooth
Programas que se han estudiados:
Psiloc_BlueText_S603rd.exe En el trabajo, muchos usamos el PC el 90 % del tiempo, y cuando
suena el móvil, pues esto nos hace desviar la atención, incluso hemos de salir del despacho para
coger la llamada sin molestar. Para que esto no vuelva a pasar, lo mejor es poner el modo
reunión, es decir silencio, y usar BlueText para poder recibir y responder a los mensajes de texto
desde el Escritorio del PC con Windows. Para ello necesitarás activar el Bluetooth de tu móvil
y descargar BlueText para que inicie la instalación del programa en tu PC. A partir de este
momento, recibirás avisos cuando te entre un mensaje de texto, podrás verlo y responderlo desde
el PC, sin perder tiempo ni desviarte de tu trabajo.
Easy_Jack_v2.0_By_Rock_ADS Envio de mensajes via bluetooth.
Otras aplicaciones bluetooth que se encuentran en el CD junto a la memoria.
4.2.
4.2.1.
Sniffer para Bluetooh
Introducción
Un atacante puede tener acceso al tráfico intercambiado en una piconet si dispone de la tabla que
contiene la secuencia o patrón de saltos de frecuencia que utilizan los dispositivos pertenecientes a esa
piconet. Para obtener esta tabla, únicamente necesita estar presente en el momento en el que la piconet
se establece entre maestro y esclavos y recibir el paquete FHS (Frequency Hop Synchronization) que
permite sincronizar su reloj interno con el reloj del maestro y también generar el patrón de saltos de
frecuencia que sigue dicha piconet. A partir de entonces, formará parte de la piconet y podrá sniffar el
tráfico, como en la figura 4.1.
38
CAPÍTULO 4. EJEMPLOS Y CASOS DE USO PRÁCTICO
Figura 4.1: Escenario atacante hacia una piconet
En Octubre de 2002 FTE desarrolló el primer analizador del protocolo Bluetooth comercial, FTS4BT,
un sniffer dotado de una tecnología muy avanzada cuyo precio rondaba los miles de $. Durante varios
años, fue la única herramienta capaz de sniffar tráfico Bluetooth.
En 2007 Max Moser publicó en su paper Busting The Bluetooth® Myth – Getting RAW Access
un procedimiento para construir un sniffer Bluetooth a partir de un adaptador Bluetooth convencional.
Básicamente, consiguió instalar en un adaptador convencional el firmware de un sniffer comercial y
obtener con éxito la parte hardware de un sniffer Bluetooth.
En el mismo año, Andrea Bittau y Dominic Spill publicaron el paper BlueSniff: Eve meets Alice and
Bluetooth, en el que demostraron que es posible determinar los parámetros necesarios para calcular
la secuencia de saltos de frecuencia y obtener un mecanismo para sniffar Bluetooth. Posteriormente,
Andrea Bittau publicó BTSniff, una implementación práctica para enviar comandos a un hardware
sniffer y sincronizarlo con los dispositivos de una piconet.
4.2.2.
Herramientas software necesarias
Vamos a hablar sobre BlueZ. Las herramientas de este proyecto nos permite interactuar con equipos
remotos bluetooth con líneas de comandos.
Herramientas:
Bluez-pin: Gestión de suministro del PIN para conectarnos con otros dispositivos.
Hciattach: Configuración de dispositivos serial UART (Universal Asynchronous Receiver/Transmitter) como interfaces HCI Bluetooth.
Hciconfig: Configuración de dispositivos Bluetooth locales.
Hcid: Demonio interfaz HCI.
Hcidump: Sniffer local de tráfico HCI que entra y sale por el dispositivo Bluetooth instalado en
el sistema.
Hcitool: Gestión del enlace con otros dispositivos Bluetooth, detección de dispositivos remotos,
resolución de nombres, identificación de clases, etc.
L2ping: Envío de solicitudes echo request (pings) a nivel L2CAP.
Pand: Gestión de conexiones PAN (Personal Area Network)
Rfcomm: Gestión de conexiones RFCOMM
39
Sdpd: Demonio del protocolo de descubrimiento de servicios SDP. Se encarga de proporcionar
acceso a los servicios Bluetooth locales.
Sdptool: Gestión de SDP (Service Discovery Protocol), descubrimiento de servicios Bluetooth en
dispositivos remotos.
La mayoría de las herramientas mencionadas se encuentran instaladas por defecto en aquellas distribuciones Linux que incorporan el núcleo de BlueZ. Sin embargo, también es posible obtener las
herramientas y librerías necesarias para el funcionamiento de BlueZ por medio de módulos del núcleo
BlueZ. Estos módulos se encuentran disponibles en internet[8] y son los siguientes:
bluez-libs-x.x.tar.gz (Librerías básicas Bluetooth)
bluez-libs-devel-x.x.tar.gz (Librerías de desarrollo Bluetooth)
bluez-utils-x.x.tar.gz (Herramientas Bluetooth)
bluez-firmware-x.x.tar.gz (Actualización de firmware)
bluez-hcidump-x.x.tar.gz (Sniffer local de tráfico HCI)
Tambien hará falta Bluetooth File Transfer (OBEX FTP) funciona con casi todos los modelos de
móviles actuales con conexión Bluetooth, puesto que soportan el protocolo de comunicaciones OBEX
(OBject EXchange o intercambio de datos).
Plataformas:
Intel and AMD x86
AMD64 and EM64T (x86-64)
SUN SPARC 32/64bit * PowerPC 32/64bit
Intel StrongARM and XScale
Hitachi/Renesas SH processors
Motorola DragonBall
Distribuciones:
Debian.
Ubuntu.
Fedora.
OpenSuSE.
Mandrake.
Dicho proyecto ganó en el año 2.005 el TuxMobil GNU/Linux Award. Para saber si teneis el paquete
en el repositorio de la distribución, tan sólo hay que abrir una línea de comandos y teclear lo siguiente:
# sudo aptitude search bluez
# sudo apt - get install obexftp
40
4.2.3.
4.2.3.1.
Comandos útiles
Interfaz Bluetooth
Con hciconfig -a examinamos la interfaz de nuestro adaptador Bluetooth.
# sudo hciconfig -a hci0
hci0 :
Type : USB
BD Address : 00:1 E :37:69: C0 :6 D
ACL MTU : 1017:8 SCO MTU : 64:8
UP RUNNING PSCAN
RX bytes :2545 acl :0 sco :0 events :69 errors :0
TX bytes :429 acl :0 sco :0 commands :33 errors :0
Features : 0 xff 0 xff 0 x8f 0 xfe 0 x9b 0 xf9 0 x00 0 x80
Packet type : DM1 DM3 DM5 DH1 DH3 DH5 HV1 HV2 HV3
Link policy : RSWITCH HOLD SNIFF PARK
Link mode : SLAVE ACCEPT
Name : ’ portatil -0 ’
Class : 0 x4a010c
Service Classes : Networking , Capturing , Telephony
Device Class : Computer , Laptop
HCI Ver : 2.0 (0 x3 ) HCI Rev : 0 x2129 LMP Ver : 2.0 (0 x3 )
LMP Subver : 0 x41cf
Manufacturer : Broadcom Corporation (15)
4.2.3.2.
Lista de dispositivos. Escaner
Con hcitool scan podemos obtener una lista de dispositivos presentes en el alredor. Por ejemplo:
# sudo hcitool scan
Scanning ...
60: D0 : A9 :4 D :99:4 F
00:1 A :89:64:67:7 F
4.2.3.3.
n/a
Miguel Ángel
Sniffer de tráfico de datos
El comando para extraer información entre una comunicación Bluetooth es hcidump, en el siguiente
recuadro podemos observar como se extrae la información de un envio de datos de un dispositivo a
otro:
# sudo hcidump
HCI sniffer - Bluetooth packet analyzer ver 1.42
device : hci0 snap_len : 1028 filter : 0 xffffffff
< HCI Command : Periodic Inquiry Mode (0 x01 |0 x0003 ) plen 9
> HCI Event : Command Complete (0 x0e ) plen 4
41
>
>
>
>
>
<
>
>
<
>
>
<
>
>
<
>
>
>
<
>
>
<
>
<
<
>
>
>
<
>
HCI Event : Inquiry Result with RSSI (0 x22 ) plen 15
HCI Command : Exit Periodic Inquiry Mode (0 x01 |0 x0004 ) plen 0
HCI Event : Command Complete (0 x0e ) plen 4
HCI Event : Command Complete (0 x0e ) plen 4
HCI Command : Create Connection (0 x01 |0 x0005 ) plen 13
HCI Event : Command Status (0 x0f ) plen 4
HCI Event : Connect Complete (0 x03 ) plen 11
HCI Command : Read Remote Supported Features (0 x01 |0 x001b ) plen 2
HCI Event : Read Remote Supported Features (0 x0b ) plen 11
ACL data : handle 11 flags 0 x02 dlen 10
L2CAP ( s ): Info req : type 2
HCI Event : Page Scan Repetition Mode Change (0 x20 ) plen 7
HCI Event : Max Slots Change (0 x1b ) plen 3
L2CAP ( s ): Info rsp : type 2 result 0
Extended feature mask 0 x0000
L2CAP ( s ): Connect req : psm 1 scid 0 x0040
HCI Event : Number of Completed Packets (0 x13 ) plen 5
L2CAP ( s ): Connect rsp : dcid 0 x0040 scid 0 x0040 result 0 status 0
Connection successful
L2CAP ( s ): Config req : dcid 0 x0040 flags 0 x00 clen 0
MTU 65535
L2CAP ( s ): Config rsp : scid 0 x0040 flags 0 x00 result 0 clen 4
MTU 65535
HCI Command : Remote Name Request (0 x01 |0 x0019 ) plen 10
Success
L2CAP ( d ): cid 0 x0040 len 20 [ psm 1]
SDP SSA Req : tid 0 x0 len 0 xf
pat uuid -16 0 x1105 ( OBEXObjPush )
max 65535
aid ( s ) 0 x0000 - 0 xffff
cont 00
42
<
>
<
>
<
>
<
>
<
SDP SSA Rsp : tid 0 x0 len 0 x6e
count 107
record #0
aid 0 x0000 ( SrvRecHndl )
uint 0 x1000b
aid 0 x0001 ( SrvClassIDList )
< uuid -16 0 x1105 ( OBEXObjPush ) >
aid 0 x0004 ( ProtocolDescList )
< < uuid -16 0 x0100 ( L2CAP ) > <
uuid -16 0 x0003 ( RFCOMM ) uint 0 x9 > <
uuid -16 0 x0008 ( OBEX ) > >
aid 0 x0005 ( BrwGrpList )
< uuid -16 0 x1002 ( PubBrwsGrp ) >
aid 0 x0006 ( LangBaseAttrIDList )
< uint 0 x656e uint 0 x6a uint 0 x100 >
aid 0 x0009 ( BTProfileDescList )
< < uuid -16 0 x1105 ( OBEXObjPush ) uint 0 x100 > >
aid 0 x0100 ( SrvName )
str " OBEX Object Push "
aid 0 x0303 ( SuppFormatsList )
< uint 0 xff >
cont 00
L2CAP ( s ): Connect req : psm 3 scid 0 x0041
L2CAP ( s ): Connect rsp : dcid 0 x0041 scid 0 x0041 result 0 status 0
Connection successful
MTU 1013
MTU 32772
MTU 32772
MTU 1013
RFCOMM ( s ): SABM : cr 1 dlci 0 pf 1 ilen 0 fcs 0 x1c
RFCOMM ( s ): UA : cr 1 dlci 0 pf 1 ilen 0 fcs 0 xd7
RFCOMM ( s ): PN CMD : cr 1 dlci 0 pf 0 ilen 10 fcs 0 x70 mcc_len 8
dlci 18 frame_type 0 credit_flow 15 pri 7 ack_timer 0
frame_size 1008 max_retrans 0 credits 7
43
> HCI Event : Remote Name Req Complete (0 x07 ) plen 255
> ACL data : handle 11 flags 0 x02 dlen 18
RFCOMM ( s ): PN RSP : cr 0 dlci 0 pf 0 ilen 10 fcs 0 xaa mcc_len
dlci 18 frame_type 0 credit_flow 14 pri 7 ack_timer 0
frame_size 1008 max_retrans 0 credits 0
< ACL data : handle 11 flags 0 x02 dlen 8
RFCOMM ( s ): SABM : cr 1 dlci 18 pf 1 ilen 0 fcs 0 x32
> HCI Event : Number of Completed Packets (0 x13 ) plen 5
RFCOMM ( s ): UA : cr 1 dlci 18 pf 1 ilen 0 fcs 0 xf9
RFCOMM ( s ): MSC CMD : cr 0 dlci 0 pf 0 ilen 4 fcs 0 xaa mcc_len
dlci 18 fc 0 rtc 1 rtr 1 ic 0 dv 0 b1 0 b2 0 b3 0 len 0
RFCOMM ( s ): MSC CMD : cr 1 dlci 0 pf 0 ilen 4 fcs 0 x70 mcc_len
RFCOMM ( s ): MSC RSP : cr 1 dlci 0 pf 0 ilen 4 fcs 0 x70 mcc_len
L2CAP ( s ): Disconn req : dcid 0 x0040 scid 0 x0040
RFCOMM ( d ): UIH : cr 0 dlci 18 pf 1 ilen 0 fcs 0 x8 credits 9
RFCOMM ( s ): MSC RSP : cr 0 dlci 0 pf 0 ilen 4 fcs 0 xaa mcc_len
RFCOMM ( d ): UIH : cr 1 dlci 18 pf 1 ilen 0 fcs 0 xd2 credits 33
RFCOMM ( d ): UIH : cr 1 dlci 18 pf 0 ilen 7 fcs 0 xce
OBEX : Connect cmd ( f ): len 7 version 1.0 flags 0 mtu 32767
L2CAP ( s ): Disconn rsp : dcid 0 x0040 scid 0 x0040
8
2
2
2
2
44
>
>
>
<
>
>
>
>
>
>
<
>
>
>
OBEX : Connect rsp ( f ): status 200 len 7 version 1.0 flags 0 mtu 32767
RFCOMM ( d ): UIH : cr 0 dlci 18 pf 0 ilen 0 fcs 0 x14
OBEX : Put cmd ( f ): len 54
Name (0 x01 ) = Unicode length 16
Time (0 x44 ) = Sequence length 16
Length (0 xc3 ) = 5
End of Body (0 x49 ) = Sequence length 5
OBEX : Put rsp ( f ): status 200 len 3
OBEX : Disconnect cmd ( f ): len 3
45
RFCOMM ( s ): DISC : cr 1 dlci 18 pf 1 ilen 0 fcs 0 xd3
RFCOMM ( s ): UA : cr 1 dlci 18 pf 1 ilen 0 fcs 0 xf9
RFCOMM ( s ): DISC : cr 1 dlci 0 pf 1 ilen 0 fcs 0 xfd
L2CAP ( s ): Disconn req : dcid 0 x0041 scid 0 x0041
RFCOMM ( s ): UA : cr 1 dlci 0 pf 1 ilen 0 fcs 0 xd7
L2CAP ( s ): Disconn rsp : dcid 0 x0041 scid 0 x0041
< HCI Command : Disconnect (0 x01 |0 x0006 ) plen 3
> HCI Event : Command Status (0 x0f ) plen 4
> HCI Event : Disconn Complete (0 x05 ) plen 4
4.2.3.4.
Descubrimientos de servicio
Para el descubrimiento de servicio utilizamos sdptool :
# sudo sdptool
sdptool - SDP tool v4 .51
Usage :
sdptool [ options ] < command > [ command parameters ]
Options :
-h
Display help
-i
Specify source interface
Commands :
search
Search for a service
browse
Browse all available services
records
Request all records
add
Add local service
del
Delete local service
get
Get local service
setattr
Set / Add attribute to a SDP record
setseq
Set / Add attribute sequence to a SDP record
Services :
DID SP DUN LAN FAX OPUSH FTP PRINT HS HSAG HF HFAG SAP PBAP NAP
GN PANU HCRP HID KEYB WIIMOTE CIP CTP A2SRC A2SNK AVRCT AVRTG
UDIUE UDITE SEMCHLA SR1 SYNCML SYNCMLSERV ACTIVESYNC HOTSYNC
PALMOS NOKID PCSUITE NFTP NSYNCML NGAGE APPLE ISYNC
46
vemos un ejemplo:
# sudo sdptool browse 00:1 A :89:64:67:7 F
Browsing 00:1 A :89:64:67:7 F ...
Service Name : Dial - up networking
Service RecHandle : 0 x10026
Service Class ID List :
" Dialup Networking " (0 x1103 )
" Generic Networking " (0 x1201 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 1
Language Base Attr List :
encoding :
0 x6a
base_offset : 0 x100
" Dialup Networking " (0 x1103 )
Version : 0 x0100
Service Name : Nokia PC Suite
" Serial Port " (0 x1101 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 15
encoding :
0 x6a
Service Name : COM 1
" Serial Port " (0 x1101 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 3
encoding :
0 x6a
47
Service Name : Voice Gateway
" Handsfree Audio Gateway " (0 x111f )
" Generic Audio " (0 x1203 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 13
encoding :
0 x6a
" Handsfree " (0 x111e )
Version : 0 x0105
Service Name : Audio Gateway
Service RecHandle : 0 x1002a
" Headset Audio Gateway " (0 x1112 )
" Generic Audio " (0 x1203 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 12
encoding :
0 x6a
" Headset " (0 x1108 )
Version : 0 x0100
Service Name : OBEX Object Push
" OBEX Object Push " (0 x1105 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 9
" OBEX " (0 x0008 )
encoding :
0 x6a
" OBEX Object Push " (0 x1105 )
Version : 0 x0100
48
Service Name : OBEX File Transfer
" OBEX File Transfer " (0 x1106 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 10
" OBEX " (0 x0008 )
encoding :
0 x6a
" OBEX File Transfer " (0 x1106 )
Version : 0 x0100
Service Name : SyncML Client
UUID 128: 00000002 -0000 -1000 -8000 -0002 ee000002
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 11
" OBEX " (0 x0008 )
encoding :
0 x6a
Service Name : Music - Player
Service Provider : Nokia
" Audio Source " (0 x110a )
" L2CAP " (0 x0100 )
PSM : 25
" AVDTP " (0 x0019 )
uint16 : 0 x100
encoding :
0 x6a
" Advanced Audio " (0 x110d )
Version : 0 x0100
49
Service Name : Media Player
" AV Remote Target " (0 x110c )
" L2CAP " (0 x0100 )
PSM : 23
" AVCTP " (0 x0017 )
uint16 : 0 x100
encoding :
0 x6a
" AV Remote " (0 x110e )
Version : 0 x0100
Service Name : Media Player
" L2CAP " (0 x0100 )
PSM : 23
" AVCTP " (0 x0017 )
uint16 : 0 x100
encoding :
0 x6a
Version : 0 x0100
Service Name : SIM ACCESS
" SIM Access " (0 x112d )
" Generic Telephony " (0 x1204 )
" L2CAP " (0 x0100 )
" RFCOMM " (0 x0003 )
Channel : 4
encoding :
0 x6a
50
" SIM Access " (0 x112d )
Version : 0 x0101
Esto proporciona toda la información que necesitamos acerca de todos los servicios presentes en el
dispositivo, en este caso el teléfono móvil.
4.2.4.
Contruir nuestro propio sniffer Bluetooth
Es posible construir nuestro propio sniffer Bluetooth a partir de un adaptador USB Bluetooth
convencional. Entre todas las cosas que podríamos hacer con un sniffer, resulta interesante poder sniffar durante el emparejamiento de dos dispositivos Bluetooth y obtener la clave de enlace que comparten.
El procedimiento para construir nuestro propio sniffer Bluetooth a partir de un adaptador USB
Bluetooth convencional está perfectamente documentado en Internet, por lo que esta será una sencilla
explicación práctica. El inconveniente es el adaptador Bluetooth que debe tener algunas características
especiales.
El adaptador Bluetooth necesita cumplir dos requerimientos para poder ser convertido en un sniffer
Bluetooth (pondremos unas capturas a modo de ejemplo):
1. Chipset Cambridge Silicon Radio (CSR). Ver figuras 4.2, 4.3
2. BC4 externo o flash. Los adaptadores Bluetooth con memoria ROM no sirven. Ver figura 4.4
a) El segundo adaptador (BC4 EXT) sirve, el primero (BC2 EXT) no es muy seguro de que
funcione. Se necesita conseguir las siguientes herramientas:
1) bccmd: permite modificar la configuración del firmware.
2) dfutool: permite flashear el adaptador y actualizar el firmware.
b) Se pueden obtener vía bluez-cvs, aquí se explica cómo:
# sudo apt - get install libbluetooth2 libbluetooth2 - dev
libusb -0.1 -4 libusb - dev
# cvs -d : pserver : anonymous@cvs . bluez . org :/ cvsroot / bluez login
# cvs -d : pserver : anonymous@cvs . bluez . org :/ cvsroot / bluez co utils
# cd utils / tools
# gcc - lusb - lbluetooth csr . c csr_3wire . c csr_bcsp . c csr_h4 . c
csr_hci . c csr_usb . c ubcsp . c bccmd . c -o bccmd
# gcc - lusb - lbluetooth csr . c dfutool . c -o dfutool
3. También hace falta descargarse[9] e instalar el paquete Frontline Test Equipment FTS4BT versión
<= 5.6.9.0, que contiene el firmware airsnifferdev4*bc4.dfu, que luego se utiliza para actualizar
el adaptador Bluetooth.
a) El procedimiento es simple. En primer lugar, la herramienta FTS4BT requiere cierta configuración para poder reconocer el adaptador como sniffer hardware. Hay que cambiar el id
de producto (debería ser 0x0002) y el id de fabricante (debería ser 0x0a12). Ver figura 4.5
51
4. Después, es recomendable hacer backup del firmware existente en el adaptador Bluetooth antes
de flashearlo y cargarle el firmware airsnifferdev4*bc4.dfu. Ver figuras 4.6, 4.7.
5. Si se utiliza el firmware airsnifferdev5*bc4.dfu el adaptador puede quedar inservible así que es
importante obtener la versión correcta de FTS4BT (la que contiene airsnifferdev4*bc4.dfu).
6. Tras haber realizado con éxito estas operaciones, se puede observar que el adaptador Bluetooth
se encuentra en modo RAW. Los bytes RX y TX deberían ir en aumento. Ver figura 4.8.
7. También se puede comprobar que funciona ejecutando frontline, que permite enviar comandos a
un sniffer hardware. El tiempo debería ir creciendo. Ver figura 4.9.
Figura 4.2: Adaptador Bluetooth que soporta el cambio de firmware
Figura 4.3: Chipset Cambridge Silicon Radio
Figura 4.4: Parámetros del adaptador Bluetooth
52
Figura 4.5: Configuración de la herramienta FTS4BT
Figura 4.6: Backup I
Figura 4.7: Backup II
53
Figura 4.8: Modo RAW
Figura 4.9: Comprobando que funciona bien ejecutando frontline
4.3.
Análisis de Intercambio de Tramas Bluetooth
En el siguiente cuadro se puede ver un análisis exhaustivo de las fases de una conexión y envío de
datos exitosa. Se ha marcado por colores cada fase de la conexión de ejemplo entre un ordenador y un
teléfono móvil.
54
55
56
57
Bibliografía
[1] Comunicaciones Inalámbricas. Autor David Roldán Martínez. Editorial Ra-Ma (2004) 621.396.7
ROL-3 1
[2] Página oficial sobre el SIG de Bluetoothhttp://bluetooth.com/Spanish/SIG/Pages/default.aspx
(document), 1.2.2.1
[3] Página oficial del estándar 802.15. http://www.ieee802.org/15/ 2, 3
[4] Perfiles Bluetooth de SIG: http://www.bluetooth.com/English/Technology/Works/Pages/Profiles_Overview.a
2.6
[5] Perfil de control del Teléfono.http://www.palowireless.com/infotooth/glossary.asp#SR 2.6.18
[6] Ataque Hello Moto.http://trifinite.org/Downloads/helomoto.tgz 3.3.3
[7] Herramienta cu, del paquete Taylor UUCP.http://www.airs.com/ian/uucp-doc/uucp.html 3
[8] Herramientas de BlueZ.http://www.bluez.org/download.html 4.2.2
[9] Firmware para sniffer Bluetooth.http://www.fte.com/ 3
[10] Funcionamiento de RFCOMM.http://authors.phptr.com/bluetooth/bray/pdf/cr_ch10.pdf 2.2.4
[11] Para la elaboración de este documento y su presentación se ha hecho uso de LYX y LATEX.
http://www.lyx.org
58

Trabajo Redes y Servcios de Radio

Transcripción

Documentos relacionados

Sistema profesional LAUNCH X-431 PRO

MINI ADAPTADOR USB PARA BLUETOOTH 4.0

mp4 con bluetooth