Seguridad en Bluetooth

1. Introducción.

El concepto de Bluetooth surge de la imperiosa necesidad de las grandes empresas de telecomunicaciones e informática, de desarrollar una interfaz abierta, que facilite la comunicación entre los diferentes equipos informáticos y telefónicos, aprovechando la capacidad y la movilidad de los dispositivos inalámbricos, para la total supresión de los cables de conexión, adoptando así un único estándar de conexión.

El Bluetooth Special Interest Group (SIG), una asociación comercial formada por líderes en telecomunicación, informática e industrias de red, es la encargada del desarrollo e introducción en el mercado de esta tecnología inalámbrica.

Los promotores de Bluetooth incluyen Agere, Ericsson, IBM, Intel, Microsoft, Motorola, Nokia y Toshiba, y centenares de compañías asociadas.

El nombre viene de Harald Bluetooth, un Vikingo y rey de Dinamarca a de los años 940 a 981, fue reconocido por su capacidad de ayudar a la gente a comunicarse. Durante su reinado unió Dinamarca y Noruega.

2.  Especificaciones BlueTooth.

2.1.  Tecnología.

Bluetooth se puede definir como una propuesta de especificación de radio frecuencia por transmisión de corto alcance de datos, pudiendo transmitir a través de objetos sólidos no metálicos.

Su alcance nominal es de 10 cm a 10 m “en teoría”, pero puede extenderse a 100 m mediante el incremento de transmisión de energía. Más tarde analizaremos lo del alcance.

Los ordenadores, teléfonos móviles, aparatos domésticos y equipos de oficina, basados en Bluetooth pueden conectarse entre sí dentro de áreas físicas reducidas, sin necesidad de utilizar cableado, de forma “segura” (también analizaremos esto) y barata y a altas velocidades de transmisión.
También se pretende ofrecer acceso a Internet.

La tecnología usa la banda ISM (Industrial Scientific Medicine) de los 2.4 GHz que no necesita licencia, está disponible en casi todo el mundo.
Bluetooth es además, un módulo radio de baja potencia, puede integrarse en una amplia variedad de dispositivos. Soporta transmisión de tres canales de voz, vídeo y datos a una velocidad máxima de 1 Mbps, aunque la máxima velocidad real girará alrededor de los 721 Kbps.

Ya se habla de su uso para todo, seguridad del hogar, dispositivos médicos, etc.

2.2.  Pila de Protocolos.

La especificación de Bluetooth pretende que todas las aplicaciones sean capaces de operar entre sí. Para conseguir esta interoperabilidad, las aplicaciones en dispositivos remotos deben ejecutarse sobre una pila de protocolos idénticos.

Para comunicarse con otros dispositivos Bluetooth, se requiere un hardware específico para Bluetooth, que incluye un módulo de banda base, así como otro módulo de radio y una antena.
Además deberá haber un software encargado de controlar la conexión entre dos dispositivos Bluetooth; este software (Link Manager) por lo general correrá en un microprocesador dedicado. Los Link Managers de diferentes dispositivos Bluetooth se comunicarán mediante el protocolo LMP (Link Manager Protocol).
Además habrá otros módulos de software, que constituirán la pila de protocolos, y garantizarán la interoperabilidad entre aplicaciones alojadas en diferentes dispositivos Bluetooth.


La pila completa se compone tanto de protocolos específicos de Bluetooth (LM (Link Manager) y L2CAP (Logical Link Control Adaption Protocol), por ejemplo) como de protocolos no específicos de Bluetooth como son OBEX (Objects Exchange Protocol), UDP (User Datagram Protocol), TCP, IP, etc. Debido a que la hora de diseñar la torre de protocolos, el objetivo principal ha sido maximizar el número de protocolos existentes que se puedan reutilizar en las capas más altas para diferentes propósitos.

A parte de todos estos protocolos, la especificación define el HCI (Host Controller Interface), que se encarga de proporcionar una interfaz de comandos al controlador BaseBand, al gestor de enlace, y nos da acceso al estado del hardware y a los registros de control.

