Chapter 08

페어링과 보안

새 키보드를 노트북에 연결하면 “화면의 6자리 숫자를 키보드로 입력하세요”라는 창이 뜬다. 휴대폰 두 대를 연결하면 “두 화면의 숫자가 같습니까?”라고 묻는다. 무선 이어폰은 아무것도 묻지 않고 그냥 연결된다. 같은 블루투스인데 왜 이렇게 다를까? 그리고 이 숫자들은 정말로 무엇을 막아 주는 걸까? 이 장에서는 두 기기가 처음 만나 둘만 아는 키를 만드는 과정(페어링)을 따라가면서, 엿듣는 사람과 중간에 끼어드는 사람을 각각 어떻게 막는지 실제 암호 계산으로 확인한다. 그리고 광고 주소를 바꿔 가며 추적을 피하는 방법도 본다.

페어링의 세 단계(기능 교환 → 키 생성 → 키 배포)와 본딩의 뜻을 안다.
입출력 능력(IO capability)의 조합으로 Just Works·숫자 비교·패스키 입력·OOB가 정해지는 사양 표를 직접 돌려 본다.
레거시 페어링의 키가 왜 엿듣기에 약한지, LE Secure Connections의 P-256 타원곡선 디피-헬먼 교환이 이를 어떻게 막는지 설명한다.
숫자 비교와 패스키가 중간자 공격을 100만 분의 1 확률로 줄이는 원리를 g2 함수 계산으로 확인한다.
RPA(바뀌는 가명 주소)를 IRK와 AES-128로 만들고 해석하며, 15분 주기와 6.1의 무작위 갱신이 무엇을 막는지 안다.

무엇을 막아야 하나: 엿듣기, 끼어들기, 따라다니기

무선은 누구나 들을 수 있다. 블루투스 보안은 세 가지 위협을 구분해 다룬다.

도청(passive eavesdropping): 근처에서 전파를 녹음해 내용을 알아내는 것. 막으려면 둘만 아는 키로 암호화해야 하고, 그 키를 만드는 과정 자체가 엿들어도 안전해야 한다.
중간자 공격(MITM, man-in-the-middle): 공격자가 두 기기 사이에 끼어 각각에게 상대인 척하는 것. 양쪽과 따로 키를 만들어 중계하면서 내용을 읽고 바꾼다. 막으려면 “지금 키를 나눈 상대가 정말 저 기기인가”를 사람이 확인하는 인증이 필요하다.
추적(tracking): 내용은 몰라도 광고의 고정 주소를 따라가 사람의 동선을 알아내는 것. 막으려면 주소를 자주 바꾸되 친구는 알아볼 수 있어야 한다(프라이버시).

카페에서 둘만의 암호 정하기

처음 만난 두 손님이 시끄러운 카페에서 둘만의 암호를 정하고 싶다. 큰 소리로 암호를 말하면 옆 테이블이 다 듣는다(도청). 그래서 공개해도 되는 재료만 주고받고 각자 머릿속에서 같은 암호를 계산하는 방법을 쓴다(디피-헬먼). 그런데 웨이터가 중간에서 쪽지를 바꿔치기하면, 두 손님은 각자 웨이터와 암호를 정한 줄도 모른다(중간자). 그래서 마지막에 “제 쪽지에서 나온 숫자는 438912인데 당신도 그렇습니까?”라고 얼굴을 보고 확인한다(숫자 비교). 그 뒤 서로를 연락처에 저장하면(본딩) 다음에는 이 과정을 건너뛴다.

페어링의 세 단계와 본딩

LE 페어링은 호스트의 SMP(Security Manager Protocol)가 맡는다(1장). 연결된 상태에서 L2CAP 고정 채널로 진행된다.

① 기능 교환Pairing Request/Response로 입출력 능력, OOB 데이터 유무, MITM 보호 요구, Secure Connections 지원, 본딩 여부, 키 길이(7~16바이트)를 알린다.

