Bluetooth Beaconのセキュリティ：スプーフィング、盗聴、リプレイ攻撃

Bluetooth Beaconは雑踏する部屋の拡声器だ。範囲内の全員に同じパケットをペアリングなし・認証なしで放送する。その公開性こそがBeaconを安価で容易に導入できる理由だが、誰でもスマホでBeaconの通信を読み取り・複製・偽造できることも意味する。本稿ではBluetooth Beaconの現実的な脅威モデルと、攻撃を実際に止めるエンジニアリング制御を整理する。

Beaconが設計上晒される理由

Beaconは聞かれるためにアドバタイズする。アドバタイズパケットは任意のスキャナが読め、ペイロード（iBeaconのUUID/Major/Minor、Eddystoneのnamespace/instance、または独自MSD）は特に暗号化しない限り平文で送られる。アドバタイズ時に共有鍵は交渉されないため、無線機は正規ゲートウェイと見知らぬスマホを見分けられない。

脅威モデル

脅威	攻撃者の行動	破られるもの
盗聴	アドバタイズを受動的に記録	プライバシ・位置漏洩
スプーフィング	あなたのIDで偽Beaconを送出	在席詐称・トリガ悪用
リプレイ	有効なパケットを録画し後で再送	「まだ在る」錯覚
MITM/不正ゲートウェイ	ゲートウェイ上りを詐称	データ改ざん・注入

盗聴：平文が位置を漏らす

標準iBeaconフレームは固定UUIDと階/ゾーン/資産クラスを表すMajor/Minorを運ぶ。ロビーに居る攻撃者はUUIDを記録し、午後にはゾーンの地図を作る。対策：不透明で回転するIDを使い、静的フィールドに意味のあるデータを入れず、本来の対応表はサーバ側に置く。

スプーフィング：在席の偽造

BeaconのIDは公開されているため、攻撃者は10ドルの開発板から同じUUID/Major/Minorを送出し、システムは資産（や顧客）がそこにいると誤認する。小売：偽「来店」イベント。物流：幻のパレット。解決は真正性——受信側はID一致だけでなく、鍵保持者から来たことを暗号検証しなければならない。

リプレイ：録画して再送

リプレイは最も単純で見逃しやすい攻撃だ。攻撃者は今日有効なパケットを録画し来週再送して「まだここにいる」と主張する。生iBeaconフレームはタイムスタンプもナンスもないので、受信側は新旧を見分けられない。署名付タイムスタンプがこれを防ぐ。

MITMと不正ゲートウェイ

Beaconがゲートウェイと暗号化なしで通信するなら、不正ゲートウェイは読値を注入・改ざんできる。ゲートウェイ→クラウドが未認証なら同様だ。すべてのホップに自身の完全性、機微なデータには秘匿性が要る。

効く暗号化対策

暗号化アドバタイズ。 意味のあるペイロードを暗号ブロブに入れる（LE Secure Connectionsまたは事前共有鍵下のAES-CCM）。無線は依然放送するが、鍵保持者だけが読める。

署名付Beacon。 各パケットにペイロード＋タイムスタンプのECDSA署名を付ける。受信側は信用前に検証する。

def sign_beacon(payload, ts, priv_key):
msg = payload + ts
sig = ecdsa_sign(msg, priv_key)   # P-256 / Ed25519
return payload + ts + sig


def verify_beacon(advert, pub_key, window):
payload, ts, sig = split(advert)
if now() - ts > window:            # 例 60 秒
return REPLAY_DETECTED
return ecdsa_verify(payload + ts, sig, pub_key)

回転する揮発ID。 リゾルブァブル私用アドレスのプライバシモデルにならい、サーバだけが解決できる鍵導出の回転IDを放送する。盗聴者は数分ごとに別IDを見て追跡できない。

タイムスタンプ＋ナンスのリプレイ防止。 署名封筒内の単調カウンタや粗略タイムスタンプで各パケットを一意かつ短命にする。

セキュリティ対コスト

方式	秘匿性	完全性	リプレイ耐性	電力	互換性
平文	なし	なし	なし	なし	普遍
回転ID	弱	なし	一部	低	普遍
署名	なし	強	あり(時刻)	中	検証器要
暗号化	強	強	あり(ナンス)	高	鍵要

鍵プロビジョニングとハードウェアルート

署名の信頼は秘密鍵次第。セキュアエレメントに格納するかPUFから導出し、ファームウェアイメージから読み出せないようにする。これはセキュアブートと同じルートオブトラストの規律だ。Beaconの同一性は工場で焼かれ、実行時にフラッシュから読まれるべきではない。

運用検知

暗号化しても空を監視せよ。

• RSSI異常：Beaconが突然+20 dB強く読めば近くのスプーファを示唆。
• 同IDが同時に二地点から：物理的に不可能——フラグせよ。
• ゲートウェイホワイトリスト：既知証明書の上りだけ受け入れよ。

頼る規格

Apple Find MyおよびクロスプラットフォームのDetecting Unwanted Location Trackers仕様は（分離警告・音鳴動など）アンチストーキング挙動を定義し、consumerタグはこれにならうべき。Device Provisioning Protocol(DPP)はゲートウェイの明確なオンボーディングを与える。

OEMチェックリスト

1. 方式選び前に脅威モデルを決めよ——多くの導入は暗号化ではなく署名を要する。

2. 鍵はセキュアエレメント/PUFに、アプリフラッシュには絶対置くな。

3. 全パケットにタイムスタンプかカウンタを付け、窓を検証せよ。

4. サーバが解決できるスケジュールで公開IDを回転せよ。

5. 侵害Beaconを失効・再鍵できる手段を出荷せよ。

Bluetooth Beaconは他と同じく信頼を得る——すべてのパケットで、自称する主体が本物だと証明することで。