Módulo 3.5

Seguridad en BLE

Pairing, Bonding y Protección de Comunicaciones

Santi Scagliusi, PhD

Comenzar arrow_downward
handshake
Pairing
Establecer confianza
link
Bonding
Persistir claves
enhanced_encryption
Encriptación
Proteger datos
shield
Niveles
1, 2, 3 y 4

Pairing vs Bonding

Dos conceptos fundamentales para entender la seguridad en BLE.

handshake

Pairing

Emparejamiento

Proceso de establecer una relación de confianza entre dos dispositivos BLE. Genera claves temporales para la sesión actual.

  • check_circle Intercambio de capacidades de seguridad
  • check_circle Autenticación mutua de dispositivos
  • check_circle Generación de claves de encriptación
  • warning Las claves se pierden al desconectar
link

Bonding

Vinculación

Proceso de almacenar las claves generadas durante el pairing para uso futuro. Permite reconexión segura sin repetir el pairing.

  • check_circle Claves almacenadas en memoria no volátil
  • check_circle Reconexión rápida y automática
  • check_circle Sin necesidad de autenticación repetida
  • check_circle Persiste entre reinicios del dispositivo
lightbulb
Analogía: El pairing es como intercambiar tarjetas de visita en una reunión. El bonding es guardar esa tarjeta en tu agenda para contactos futuros.

Las 3 Fases del Pairing

El proceso de pairing se divide en tres fases secuenciales.

1

Feature Exchange

Intercambio de características de seguridad

  • check Capacidades I/O
  • check Requisitos de bonding
  • check Protección MITM
  • check Soporte LE Secure Connections
2

Authentication

Verificación de identidad de los dispositivos

  • check Just Works
  • check Passkey Entry
  • check Numeric Comparison
  • check Out of Band (OOB)
3

Key Distribution

Distribución de claves para encriptación

  • check LTK (Long Term Key)
  • check IRK (Identity Resolving Key)
  • check CSRK (Signing Key)
  • check Almacenamiento (bonding)
key LTK

Long Term Key - Clave principal para encriptación de la conexión.

fingerprint IRK

Identity Resolving Key - Permite resolver direcciones privadas.

verified CSRK

Connection Signature Resolving Key - Firma de datos sin encriptar.

Capacidades de I/O

Las capacidades de entrada/salida determinan qué métodos de pairing están disponibles.

tv

DisplayOnly

Solo puede mostrar información

0x00
touch_app

DisplayYesNo

Display + botones Sí/No

0x01
keyboard

KeyboardOnly

Solo teclado numérico

0x02
block

NoInputNoOutput

Sin interfaz de usuario

0x03
dialpad

KeyboardDisplay

Teclado + pantalla

0x04
priority_high
Importante: Las capacidades I/O de ambos dispositivos determinan automáticamente qué método de autenticación se usará durante el pairing. Un dispositivo NoInputNoOutput solo puede usar Just Works.

Métodos de Pairing

Cuatro métodos para autenticar dispositivos durante el pairing.

touch_app

Just Works

Sin protección MITM

No requiere interacción del usuario. Se usa cuando al menos un dispositivo no tiene capacidad de I/O.

  • check Fácil de usar, sin fricción
  • close Vulnerable a ataques MITM
pin

Passkey Entry

Protección MITM

Un dispositivo muestra un PIN de 6 dígitos, el otro lo introduce. Proporciona autenticación.

  • check Protege contra MITM
  • check Requiere interacción del usuario
compare

Numeric Comparison

Máxima seguridad

Ambos dispositivos muestran un número de 6 dígitos. El usuario confirma que coinciden.

  • check Solo disponible con LE Secure Connections
  • check Requiere DisplayYesNo en ambos
nfc

Out of Band (OOB)

Máxima seguridad

Usa un canal secundario (NFC, QR code) para intercambiar datos de autenticación.

  • check Muy seguro si el canal OOB es seguro
  • check Requiere hardware adicional

Selección de Método de Pairing

El método se selecciona automáticamente según las capacidades I/O de ambos dispositivos.

grid_on Selección de Método según Capacidades I/O

Iniciador / Responder DisplayOnly DisplayYesNo KeyboardOnly NoInputNoOutput KeyboardDisplay
DisplayOnly Just Works Just Works Passkey Just Works Passkey
DisplayYesNo Just Works Numeric Comp Passkey Just Works Numeric Comp
KeyboardOnly Passkey Passkey Passkey Just Works Passkey
NoInputNoOutput Just Works Just Works Just Works Just Works Just Works
KeyboardDisplay Passkey Numeric Comp Passkey Just Works Numeric Comp
lightbulb
Consejo: Para máxima seguridad, diseña tu dispositivo con capacidad DisplayYesNo o KeyboardDisplay para habilitar Numeric Comparison con LE Secure Connections.

Legacy Pairing vs LE Secure Connections

BLE 4.2 introdujo LE Secure Connections con mejoras significativas de seguridad.