② 키 생성①의 정보로 방식(Just Works, 숫자 비교, 패스키, OOB)을 정하고 키를 만든다. 레거시는 TK → STK, Secure Connections는 ECDH → LTK.

③ 키 배포링크를 암호화한 뒤 오래 쓸 키를 나눈다. 주소 해석용 IRK와 신원 주소, (레거시면) LTK. 예전에는 서명용 CSRK도 나눴지만 6.3에서 데이터 서명이 삭제되었다.

③에서 받은 키를 저장해 두는 것이 본딩(bonding)이다. 본딩한 두 기기는 다음 연결 때 페어링 없이 저장된 LTK로 바로 암호화를 시작한다(링크 계층의 Encryption Start, 6장). 휴대폰 블루투스 설정의 “등록된 기기” 목록이 본딩 목록이다. 암호화는 컨트롤러가 AES-CCM으로 하며, 패킷마다 4바이트 MIC(메시지 무결성 코드)를 붙여 위조를 막는다.

그림 8-1. LE 페어링의 세 단계. ①에서 두 기기가 능력을 알리면 ②에서 확인 방식이 정해지고 키가 만들어진다. 그 키로 링크를 암호화한 뒤 ③에서 오래 쓸 키를 나눈다. ③의 키를 저장해 두는 것이 본딩이고, 본딩한 기기는 다음 연결 때 페어링 없이 저장한 LTK로 바로 암호화를 시작한다.

페어링 방식·키 생성·배포: [Vol 3] Part H §2.3·§2.4 · 키 길이 7~16바이트: §2.3.4 · AES-CCM 링크 암호화와 MIC: [Vol 6] Part E §1 · LE 보안 모드 1의 네 단계(보안 없음 / 미인증 암호화 / 인증 암호화 / 128비트 LE Secure Connections 인증): [Vol 3] Part C §10.2.1

어떤 방식으로 확인할까: 입출력 능력의 조합

사람이 할 수 있는 확인은 기기가 가진 버튼과 화면에 달려 있다. 사양은 입력(없음 / 예·아니요 / 숫자 키보드)과 출력(없음 / 6자리 숫자 표시)을 조합해 기기를 다섯 종류의 입출력 능력(IO capability)으로 나눈다. DisplayOnly(시계), DisplayYesNo(휴대폰), KeyboardOnly(키보드), NoInputNoOutput(이어폰, 센서), KeyboardDisplay(노트북). 두 기기의 조합이 방식을 정한다.

Just Works: 아무것도 묻지 않는다. 도청은 Secure Connections면 막지만, 중간자는 막지 못한다(미인증).
숫자 비교(Numeric Comparison): 양쪽 화면에 같은 6자리 숫자가 뜨고 사람이 “예”를 누른다. Secure Connections 전용.
패스키 입력(Passkey Entry): 한쪽이 6자리를 보여 주고 다른 쪽에 입력한다(또는 둘 다 같은 숫자를 입력).
OOB(Out of Band): NFC 태그 대기 같은 다른 경로로 인증 정보를 나눈다.

SIMULATOR

페어링 방식 판정기 (사양 Table 2.6~2.8 그대로)

개시자(Initiator, 보통 휴대폰)
응답자(Responder, 보통 액세서리)

양쪽 모두 LE Secure Connections 지원 개시자 MITM 보호 요구 응답자 MITM 보호 요구 개시자가 상대의 OOB 데이터 보유 응답자가 상대의 OOB 데이터 보유

해볼 것: ① 휴대폰(DisplayYesNo) ↔ 이어폰(NoInputNoOutput): 어떤 설정이든 Just Works다. 이어폰에는 숫자를 보여 줄 화면도, “예”를 누를 버튼도 없기 때문이다. ② 휴대폰 ↔ 휴대폰: Secure Connections면 숫자 비교, 끄면(레거시) Just Works로 떨어진다. ③ 노트북(KeyboardDisplay) ↔ 키보드(KeyboardOnly): 노트북이 보여 주고 키보드로 입력한다. 레거시에서는 같은 패스키 입력이라도 6.2부터 사양 표가 “미인증” 키로 분류한다는 점을 보자(아래 설명). ④ 한쪽만 OOB 데이터를 가져도 Secure Connections면 OOB, 레거시면 양쪽 모두 가져야 OOB다.

