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
Nota: En este 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 Kinit.
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 Kab. 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:
Algoritmo de cifrado E0
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 • Buffers 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.
En el siguiente apartado, el 3.4, veremos los comandos necesarios para manipular sin restricciones un móvil BlueTooth, y veremos como hacerlo a través del IrD. Empieza la parte práctica.
Autor
En línea