2.3.  Descripción de los protocolos

2.3.1.  Link Manager (LM) y Link Manager Protocol (LMP).

2.3.1.1.  Link Manager.

El Link Manager es el sistema que consigue establecer la conexión entre dispositivos.
Se encarga del establecimiento, la autentificación y la configuración del enlace.

El Link Manager localiza a otros gestores y se comunica con ellos gracias al protocolo de gestión del enlace LMP.
Para poder realizar su función de proveedor de servicio, el LM utiliza los servicios incluidos en el controlador de enlace (LC, «Link Controller»).

El Link Manager Protocol básicamente consiste en un número de PDUs (Protocol Data Units) que son enviadas de un dispositivo a otro.

A continuación se enuncian los servicios soportados:

• Transmisión y recepción de datos.
• Petición de nombre: El gestor de enlace tiene un eficiente método para inquirir y reportar la ID de un dispositivo con una longitud de máximo 16 caracteres.
• Petición de las direcciones de enlace.
• Establecimiento de la conexión.
• Autentificación.
• Negociación del modo de enlace y establecimiento, por ejemplo, modo datos o modo voz/datos. Esto puede cambiarse durante la conexión.

2.3.1.2. Modos.

Establecimiento de un dispositivo al modo «sniff». En este modo se reduce el ciclo de trabajo de una estación esclava, ya que sólo escucha cada M slots, siendo el valor de M negociado con el gestor de enlace. La estación maestra puede sólo comenzar la transmisión en tiempos/slots específicos, separados estos por intervalos regulares.

Mantenimiento de un dispositivo de enlace en espera. En modo espera, el apagado del receptor durante períodos de tiempo más largos ahorra energía. Cualquier entidad puede volver a establecer un enlace, con una latencia media de 4 segundos. Esto es definido por el gestor de enlace y manejado por el controlador de enlace.

Establecimiento de un dispositivo en modo «aparcado»: Esto es útil cuando un dispositivo no necesita participar activamente en el canal, pero sí quiere permanecer sincronizado. En este modo dicha entidad «despierta» en intervalos regulares de tiempo para escuchar al canal y así poder re-sincronizarse con el resto de entidades de la piconet

2.3.2.  Interfaz de la Controladora de la Máquina (HCI).

La interfaz de la Controladora de la Máquina (Host Controller Interface) proporciona una interfaz de comandos para la controladora de banda base y para el gestor de enlace, y permite acceder al estado del hardware y a los registros de control.
Esta interfaz proporciona una capa de acceso homogénea para todos los dispositivos Bluetooth de banda base.
La capa HCI de la máquina intercambia comandos y datos con el firmware del HCI presente en el dispositivo Bluetooth. El driver de la capa de transporte de la controladora de la máquina (es decir, el driver del bus físico) proporciona ambas capas de HCI la posibilidad de intercambiar información entre ellas.

Una de las tareas más importantes de HCI que se deben realizar es el descubrimiento automático de otros dispositivos Bluetooth que se encuentren dentro del radio de cobertura. Esta operación se denomina en inglés inquiry (consulta). Tenga siempre presente que un dispositivo remoto sólo contesta a la consulta si se encuentra configurado en modo visible (discoverable mode).

% hccontrol -n ubt0hci inquiry
Inquiry result, num_responses=1
Inquiry result #0
BD_ADDR: 00:80:37:29:19:a4
Page Scan Rep. Mode: 0x1
Page Scan Period Mode: 00
Page Scan Mode: 00
Class: 52:02:04
Clock offset: 0x78ef
Inquiry complete. Status: No error [00]]

BD_ADDR es la dirección identificativa única del dispositivo Bluetooth, similar a las direcciones MAC de las tarjetas Ethernet. Esta dirección se necesita para transmitir otro tipo de información a otros dispositivos.

Si se realiza una consulta (inquiry) sobre el dispositivo Bluetooth remoto, dicho dispositivo identificará nuestro computador como «nombre.de.su.sistema (ubt0)». El nombre asignado al dispositivo local se puede modificar en cualquier momento.

