🛜

BLE通信:接続について

に公開

概要

基礎的な内容ですが備忘録で。ConnectとPairingの違いや、それ以外の認証についてを整理します。


基本的な用語

簡単な用語について:

用語 説明
Peripheral 通常は「子機」。例:イヤホン、心拍計、センサーなど
Central 通常は「親機」。例:スマートフォン、PCなど

接続までのシーケンス

以下が典型的な流れです。


接続フェーズ

Peripheralは常にアドバタイズパケットを発信しています。

引用:ムセンコネクト

この中には以下のような情報が含まれることが多いです:

  • デバイス名
  • サービスUUID
  • その他(Tx Power Levelなど)

Centralは**スキャン(Scan)**を実行することでアドバタイズを受信し、一覧表示や接続候補の判断を行います。

スマホで「接続できるBluetoothデバイスのリスト」が出てくる状態がこれに該当します。

接続対象を選ぶと、Connectリクエストが送られ、BLEリンクが確立されます。


Pairingフェーズ

接続しただけでもそれなりに使えますが、peripheralによっては特定の機能にアクセスする際にセキュリティ要件がある場合、ペアリングを要求します。

  • 例:ロックの操作、ユーザーデータ書き込みなど

Pairing方式(代表例):

モード 説明
Just Works 認証なし。自動でペアリング
Passkey Entry PINを入力または表示して認証
Numeric Comparison 双方に数字を表示して確認
OOB(Out-of-Band) QRコードやNFCなどBLE外で情報交換

Bonding(ペアリング結果の保持)

ペアリングが成功した後、セントラルとペリフェラルは交換した鍵情報をそれぞれ不揮発領域に保存することができます。
これを**ボンディング(Bonding)**と呼びます。

→ 次回接続時、ペアリング不要で即暗号化通信が可能になります。


独自認証について

BLEの標準仕様では、認証とセキュリティの確立は Pairing(ペアリング) によって行われます。
しかし一部の機器では、独自に定義された認証プロトコル(準標準) を使用するケースがあります。

独自認証を使用する理由・ケース

  • より高度なセキュリティを実現したい場合(例:TLSに近い構成)
  • BLEスタックに依存せず、アプリ層で認証・暗号化を制御したい
  • 認証や鍵をクラウド連携で一元管理・更新したい(IoTゲートウェイなど)

具体例

機器の種類 独自認証の理由
医療機器 ペアリングUIが使えない+高度な認証要件がある
法人向けIoTセンサー クラウド上のデバイス管理と統合した認証が必要
ロッカー・キー制御装置 BLEだけでなくサーバー側との連携認証が必須

ペアリングを使わない=非セキュアではなく、むしろ独自認証でより強固に設計するケースもあります。


まとめ

BLEの基礎的な内容で、ペアリングとか普段から使ってると思いますが、案外それが何なのか開発したことない人は知らないかと思いますので残しておきます。

Discussion