Bonding: cos’è, processo e sicurezza dell’abbinamento BLE

Cos’è il Bonding in BLE?

Bonding è un’estensione del processo di pairing in Bluetooth Low Energy, in cui i dispositivi archiviano chiavi di crittografia per connessioni successive. Lo standard BLE definisce tre modalità di sicurezza: Security Mode 1 (crittografia senza autenticazione), Security Mode 2 (firma dei dati senza crittografia) e Security Mode 3 (crittografia con autenticazione). Il bonding è rilevante per le modalità con crittografia dove sono necessarie connessioni ripetute senza rinnovo delle chiavi.

Perché serve il Bonding

Lo scopo principale del bonding è il ripristino automatico delle connessioni crittografate quando i dispositivi si riconnettono. Quando un utente toglie gli auricolari dalla custodia e li indossa, il bonding garantisce una connessione immediata allo smartphone senza dover selezionare nuovamente il dispositivo dal menu Bluetooth. Secondo le Apple Bluetooth Design Guidelines (2025), i dispositivi associati devono connettersi entro non più di 2 secondi dal rilevamento.

Quali dati vengono archiviati durante il Bonding

Durante il bonding, ogni dispositivo archivia un insieme di materiali crittografici: Long Term Key (LTK) per la crittografia della connessione, Identity Resolving Key (IRK) per risolvere gli indirizzi casuali e Connection Signature Resolving Key (CSRK) per verificare le firme dei dati. LTK è la chiave primaria a 128 bit generata durante il pairing e utilizzata per tutte le successive sessioni crittografate.

Bonding vs Pairing: qual è la differenza

Pairing è la negoziazione temporanea di chiavi per crittografare la sessione di comunicazione corrente. Quando la connessione termina, le chiavi di crittografia vengono eliminate e la connessione successiva richiede un nuovo processo completo di pairing. Bonding include tutte le fasi del pairing ma archivia inoltre le chiavi per sessioni future. Praticamente tutti i dispositivi Bluetooth di consumo (cuffie, altoparlanti, orologi) utilizzano il bonding perché senza di esso, ogni connessione richiederebbe il reinserimento del PIN.

Tre fasi del Pairing e del Bonding

Il processo di pairing secondo la specifica BLE consiste in tre fasi. Fase 1 — scambio delle capacità del dispositivo (capacità IO, supporto all’autenticazione). Fase 2 — generazione e scambio di Short Term Key (STK) o LTK, a seconda del metodo di abbinamento. Fase 3 — trasporto delle chiavi: scambio di LTK, IRK, CSRK tra i dispositivi. Se i dispositivi hanno archiviato le chiavi dopo la Fase 3 — questo è bonding. Se no — è semplicemente pairing.

Come funziona il processo di Bonding

Il processo di bonding viene avviato dopo il completamento con successo del pairing, quando un dispositivo invia una richiesta di archiviazione delle chiavi. In BLE, il Central (di solito uno smartphone) e il Peripheral (dispositivo indossabile) scambiano chiavi attraverso il canale sicuro stabilito nella Fase 2. Dopo il riuscito scambio di chiavi, ogni dispositivo le archivia in memoria non volatile insieme all’indirizzo MAC o all’Identity Address del partner.

Archiviazione delle chiavi lato Central

Sul lato Central (iOS/Android), le chiavi vengono archiviate nell’archivio Bluetooth di sistema. iOS utilizza lo stack di sistema Core Bluetooth con gestione automatica del bonding: al primo abbinamento, le chiavi vengono salvate nella NVRAM del dispositivo e le connessioni successive allo stesso Peripheral avvengono automaticamente. Lo sviluppatore non gestisce le chiavi direttamente — lo stack di sistema Core Bluetooth gestisce il bonding automaticamente quando si connette a un dispositivo che supporta l’archiviazione delle chiavi.

Ripristino della connessione tramite Bonding

Alla riconnessione, il Peripheral invia pacchetti pubblicitari contenenti il suo indirizzo pubblico o un Resolvable Private Address (RPA). Il Central riceve il pacchetto, confronta l’indirizzo con i dispositivi associati archiviati e, se trova una corrispondenza, avvia il ripristino della sessione utilizzando il LTK archiviato. Se il LTK corrisponde, la connessione crittografata viene stabilita senza ripetere il pairing.

Metodi di autenticazione nel Bonding

La specifica BLE definisce diversi metodi di autenticazione che influenzano il livello di sicurezza del bonding. La scelta del metodo dipende dalle capacità IO dei dispositivi — se hanno display, tastiera o la possibilità di confermare il confronto numerico. Un bonding sicuro richiede l’uso almeno di Just Works per applicazioni non critiche e Numeric Comparison o Passkey Entry per attività che richiedono protezione dagli attacchi Man-in-the-Middle.

Just Works

Just Works è un metodo senza autenticazione utilizzato quando uno dei dispositivi non ha display o tastiera. Le chiavi di crittografia vengono trasmesse senza verificare l’identità del secondo dispositivo — sensori di temperatura, cardiofrequenzimetri. Just Works è vulnerabile agli attacchi MITM, quindi viene utilizzato solo per dispositivi in cui la compromissione dei dati non rappresenta una minaccia.

Numeric Comparison

Numeric Comparison è un metodo di autenticazione in cui entrambi i dispositivi mostrano un numero di sei cifre e l’utente deve confermare la corrispondenza. Questo metodo fornisce protezione contro gli attacchi MITM ed è raccomandato per dispositivi con display — smartwatch, tracker fitness, telecomandi. Dopo la conferma, il bonding viene archiviato con il massimo livello di fiducia.

Passkey Entry

Passkey Entry richiede l’inserimento di un PIN a sei cifre su uno dei dispositivi. Di solito, il codice viene generato da un dispositivo e visualizzato su di esso, mentre l’utente lo inserisce sul secondo dispositivo. Questo metodo viene utilizzato per dispositivi medici e serrature IoT dove è richiesto un alto livello di sicurezza ma uno dei dispositivi non ha display per Numeric Comparison.

Gestione dei dispositivi associati in iOS e Android

La gestione del bonding è il processo di visualizzazione, eliminazione e manutenzione delle chiavi archiviate dei dispositivi abbinati. Nello sviluppo mobile, è importante gestire correttamente gli stati dei dispositivi associati, specialmente quando un dispositivo periferico viene resettato o il suo firmware viene sostituito. Quando le chiavi di bonding sul Peripheral cambiano, le vecchie chiavi sul Central devono essere rimosse e deve essere effettuato un nuovo abbinamento.

Gestione in iOS

iOS gestisce automaticamente i dispositivi associati attraverso lo stack di sistema Core Bluetooth. Lo sviluppatore non ha un’API diretta per visualizzare o eliminare singoli dispositivi associati — la gestione avviene attraverso le impostazioni di sistema (Impostazioni > Bluetooth > dispositivo > Forget). Se è necessario cancellare il bonding a livello di programma, l’app può indirizzare l’utente alle impostazioni Bluetooth di sistema utilizzando UIApplication.openSettingsURLString.

Gestione in Android

Android fornisce un’API diretta per lavorare con i dispositivi associati attraverso la classe BluetoothAdapter. Il metodo getBondedDevices() restituisce un Set<BluetoothDevice> di tutti i dispositivi abbinati. Per rimuovere il bonding, il metodo removeBond() viene utilizzato tramite riflessione o, su Android 12+, l’API ufficiale BluetoothDevice.removeBond().

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

Esempio pratico di implementazione del Bonding

L’implementazione del bonding su Android richiede la corretta gestione del BroadcastReceiver per gli eventi BluetoothDevice.ACTION_BOND_STATE_CHANGED. Al primo collegamento a un dispositivo, il sistema Android avvia automaticamente il bonding se il dispositivo supporta questa capacità. Lo sviluppatore deve gestire tre stati: BOND_NONE (non abbinato), BOND_BONDING (abbinamento in corso), BOND_BONDED (abbinato).

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", "Associazione rimossa")
        }
    }
}

Avviare il Bonding su Android

Per avviare il bonding su Android, il metodo createBond() deve essere chiamato sull’oggetto BluetoothDevice. Il metodo restituisce un booleano — true se il processo di abbinamento è stato avviato con successo. A partire da Android 12, createBond() richiede l’autorizzazione BLUETOOTH_CONNECT e può essere rifiutato dal sistema se l’app non ha accesso Bluetooth in background.

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

Errori comuni nel lavoro con Bonding

Gli sviluppatori di app mobili incontrano spesso errori comuni quando lavorano con il bonding di dispositivi BLE. Una gestione errata degli stati di bonding può portare a fallimenti di connessione, impossibilità di riabbinare o perdita di dati. Esaminiamo i problemi più frequenti e le loro soluzioni.

Reset del firmware del Peripheral e stale bonding

Dopo un aggiornamento del firmware di un dispositivo BLE, le sue chiavi di bonding possono essere resettate, ma lo smartphone continua a memorizzare le vecchie chiavi (stale bonding). Quando si tenta di connettere, il Central cerca di ripristinare la sessione con il vecchio LTK, il Peripheral rifiuta la chiave e la connessione fallisce. La soluzione è rimuovere il bonding sullo smartphone tramite Impostazioni > Bluetooth > Forget Device ed effettuare un nuovo abbinamento.

Limite del numero di dispositivi associati

I chip BLE hanno un limite sul numero di record di bonding archiviabili. Per i popolari chip Nordic nRF5x, il limite è di 8-20 record a seconda della configurazione. Quando il limite viene superato, il dispositivo smette di accettare nuovi abbinamenti. La soluzione è rimuovere i record di bonding inutilizzati o utilizzare un portachiavi con pulizia prioritaria.

Problemi con la funzione Privacy

Quando si utilizza la funzione Privacy (indirizzi MAC casuali), il dispositivo cambia periodicamente il suo indirizzo. Se il Central non ha archiviato l’IRK, non può associare il nuovo indirizzo casuale a un dispositivo noto. La soluzione è implementare correttamente l’archiviazione IRK e utilizzarlo per risolvere RPA ad ogni rilevamento del dispositivo.