El sistema Bluetooth proporciona una conexión punto a punto (con sólo dos unidades Bluetooth involucradas) o también una conexión punto multipunto. En el último caso, la conexión se comparte entre varios dispositivos Bluetooth.

2.3.3.  Protocolo de Adaptación y de Control de Enlace a nivel Lógico (L2CAP).

El protocolo L2CAP (Logical Link Control and Adaptation Protocol) proporciona servicios de datos tanto orientados a conexión como no orientados a conexión a los protocolos de las capas superiores, junto con facilidades de multiplexación y de segmentacion y reensamblaje.
L2CAP permite que los protocolos de capas superiores puedan transmitir y recibir paquetes de datos L2CAP de hasta 64 kilobytes de longitud.

L2CAP se basa en el concepto de canales. Un canal es una conexión lógica que se sitúa sobre la conexión de banda base. Cada canal se asocia a un único protocolo. Cada paquete L2CAP que se recibe a un canal se redirige al protocolo superior correspondiente. Varios canales pueden operar sobre la misma conexión de banda base, pero un canal no puede tener asociados más de un protocolo de alto nivel.

Una herramienta de diagnóstico interesante es btsockstat, para FreeBSD.
Realiza un trabajo similar al comando netstat, pero en este caso para las estructuras de datos relacionadas con el sistema Bluetooth. A continuación se muestra la información relativa a la misma conexión lógica del ejemplo anterior.

% btsockstat
Active L2CAP sockets
PCB      Recv-Q Send-Q Local address/PSM       Foreign address   CID   State
c2afe900      0      0 00:02:72:00:d4:1a/3     00:07:e0:00:0b:ca 66    OPEN
Active RFCOMM sessions
L2PCB    PCB      Flag MTU   Out-Q DLCs State
c2afe900 c2b53380 1    127   0     Yes  OPEN
Active RFCOMM sockets
PCB      Recv-Q Send-Q Local address     Foreign address   Chan DLCI State
c2e8bc80      0    250 00:02:72:00:d4:1a 00:07:e0:00:0b:ca 3    6    OPEN

2.3.4.  Protocolo RFCOMM.

El protocolo RFCOMM proporciona emulación de puertos serie a través del protocolo L2CAP. Este protocolo se basa en el estándar de la ETSI denominado TS 07.10. RFCOMM es un protocolo de transporte sencillo, con soporte para hasta 9 puertos serie RS-232 (EIATIA-232-E). El protocolo RFCOMM permite hasta 60 conexiones simultáneas (canales RFCOMM) entre dos dispositivos Bluetooth.

Para los propósitos de RFCOMM, un camino de comunicación involucra siempre a dos aplicaciones que se ejecutan en dos dispositivos distintos (los extremos de la comunicación). Entre ellos existe un segmento que los comunica. RFCOMM pretende cubrir aquellas aplicaciones que utilizan los puertos serie de las máquinas donde se ejecutan. El segmento de comunicación es un enlace Bluetooth desde un dispositivo al otro (conexión directa).

RFCOMM trata únicamente con la conexión de dispositivos directamente, y también con conexiones entre el dispositivo y el modem para realizar conexiones de red. RFCOMM puede soportar otras configuraciones, tales como módulos que se comunican via Bluetooth por un lado y que proporcionan una interfaz de red cableada por el otro.

2.3.5.  Protocolo de Descubrimiento de Servicios (SDP).

El Protocolo de Descubrimiento de Servicios (Service Discovery Protocol o SDP) permite a las aplicaciones cliente descubrir la existencia de diversos servicios proporcionados por uno o varios servidores de aplicaciones, junto con los atributos y propiedades de los servicios que se ofrecen.

Estos atributos de servicio incluyen el tipo o clase de servicio ofrecido y el mecanismo o la información necesaria para utilizar dichos servicios.

SDP se basa en una determinada comunicación entre un servidor SDP y un cliente SDP.

