🛜
BLE通信：pairing時のセキュア通信について
ペアリングの流れとして、DH鍵交換からAES-CCMが用いられており、これによりセキュアな通信を実現しています。 本記事では、それぞれの役割や仕組みについて簡単に解説します。
DH鍵交換
基礎的な話ですが、鍵交換とは「AとBの通信が第三者に傍受可能な状態であっても、第三者にはわからない形でAとBが通信を通して共通の鍵値を生成できる仕組み」です。すごい。
DH鍵交換のシーケンス
※BLEでは標準でECDH(Elliptic Curve Diffie-Hellman)の楕円曲線暗号でサポートされています
- AとBは、それぞれ自分の秘密鍵（a, b）を生成
- 両者は共通の楕円曲線（P, G）を知っているとする
- Aは
A_pub = G^aを計算してBに送る - Bは
B_pub = G^bを計算してAに送る - Aは
Shared = B_pub^a = G^(ab)を計算 - Bは
Shared = A_pub^b = G^(ab)を計算
→ 両者は同じ G^(ab) を得るが、第三者は a も b もわからないので、共通鍵を導出できない
AES-CCM
秘匿された共通鍵は生成できましたので、通信の秘匿化はできますが、改ざん検知は出来ていない状態です。
それを実現するのが AES-CCM（Counter with CBC-MAC） です。
AES-CCMの中身（ざっくり）
-
AES-CTR：通信データの暗号化を行う（ブロック単位ではなくストリーム的に暗号化）
引用：はじめのiT -
CBC-MAC：暗号化前の平文に対してMAC（メッセージ認証コード）を生成し、改ざんを検知
引用：Wikipedia
→ 暗号化されたデータ + MACタグ が送信され、受信側はMACタグの検証を行うことで整合性（改ざん検知）を担保
認証
DH鍵とAES-CCMによって秘匿化と改ざん検知は実現できているため、セキュアな通信ラインは確保されています。
以降の認証は、用途に応じて簡易なものから高強度なものまで様々です。
ペアリング時の認証例
そんなに詳しくないのでGPTに聞いてみました。確かにそんな感じのあるなって、感じですよね。
| 認証方式 | 概要 | MITM耐性 | UI要件 |
|---|---|---|---|
| Just Works | 認証なし。自動で接続 | なし | 不要 |
| Passkey Entry | 双方で6桁の数字を入力・一致確認 | あり | 数字入力/表示 |
| Numeric Comparison | 双方の画面に数字を表示して一致を確認 | あり | ディスプレイ必要 |
| Out of Band（OOB） | NFC等の別経路で認証情報を共有 | あり | OOB機能必要 |
| 独自証明書 | アプリ層でX.509等の証明書を使う | 高強度 | 実装次第 |
まとめ
暗号系は一度しっかり見てみると、何のためにやっているかわかると割と面白いです。
BLEのような無線通信において、鍵交換・暗号化・認証が何のために行われるか分かると納得感があります。 基礎的な内容ですが、今後の設計や理解の一助になれば。
Discussion