Bonding: qué es, proceso y seguridad del emparejamiento BLE

¿Qué es Bonding en BLE?

Bonding es una extensión del proceso de pairing en Bluetooth Low Energy, donde los dispositivos almacenan claves de cifrado para conexiones posteriores. El estándar BLE define tres modos de seguridad: Security Mode 1 (cifrado sin autenticación), Security Mode 2 (firma de datos sin cifrado) y Security Mode 3 (cifrado con autenticación). El bonding es relevante para modos con cifrado donde se requieren conexiones repetidas sin renovación de claves.

Por qué se necesita Bonding

El propósito principal del bonding es la restauración automática de conexiones cifradas cuando los dispositivos se reconectan. Cuando un usuario saca los auriculares de su estuche y se los pone, el bonding garantiza una conexión instantánea al teléfono inteligente sin necesidad de seleccionar el dispositivo nuevamente del menú Bluetooth. Según las Apple Bluetooth Design Guidelines (2025), los dispositivos vinculados deben conectarse en no más de 2 segundos desde su detección.

Qué datos se almacenan durante el Bonding

Durante el bonding, cada dispositivo almacena un conjunto de materiales criptográficos: Long Term Key (LTK) para el cifrado de la conexión, Identity Resolving Key (IRK) para resolver direcciones aleatorias y Connection Signature Resolving Key (CSRK) para verificar firmas de datos. El LTK es la clave principal de 128 bits generada durante el pairing y utilizada para todas las sesiones cifradas posteriores.

Bonding vs Pairing: cuál es la diferencia

Pairing es la negociación temporal de claves para cifrar la sesión de comunicación actual. Cuando la conexión finaliza, las claves de cifrado se eliminan y la siguiente conexión requiere un proceso completo de pairing nuevamente. Bonding incluye todas las etapas del pairing pero adicionalmente guarda las claves para sesiones futuras. Prácticamente todos los dispositivos Bluetooth de consumo (auriculares, altavoces, relojes) usan bonding porque sin él, cada conexión requeriría volver a ingresar el PIN.

Tres fases de Pairing y Bonding

El proceso de pairing según la especificación BLE consta de tres fases. Fase 1 — intercambio de capacidades del dispositivo (capacidades IO, soporte de autenticación). Fase 2 — generación e intercambio de Short Term Key (STK) o LTK, según el método de emparejamiento. Fase 3 — transporte de claves: intercambio de LTK, IRK, CSRK entre dispositivos. Si los dispositivos guardaron las claves después de la Fase 3 — esto es bonding. Si no — es simplemente pairing.

Cómo funciona el proceso de Bonding

El proceso de bonding se inicia después de completar exitosamente el pairing, cuando un dispositivo envía una solicitud para guardar las claves. En BLE, el Central (generalmente un teléfono inteligente) y el Peripheral (dispositivo portátil) intercambian claves a través del canal seguro establecido en la Fase 2. Después del intercambio exitoso de claves, cada dispositivo las almacena en memoria no volátil junto con la dirección MAC o Identity Address del socio.

Almacenamiento de claves en el lado Central

En el lado del Central (iOS/Android), las claves se almacenan en el almacenamiento Bluetooth del sistema. iOS utiliza la pila del sistema Core Bluetooth con gestión automática de bonding: en el primer emparejamiento, las claves se guardan en la NVRAM del dispositivo, y las conexiones posteriores al mismo Peripheral ocurren automáticamente. El desarrollador no gestiona las claves directamente — la pila del sistema Core Bluetooth maneja el bonding automáticamente al conectarse a un dispositivo que soporta almacenamiento de claves.

Restauración de conexión mediante Bonding

Al reconectarse, el Peripheral envía paquetes de publicidad que contienen su dirección pública o una Resolvable Private Address (RPA). El Central recibe el paquete, compara la dirección con los dispositivos vinculados almacenados y, si encuentra una coincidencia, inicia la restauración de la sesión utilizando el LTK guardado. Si el LTK coincide, la conexión cifrada se establece sin repetir el pairing.

Métodos de autenticación en Bonding

La especificación BLE define varios métodos de autenticación que afectan el nivel de seguridad del bonding. La elección del método depende de las capacidades IO de los dispositivos — si tienen pantalla, teclado o la capacidad de confirmar comparación numérica. Un bonding seguro requiere usar al menos Just Works para aplicaciones no críticas y Numeric Comparison o Passkey Entry para tareas que requieren protección contra ataques Man-in-the-Middle.

Just Works

Just Works es un método sin autenticación utilizado cuando uno de los dispositivos no tiene pantalla ni teclado. Las claves de cifrado se transmiten sin verificar la identidad del segundo dispositivo — sensores de temperatura, pulsómetros. Just Works es vulnerable a ataques MITM, por lo que solo se usa para dispositivos donde la compromisión de datos no representa una amenaza.

Numeric Comparison

Numeric Comparison es un método de autenticación donde ambos dispositivos muestran un número de seis dígitos y el usuario debe confirmar la coincidencia. Este método proporciona protección contra ataques MITM y se recomienda para dispositivos con pantalla — relojes inteligentes, rastreadores de fitness, controles remotos. Después de la confirmación, el bonding se almacena con el máximo nivel de confianza.

Passkey Entry