El servidor mantiene una lista de registros de servicios, los cuales describen las características de los servicios ofrecidos. Cada registro contiene información sobre un determinado servicio. Un cliente puede recuperar la información de un registro de servicio almacenado en un servidor SDP lanzando una petición SDP. Si el cliente o la aplicación asociada con el cliente decide utilizar un determinado servicio, debe establecer una conexión independiente con el servicio en cuestión. SDP proporciona un mecanismo para el descubrimiento de servicios y sus atributos asociados, pero no proporciona ningún mecanismo ni protocolo para utilizar dichos servicios.

Normalmente, un cliente SDP realiza una búsqueda de servicios acotada por determinadas características. No obstante hay momentos en los que resulta deseable descubrir todos los servicios ofrecidos por un servidor SDP sin que pueda existir ningún conocimiento previo sobre los registros que pueda contener. Este proceso de búsqueda de cualquier servicio ofrecido se denomina navegación o browsing.

El siguiente ejemplo muestra cómo realizar una consulta de navegación una consulta de navegación SDP mediante el servidor Bluetooth SDP denominado sdpd y el cliente de línea de comando denominado sdpcontrol se incluyen en la instalación estándar de FreeBSD.

% sdpcontrol -a 00:01:03:fc:6e:ec browse
Record Handle: 00000000
Service Class ID List:
Service Discovery Server (0x1000)
Protocol Descriptor List:
L2CAP (0x0100)
Protocol specific parameter #1: u/int/uuid16 1
Protocol specific parameter #2: u/int/uuid16 1

Record Handle: 0x00000001
Service Class ID List:
Browse Group Descriptor (0x1001)

Record Handle: 0x00000002
Service Class ID List:
LAN Access Using PPP (0x1102)
Protocol Descriptor List:
L2CAP (0x0100)
RFCOMM (0x0003)
Protocol specific parameter #1: u/int8/bool 1
Bluetooth Profile Descriptor List:
LAN Access Using PPP (0x1102) ver. 1.0

Resulta importante resaltar una vez más que cada servicio posee una lista de atributos (por ejemplo en el canal RFCOMM). Dependiendo de los servicios que se quieran utilizar puede resultar necesario anotar algunos de los atributos. Algunas implementaciones de Bluetooth no soportan navegación de servicios y pueden devolver una lista vacía. En este caso se puede intentar buscar algún servicio determinado. OBEX Object Push (OPUSH):

% sdpcontrol -a 00:01:03:fc:6e:ec search OPUSH

2.3.6.  Perfiles (Profiles)

Desde que se inició la especificación de este estándar, una de las principales preocupaciones del SIG fue garantizar la interoperabilidad total entre dispositivos de distintos fabricantes, siempre y cuando éstos compartan el mismo perfil.
Los perfiles especifican cómo utilizar la pila de protocolos de Bluetooth para implementar una solución que trabaje sin problemas con las de otras marcas. En cada uno se establecen opciones y parámetros, además de detallar cómo usar los distintos procedimientos de los diversos estándares que se encuentren implicados.

Podemos ver la estructura de perfiles de BlueTooth y su dependencia en el siguiente gráfico.

Los perfiles tienen dependencia de otro perfil si reutilizan partes de él. En el gráfico vemos como el perfil Object Push depende del Generic Object Exchange, de Serial Port y de Generic Access.

Han sido desarrollados más perfiles, y todo indica que se seguirán desarrollando otros nuevos.
En este tutorial comentaremos solo los dos siguientes, pero si alguien quiere profundizar en el tema, tiene más información en:http://www.palowireless.com/infotooth/tutorial/profiles.asp

2.3.6.1.  Acceso Telefónico a Redes (DUN) y Acceso a Redes mediante perfiles PPP (LAN).

El perfil de Acceso Telefónico a Redes (Dial-Up Networking o DUN) se utiliza mayoritariamente con modems y teléfonos celulares. Los escenarios cubiertos por este perfil se describen a continuación:

• Utilización de un teléfono celular o un modem por una computadora para simular un modem sin cables que se conecte a un servidor de acceso telefónico a redes o para otros servicios de acceso telefónico relacionados;
• Utilización de un teléfono celular o un modem por un computador para recibir llamadas de datos.

