Bonding : ce que c’est, processus et sécurité de l’appairage BLE

Qu’est-ce que le Bonding en BLE ?

Bonding est une extension du processus de pairing en Bluetooth Low Energy, où les dispositifs stockent des clés de cryptage pour les connexions ultérieures. La norme BLE définit trois modes de sécurité : Security Mode 1 (cryptage sans authentification), Security Mode 2 (signature de données sans cryptage) et Security Mode 3 (cryptage avec authentification). Le bonding est pertinent pour les modes avec cryptage lorsque des connexions répétées sans renouvellement de clés sont nécessaires.

Pourquoi le Bonding est nécessaire

Le but principal du bonding est la restauration automatique des connexions cryptées lorsque les dispositifs se reconnectent. Lorsqu’un utilisateur sort des écouteurs de leur boîtier et les met, le bonding assure une connexion instantanée au smartphone sans avoir à sélectionner à nouveau le dispositif dans le menu Bluetooth. Selon les Apple Bluetooth Design Guidelines (2025), les dispositifs liés doivent se connecter en moins de 2 secondes après la découverte.

Quelles données sont stockées lors du Bonding

Lors du bonding, chaque dispositif stocke un ensemble de matériaux cryptographiques : Long Term Key (LTK) pour le cryptage de la connexion, Identity Resolving Key (IRK) pour la résolution des adresses aléatoires et Connection Signature Resolving Key (CSRK) pour la vérification des signatures de données. Le LTK est la clé primaire de 128 bits générée lors du pairing et utilisée pour toutes les sessions cryptées ultérieures.

Bonding vs Pairing : quelle est la différence

Pairing est la négociation temporaire de clés pour crypter la session de communication en cours. Lorsque la connexion se termine, les clés de cryptage sont supprimées et la connexion suivante nécessite à nouveau un processus complet de pairing. Bonding inclut toutes les étapes du pairing mais stocke en plus les clés pour les sessions futures. Pratiquement tous les dispositifs Bluetooth grand public (casques, enceintes, montres) utilisent le bonding car sans lui, chaque connexion nécessiterait une ressaisie du PIN.

Trois phases du Pairing et du Bonding

Le processus de pairing selon la spécification BLE comprend trois phases. Phase 1 — échange des capacités des dispositifs (capacités IO, support d’authentification). Phase 2 — génération et échange de Short Term Key (STK) ou LTK, selon la méthode d’appairage. Phase 3 — transport des clés : échange de LTK, IRK, CSRK entre les dispositifs. Si les dispositifs ont stocké les clés après la Phase 3 — c’est du bonding. Sinon — ce n’est que du pairing.

Comment fonctionne le processus de Bonding

Le processus de bonding est initié après la réussite du pairing, lorsqu’un dispositif envoie une demande de stockage des clés. En BLE, le Central (généralement un smartphone) et le Peripheral (dispositif portable) échangent des clés via le canal sécurisé établi lors de la Phase 2. Après un échange réussi, chaque dispositif les stocke dans la mémoire non volatile avec l’adresse MAC ou l’Identity Address du partenaire.

Stockage des clés côté Central

Du côté Central (iOS/Android), les clés sont stockées dans le stockage Bluetooth système. iOS utilise la pile système Core Bluetooth avec gestion automatique du bonding : lors du premier appairage, les clés sont enregistrées dans la NVRAM du dispositif, et les connexions ultérieures au même Peripheral se font automatiquement. Le développeur ne gère pas les clés directement — la pile système Core Bluetooth traite le bonding automatiquement lors de la connexion à un dispositif prenant en charge le stockage des clés.

Restauration de connexion via Bonding

Lors de la reconnexion, le Peripheral envoie des paquets de publicité contenant soit son adresse publique, soit une Resolvable Private Address (RPA). Le Central reçoit le paquet, compare l’adresse avec les dispositifs liés stockés et, si une correspondance est trouvée, initie la restauration de la session en utilisant le LTK stocké. Si le LTK correspond, la connexion cryptée est établie sans nouveau pairing.

Méthodes d’authentification lors du Bonding

La spécification BLE définit plusieurs méthodes d’authentification qui affectent le niveau de sécurité du bonding. Le choix de la méthode dépend des capacités IO des dispositifs — s’ils ont un écran, un clavier ou la capacité de confirmer une comparaison numérique. Un bonding sécurisé nécessite au moins Just Works pour les applications non critiques et Numeric Comparison ou Passkey Entry pour les tâches nécessitant une protection contre les attaques Man-in-the-Middle.

Just Works

Just Works est une méthode sans authentification utilisée lorsqu’un des dispositifs n’a pas d’écran ni de clavier. Les clés de cryptage sont transmises sans vérifier l’identité du second dispositif — capteurs de température, moniteurs cardiaques. Just Works est vulnérable aux attaques MITM, donc il n’est utilisé que pour les dispositifs où la compromission des données ne représente pas une menace.