Passkey Entry requiere ingresar un PIN de seis dígitos en uno de los dispositivos. Generalmente, el código es generado por un dispositivo y mostrado en él, mientras que el usuario lo ingresa en el segundo dispositivo. Este método se utiliza para dispositivos médicos y cerraduras IoT donde se requiere un alto nivel de seguridad pero uno de los dispositivos carece de pantalla para Numeric Comparison.

Gestión de dispositivos vinculados en iOS y Android

La gestión de bonding es el proceso de ver, eliminar y mantener las claves almacenadas de dispositivos emparejados. En el desarrollo móvil, es importante manejar correctamente los estados de los dispositivos vinculados, especialmente cuando se restablece un dispositivo periférico o se reemplaza su firmware. Cuando las claves de bonding en el Peripheral cambian, las claves antiguas en el Central deben eliminarse y realizarse un nuevo emparejamiento.

Gestión en iOS

iOS gestiona automáticamente los dispositivos vinculados a través de la pila del sistema Core Bluetooth. El desarrollador no tiene una API directa para ver o eliminar dispositivos vinculados individualmente — la gestión se realiza a través de la configuración del sistema (Settings > Bluetooth > dispositivo > Forget). Si es necesario borrar el bonding mediante programación, la aplicación puede dirigir al usuario a la configuración Bluetooth del sistema usando UIApplication.openSettingsURLString.

Gestión en Android

Android proporciona una API directa para trabajar con dispositivos vinculados a través de la clase BluetoothAdapter. El método getBondedDevices() devuelve un Set<BluetoothDevice> de todos los dispositivos emparejados. Para eliminar el bonding, se utiliza el método removeBond() mediante reflexión o, en Android 12+, la API oficial BluetoothDevice.removeBond().

val adapter = BluetoothAdapter.getDefaultAdapter()
val bondedDevices: Set<BluetoothDevice> = adapter.getBondedDevices()
bondedDevices.forEach { device ->
    Log.d("Bonding", "Bonded device: ${device.name}, ${device.address}")
}

Ejemplo práctico de implementación de Bonding

La implementación de bonding en Android requiere el manejo correcto de BroadcastReceiver para eventos BluetoothDevice.ACTION_BOND_STATE_CHANGED. En la primera conexión a un dispositivo, el sistema Android inicia automáticamente el bonding si el dispositivo soporta esta capacidad. El desarrollador debe manejar tres estados: BOND_NONE (no emparejado), BOND_BONDING (emparejando), BOND_BONDED (emparejado).

val bondReceiver = object : BroadcastReceiver() {
    override fun onReceive(context: Context, intent: Intent) {
        val device = intent.getParcelableExtra(BluetoothDevice.EXTRA_DEVICE)
        val bondState = intent.getIntExtra(BluetoothDevice.EXTRA_BOND_STATE, -1)
        when (bondState) {
            BluetoothDevice.BOND_BONDED -> Log.d("Bonding", "Bonded: ${device.name}")
            BluetoothDevice.BOND_NONE -> Log.d("Bonding", "Enlace eliminado")
        }
    }
}

Iniciar Bonding en Android

Para iniciar el bonding en Android, se debe llamar al método createBond() en el objeto BluetoothDevice. El método devuelve un booleano — true si el proceso de emparejamiento se inició correctamente. A partir de Android 12, createBond() requiere el permiso BLUETOOTH_CONNECT y puede ser rechazado por el sistema si la aplicación no tiene acceso Bluetooth en segundo plano.

fun initiateBonding(device: BluetoothDevice) {
    if (device.bondState == BluetoothDevice.BOND_NONE) {
        val success = device.createBond()
        if (success) {
            Toast.makeText(context, "Bonding iniciado", Toast.LENGTH_SHORT)
        }
    }
}

Errores comunes al trabajar con Bonding

Los desarrolladores de aplicaciones móviles a menudo se enfrentan a errores comunes al trabajar con bonding de dispositivos BLE. El manejo incorrecto de los estados de bonding puede provocar fallos de conexión, imposibilidad de reemparejar o pérdida de datos. Examinemos los problemas más frecuentes y sus soluciones.

Restablecimiento de firmware del Peripheral y stale bonding

Después de una actualización de firmware de un dispositivo BLE, sus claves de bonding pueden restablecerse, pero el teléfono inteligente continúa almacenando las claves obsoletas (stale bonding). Al intentar conectar, el Central intenta restaurar la sesión con el LTK antiguo, el Peripheral rechaza la clave y la conexión falla. La solución es eliminar el bonding en el teléfono a través de Settings > Bluetooth > Forget Device y realizar un nuevo emparejamiento.

Límite de dispositivos vinculados

Los chips BLE tienen un límite en el número de registros de bonding almacenados. Para los populares chips Nordic nRF5x, el límite es de 8 a 20 registros según la configuración. Cuando se supera el límite, el dispositivo deja de aceptar nuevos emparejamientos. La solución es eliminar los registros de bonding no utilizados o usar un llavero de claves con limpieza prioritaria.

Problemas con Privacy Feature

Al usar la Privacy Feature (direcciones MAC aleatorias), el dispositivo cambia periódicamente su dirección. Si el Central no almacenó el IRK, no puede asociar la nueva dirección aleatoria con un dispositivo conocido. La solución es implementar correctamente el almacenamiento de IRK y usarlo para resolver RPA en cada detección de dispositivo.