IO 능력 매핑(Table 2.5), 레거시 OOB·MITM 규칙(Table 2.6), Secure Connections 규칙(Table 2.7), 방식 표(Table 2.8): [Vol 3] Part H §2.3.2·§2.3.5.1 · 패스키 000000~999999, 0도 포함해 6자리 모두 표시: §2.3.5.3

레거시 페어링의 약점과 Secure Connections

4.0~4.1의 레거시 페어링(LE legacy pairing)은 임시 키 TK에서 단기 키 STK를 만든다. Just Works면 TK = 0, 패스키면 TK = 그 6자리 숫자다. 문제는 STK를 만드는 데 쓰인 나머지 재료(난수 두 개)가 전부 공중으로 오간다는 것이다. 페어링 순간을 녹음한 공격자는 TK 후보 100만 개(000000~999999)를 집에서 하나씩 대입해 보면 된다. 요즘 컴퓨터로 1초도 걸리지 않는다. 그 뒤로는 그 연결의 모든 대화를 풀 수 있다. 이 공격은 2013년 공개 도구로 시연되었다.

4.2의 LE Secure Connections는 키를 만드는 방법을 바꿨다. 두 기기가 각자 P-256 타원곡선의 비밀 키와 공개 키를 만들고 공개 키만 교환한다. 각자 “내 비밀 키 × 상대 공개 키”를 계산하면 같은 값(DHKey)이 나오지만, 공개 키 둘만 들은 공격자는 그 값을 계산할 수 없다. 이것이 타원곡선 디피-헬먼(ECDH)이다. 그래서 Secure Connections는 Just Works라도 도청에는 안전하다. 남은 위협은 중간자다. 공격자가 양쪽에 자기 공개 키를 끼워 넣으면 양쪽과 각각 다른 DHKey를 만든다. 이를 사람이 잡아내는 것이 숫자 비교와 패스키다.

숫자 비교: 양쪽이 g2(PKax, PKbx, Na, Nb) = AES-CMAC의 하위 32비트를 계산하고, 그 10진 하위 6자리를 보여 준다. 공개 키가 바꿔치기되었다면 두 숫자는 0.999999의 확률로 다르다. 사람 눈이 마지막 방어선이다.
패스키(Secure Connections): 6자리 숫자는 20비트다. 이를 한 비트씩 20번에 나눠 확약(commit)과 공개를 주고받는다. 공격자는 비트마다 맞힐 확률 1/2로 도박해야 하고, 틀리면 들킨다. 레거시처럼 녹음 뒤 대입하는 길은 막힌다.

g2와 6자리 비교값(g2 mod 10⁶): [Vol 3] Part H §2.2.9 · 숫자 비교에서 단순 MITM이 다른 값을 낼 확률 0.999999: §2.3.5.6.2 · 패스키 20라운드: §2.3.5.6.3 · 샘플 데이터 D.5(g2), D.7(ah): [Vol 3] Part H Appendix D

SIMULATOR

숫자 비교 직접 해 보기: 진짜 P-256 키와 AES-CMAC

휴대폰 A

——————

공개 키 —

휴대폰 B

——————

공개 키 —

중간자가 공개 키를 바꿔치기

“새로 페어링”을 누를 때마다 브라우저의 WebCrypto로 두 기기의 실제 P-256 키 쌍과 128비트 난수 Na·Nb를 만들고, 사양의 g2 = AES-CMAC_Na(PKax ∥ PKbx ∥ Nb) mod 2³²를 계산해 하위 6자리를 보여 준다(AES-128과 CMAC은 이 페이지가 직접 계산한다). 해볼 것: ① 그냥 누르면 두 화면의 숫자가 같다. ② “중간자”를 켜면 A는 중간자와, B도 중간자와 따로 키를 만든다. 두 화면의 숫자가 다르게 나와 사람이 “아니요”를 누르게 된다. ③ “사양 샘플 D.5 계산”을 누르면 사양의 U·V·X·Y로 계산한 AES-CMAC이 1536d18d…2f9ed5ba와 같은지 확인한다. 단순화: 실제로는 DHKey로 LTK를 만들고(f5), 확인값(f4, f6)도 주고받는다.

6.2가 짚은 것: 레거시 패스키는 “미인증”

Core 6.2부터 방식 표(Table 2.8)는 같은 패스키 입력이라도 레거시 페어링에서는 미인증(Unauthenticated), Secure Connections에서는 인증(Authenticated) 키로 분류한다. 위에서 본 것처럼 레거시 패스키는 녹음 뒤 대입으로 풀리므로 “사람이 확인했다”는 보장이 의미가 없기 때문이다. 6.2에는 클래식(BR/EDR)의 Secure Simple Pairing 구현이 약한 패스키를 만들 수 있다는 보안 정정(erratum 24489)도 반영되었다. 클래식에서는 2019년 키 길이 협상을 1바이트까지 낮추는 KNOB 공격이 알려진 뒤, 최소 7바이트 키를 강제하는 것이 권고되었다.

레거시 패스키의 Unauthenticated 분류: [Vol 3] Part H Table 2.8 · 6.2 보안 정정 24489: [Vol 1] Part C §16.3

예측해 보기

LE Secure Connections를 지원하는 휴대폰과 이어폰(입출력 없음)이 페어링한다. 근처에서 녹음만 하는 도청자와, 중간에서 쪽지를 바꾸는 중간자 중 누구를 막을 수 있을까?

위 판정기에서 방식을 확인하고, ECDH가 무엇을 막는지 떠올려 보자.

입출력이 없으니 Just Works다. ECDH 덕분에 공개 키만 들은 도청자는 키를 계산할 수 없다. 하지만 사람이 확인할 수단이 없어 중간자의 바꿔치기는 잡지 못한다. 그래서 이어폰은 “케이스를 열었을 때만 페어링 모드”처럼 공격 기회를 줄이는 방식을 쓴다.

바뀌는 이름표: RPA로 추적 막기

5장에서 본 것처럼 광고에는 기기의 주소(AdvA)가 담긴다. 이 주소가 고정이면 거리 곳곳의 수신기가 한 사람의 이어폰을 따라다닐 수 있다. 그래서 LE는 몇 분마다 바뀌는 RPA(Resolvable Private Address, 해석 가능한 가명 주소)를 쓴다. 비결은 본딩 때 나눈 IRK(Identity Resolving Key)다.

RPA 48비트 = 상위 24비트 prand(맨 위 두 비트는 01, 나머지 22비트는 난수) + 하위 24비트 hash.
hash = ah(IRK, prand) = AES-128_IRK(0…0 ∥ prand)의 하위 24비트.
IRK를 가진 친구는 받은 주소의 prand로 hash를 계산해 보고, 맞으면 “아, 그 이어폰이구나” 하고 알아본다. IRK가 없는 사람에게는 매번 다른 무작위 주소로 보인다.

주소를 얼마나 자주 바꿀까? GAP는 TGAP(private_addr_int)를 15분(주소를 바꾸는 최대 간격)으로 권장한다. 그런데 모든 기기가 정확히 15분마다 바꾸면, 주소가 바뀌는 순간의 박자로 다시 이어 붙여 추적할 수 있다. 6.1은 컨트롤러가 최소~최대 범위 안의 무작위 시간마다 주소를 바꾸게 했다(HCI 기본값 8~15분).

무작위 주소 종류(상위 2비트 00 비해석, 01 RPA, 11 정적): [Vol 6] Part B §1.3.2 · RPA 생성과 해석: §1.3.2.2·§1.3.2.3 · ah 함수: [Vol 3] Part H §2.2.2 · TGAP(private_addr_int) 15 min: [Vol 3] Part C Appendix A · 무작위 RPA 갱신(RPA_Timeout_Min/Max, 기본 480~900 s): [Vol 4] Part E HCI_LE_Set_Resolvable_Private_Address_Timeout [v2]

SIMULATOR

가명 주소 만들고 알아보기: AES-128로 계산하는 RPA

주소를 보는 사람

본 주소 수—

같은 기기로 알아본 수—

사양 샘플 ah—

이어폰이 시간이 지날 때마다 새 RPA를 만든다. 주소의 파란 부분이 prand, 청록 부분이 hash다. 해볼 것: ① “친구”로 보면 모든 주소가 ✓(같은 이어폰)으로 해석된다. ② “낯선 수신기”는 다른 IRK로 계산하므로 하나도 연결하지 못한다. ③ “사양 샘플 D.7”은 IRK ec0234a3…7d9b, prand 0x708194로 hash 0x0dfbaa가 나오는지 확인한다. AES-128은 이 페이지에 구현된 코드로 계산하며 FIPS-197 예제로도 검증되어 있다.

핵심 정리

보안의 세 위협: 도청(암호화로), 중간자(사람의 인증으로), 추적(바뀌는 주소로).
페어링 = 기능 교환 → 키 생성 → 키 배포. 키를 저장하면 본딩. 암호화는 AES-CCM, 키 길이 7~16바이트.
방식은 두 기기의 입출력 능력으로 정해진다: Just Works(미인증), 숫자 비교(SC 전용), 패스키, OOB. 한쪽이 NoInputNoOutput이면 Just Works다.
레거시는 TK가 0 또는 6자리라 녹음 뒤 대입으로 풀린다(6.2 표에서 레거시 패스키도 미인증). Secure Connections(4.2)는 P-256 ECDH로 도청을 막고, 숫자 비교(g2 하위 6자리, MITM 성공 10⁻⁶)와 비트 단위 20라운드 패스키로 중간자를 막는다.
RPA = prand(상위 2비트 01) ∥ ah(IRK, prand). IRK를 가진 친구만 알아본다. 15분 이내마다 바꾸며, 6.1부터 바꾸는 시점을 무작위로 흩뜨린다.

확인 퀴즈

휴대폰(DisplayYesNo)과 스마트워치(DisplayYesNo)가 LE Secure Connections로 MITM 보호를 요구하며 페어링한다. 방식은?

둘 다 6자리를 보여 주고 예/아니요를 누를 수 있으므로 숫자 비교다. 레거시였다면 같은 조합이 Just Works가 된다.

레거시 Just Works 페어링을 녹음한 공격자가 키를 알아내는 데 필요한 것은?

레거시 Just Works의 TK는 0이고 나머지 재료는 공중으로 오가므로, 녹음만으로 STK를 계산할 수 있다. 패스키라도 후보가 100만 개뿐이다.

LE Secure Connections의 Just Works가 막지 못하는 것은?

ECDH는 도청을 막지만, 상대 공개 키가 진짜인지 확인할 수단이 없으면 중간자를 잡지 못한다. 그래서 Just Works 키는 “미인증”이다.

Secure Connections의 패스키 입력이 6자리를 한 번에 확인하지 않고 20번에 나눠 확인하는 이유는?

999999 = 0xF423F로 20비트다. 비트마다 확약을 먼저 받고 공개하므로, 공격자는 각 비트를 1/2 확률로 맞혀야 하고 한 번 틀리면 페어링이 실패한다.

RPA 주소의 최상위 두 비트는?

무작위 주소의 상위 두 비트: 00 비해석 가명, 01 해석 가능 가명(RPA), 11 정적 주소, 10 예약.

6.1의 “무작위 RPA 갱신”이 막으려는 것은?

교체 시점이 규칙적이면 “이 주소가 사라진 순간 저 주소가 나타났다”로 이어 붙일 수 있다. 최소~최대 사이 무작위 시간에 바꾸면 그 단서가 흐려진다.