接続製品におけるBluetoothモジュールセキュリティの重要性
エンジニアが新製品向けにBluetoothモジュールを評価する際、通常は消費電力、通信距離、フォームファクターを重視します。セキュリティが議題に上がるのは、多くの場合プロトタイプが動作し始めた後です。しかし、BLEのセキュリティアーキテクチャはモジュールとファームウェアの選定段階でほぼ決まるため、後から修正すると高コストになるか、ハードウェアの改版なしには不可能な場合もあります。
BLEセキュリティアーキテクチャ：仕様が提供するもの
BLEセキュリティはリンク層とホスト層で動作します。主要なメカニズムは次のとおりです：
- ペアリングとボンディング：デバイス間で共有シークレット（LTK）を確立します。Just Works（MITM攻撃に脆弱）からPasskey Entry（MITM耐性あり）まで様々なペアリング方法があります。
- LE Secure Connections（LESC）：BLE 4.2で導入。P-256曲線上のECDH鍵交換を使用し、フォワードシークレシーを提供します。BLE 5.0+では必須サポートです。
- プライバシー / Resolvable Private Addresses（RPA）：デバイスが定期的にMACアドレスをローテーションし、第三者によるトラッキングを防止します。
- 属性暗号化と署名：GATT特性は暗号化リンクまたは署名済み書き込みを要求できます。
モジュール展開における一般的なセキュリティの欠陥
| 脆弱性 | 根本原因 | 攻撃による影響 |
|---|---|---|
| 本番環境でのJust Worksペアリング | SDKサンプルコードをそのまま使用 | MITM攻撃でセッションキーを傍受 |
| 暗号化されていないGATT特性 | GATTテーブル定義のパーミッションフラグ欠落 | 任意のスキャナーがデバイス状態を読み書き可能 |
| 固定MACアドレス | プライバシー/RPAが無効 | 受動的観察者によるデバイス位置追跡 |
| 平文OTAファームウェアペイロード | トランスポート暗号化なしのカスタムOTA | ファームウェアの抽出または悪意あるイメージへの置換 |
| ハードコードされたペアリングPIN | 固定値”000000″のPasskey Entry | 1秒以内にブルートフォース攻撃可能 |
実践的な設定チェックリスト
- □ LE Secure Connectionsに設定；Just Worksは無効化
- □ 機密データを含むすべてのGATT特性が暗号化リンクを要求
- □ プライバシー/RPAを有効化（ローテーション間隔≤15分）
- □ 本番プログラミングスクリプトでフラッシュ読み出し保護を有効化
- □ SDK設定でTRNGソースを確認
- □ OTAペイロードをファームウェア署名で検証してから適用
- □ PINはハードコードせず動的生成またはデバイスごとにプロビジョニング
- □ 本番ユニットのデバッグインターフェース（SWD/JTAG）をロック
このチェックリストを通過したBluetoothモジュールは、RF性能と同等のセキュリティ品質を持って出荷されます。セキュリティは後から追加する機能ではなく、最初のプロトタイプ段階での設計決定です。