El Acceso a Redes con perfiles PPP (LAN) se puede utilizar en las siguientes situaciones:
• Acceso LAN para un único dispositivo Bluetooth;
• Acceso LAN para múltiples dispositivos Bluetooth;
• Conexión de PC a PC (utilizando emulación de PPP sobre una línea serie).

2.3.6.2.   Perfil OBEX Object Push (OPUSH).

OBEX es un protocolo muy utilizado para transferencias de ficheros sencillas entre dispositivos móviles. Su uso más importante se produce en comuncaciones por infrarrojos, donde se utiliza para transferencia de ficheros genéricos entre portátiles o dispositivos Palm y para enviar tarjetas de visita o entradas de la agenda entre teléfonos celulares y otros dispositivos con aplicaciones PIM.

El cliente OBEX se utiliza para introducir y para recuperar recuperar objetos del servidor OBEX. Un objeto puede por ejemplo ser una tarjeta de visita o una cita. El cliente OBEX puede obtener un número de canal RFCOMM del dispositivo remoto utilizando SDP. Esto se hace especificando el nombre del servicio en lugar del número de canal RFCOMM. Los nombres de servicios soportados son: IrMC, FTRN y OPUSH. Es posible especificar el canal RFCOMM como un número.

A continuación se muestra un ejemplo de una sesión OBEX donde el objeto que posee la información del dispositivo se recupera del teléfono celular y un nuevo objeto (la tarjeta de visita) se introduce en el directorio de dicho teléfono.

% obexapp -a 00:80:37:29:19:a4 -C IrMC
obex> get
get: remote file> telecom/devinfo.txt
get: local file> devinfo-t39.txt
Success, response: OK, Success (0x20)
obex> put
put: local file> new.vcf
put: remote file> new.vcf
Success, response: OK, Success (0x20)
obex> di
Success, response: OK, Success (0x20)

3. La Seguridad en Bluetooth

3.1. Descripción general

3.1.1. Modos de seguridad.

Hay tres modos primarios de seguridad.

Modo 1. Sin seguridad . Todos los mecanismos de seguridad (autenticación y cifrado) están deshabilitados. Además el dispositivo se situa en modo promiscuo, permitiendo que todos los dispositivos Bluetooth se conecten a él.

Modo 2. En la capa L2CAP, nivel de servicios . Los procedimientos de seguridad son inicializados después de establecerse un canal entre el nivel LM y el de L2CAP. Un gestor de seguridad controla el acceso a servicios y dispositivos. Variando las políticas de seguridad y los niveles de confianza se pueden gestionar los accesos de aplicaciones con diferentes requerimientos de seguridad que operen en paralelo.
Su interface es muy simple y no hay ninguna codificación adicional de PIN o claves.

Modo 3. En el nivel de Link. Todas las rutinas están dentro del chip BlueTooth y nada es transmitido en plano. Los procedimientos de seguridad son iniciados antes de establecer algún canal. Aparte del cifrado tiene autenticación PIN y seguridad MAC. Su metodología consiste en compartir una clave de enlace (clave de linkado) secreta entre un par de dispositivos. Para generar esta clave, se usa un procedimiento de “pairing” cuando los dos dispositivos se comunican por primera vez.

3.1.2. Emparejamiento de Dispositivos.

Por defecto, la comunicación Bluetooth no se valida, por lo que cualquier dispositivo puede en principio hablar con cualquier otro. Un dispositivo Bluetooth (por ejemplo un teléfono celular) puede solicitar autenticación para realizar un determinado servicio (por ejemplo para el servicio de marcación por modem).

La autenticación de Bluetooth normalmente se realiza utilizando códigos PIN. Un código PIN es una cadena ASCII de hasta 16 caracteres de longitud. Los usuarios deben introducir el mismo código PIN en ambos dispositivos.
Una vez que el usuario ha introducido el PIN adecuado ambos dispositivos generan una clave de enlace. Una vez generada, la clave se puede almacenar en el propio dispositivo o en un dispositivo de almacenamiento externo. La siguiente vez que se comuniquen ambos dispositivos se reutilizará la misma clave.

