Bonding: BLE 페어링의 과정과 보안

BLE에서 Bonding이란?

Bonding은 Bluetooth Low Energy에서 페어링 과정의 확장으로, 기기가 후속 코넗션을 위해 암호화 키를 저장합니다. BLE 표준은 세 가지 보안 모드를 정의합니다: Security Mode 1 (인증 없는 암호화), Security Mode 2 (암호화 없는 데이터 서명), Security Mode 3 (인증이 있는 암호화). Bonding은 키 재구성 없이 반복 접속이 필요한 암호화 모드에 적합합니다.

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 vs 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에서 본딩 키가 변경되면 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 기기 펜웨어 업데이트 후, 본딩 키가 리셋될 수 있지만 스마트폰은 구 키를 계속 저장합니다(stale bonding). 접속을 시도하면 Central이 구 LTK로 세션을 복원하려고 시도하고, Peripheral이 키를 거부하며 코넗션이 실패합니다. 해결 방법은 Settings > Bluetooth > Forget Device를 통해 스마트폰에서 본딩을 제거하고 새로운 페어링을 수행하는 것입니다.

본딩 기기 수 제한

BLE 칩은 저장 가능한 본딩 레코드 수에 제한이 있습니다. 인기있는 Nordic nRF5x 칩의 경우 구성에 따라 8-20개입니다. 제한을 초과하면 기기가 새 페어링을 봇아들이지 않습니다. 해결 방법은 사용하지 않는 본딩 레코드를 제거하거나 우선순위 기반의 키 링을 청소함과 함께 사용하는 것입니다.

Privacy Feature 문제

Privacy Feature(무작위 MAC 주소)를 사용할 때, 기기는 주기적으로 주소를 변경합니다. Central이 IRK를 저장하지 않은 경우, 새 무작위 주소를 알려진 기기와 매칭할 수 없습니다. 해결 방법은 IRK 저장을 올바르게 구현하고 기기 검출시마다 RPA를 해결하는 것입니다.