Bonding: wat is het, het proces en de beveiliging van BLE-koppeling

Wat is Bonding in BLE?

Bonding — is een uitbreiding van het pairing-proces in Bluetooth Low Energy, waarbij apparaten coderingssleutels opslaan voor latere verbindingen. De BLE-standaard definieert drie beveiligingsmodi: Security Mode 1 (codering zonder authenticatie), Security Mode 2 (gegevens ondertekenen zonder codering) en Security Mode 3 (codering met authenticatie). Bonding is relevant voor modi met codering waarbij meerdere verbindingen nodig zijn zonder heronderhandeling van sleutels.

Waarom is Bonding nodig

Het belangrijkste doel van bonding is het automatisch herstellen van de gecodeerde verbinding bij hernieuwde verbinding van apparaten. Wanneer een gebruiker de hoofdtelefoon uit de case haalt en opzet, zorgt bonding voor directe verbinding met de smartphone zonder het apparaat opnieuw te selecteren in het Bluetooth-menu. Volgens Apple Bluetooth Design Guidelines (2025) moeten bonded apparaten binnen maximaal 2 seconden na detectie verbinding maken.

Welke gegevens worden opgeslagen tijdens Bonding

Tijdens bonding slaat elk apparaat een reeks cryptografisch materiaal op: Long Term Key (LTK) voor het coderen van de verbinding, Identity Resolving Key (IRK) voor het oplossen van willekeurige adressen, Connection Signature Resolving Key (CSRK) voor het verifiëren van gegevenshandtekeningen. LTK — de hoofdsleutel van 128 bit, gegenereerd tijdens het pairing-proces en gebruikt voor alle volgende gecodeerde sessies.

Bonding vs Pairing: wat is het verschil

Pairing — is de tijdelijke overeenkomst van sleutels voor het coderen van de huidige communicatiesessie. Wanneer de verbinding wordt beëindigd, worden de coderingssleutels verwijderd en is bij de volgende verbinding een herhaald pairing-proces nodig. Bonding omvat alle fasen van pairing, maar slaat daarnaast de sleutels op voor volgende sessies. Vrijwel alle consumenten Bluetooth-apparaten (hoofdtelefoons, luidsprekers, horloges) gebruiken bonding, omdat zonder dit elke verbinding opnieuw een PIN zou vereisen.

Drie fasen van Pairing en Bonding

Het pairing-proces volgens de BLE-specificatie bestaat uit drie fasen. Fase 1 — uitwisseling van apparaatmogelijkheden (IO-capabilities, ondersteuning voor authenticatie). Fase 2 — genereren en uitwisselen van Short Term Key (STK) of LTK, afhankelijk van de verbindingsmethode. Fase 3 — sleuteltransport: uitwisseling van LTK, IRK, CSRK tussen apparaten. Als apparaten de sleutels hebben opgeslagen na Fase 3 — is dit bonding. Zo niet — dan is het alleen pairing.

Hoe werkt het Bonding-proces

Het bonding-proces wordt gestart na succesvolle voltooiing van pairing, wanneer een van de apparaten een verzoek stuurt om sleutels op te slaan. In BLE wisselen Central (meestal de smartphone) en Peripheral (draagbaar apparaat) sleutels uit via een beveiligd kanaal dat in Fase 2 is opgezet. Na succesvolle sleuteluitwisseling slaat elk apparaat deze op in niet-vluchtig geheugen samen met het MAC-adres of Identity Address van de partner.

Sleutelopslag aan de Central-kant

Aan de Central-kant (iOS/Android) worden sleutels opgeslagen in de systeemopslag van Bluetooth. iOS gebruikt de systeemstack Core Bluetooth met automatisch bonding-beheer: bij de eerste verbinding worden sleutels opgeslagen in het NVRAM van het apparaat en latere verbindingen met dezelfde Peripheral verlopen automatisch. De ontwikkelaar beheert sleutels niet direct — de systeemstack Core Bluetooth verwerkt bonding automatisch bij het tot stand brengen van een verbinding met een apparaat dat sleutelopslag ondersteunt.

Verbinding herstellen via Bonding

Bij hernieuwde verbinding stuurt Peripheral advertentiepakketten die ofwel het openbare adres ofwel een Resolvable Private Address (RPA) bevatten. Central ontvangt het pakket, vergelijkt het adres met opgeslagen bonded apparaten en start, indien een overeenkomst wordt gevonden, het herstel van de sessie met behulp van de opgeslagen LTK. Als LTK overeenkomt — wordt de gecodeerde verbinding tot stand gebracht zonder herhaalde pairing.

Authenticatiemethoden bij Bonding

De BLE-specificatie definieert verschillende authenticatiemethoden die van invloed zijn op het beveiligingsniveau van bonding. De keuze van de methode hangt af van de IO-mogelijkheden van de apparaten — aanwezigheid van een display, toetsenbord, mogelijkheid om numerieke vergelijking te bevestigen. Veilige bonding vereist het gebruik van ten minste Just Works voor niet-kritieke toepassingen en Numeric Comparison of Passkey Entry voor taken die bescherming tegen Man-in-the-Middle-aanvallen vereisen.

Just Works