El procedimiento descrito hasta este punto se denomina emparejamiento (pairing). Es importante recordar que si la clave de enlace se pierde en alguno de los dispositivos involucrados se debe volver a ejecutar el procedimiento de emparejamiento.

No existe ninguna limitación en los códigos PIN a excepción de su longitud. Algunos dispositivos (por ejemplo los dispositivos de mano Bluetooth) pueden obligar a escribir un número predeterminado de caracteres para el código PIN.

3.1.3. Inicialización y Generación de la claves.

La Clave de Linkado es generada durante una fase de inicialización, cuando dos dispositivos empiezan a comunicarse. Según la especificación BlueTooth, la clave es generada durante la fase de inicialización cuando el usuario introduce un PIN idéntico en ambos dispositivos. Después de completarse la inicialización, los dispositivos se autentican de manera automática y transparente y se lleva a cabo el cifrado de la conexión.

Generación de claves en la Inicialización: En el siguiente esquema los algoritmos E21 y E22 son agrupados en uno genérico llamado E2.

El proceso de Inicialización se desarrolla según los siguientes pasos:

3.1.3.1 Generación de una clave de inicialización K init.

Aplicando el PIN del dispositivo y su longitud, el BD_ADDR (48 bits) y un número aleatorio de 128bits, IN_RAND al algoritmo E22 .

El resultado es una palabra de 128 bits, referida como K init .

Resaltamos que el PIN está disponible en ambos dispositivos BlueTooth, y que IN_RAND es transmitido en plano.

Respecto a BD_ADDR, si uno de los dispositivos tiene un PIN fijo, se usa la BD_ADDR del dispositivo asociado, y si ambos tienen un PIN variable, se usa el PIN del dispositivo que recibe el IN_RAND (el Slave).
Esto debido a que algunos dispositivos tienen un PIN predefinido que no puede ser modificado, con lo cual este PIN tiene que introducirse en el dispositivo al que queremos emparejarnos. Si ambos tienen un PIN fijo, no pueden emparejarse.

3.1.3.2 Generación de la clave de linkado K ab.

Usando el algoritmo E21, ambos dispositivos crean la clave de linkado.

Los dispositivos usan la clave de inicialización  para intercambiar dos nuevos números aleatorios de 128 bits, conocidos como LK_RAND A y LK_RAND B . Cada dispositivo genera un número aleatorio de 128 bits y lo envía al otro dispositivo previamente XOReado bit a bit con K init . Dado que ambos dispositivos conocen K init , cada dispositivo conoce ambas LK_RAND.

Usando como parámetros de entrada un BD_ADDR y el LK_RAND, el algoritmo E21 obtiene la clave de linkado K ab .


3.1.3.3. Autenticación BlueTooth

El procedimiento de autenticación sigue el conocido esquema “challenge-response”, desafío-respuesta.

Los pasos son los siguiente:

• El “demandante” transfiere su dirección de 48 bits (BD_ADDR) al “verificador”.

• El verificador le transfiere un “desafío” aleatorio de 128 bits (AU_RAND) al demandante.

• El verificador usa el algoritmo E1 para generar el “response” de autenticación, usando como parámetros la dirección del demandante, BD_ADDR b , la Clave de Linkado, K ab , y el desafío. El demandante realiza la misma operación.

• El demandante le devuelve el “response”, SRES, al verificador.

• El verificador compara el SRES del demandante con el que el ha calculado.

• Si los valores de los 32 bits de los SRES son idénticos, el verificador establece la conexión.

En este proceso, se crea además un número de 96 bits llamado ACO (Authenticated Ciphering Offset) en ambos dispositivos, que será usada durante para la creación de la Clave de Cifrado.

3.1.3.4 Generación de la clave de cifrado.

Cuando el Link Manager (LM) activa el cifrado, se crea la Clave de Cifrado, K c , que es modificada cada vez que el dispositivo entra en modo dicho modo.