Numeric Comparison

Numeric Comparison est une méthode d’authentification où les deux dispositifs affichent un nombre à six chiffres et l’utilisateur doit confirmer la correspondance. Cette méthode offre une protection contre les attaques MITM et est recommandée pour les dispositifs avec écran — montres connectées, trackers de fitness, télécommandes. Après confirmation, le bonding est stocké avec le niveau de confiance maximal.

Passkey Entry

Passkey Entry nécessite la saisie d’un PIN à six chiffres sur l’un des dispositifs. Généralement, le code est généré par un dispositif et affiché sur celui-ci, tandis que l’utilisateur le saisit sur le second dispositif. Cette méthode est utilisée pour les dispositifs médicaux et les serrures IoT où un haut niveau de sécurité est requis mais l’un des dispositifs n’a pas d’écran pour Numeric Comparison.

Gestion des dispositifs liés dans iOS et Android

La gestion du bonding est le processus de visualisation, suppression et maintenance des clés stockées des dispositifs appairés. Dans le développement mobile, il est important de traiter correctement les états des dispositifs liés, en particulier lorsqu’un dispositif périphérique est réinitialisé ou que son firmware est remplacé. Lorsque les clés de bonding sur le Peripheral changent, les anciennes clés sur le Central doivent être supprimées et un nouvel appairage effectué.

Gestion dans iOS

iOS gère automatiquement les dispositifs liés via la pile système Core Bluetooth. Le développeur n’a pas d’API directe pour visualiser ou supprimer individuellement les dispositifs liés — la gestion se fait via les paramètres système (Settings > Bluetooth > dispositif > Forget). Si le bonding doit être effacé par programmation, l’application peut diriger l’utilisateur vers les paramètres Bluetooth système en utilisant UIApplication.openSettingsURLString.

Gestion dans Android

Android fournit une API directe pour travailler avec les dispositifs liés via la classe BluetoothAdapter. La méthode getBondedDevices() retourne un Set<BluetoothDevice> de tous les dispositifs appairés. Pour supprimer le bonding, la méthode removeBond() est utilisée par réflexion ou, sur Android 12+, l’API officielle BluetoothDevice.removeBond().

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

Exemple pratique d’implémentation du Bonding

L’implémentation du bonding sur Android nécessite un traitement correct du BroadcastReceiver pour les événements BluetoothDevice.ACTION_BOND_STATE_CHANGED. Lors de la première connexion à un dispositif, le système Android initie automatiquement le bonding si le dispositif prend en charge cette capacité. Le développeur doit gérer trois états : BOND_NONE (non appairé), BOND_BONDING (appairage en cours), BOND_BONDED (appairé).

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", "Lien supprimé")
        }
    }
}

Initier le Bonding sur Android

Pour initier le bonding sur Android, la méthode createBond() doit être appelée sur l’objet BluetoothDevice. La méthode retourne un booléen — true si le processus d’appairage a démarré avec succès. À partir d’Android 12, createBond() nécessite l’autorisation BLUETOOTH_CONNECT et peut être rejeté par le système si l’application n’a pas d’accès Bluetooth en arrière-plan.

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

Erreurs courantes lors du travail avec Bonding

Les développeurs d’applications mobiles rencontrent fréquemment des erreurs courantes lors du travail avec le bonding des dispositifs BLE. Un traitement incorrect des états de bonding peut entraîner des échecs de connexion, une impossibilité de réappairer ou une perte de données. Examinons les problèmes les plus fréquents et leurs solutions.

Réinitialisation du firmware du Peripheral et stale bonding

Après une mise à jour du firmware d’un dispositif BLE, ses clés de bonding peuvent être réinitialisées, mais le smartphone continue de stocker les anciennes clés (stale bonding). En tentant de se connecter, le Central essaie de restaurer la session avec l’ancien LTK, le Peripheral rejette la clé et la connexion échoue. La solution est de supprimer le bonding sur le smartphone via Settings > Bluetooth > Forget Device et d’effectuer un nouvel appairage.

Limite du nombre de dispositifs liés

Les puces BLE ont une limite sur le nombre d’enregistrements de bonding stockés. Pour les populaires puces Nordic nRF5x, la limite est de 8 à 20 enregistrements selon la configuration. Lorsque la limite est dépassée, le dispositif cesse d’accepter de nouveaux appairages. La solution est de supprimer les enregistrements de bonding inutilisés ou d’utiliser un trousseau de clés avec nettoyage prioritaire.

Problèmes avec la fonction de confidentialité

Lors de l’utilisation de la fonction de confidentialité (adresses MAC aléatoires), le dispositif change périodiquement son adresse. Si le Central n’a pas stocké l’IRK, il ne peut pas associer la nouvelle adresse aléatoire à un dispositif connu. La solution est d’implémenter correctement le stockage de l’IRK et de l’utiliser pour résoudre le RPA à chaque découverte de dispositif.