Just Works — methode zonder authenticatie, gebruikt wanneer een van de apparaten geen display of toetsenbord heeft. Coderingssleutels worden verzonden zonder verificatie van de authenticiteit van het tweede apparaat — temperatuur, hartslag). Just Works is kwetsbaar voor MITM-aanvallen en wordt daarom alleen toegepast op apparaten waar gegevenscompromittering geen bedreiging vormt.

Numeric Comparison

Numeric Comparison — authenticatiemethode waarbij beide apparaten een zescijferig nummer tonen en de gebruiker de overeenkomst moet bevestigen. Deze methode biedt bescherming tegen MITM-aanvallen en wordt aanbevolen voor apparaten met een display — smartwatches, fitnesstrackers, afstandsbedieningen. Na bevestiging wordt bonding opgeslagen met het maximale vertrouwensniveau.

Passkey Entry

Passkey Entry vereist het invoeren van een zescijferige PIN op een van de apparaten. Meestal wordt de code door het ene apparaat gegenereerd en erop weergegeven, en de gebruiker voert deze in op het tweede apparaat. De methode wordt toegepast op medische apparaten en IoT-sloten waar een hoog beveiligingsniveau vereist is, maar een van de apparaten geen display heeft voor Numeric Comparison.

Beheer van bonded apparaten in iOS en Android

Bonding-beheer — het proces van bekijken, verwijderen en onderhouden van opgeslagen sleutels van gekoppelde apparaten. In mobiele ontwikkeling is het belangrijk om de status van bonded apparaten correct te beheren, vooral bij het resetten van de instellingen van een randapparaat of het vervangen van de firmware. Bij wijziging van bonding-sleutels op Peripheral moeten de oude sleutels op Central worden verwijderd en moet opnieuw worden gekoppeld.

Beheer in iOS

iOS beheert bonded apparaten automatisch via de systeemstack Core Bluetooth. De ontwikkelaar heeft geen directe API voor het bekijken of verwijderen van individuele bonded apparaten — beheer gebeurt via systeeminstellingen (Settings > Bluetooth > apparaat > Forget). Als programmatisch wissen van bonding nodig is, kan de app de gebruiker doorverwijzen naar de Bluetooth-systeeminstellingen met UIApplication.openSettingsURLString.

Beheer in Android

Android biedt een directe API voor het werken met bonded apparaten via de klasse BluetoothAdapter. De methode getBondedDevices() retourneert een Set<BluetoothDevice> van alle gekoppelde apparaten. Voor het verwijderen van bonding wordt de methode removeBond() gebruikt via reflectie of in Android 12+ de officiële API BluetoothDevice.removeBond().

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

Praktisch voorbeeld van Bonding-implementatie

Implementatie van bonding aan de Android-kant vereist correcte afhandeling van BroadcastReceiver voor BluetoothDevice.ACTION_BOND_STATE_CHANGED-gebeurtenissen. Bij de eerste verbinding met een apparaat start het Android-systeem automatisch bonding, als het apparaat deze mogelijkheid ondersteunt. De ontwikkelaar moet drie toestanden afhandelen: BOND_NONE (niet gekoppeld), BOND_BONDING (koppelingsproces), BOND_BONDED (gekoppeld).

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", "Bond verwijderd")
        }
    }
}

Bonding starten in Android

Om bonding in Android te starten, moet de methode createBond() op het BluetoothDevice-object worden aangeroepen. De methode retourneert een boolean — true, als het koppelingsproces succesvol is gestart. Vanaf Android 12 vereist createBond() de machtiging BLUETOOTH_CONNECT en kan het door het systeem worden geweigerd als de app geen achtergrondtoegang tot Bluetooth heeft.

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

Veelvoorkomende fouten bij het werken met Bonding

Ontwikkelaars van mobiele apps krijgen vaak te maken met veelvoorkomende fouten bij het werken met bonding van BLE-apparaten. Onjuiste afhandeling van bonding-toestanden kan leiden tot verbindingsfouten, onmogelijkheid om opnieuw te koppelen of gegevensverlies. Laten we de meest voorkomende problemen en hun oplossingen bekijken.

Firmware reset van Peripheral en verouderde bonding

Na het bijwerken van de firmware van een BLE-apparaat kunnen de bonding-sleutels worden gereset, maar de smartphone blijft verouderde sleutels (stale bonding) opslaan. Bij een verbindingspoging probeert Central de sessie met de oude LTK te herstellen, Peripheral wijst de sleutel af en de verbinding wordt niet tot stand gebracht. Oplossing — verwijder bonding op de smartphone via Settings > Bluetooth > Forget Device en voer opnieuw koppelen uit.

Limiet van het aantal bonded apparaten

BLE-chips hebben een beperking van het aantal opgeslagen bonding-records. Voor populaire Nordic nRF5x-chips is de limiet 8–20 records, afhankelijk van de configuratie. Bij overschrijding van de limiet accepteert het apparaat geen nieuwe koppelingen meer. Oplossing — verwijder ongebruikte bonding-records of gebruik een sleutelketen met prioriteitsopschoning.

Problemen met Privacy Feature

Bij gebruik van Privacy Feature (willekeurige MAC-adressen) verandert het apparaat periodiek zijn adres. Als Central de IRK niet heeft opgeslagen, kan het het nieuwe willekeurige adres niet koppelen aan een bekend apparaat. Oplossing — implementeer de opslag van IRK correct en gebruik het om RPA op te lossen bij elke detectie van het apparaat.