La Clave de Cifrado es generada aplicando al algoritmo E3 la Clave de Linkado, un número aleatorio de 128 bits y un Ciphering Offset (COF) basado en el valor de ACO del proceso de autenticación.

En este punto ya estaríamos en condiciones de transferir datos cifrados.

3.1.4. Proceso de cifrado en BlueTooth.

La especificación de BlueTooth, cono hemos permite tres modos de cifrado diferentes.

• Modo 1. Ninguna parte del tráfico de datos es cifrada.

• Modo 2. El tráfico general va sin cifrar, pero el tráfico dirigido individualmente se cifra según las claves individuales de la conexión.

• Modo 3. Todo el tráfico es cifrado acorde a la Clave de Cifrado.

La información de usuario es protegida por cifrado de la carga útil (payload), ya que el código de acceso y la cabecera del paquete nunca son cifrados. El cifrado se lleva a cabo con el algoritmo de cifrado E0, que consiste básicamente de tres partes, como se ve en la figura siguiente:

Una parte que realiza la inicialización (generación de la clave de carga útil). Una segunda parte que es el generador de cadenas de claves, y finalmente una tercera parte en la cual se realiza el cifrado o el descifrado.
Los parámetros de entrada a dicho algoritmo serán la clave de cifrado que se obtiene del algoritmo E3, la BD_ADDR del maestro y el reloj del mismo y un número aleatorio.

El Generador de Clave de KeyStream combina los bits de entrada de una forma apropiada y los guarda en 4 registros de desplazamiento retroalimentados, conocidos como Linear Feedback Shift Registers (LSFR). Estos registros son de 25, 31, 33 y 39 bits (128 en total). Este método viene derivado del generador de cifrado de Streams de Massey y Rueppel.

Cuando el cifrado está activo, el maestro envía un número aleatorio (RAND) al esclavo. Antes de la transmisión de cada paquete, el LFSR se inicializa en el Generador de Clave de Carga mediante la combinación de RAND, la identificación del maestro, la clave de cifrado K c y el número de reloj (o número de Slot).

Como el tamaño de la Clave de Cifrado varía desde 8 a 128 bits, tiene que ser «negociado» entre los dispositivos previamente. En cada dispositivo hay un parámetro que define la longitud máxima permitida de la clave. En esta negociación, el maestro manda su sugerencia al esclavo, y este puede aceptarla o enviar otra sugerencia. Así hastaque haya consenso entre los dispositivos, o la uno de ellos aborte la negociación. En cada aplicación, hay definido un tamaño mínimo de clave aceptable, y si estos requerimientos no son cumplidos por ambos dispositivos, la aplicación aborta la negociación, y el cifrado no puede ser usado. Esto es necesario para evitar la situación donde uno de los dispositivos fuerce un cifrado débil algún fin malicioso.

Finalmente se genera el KeyStream (K cipher ) que es sumada en módulo-2 a los datos que se desean cifrar. El descifrado se realizará exactamente de la misma manera usando la misma clave que se usó para el cifrado.

Cada paquete de carga útil es cifrado separadamente, lo cual se consigue si tenemos en cuenta que una de las entradas al algoritmo E0 es el reloj del maestro, el cual cambia una unidad cada intervalo de tiempo (625µs), por lo que la clave de carga útil será diferente para cada paquete, excepto para aquellos que ocupen más de un intervalo de tiempo, en cuyo caso el valor del reloj del primer intervalo de tiempo del paquete será el que se utilizará para todo el paquete.

Descripción funcional del procedimiento de cifrado

3.2. Debilidades de la seguridad.

3.2.1. Generales

• No está demostrada la fuerza del generador pseudoaleatorio del procedimiento “challenge-Response”. Se podrían pruducir números estáticos o repeteciones periódicas que redujeran su efectividad.

• PINs cortos son permitidos. De hecho se puede elegir la longitud del PIN, que va de entre 1 a 16 bytes. Normalmente los usuarios los prefieren muy cortos.

• No hay una forma “elegante” de generar y distribuir el PIN. Establecer PINs en una red BlueTooth grande y con muchos usuarios puede ser dificil, y esto lleva normalmente a problemas de seguridad.

