Bondingとは何か、BLEペアリングのプロセスとセキュリティ

BLEにおけるBondingとは？

BondingはBluetooth Low Energyにおけるペアリングプロセスの拡張であり、デバイスが後続の接続のために暗号化キーを保存します。BLE標準は三つのセキュリティモードを定義しています: Security Mode 1 (認証なしの暗号化)、Security Mode 2 (暗号化なしのデータ署名)、Security Mode 3 (認証付きの暗号化)。ボンディングは、キーの再構築なしに繰り返し接続が必要な暗号化モードに関連します。

Bondingが必要な理由

ボンディングの主な目的は、デバイスが再接続する際の暗号化接続の自動復元です。ユーザーがケースからイヤホンを取り出して装着すると、ボンディングによってBluetoothメニューからデバイスを再選択することなくスマートフォンへの即時接続が保証されます。Apple Bluetooth Design Guidelines (2025)によると、ボンデッドデバイスは発見から2秒以内に接続する必要があります。

Bonding中に保存されるデータ

ボンディング中、各デバイスは暗号化材料のセットを保存します: 接続暗号化のためのLong Term Key (LTK)、ランダムアドレス解決のためのIdentity Resolving Key (IRK)、データ署名検証のためのConnection Signature Resolving Key (CSRK)。LTKはペアリング中に生成される128ビットの主キーで、その後のすべての暗号化セッションに使用されます。

BondingとPairingの違い

Pairingは現在のコミュニケーションセッションを暗号化するためのキーの一時的な交渉です。接続が終了すると暗号化キーは削除され、次の接続ではもう一度完全なペアリングプロセスが必要になります。Bondingはすべてのペアリング工程を含みますが、将来のセッションのためにキーを追加で保存します。ほとんどすべての消費者Bluetoothデバイス〈ヘッドホン、スピーカー、時計〉はボンディングを使用します。それがなければ、接続ごとにPINの再入力が必要になるからです。

PairingとBondingの三つのフェーズ

BLE仕様によるペアリングプロセスは、三つのフェーズから構成されます。フェーズ1 — デバイス機能の交換 (IO機能、認証サポート)。フェーズ2 — ペアリング方法に応じてShort Term Key (STK)またはLTKの生成と交換。フェーズ3 — キーのトランスポート: デバイス間でのLTK、IRK、CSRKの交換。デバイスがフェーズ3後にキーを保存した場合 — これがボンディングです。保存しなかった場合 — 単なるペアリングです。

Bondingプロセスの仕組み

ボンディングプロセスは、ペアリングが成功した後、一方のデバイスがキー保存リクエストを送信することで始まります。BLEでは、Central〈通常はスマートフォン〉とPeripheral〈装着可能デバイス〉が、フェーズ2で確立されたセキュアなチャネルを通じてキーを交換します。キー交換が成功した後、各デバイスはパートナーのMACアドレスまたはIdentity Addressとともに非幅発性メモリにキーを保存します。

Central側でのキー保存

Central側〈iOS/Android〉では、キーはシステムのBluetoothストレージに保存されます。iOSは自動ボンディング管理とともにCore Bluetoothシステムスタックを使用します: 初回のペアリング時にキーがデバイスのNVRAMに保存され、同じPeripheralへの後続接続は自動的に行われます。開発者はキーを直接管理せず、Core Bluetoothシステムスタックがキー保存をサポートするデバイスに接続する際に自動的にボンディングを処理します。

Bondingによる接続復元

再接続時、Peripheralは、そのパブリックアドレスまたはResolvable Private Address (RPA)を含む広告パケットを送信します。Centralはパケットを受け取り、保存されたボンデッドデバイスとアドレスを比較し、一致するものがあれば、保存されたLTKを使用してセッション復元を開始します。LTKが一致すれば、再ペアリングなしで暗号化接続が確立されます。

Bondingでの認証方法

BLE仕様は、ボンディングのセキュリティレベルに影響を与えるいくつかの認証方法を定義しています。方法の選択は、デバイスのIO機能、すなわちディスプレイやキーボードの有無、数字比較確認の可能性に依存します。セキュアなボンディングには、非重要なアプリケーションではJust Worksを、Man-in-the-Middle攻撃からの保護が必要なタスクではNumeric ComparisonまたはPasskey Entryを使用する必要があります。

Just Works

Just Worksは、一方のデバイスにディスプレイやキーボードがない場合に使用される認証不要の方法です。暗号化キーは、相手デバイスのアイデンティティを検証せずに送信されます — 温度センサー、心拍モニターなど。Just WorksはMITM攻撃に弱く、データの悪用が脅威とならないデバイスにのみ使用されます。

Numeric Comparison

