Bonding: o que é, processo e segurança do emparelhamento BLE

O que é Bonding em BLE?

Bonding é uma extensão do processo de pairing em Bluetooth Low Energy, onde os dispositivos armazenam chaves de criptografia para conexões subsequentes. O padrão BLE define três modos de segurança: Security Mode 1 (criptografia sem autenticação), Security Mode 2 (assinatura de dados sem criptografia) e Security Mode 3 (criptografia com autenticação). O bonding é relevante para modos com criptografia onde conexões repetidas sem renovação de chaves são necessárias.

Por que o Bonding é necessário

O principal propósito do bonding é a restauração automática de conexões criptografadas quando os dispositivos reconectam. Quando um usuário tira os fones de ouvido do estojo e os coloca, o bonding garante conexão instantânea ao smartphone sem precisar selecionar o dispositivo novamente no menu Bluetooth. De acordo com as Apple Bluetooth Design Guidelines (2025), dispositivos vinculados devem conectar em no máximo 2 segundos desde a descoberta.

Quais dados são armazenados durante o Bonding

Durante o bonding, cada dispositivo armazena um conjunto de materiais criptográficos: Long Term Key (LTK) para criptografia da conexão, Identity Resolving Key (IRK) para resolver endereços aleatórios e Connection Signature Resolving Key (CSRK) para verificar assinaturas de dados. O LTK é a chave primária de 128 bits gerada durante o pairing e usada para todas as sessões criptografadas subsequentes.

Bonding vs Pairing: qual a diferença

Pairing é a negociação temporária de chaves para criptografar a sessão de comunicação atual. Quando a conexão termina, as chaves de criptografia são excluídas e a próxima conexão requer um processo completo de pairing novamente. Bonding inclui todos os estágios do pairing mas adicionalmente armazena as chaves para sessões futuras. Praticamente todos os dispositivos Bluetooth de consumo (fones, alto-falantes, relógios) usam bonding porque sem ele, cada conexão exigiria reinserção do PIN.

Três fases de Pairing e Bonding

O processo de pairing segundo a especificação BLE consiste em três fases. Fase 1 — troca de capacidades do dispositivo (capacidades IO, suporte a autenticação). Fase 2 — geração e troca de Short Term Key (STK) ou LTK, dependendo do método de emparelhamento. Fase 3 — transporte de chaves: troca de LTK, IRK, CSRK entre dispositivos. Se os dispositivos armazenaram as chaves após a Fase 3 — isso é bonding. Se não — é simplesmente pairing.

Como funciona o processo de Bonding

O processo de bonding é iniciado após a conclusão bem-sucedida do pairing, quando um dispositivo envia uma solicitação para armazenar chaves. Em BLE, o Central (geralmente um smartphone) e o Peripheral (dispositivo vestível) trocam chaves através do canal seguro estabelecido na Fase 2. Após a troca bem-sucedida de chaves, cada dispositivo as armazena em memória não volátil junto com o endereço MAC ou Identity Address do parceiro.

Armazenamento de chaves no lado Central

No lado do Central (iOS/Android), as chaves são armazenadas no armazenamento Bluetooth do sistema. iOS usa a pilha de sistema Core Bluetooth com gerenciamento automático de bonding: no primeiro emparelhamento, as chaves são salvas na NVRAM do dispositivo e as conexões subsequentes ao mesmo Peripheral acontecem automaticamente. O desenvolvedor não gerencia chaves diretamente — a pilha de sistema Core Bluetooth lida com o bonding automaticamente ao conectar a um dispositivo que suporta armazenamento de chaves.

Restauração de conexão via Bonding

Ao reconectar, o Peripheral envia pacotes de publicidade contendo seu endereço público ou um Resolvable Private Address (RPA). O Central recebe o pacote, compara o endereço com os dispositivos vinculados armazenados e, se encontrar uma correspondência, inicia a restauração da sessão usando o LTK armazenado. Se o LTK corresponder, a conexão criptografada é estabelecida sem repetir o pairing.

Métodos de autenticação no Bonding

A especificação BLE define vários métodos de autenticação que afetam o nível de segurança do bonding. A escolha do método depende das capacidades IO dos dispositivos — se possuem tela, teclado ou capacidade de confirmar comparação numérica. Bonding seguro requer usar pelo menos Just Works para aplicações não críticas e Numeric Comparison ou Passkey Entry para tarefas que exigem proteção contra ataques Man-in-the-Middle.

Just Works

Just Works é um método sem autenticação usado quando um dos dispositivos não tem tela ou teclado. As chaves de criptografia são transmitidas sem verificar a identidade do segundo dispositivo — sensores de temperatura, monitores cardíacos. Just Works é vulnerável a ataques MITM, portanto é usado apenas para dispositivos onde o comprometimento de dados não representa ameaça.

