Bonding: vad det är, processen och säkerheten för BLE-parning

Vad är Bonding i BLE?

Bonding — är en utökning av parningsprocessen i Bluetooth Low Energy där enheter sparar krypteringsnycklar för efterföljande anslutningar. BLE-standarden definierar tre säkerhetslägen: Security Mode 1 (kryptering utan autentisering), Security Mode 2 (datasignering utan kryptering) och Security Mode 3 (kryptering med autentisering). Bonding är relevant för lägen med kryptering när flera anslutningar krävs utan omförhandling av nycklar.

Varför Bonding behövs

Det främsta syftet med bonding är automatisk återställning av krypterad anslutning vid återanslutning av enheter. När användaren tar ut hörlurarna ur fodralet och sätter på dem, säkerställer bonding omedelbar anslutning till smarttelefonen utan att behöva välja enheten igen i Bluetooth-menyn. Enligt Apple Bluetooth Design Guidelines (2025) ska parade enheter ansluta på mindre än 2 sekunder från upptäckt.

Vilka data sparas vid Bonding

Vid bonding sparar varje enhet en uppsättning kryptografiskt material: Long Term Key (LTK) för anslutningskryptering, Identity Resolving Key (IRK) för upplösning av slumpmässiga adresser, Connection Signature Resolving Key (CSRK) för verifiering av datasignaturer. LTK är huvudnyckeln på 128 bitar som genereras under parningsprocessen och används för alla efterföljande krypterade sessioner.

Bonding vs Pairing: vad är skillnaden

Pairing — är tillfällig nyckelförhandling för kryptering av den aktuella kommunikationssessionen. När anslutningen avslutas raderas krypteringsnycklarna och vid nästa anslutning krävs en ny parningsprocess. Bonding inkluderar alla steg i pairing men sparar dessutom nycklarna för framtida sessioner. Praktiskt taget alla konsument-Bluetooth-enheter (hörlurar, högtalare, klockor) använder bonding eftersom varje anslutning annars skulle kräva ny PIN-inmatning.

Tre faser av Pairing och Bonding

Parningsprocessen enligt BLE-specifikationen består av tre faser. Fas 1 — utbyte av enhetskapacitet (IO capabilities, autentiseringsstöd). Fas 2 — generering och utbyte av Short Term Key (STK) eller LTK, beroende på parningsmetod. Fas 3 — nyckeltransport: utbyte av LTK, IRK, CSRK mellan enheter. Om enheterna sparade nycklarna efter Fas 3 — är det bonding. Om inte — är det bara pairing.

Hur fungerar Bondingprocessen

Bondingprocessen initieras efter framgångsrikt slutförd pairing när en av enheterna skickar en begäran om att spara nycklar. I BLE utbyter Central (vanligtvis smartphone) och Peripheral (bärbar enhet) nycklar via en säker kanal som etablerats i Fas 2. Efter framgångsrikt nyckelutbyte sparar varje enhet nycklarna i icke-flyktigt minne tillsammans med partnerns MAC-adress eller identitetsadress.

Nyckellagring på Central-sidan

På Central-sidan (iOS/Android) lagras nycklar i systemets Bluetooth-lagring. iOS använder systemstacken Core Bluetooth med automatisk bondinghantering: vid första parningen sparas nycklar i enhetens NVRAM och efterföljande anslutningar till samma Peripheral sker automatiskt. Utvecklaren hanterar inte nycklar direkt — systemstacken Core Bluetooth hanterar bonding automatiskt vid anslutning till en enhet som stöder nyckellagring.

Återställning av anslutning via Bonding

Vid återanslutning skickar Peripheral reklampaket som innehåller antingen sin publika adress eller en Resolvable Private Address (RPA). Central tar emot paketet, matchar adressen med sparade parade enheter och om en matchning hittas initierar den sessionsåterställning med det sparade LTK. Om LTK matchar — skapas den krypterade anslutningen utan ny pairing.

Autentiseringsmetoder vid Bonding

BLE-specifikationen definierar flera autentiseringsmetoder som påverkar säkerhetsnivån för bonding. Valet av metod beror på enheternas IO capabilities — närvaro av display, tangentbord, möjlighet till numerisk jämförelsebekräftelse. Säker bonding kräver användning av metod minst Just Works för icke-kritiska applikationer och Numeric Comparison eller Passkey Entry för uppgifter som kräver skydd mot Man-in-the-Middle-attacker.

Just Works

