デバイスの存在とプライバシ
http://takagi-hiromitsu.jp/diary/20090315.html#p01
誰でも簡単にこのようなBluetooth探査ができてしまうのだから、逆に、周囲でデバイス探査されていることを検知するプログラムを作って、警報が鳴るよう走らせておきたいところだ。
Bluetoothにおけるデバイス検出(Inquiry)や接続(Page)はHCIがまとめて処理してしまうので、通常の手段ではInquiryリクエストが空中を飛んでいることを検出できない(Bluetooth無線を完全に自作しない限り*1は)。
BluetoothはインテリジェントなHCIが前提となっているため、そもそもパケットをsniffするための手段が規格上存在しない。低機能なマイコンでも実装できるように、プロトコルの多くをホストコントローラ側に処理させている。仮にBluetoothデバイスを直接制御したとしても、Linux上のhcitool以上の事はできない。
例えば無線LANはHCIがそこまでインテリジェントではないため、アクセスポイントや他のノードを検出しようとしているかは単純に無線パケットをsniffすれば済む。(無線LAN APはビーコンと呼ばれるデータを常に送信しているので特に何もしなくてもAPを検出することが出来るが、クライアントの方から積極的にProbe requestと呼ばれるデータを送信するという手段があり、これを検出すること自体はできる。あまり意味は無いが。http://osdevj.g.hatena.ne.jp/osdevj/20071119/1195453398 )
先日のデモ(http://d.hatena.ne.jp/mjt/20090228/p1 , http://www.nicovideo.jp/watch/sm6302945 )中にデバイスを探索した人がいたら気付いていたかもしれないけれど、先日のデモではSDPサーバを実装していなかった。通常のOSはデバイスを探索するときに大抵SDPサーバにも接続するのでその接続を検出するという方法は有るかもしれない(Linux上であれば、これはhcidumpで簡単に作れる)。当然、この手法はHCIを直接制御してInquiryする人には無力となる。
要するに、Bluetoothではデバイスを発見不能にするのが一番といえる。そもそもBluetoothは見知らぬ他人とすぐに情報交換するのには向かないから、常に発見可能にしておくメリットは無い。NFC(iC通信)や赤外線を使うべきだ。電波は10mも飛んじゃうんだから。
もっとも、MACアドレスやBluetoothアドレスを広報することに神経質になるべきかどうかはなんともいえない。ちかチャットしかり、NintendoDSのすれ違い通信しかり。Bluetoothの場合、周波数ホッピングのホップ先の決定にBluetoothアドレスを使うので、動作中にランダマイズするのは容易ではない*2。
公共の場でのInquiryがダメというのもなんともいえない。僕も(セキュリティ的には望ましくないにも関わらず)イベントの会場でBluetoothヘッドセットをセットアップすることはあるし、これにはInquiryが不可欠となっている。原理的にはBluetoothアドレスさえ入手できればInquiryする必要はまったく無いが、既存のBluetoothスタックはそこまで良く出来ていないので現実的ではない。(PS3のコントローラのように、Bluetooth以外の手段でのペアリングを前提としたデバイスも有るには有るが。。)
まぁ、普通の人はPCや携帯電話同士をBluetoothで接続することは無いだろう。悪いことはいわないから探索不能にしておいた方が良い。(PCと携帯電話を接続するときだけが数少ない例外だろうか。)