Numeric Comparison

Numeric Comparison é um método de autenticação onde ambos os dispositivos exibem um número de seis dígitos e o usuário deve confirmar a correspondência. Este método oferece proteção contra ataques MITM e é recomendado para dispositivos com tela — relógios inteligentes, rastreadores fitness, controles remotos. Após a confirmação, o bonding é armazenado com o máximo nível de confiança.

Passkey Entry

Passkey Entry requer a inserção de um PIN de seis dígitos em um dos dispositivos. Geralmente, o código é gerado por um dispositivo e exibido nele, enquanto o usuário o insere no segundo dispositivo. Este método é usado para dispositivos médicos e fechaduras IoT onde um alto nível de segurança é necessário mas um dos dispositivos não possui tela para Numeric Comparison.

Gerenciamento de dispositivos vinculados em iOS e Android

Gerenciamento de bonding é o processo de visualizar, excluir e manter as chaves armazenadas de dispositivos emparelhados. No desenvolvimento móvel, é importante tratar corretamente os estados dos dispositivos vinculados, especialmente quando um dispositivo periférico é reiniciado ou seu firmware é substituído. Quando as chaves de bonding no Peripheral mudam, as chaves antigas no Central devem ser removidas e um novo emparelhamento realizado.

Gerenciamento em iOS

iOS gerencia automaticamente dispositivos vinculados através da pilha de sistema Core Bluetooth. O desenvolvedor não possui uma API direta para visualizar ou excluir dispositivos vinculados individualmente — o gerenciamento é feito através das configurações do sistema (Settings > Bluetooth > dispositivo > Forget). Se for necessário limpar o bonding programaticamente, o aplicativo pode direcionar o usuário para as configurações Bluetooth do sistema usando UIApplication.openSettingsURLString.

Gerenciamento em Android

Android fornece uma API direta para trabalhar com dispositivos vinculados através da classe BluetoothAdapter. O método getBondedDevices() retorna um Set<BluetoothDevice> de todos os dispositivos emparelhados. Para remover o bonding, o método removeBond() é usado via reflexão ou, no Android 12+, a 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}")
}

Exemplo prático de implementação de Bonding

A implementação de bonding no Android requer o tratamento correto do BroadcastReceiver para eventos BluetoothDevice.ACTION_BOND_STATE_CHANGED. Na primeira conexão a um dispositivo, o sistema Android inicia automaticamente o bonding se o dispositivo suportar esta capacidade. O desenvolvedor deve tratar três estados: BOND_NONE (não emparelhado), BOND_BONDING (emparelhando), BOND_BONDED (emparelhado).

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", "Vínculo removido")
        }
    }
}

Iniciar Bonding no Android

Para iniciar o bonding no Android, o método createBond() deve ser chamado no objeto BluetoothDevice. O método retorna um booleano — true se o processo de emparelhamento foi iniciado com sucesso. A partir do Android 12, createBond() requer a permissão BLUETOOTH_CONNECT e pode ser rejeitado pelo sistema se o aplicativo não tiver acesso Bluetooth em 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)
        }
    }
}

Erros comuns ao trabalhar com Bonding

Desenvolvedores de aplicativos móveis frequentemente encontram erros comuns ao trabalhar com bonding de dispositivos BLE. O tratamento incorreto dos estados de bonding pode levar a falhas de conexão, impossibilidade de re-emparelhar ou perda de dados. Vamos examinar os problemas mais frequentes e suas soluções.

Reinicialização de firmware do Peripheral e stale bonding

Após uma atualização de firmware de um dispositivo BLE, suas chaves de bonding podem ser reiniciadas, mas o smartphone continua armazenando as chaves obsoletas (stale bonding). Ao tentar conectar, o Central tenta restaurar a sessão com o LTK antigo, o Peripheral rejeita a chave e a conexão falha. A solução é remover o bonding no smartphone através de Settings > Bluetooth > Forget Device e realizar um novo emparelhamento.

Limite de dispositivos vinculados

Chips BLE têm um limite no número de registros de bonding armazenados. Para os populares chips Nordic nRF5x, o limite é de 8 a 20 registros dependendo da configuração. Quando o limite é excedido, o dispositivo para de aceitar novos emparelhamentos. A solução é remover registros de bonding não utilizados ou usar um chaveiro com limpeza prioritária.

Problemas com Privacy Feature

Ao usar a Privacy Feature (endereços MAC aleatórios), o dispositivo muda periodicamente seu endereço. Se o Central não armazenou o IRK, ele não pode associar o novo endereço aleatório a um dispositivo conhecido. A solução é implementar corretamente o armazenamento de IRK e usá-lo para resolver RPA em cada descoberta de dispositivo.