Just Works — metod utan autentisering som används när en av enheterna saknar display eller tangentbord. Krypteringsnycklar överförs utan verifiering av den andra enhetens identitet — termometer, pulsoximeter). Just Works är sårbart för MITM-attacker och används därför endast för enheter där datakompromettering inte utgör ett hot.

Numeric Comparison

Numeric Comparison — autentiseringsmetod där båda enheterna visar ett sexsiffrigt nummer och användaren måste bekräfta att de matchar. Denna metod ger skydd mot MITM-attacker och rekommenderas för enheter med display — smartklockor, fitnessspårare, fjärrkontroller. Efter bekräftelse sparas bonding med högsta förtroendenivå.

Passkey Entry

Passkey Entry kräver inmatning av en sexsiffrig PIN-kod på en av enheterna. Vanligtvis genereras koden av en enhet och visas på den, medan användaren anger den på den andra. Metoden används för medicintekniska produkter och IoT-lås där hög säkerhetsnivå krävs men en av enheterna saknar display för Numeric Comparison.

Hantering av parade enheter i iOS och Android

Bondinghantering — är processen att visa, ta bort och underhålla sparade nycklar för parade enheter. Inom mobilutveckling är det viktigt att korrekt hantera tillstånd för parade enheter, särskilt vid återställning av peripherals enhet eller byte av dess firmware. När bondingsnycklar på Peripheral ändras måste gamla nycklar på Central tas bort och ny parning utföras.

Hantering i iOS

iOS hanterar automatiskt parade enheter via systemets Core Bluetooth-stack. Utvecklaren har inget direkt API för att visa eller ta bort enskilda parade enheter — hantering sker via systeminställningar (Settings > Bluetooth > enhet > Forget). Om bonding måste rensas programmatiskt kan applikationen skicka användaren till systemets Bluetooth-inställningar med UIApplication.openSettingsURLString.

Hantering i Android

Android tillhandahåller direkt API för arbete med parade enheter via klassen BluetoothAdapter. Metoden getBondedDevices() returnerar Set<BluetoothDevice> av alla parade enheter. För borttagning av bonding används metoden removeBond() via reflektion eller från Android 12+ det officiella API:et BluetoothDevice.removeBond().

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

Praktiskt exempel på Bonding-implementering

Bonding-implementering på Android-sidan kräver korrekt hantering av BroadcastReceiver för BluetoothDevice.ACTION_BOND_STATE_CHANGED-händelser. Vid första anslutningen till en enhet initierar Android-systemet automatiskt bonding om enheten stöder denna funktion. Utvecklaren måste hantera tre tillstånd: BOND_NONE (inte parad), BOND_BONDING (parningsprocess), BOND_BONDED (parad).

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", "Bonding borttagen")
        }
    }
}

Initiering av Bonding på Android

För att initiera bonding på Android måste metoden createBond() anropas på BluetoothDevice-objektet. Metoden returnerar boolean — true om parningsprocessen startades framgångsrikt. Från och med Android 12 kräver createBond() tillståndet BLUETOOTH_CONNECT och kan avvisas av systemet om applikationen inte har bakgrundsåtkomst till Bluetooth.

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

Vanliga misstag vid arbete med Bonding

Utvecklare av mobila applikationer stöter ofta på vanliga misstag vid arbete med bonding av BLE-enheter. Felaktig hantering av bondingtillstånd kan leda till anslutningsfel, omöjlighet att para om eller dataförlust. Låt oss titta på de vanligaste problemen och deras lösningar.

Återställning av Peripheral firmware och stale bonding

Efter uppdatering av BLE-enhetens firmware kan dess bondingsnycklar återställas, men smarttelefonen fortsätter att lagra föråldrade nycklar (stale bonding). Vid anslutningsförsök försöker Central återställa sessionen med den gamla LTK, Peripheral avvisar nyckeln och anslutningen upprättas inte. Lösning — ta bort bonding på smarttelefonen via Settings > Bluetooth > Forget Device och utför omparning.

Gräns för antal parade enheter

BLE-chip har en begränsning på antalet lagrade bondingsposter. För populära Nordic nRF5x-chip är gränsen 8-20 poster beroende på konfiguration. Vid överskridande av gränsen slutar enheten att acceptera nya parningar. Lösning — ta bort oanvända bondingsposter eller använd ett nyckelsystem med prioriterad rensning.

Problem med Privacy Feature

Vid användning av Privacy Feature (slumpmässiga MAC-adresser) ändrar enheten periodiskt sin adress. Om Central inte sparade IRK kan den inte matcha den nya slumpmässiga adressen med en känd enhet. Lösning — implementera korrekt lagring av IRK och använd den för att lösa RPA vid varje enhetsdetektering.