history

Legacy Pairing

BLE 4.0 / 4.1

Método original de pairing en BLE. Usa un Temporary Key (TK) para generar el Short Term Key (STK).

security Algoritmo: AES-CCM con TK
warning TK de Just Works = 0 (vulnerable)
warning Passkey: solo 20 bits de entropía

Vulnerabilidad: Un atacante que capture el pairing puede descifrar la clave en segundos con fuerza bruta.

verified_user

LE Secure Connections

BLE 4.2+

Método moderno usando ECDH (Elliptic Curve Diffie-Hellman) para intercambio de claves.

security Algoritmo: ECDH P-256
check_circle Forward secrecy
check_circle Numeric Comparison disponible

Recomendación: Siempre usar LE Secure Connections cuando ambos dispositivos lo soporten.

info
Forward Secrecy: Incluso si un atacante captura todo el tráfico y posteriormente obtiene la LTK, no puede descifrar sesiones anteriores porque cada sesión usa claves ECDH únicas.

Preocupaciones de Seguridad

Principales vectores de ataque en comunicaciones BLE.

location_searching

Identity Tracking

Seguimiento de dispositivos usando su dirección MAC fija durante el advertising.

Solución: Usar direcciones privadas resolvables (RPA) con IRK.

hearing

Passive Eavesdropping

Captura del tráfico BLE sin encriptar usando un sniffer.

Solución: Usar encriptación (pairing) y LE Secure Connections.

person_cancel

MITM Attack

Atacante se interpone entre dos dispositivos durante el pairing.

Solución: Usar Passkey Entry, Numeric Comparison u OOB.

warning Visualización de Ataque MITM

smartphone
Central
warning MITM Intercepta
skull
Atacante
memory
Periférico

Sin protección MITM, el atacante puede hacer pairing con ambos dispositivos y reenviar datos modificados.

Niveles de Seguridad (Security Mode 1)

BLE define 4 niveles de seguridad en el Security Mode 1.

Nivel 1
Sin seguridad
Nivel 2
Encriptación
Nivel 3
+ MITM
Nivel 4
+ LESC
Nivel 1 Sin seguridad
  • close Sin encriptación
  • close Sin autenticación
  • info Útil solo para datos públicos
Nivel 2 Encriptación sin MITM
  • check Encriptación AES-CCM
  • close Sin protección MITM
  • info Just Works pairing
Nivel 3 Encriptación con MITM
  • check Encriptación AES-CCM
  • check Protección MITM
  • info Passkey Entry / OOB
Nivel 4 LE Secure Connections + MITM
  • check ECDH + AES-CCM
  • check Protección MITM
  • check Forward Secrecy

Selector Interactivo de Método de Pairing

Selecciona las capacidades I/O de cada dispositivo para descubrir qué método de pairing se usará según la especificación BLE (LE Secure Connections).

smartphone Iniciador Central
DisplayOnly 0x00
DisplayYesNo 0x01
KeyboardOnly 0x02
NoInputNoOutput 0x03
KeyboardDisplay 0x04
sync_alt
memory Responder Periférico
DisplayOnly 0x00
DisplayYesNo 0x01
KeyboardOnly 0x02
NoInputNoOutput 0x03
KeyboardDisplay 0x04
touch_app

Selecciona las capacidades I/O de ambos dispositivos
para ver el método de pairing resultante

grid_on Tabla de Referencia - LE Secure Connections (BLE 4.2+)

Iniciador \ Responder DisplayOnly DisplayYesNo KeyboardOnly NoInputNoOutput KeyboardDisplay
DisplayOnly JW JW PK JW PK
DisplayYesNo JW NC PK JW NC
KeyboardOnly PK PK PK JW PK
NoInputNoOutput JW JW JW JW JW
KeyboardDisplay PK NC PK JW NC
JW = Just Works PK = Passkey Entry NC = Numeric Comparison

Filter Accept List (Whitelist)

Limita qué dispositivos pueden conectarse o escanear tu dispositivo BLE.

filter_list ¿Qué es el Filter Accept List?

Una lista de direcciones de dispositivos conocidos y confiables. Solo los dispositivos en la lista pueden:

  • check_circle Conectarse al periférico
  • check_circle Recibir respuestas de scan
  • check_circle Ser escaneados por el central
lightbulb
Se usa junto con bonding: después de hacer pairing, añade el dispositivo a la whitelist.

devices Ejemplo de Filter Accept List

smartphone
Mi Teléfono
AA:BB:CC:DD:EE:01
check_circle
laptop
Mi Portátil
AA:BB:CC:DD:EE:02
check_circle
devices_other
Dispositivo Desconocido
XX:XX:XX:XX:XX:XX
block
devices_other
Atacante
XX:XX:XX:XX:XX:XX
block

Configuración de Whitelist en Zephyr

Código para habilitar y gestionar el Filter Accept List.

