７月に「PAGEMODEとペアリング」で書いたように、WT32のディフォルトの設定ではデバイスが発見可能な状態に置かれています。最近のAndroidスマホでは、Bluetoothを発見可能な状態(公開した状態)に設定するにしても2分程度に時間が制限されています。セキュリティと消費電力抑制の両方の観点から好ましい振る舞いなのでしょう。もう、しばらく前のことになってしまいましたが、高木浩光氏がこれに関連した記事を書いておられたことを思い出しました。BDADDRから、みず知らずの人と何度も同じ電車に乗り合わせていることがわかるとか、面白い話です。今ではガラケーからスマホへのユーザ移行が進むにつれて、電車の中で見つけられるデバイス数も減っているんでしょうね、きっと。
高木氏の指摘もあって、いまではBluetoothは必要な時だけ発見可能な状態にして使えばいいものだということは、良く知られるところになったと思います。きょうはあまり知られていない(と思われる)HFP接続するだけで、電話番号を知られてしまうということについて書いておきます。1年以上前から、飲み会では何度かデモして見せたことがあるのですが、今まで記事にしたことがありませんでしたので。
まずは、WT32を使ってA2DP, AVRCP, HFPをイネーブルしておきます。こんな設定です。
iWRAP5ではディフォルトでSSPがイネーブルになっています。そのため、スマホからデバイス見つけて接続操作をすれば、PIN入力の必要もなく、簡単に接続できてしまいます。まずは、デバイス検索をかけて、
見つかったデバイスにタッチするだけで、ペアリングが始まります。スマホとWT32の双方ともSSPのJust Worksモードでの相手確認を許容していますので、PINコードを入力したり、画面表示内容を確認したりすることもなくペアリングができてしまいます。
そしてそのまま、ご丁寧なことに、あれよあれよという間に、見つかったプロファイルと自動的に接続までしてくれます。
WT32側からみるとこんなふうに動いています。
便利と言えば便利なんですが、ちょっとした危険も潜んでいます。今、あなたはお店でBluetooth対応のデバイスを選定中で、自分のスマホをつないで、プレーヤの中の曲を再生してみていると想定してみましょう。音楽再生の試験をするだけならば、A2DPとAVRCPをつなげば充分なのですが、上の例に示したようにスマホはデバイス側がHFP対応していれば、HFPも接続してくれちゃいます。以前、ガラケーを使っていた時には、プロファイル毎に接続や切断操作ができたのですが、Androidの標準機能にはそのような細かい接続操作機能は備わっていないようです。
まぁ、ほとんどの人はこれで不自由することはないんですが、重要なのは使っている本人は全く意識していないうちに複数のプロファル(HFP, A2DP, AVRCP)の接続ができてしまっているということです。WT32でLISTコマンドを実行すれば、４つのリンクができていることを確認することができます。
そして、ひとたびHFPでつながってしまうと、デバイス側からATコマンドを送信することによって、携帯端末側の状態情報を調べることが可能になります。その端的な例が AT+CNUMコマンドであり、端末はこのコマンドを受けるとその電話番号を返します。上の例では、実際にWT32を使ってHFPのリンクに対してAT+CNUMコマンドを送ってみた様子を示しています。端末によっては、電話帳にアクセス可能なATコマンドを用意しているかもしれませんが、そうすると電話帳まで抜き取ることが可能かもしれません。AT+CNUMコマンドは3GPP標準の基本的なATコマンドのひとつなので、どんな端末でもサポートされているようです。
このように、HFPをサポートするBluetooth機器は、その気になればAT+CNUMコマンドを使って接続した携帯端末の電話番号を調べて、その結果を収集することが可能なのです。明示的にHFPでの接続を頼むと怪しまれるかもしれませんが、
こんなわけで、怪しげな自作Bluetoothデバイスとは、ペアリング/HFP接続してはいけません。(笑)
高木氏の指摘もあって、いまではBluetoothは必要な時だけ発見可能な状態にして使えばいいものだということは、良く知られるところになったと思います。きょうはあまり知られていない(と思われる)HFP接続するだけで、電話番号を知られてしまうということについて書いておきます。1年以上前から、飲み会では何度かデモして見せたことがあるのですが、今まで記事にしたことがありませんでしたので。
まずは、WT32を使ってA2DP, AVRCP, HFPをイネーブルしておきます。こんな設定です。
iWRAP5ではディフォルトでSSPがイネーブルになっています。そのため、スマホからデバイス見つけて接続操作をすれば、PIN入力の必要もなく、簡単に接続できてしまいます。まずは、デバイス検索をかけて、
見つかったデバイスにタッチするだけで、ペアリングが始まります。スマホとWT32の双方ともSSPのJust Worksモードでの相手確認を許容していますので、PINコードを入力したり、画面表示内容を確認したりすることもなくペアリングができてしまいます。
そしてそのまま、ご丁寧なことに、あれよあれよという間に、見つかったプロファイルと自動的に接続までしてくれます。
WT32側からみるとこんなふうに動いています。
便利と言えば便利なんですが、ちょっとした危険も潜んでいます。今、あなたはお店でBluetooth対応のデバイスを選定中で、自分のスマホをつないで、プレーヤの中の曲を再生してみていると想定してみましょう。音楽再生の試験をするだけならば、A2DPとAVRCPをつなげば充分なのですが、上の例に示したようにスマホはデバイス側がHFP対応していれば、HFPも接続してくれちゃいます。以前、ガラケーを使っていた時には、プロファイル毎に接続や切断操作ができたのですが、Androidの標準機能にはそのような細かい接続操作機能は備わっていないようです。
まぁ、ほとんどの人はこれで不自由することはないんですが、重要なのは使っている本人は全く意識していないうちに複数のプロファル(HFP, A2DP, AVRCP)の接続ができてしまっているということです。WT32でLISTコマンドを実行すれば、４つのリンクができていることを確認することができます。
そして、ひとたびHFPでつながってしまうと、デバイス側からATコマンドを送信することによって、携帯端末側の状態情報を調べることが可能になります。その端的な例が AT+CNUMコマンドであり、端末はこのコマンドを受けるとその電話番号を返します。上の例では、実際にWT32を使ってHFPのリンクに対してAT+CNUMコマンドを送ってみた様子を示しています。端末によっては、電話帳にアクセス可能なATコマンドを用意しているかもしれませんが、そうすると電話帳まで抜き取ることが可能かもしれません。AT+CNUMコマンドは3GPP標準の基本的なATコマンドのひとつなので、どんな端末でもサポートされているようです。
このように、HFPをサポートするBluetooth機器は、その気になればAT+CNUMコマンドを使って接続した携帯端末の電話番号を調べて、その結果を収集することが可能なのです。明示的にHFPでの接続を頼むと怪しまれるかもしれませんが、
音楽再生して欲しいとか
写真ファイル送信して欲しいという理由で誘導することでBluetoothのペアリング操作を実行させてしまえば、それと知らぬ間にHFPまで接続させてアッという間に電話番号読み取りが終了してしまうのです。上記の例に示したように、Android携帯端末側でおこなった操作としては、デバイス検索をかけて、みつかったデバイス名にタッチしただけであり、それ以降ユーザには何の確認動作もおこなう機会が与えられませんでした。デバイス名にタッチしてから、およそ10秒後にはもう電話番号を読み取られているかもしれないのです。
こんなわけで、怪しげな自作Bluetoothデバイスとは、ペアリング/HFP接続してはいけません。(笑)