• La longitud de la clave de cifrado es negociable. Es necesario un procedimiento de generación de claves mas fuerte.

• En el caso del modo 3, la clave maestra es compartida. Es necesario desarrollar un esquema de transmisión de claves mejorado.

• No existe autenticación de usuarios. Sólo está implementada la autenticación de dispositivos.

• No hay límite de intentos de autenticación.

• El algoritmo de cifrado por bloques E0 es muy débil. Más tarde se analiza.

• La autenticación es un simple “challenge-response” con hashes. Según esta diseñado, el esquema es vulnerable a ataques “Man in the Middle”.

• Los servicios de seguridad son limitados. Servicios de auditoría, de no repudio, etc, no están implementados.

3.2.2. Vulnerabilidades del cifrado.

Dejando aparte de que el cifrado es opcional, veremos que además acaece de varias vulnerabilidades.

• El algoritmo de cifrado por bloques E0 es débil . Aunque se perfilaba como relativamente seguro hace pocos años. Su sistema de creación del Stream para el cifrado es mucho más complejo, y soluciona los problemas de reutilización de claves como el que tiene el RC4 del wifi (802.11b).

Sin embargo, como con todos los algoritmos de cifrado, su seguridad va cayendo paulatinamente.

Aunque E0 permite longitudes de clave que van desde 1 hasta 16 bytes (8-128 bits), Jakobbson y Wetzel presentaron un ataque con complejidad matemática de O(2^100) (esto es el equivalente a reducir la longitud de clave efectiva de 128 a 100 bits).

Posteriormente Fluhrer y Lucks presentaron otro ataque que requería desde O(2^73) hasta O(2^84), dependiendo de la cantidad de keystream capturado.

Hasta aquí podríamos decir que las posibilidades de ataque de recuperación de la Clave de Cifrado no eran efectivas, considerando que para conseguir un O(2^73) había que tener unos 14.000 gigas de keystream.

Pero luego los ataques se fueron perfeccionando, hasta que en 2004, Yi Lu y Serge Vaudenay presentaron un nuevo ataque de correlación, que resuelve en O(2^37) con una cantidad de keystream consecutivo de 64 gigas, mejorándolo en el CryptoAsia 2004 a 2^40 operaciones simples solo con los primeros 24 bits de 2^35 frames.

• Uso parcial del reloj . Como hemos visto, el reloj del dispositivo maestr es un parámetro de entrada para la generación del Stream de cifrado. Aunque parece que por un fallo de diseño el bit más significativo de su valor es ignorado, permitiendo este hecho entre otras cosas ataques tipo Man in The Middle.

• Los datos cifrados pueden ser manipulados. Incluso con el cifrado más fuerte, las caracteristicas de los cifrados de Stream permiten que los datos interceptados en un ataque Man in The Middle puedan ser convenientemente manipulados dependiendo de la cantidad de texto cifrado conocida. Así es posible por ejemplo manipular cabeceras IP.

3.3. Vulnerabilidades de la seguridad.

Son debidas principalmente a prácticas de codificación erróneas en el desarrollo de los servicios RFCOMM, al desconocimiento de los protocolos de seguridad BlueTooth y demás (OBEX), y a la reutilización de servicios antiguos para protocolos diferentes.

3.3.1. Permisos IrMC

• IrMC define los permisos de acceso para los objetos comunes.
• Hay objetos visibles aunque el servicio sea “no emparejado”.
• Servicios abiertos intencionadamente.

3.3.2. Errores de pila

• Buffer Overflows.
• Fallos en la implementación de servicios como en el chequeo de la longitud de datos o la integridad de paquetes en OBEX,  o terminaciones NULL.

3.3.3. Servicios ocultos.

• Servicios con los más altos privilegios se dejan abiertos pero escondidos.
• Canales traseros para hacerle la vida más fácil a otros dispositivos.
• Acceso completo al comando AT, y por lo tanto a todo el dispositivo.

Fuente: bluehack.elhacker.net

No dejéis de visitar esta web, esta muy bien la verdad

Deja una respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *