BLEのペアリング処理を観察する

こちらは脆弱エンジニアの Advent Calendar 2024 21日目の記事です

はじめに

こんにちは，ocha-nです．

セキュリティのお勉強をしたり，岡山で大学生をしたり，Okayama-Revengers(Okarev) という技術コミュニティの運営をしたりしています．
こちらの記事は，私が第3回OkarevLTで発表した内容をもとに作成しております．
もし少しでも楽しそうかも，と思って下さった方がいれば，是非次回のLTへ！(岡山県民以外も大歓迎です🫶)

概要

BLE(Bluetooth Low Energy) のペアリング処理の様子をHCIスヌープログから観察します．
今回はLE Secure Connectionで，Association ModelとしてNumeric Comparisonが選択される場合の，Phase 1: Pairing Feature Exchange, Phase 2: Authentication and Key Generation の部分を観察します．

前提知識

LE Secure Connections

データの暗号化鍵であるLTK(Long Term Key)の交換にEDCH(楕円曲線ディフィー・ヘルマン鍵共有)を用いる方法．
従来の方法であり，2つのペアリング方法のうちもう1つの方法であるLE Legacy PairingはLTKを無線区間で送信する必要があったが，LE Secure ConnectionsはLTKを無線区間で送信しないため，比較的安全である．
Bluetooth 4.2から導入された．

IO Capability

各デバイスの入出力機能

以下のように分けられる:

• DisplayOnly: 数値を表示できるが入力機能はない
• DisplayYesNo: 数値の表示と「Yes/No」の入力が可能
• KeyboardOnly: 数値の入力のみが可能
• NoInputNoOutput: 入力・出力ともに機能なし
• KeyboardDisplay: 数値の表示と入力が可能

Association Models^[1]

ペアリングする時にパスキーを入力したり，しなかったりするアレである．
デバイス間のペアリングにおいて、認証情報をどのように共有するかを定義している．
デバイスのIO Capabilityに基づいて選択される．

LE Secure Connectionsでは4種類のAssociation Modelsがある:

• Just Works : ユーザーによる操作を必要としない
• Passkey Entry : 片方の端末で6つの数字を表示,もう一方の端末でその数字を入力させる
• Out of Band (OOB) : NFCなどBluetooth以外の通信経路を使用してパスキーや関連情報を交換する
• Numeric Comparison : 共通の6つの数字を表示し,同一であることを確認させる

出典: Bluetooth SIG. (n.d.). Bluetooth pairing part 2: Key generation methods. Retrieved December 22, 2024, from https://www.bluetooth.com/blog/bluetooth-pairing-part-2-key-generation-methods/

いざ

使用するもの

• Raspberry Pi 3B+ [ペリフェラル(子機)]
  • BlueZ, bluetoothctl : Bluetooth通信，その設定
  • btmon : ログ取得
• Zenfone4 [セントラル(親機)]
• PC
  • Wireshark : ログの解析

手順

• [Raspberry Pi] Bluetooth アダプターの動作モードをLow Energy (LE) モードに限定する
  /etc/bluetooth/main.conf

  # Restricts all controllers to the specified transport. Default value
  # is "dual", i.e. both BR/EDR and LE enabled (when supported by the HW).
  # Possible values: "dual", "bredr", "le"
  ControllerMode = le
  

• [Raspberry Pi] DisplayYesNo, discoverable on に設定する (bluetoothctl)
• [Raspberry Pi] PeripheralとしてAdvertisementを送信 (bluetoothctl)
• [Zenfone4] Raspberry Pi を選択してペアリングするよう操作する

ペアリング完了後

• [PC] btmonで取得したHCIスヌープログをWiresharkで開く

ペアリングの流れ

今回はLE Secure Connectionで，Association ModelとしてNumeric Comparisonが選択されるような設定にしています．
実際に観察する前に，仕様書を読んで観測されるはずのペアリングの流れを確認しておきます．
まず，Phase1でセントラルからペリフェラルへPairing Request, ペリフェラルからセントラルへPairing Responseが送信されます．^[2]
その後，Phase2は以下のような流れになります．^[3]

Phase2

では，ログファイルを観察していきます．
今回見たいのはSecurity Manager Protocol (SMP)の通信なので btsmp でフィルタをかけます．
画像の白く塗りつぶされている部分はセントラルのMACアドレス，localhost() はペリフェラルを指します．

Pairing Request (セントラル → ペリフェラル)^[4]

Pairing Request
Initiator，今回の場合セントラルが，Responder，今回の場合ペリフェラルにペアリング要求を送信する．
サポートする機能についての情報も含まれ，次のPairing Responseと合わせて互換性の確認，ペアリング手法の選択が行われる．

以下のような情報が含まれる:

• IO Capability : Keyboard, Display
• LE Secure Connectionsのサポート可否 : True
• ボンディングを希望するか否か : Bonding

ボンディング(Bonding)

一度ペアリングしたデバイスが再接続する際に再ペアリング処理を行う必要がないよう,セキュリティ情報を保存するプロセス^[5]

Pairing Response (ペリフェラル → セントラル)^[6]

Pairing Response
ペリフェラルがペアリングの許可をしている．
Pairing Requestと同じくサポートする機能についての情報などが含まれる．

• IO Capability : Display Yes/No
  → セントラルが Keyboard, Display ，かつ， LE Secure Connectionsが使用されるので，Association Modelは Numeric Comparison に
• LE Secure Connectionsのサポート可否 : True
  → セントラルもサポートしているのでLE Secure Connectionsが使用される
• ボンディングを希望するか否か : Bonding
  → セントラルもしたがっているのでボンディングされる

Pairing Public Key (セントラル ↔ ペリフェラル)^[7]

Pairing Public Key セントラル→ペリフェラル

Pairing Public Key ペリフェラル→セントラル

公開鍵を交換する．

nonce生成 (セントラル，ペリフェラル)

リプレイ攻撃などを防ぐために使用される．

• Na : セントラルの128bit nonce
• Nb : ペリフェラルの128bit nonce

Pairing Confirm (ペリフェラル → セントラル)^[8]

Pairing Confirm

ペリフェラルで，Nb, PKa, PKb，0 を使用した確認値Cbを計算，セントラルへ送信する．

Pairing Random (セントラル ↔ ペリフェラル)^[9]

Pairing Random セントラル→ペリフェラル

Pairing Random ペリフェラル→セントラル

それぞれ生成したNa,Nbを送信する．

確認値 Cb の計算，確認 (セントラル)

受信したNbを使用して，Cbを計算．
受信したCbと計算したCbが一致することを確認する．
一致しない場合，攻撃者の存在あるいは送信エラーがあったとしてペアリングプロセスを終了する．

ユーザーによる確認 (セントラル，ペリフェラル)

セントラル

ペリフェラル
セントラル，ペリフェラル，それぞれでPKa, PKb, Na, Nb を用いて6桁の値を計算．
画面に表示させる．
ユーザーは各デバイスに表示されている値が一致していることを確認する．

Long Term Key (LTK) の生成 (セントラル，ペリフェラル)

ペアリング後の接続を暗号化するために使用される鍵であるLong Term Key (LTK)を生成する.

Pairing DHKey Check (セントラル ↔ ペリフェラル)^[10]

Pairing DHKey Check セントラル→ペリフェラル

Pairing DHKey Check ペリフェラル→セントラル

DHKeyをもとに確認値を計算，交換しDHKeyが正しく生成されたことを確認する．

(Phase2まで) 完了😎

この後Phase3として必要な暗号化キーの配布などがあり，その後，生成されたLTKを用いて接続を暗号化できたらペアリング完了となります．

まとめ

btmonを使用して，HCIスヌープログを取得し，Security Manager Protocol (SMP)の通信を観察することでBLEのLTKの交換までの様子を観察することができました．
個人的に，Bluetoothについての知識がゼロだった (BLEとBluetooth Classicがあるのを知らなかった🥺) のですが，仕様書が図も多く読みやすくて助かりました．
知らない事ばかりでとても面白かったです．
Association Modelsについては，何になるのかわからないおみくじ的な何かだと思っていたので，ちゃんと決まってたんや...と感動しました．
今回まとめきれなかったのですが，Phase3についてなど，他にも色々調べたので，また残せたらと思います．

脚注

1. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 313, 5.2.4 Association models

2. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1694, C.1 Phase 1: Pairing feature exchange

3. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1694, C.2 Phase 2: Authenticating and encrypting

4. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1667, 3.5.1 Pairing Request

5. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1402, 9.4 Bonding modes and procedures

6. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1670, 3.5.2 Pairing Response

7. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1676, 3.5.6 Pairing Public Key

8. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1672, 3.5.3 Pairing Confirm

9. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1673, 3.5.4 Pairing Random

10. BLUETOOTH CORE SPECIFICATION Version 6.0 Page 1676, 3.5.7 Pairing DHKey Check