Numeric Comparisonは、両方のデバイスが6桁の数字を表示し、ユーザーが一致を確認する認証方法です。この方法はMITM攻撃に対する保護を提供し、ディスプレイを備えたデバイス〈スマートウォッチ、フィットネストラッカー、リモコン〉に推奨されます。確認後、ボンディングは最大の信頼レベルで保存されます。

Passkey Entry

Passkey Entryは、一方のデバイスで6桁のPINを入力する必要があります。通常、コードは一方のデバイスで生成されディスプレイされ、ユーザーがもう一方のデバイスに入力します。この方法は、高いセキュリティが必要だが、Numeric Comparisonのためのディスプレイがない医療デバイスやIoTロックに使用されます。

iOSとAndroidでのボンデッドデバイスの管理

ボンディング管理は、ペアリング済みデバイスの保存されたキーを表示、削除、維持するプロセスです。モバイル開発では、特にPeripheralデバイスがリセットされたり、ファームウェアが置き換えられたりした場合、ボンデッドデバイスの状態を正しく処理することが重要です。Peripheralでのボンディングキーが変更された場合、Central上の古いキーを削除し、新たにペアリングを実行する必要があります。

iOSでの管理

iOSは、システムCore Bluetoothスタックを通じて自動的にボンデッドデバイスを管理します。開発者は個々のボンデッドデバイスを表示または削除するための直接のAPIを持ちません — 管理はシステム設定〈Settings > Bluetooth > デバイス > Forget〉を通じて行われます。プログラムでボンディングをクリアする必要がある場合、アプリはUIApplication.openSettingsURLStringを使用してユーザーをシステムのBluetooth設定に向けることができます。

Androidでの管理

AndroidはBluetoothAdapterクラスを通じてボンデッドデバイスと作業するための直接のAPIを提供しています。getBondedDevices()メソッドは、すべてのペアリング済みデバイスのSet<BluetoothDevice>を返します。ボンディングを削除するには、removeBond()メソッドをリフレクションで使用するか、Android 12+では公式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}")
}

Bonding実装の実践例

Androidでのボンディング実装には、BluetoothDevice.ACTION_BOND_STATE_CHANGEDイベントのためのBroadcastReceiverの正しい処理が必要です。デバイスへの初回接続時、Androidシステムはデバイスがこの機能をサポートしていれば、自動的にボンディングを開始します。開発者は三つの状態を処理する必要があります: BOND_NONE〈未ペアリング〉、BOND_BONDING〈ペアリング中〉、BOND_BONDED〈ペアリング済み〉。

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", "ボンドを削除しました")
        }
    }
}

AndroidでのBondingの開始

Androidでボンディングを開始するには、BluetoothDeviceオブジェクトのcreateBond()メソッドを呼び出す必要があります。このメソッドは、ペアリングプロセスが正常に開始された場合にtrueを返します。Android 12以降、createBond()にはBLUETOOTH_CONNECTパーミッションが必要で、アプリにバックグラウンドでのBluetoothアクセスがない場合、システムによって拒否される可能性があります。

fun initiateBonding(device: BluetoothDevice) {
    if (device.bondState == BluetoothDevice.BOND_NONE) {
        val success = device.createBond()
        if (success) {
            Toast.makeText(context, "Bondingを開始しました", Toast.LENGTH_SHORT)
        }
    }
}

Bondingでの一般的なミス

モバイルアプリ開発者は、BLEデバイスのボンディングで作業する際に、よく一般的なミスに遭遇します。ボンディング状態の不正な処理は、接続失敗、再ペアリング不可、データ丢失の原因となります。最もよくある問題とその解決策を見てみましょう。

Peripheralのファームウェアリセットとstale bonding

BLEデバイスのファームウェアアップデート後、ボンディングキーがリセットされる可能性がありますが、スマートフォンは古いキーを保持し続けます。接続を試みると、Centralは古いLTKでセッション復元を試み、Peripheralがキーを拒否し、接続が失敗します。解決策は、Settings > Bluetooth > Forget Deviceでスマートフォン上のボンディングを削除し、新たにペアリングを実行することです。

ボンデッドデバイス数の制限

BLEチップには、保存できるボンディング記録の数に制限があります。人気のNordic nRF5xチップの場合、構成に応じて制限は8〜20記録です。制限を超えると、デバイスは新しいペアリングを受け付けられなくなります。解決策は、使用していないボンディング記録を削除するか、クリーニング機能付きの優先度ベースのキーリングを使用することです。

Privacy Featureの問題

Privacy Feature〈ランダムMACアドレス〉を使用すると、デバイスは定期的にアドレスを変更します。CentralがIRKを保存していない場合、新しいランダムアドレスを己のデバイスと対応付けることができません。解決策は、IRKの保存を正しく実装し、デバイスが検出されるごとにRPAを解決することです。