Configuración de Filter Accept List en Zephyr
/* Habilitar whitelist en advertising */ static struct bt_le_adv_param adv_param = BT_LE_ADV_PARAM_INIT( BT_LE_ADV_OPT_CONNECTABLE | BT_LE_ADV_OPT_FILTER_CONN | // Solo conexiones de whitelist BT_LE_ADV_OPT_FILTER_SCAN_REQ, // Solo scan requests de whitelist BT_GAP_ADV_FAST_INT_MIN_2, BT_GAP_ADV_FAST_INT_MAX_2, NULL ); /* Añadir dispositivo bonded a la whitelist */ static void add_bonded_to_whitelist(const struct bt_bond_info *info, void *data) { int *count = data; int err = bt_le_filter_accept_list_add(&info->addr); if (!err) { (*count)++; } } /* Cargar todos los dispositivos bonded en la whitelist */ int count = 0; bt_foreach_bond(BT_ID_DEFAULT, add_bonded_to_whitelist, &count); printk("Added %d bonded devices to whitelist\n", count);
warning
Nota: La whitelist solo funciona correctamente si también guardas las direcciones IRK de los dispositivos bonded, ya que muchos dispositivos usan direcciones privadas resolvables (RPA).

APIs de Seguridad en Zephyr

Configuración y callbacks para implementar seguridad BLE.

prj.conf - Configuración de seguridad
# Habilitar Security Manager Protocol CONFIG_BT_SMP=y # Habilitar bonding (persistir claves) CONFIG_BT_SETTINGS=y CONFIG_FLASH=y CONFIG_FLASH_MAP=y CONFIG_NVS=y CONFIG_SETTINGS=y # Habilitar LE Secure Connections CONFIG_BT_SMP_SC_ONLY=y CONFIG_BT_SMP_SC_PAIR_ONLY=y # Nivel de log para debugging CONFIG_BT_SMP_LOG_LEVEL_DBG=y
Estructura de callbacks de autenticación
static struct bt_conn_auth_cb auth_cb_display = { /* DisplayOnly: muestra passkey */ .passkey_display = auth_passkey_display, /* KeyboardOnly: solicita passkey */ .passkey_entry = auth_passkey_entry, /* DisplayYesNo: confirmación numérica */ .passkey_confirm = auth_passkey_confirm, /* OOB data */ .oob_data_request = auth_oob_data_request, /* Cancelar pairing */ .cancel = auth_cancel, }; /* Registrar callbacks */ bt_conn_auth_cb_register(&auth_cb_display);

Implementación de Callbacks

Ejemplo de implementación de los callbacks de autenticación.

Implementación de callbacks de seguridad
/* Callback: mostrar passkey (para DisplayOnly) */ static void auth_passkey_display(struct bt_conn *conn, unsigned int passkey) { char addr[BT_ADDR_LE_STR_LEN]; bt_addr_le_to_str(bt_conn_get_dst(conn), addr, sizeof(addr)); printk("Passkey for %s: %06u\n", addr, passkey); } /* Callback: confirmar passkey (para Numeric Comparison) */ static void auth_passkey_confirm(struct bt_conn *conn, unsigned int passkey) { printk("Confirm passkey: %06u [y/n]\n", passkey); // El usuario debe confirmar, luego llamar: // bt_conn_auth_passkey_confirm(conn) o bt_conn_auth_cancel(conn) } /* Callback: pairing completado */ static void auth_pairing_complete(struct bt_conn *conn, bool bonded) { printk("Pairing Complete, bonded: %s\n", bonded ? "yes" : "no"); } /* Registrar info callbacks */ static struct bt_conn_auth_info_cb auth_info_cb = { .pairing_complete = auth_pairing_complete, .pairing_failed = auth_pairing_failed, }; bt_conn_auth_info_cb_register(&auth_info_cb);

Funciones de Seguridad

Principales funciones de la API de seguridad de Zephyr.

bt_conn_set_security()

Solicita un nivel de seguridad específico para la conexión.

bt_conn_auth_passkey_entry()

Proporciona el passkey introducido por el usuario.

bt_conn_auth_passkey_confirm()

Confirma que el passkey mostrado es correcto.

bt_unpair()

Elimina el bonding con un dispositivo específico.

bt_conn_auth_cancel()

Cancela el proceso de pairing en curso.

bt_foreach_bond()

Itera sobre todos los dispositivos con bonding.

code
Documentación: Consulta la documentación oficial de Zephyr BLE para más detalles sobre cada función.

Resumen del Módulo

handshake
Pairing
3 fases secuenciales
pin
Métodos
JW, Passkey, NC, OOB
shield
Niveles
1, 2, 3 y 4
filter_list
Whitelist
Control de acceso
arrow_forward Siguiente módulo

3.6 Debugging BLE: Sniffer

Herramientas y técnicas para depurar comunicaciones BLE.

arrow_back Módulo 3.4 home Índice del curso Siguiente: Debugging arrow_forward