<前の日記(2007年10月21日) 次の日記(2007年10月30日)> 最新 編集

高木浩光@自宅の日記

目次 はじめに 連絡先:blog@takagi-hiromitsu.jp
訪問者数 本日: 2232   昨日: 1295

2007年10月27日

自分の無線LANがPlaceEngineに登録されていないか確認する方法

前回の日記に対するリンク元などを見てまわったところ、「PlaceEngineは使いたいが自分のアクセスポイントは登録したくない」といった声があった。さて、「PlaceEngineを使いつつも登録しないでいる」ことは可能なのだろうか。

PlaceEngineには「位置を教える」という機能があるが、このボタン(図1)を押さないようにしていれば登録されずに済むかというと、そうではない。

図1: PlaceEngineの「位置を教える」ボタン

このボタンは、PlaceEngineの取扱説明書よると、次の場合に使うものとして用意されている。

まだ PlaceEngine サービスエリアに含まれない場所で「現在地を取得」ボタンをクリックすると、現在地取得に失敗します。この場合、地図の下の「位置を教える」ボタンをクリックし、(略)

PlaceEngine MAP サイトで現在地を表示しても、推定された現在地が正しく地図上に表示されない場合は、結果を修正して正しい情報を PlaceEngine サーバーに教えて頂くことが可能です。この場合、地図の下の「位置を教える」ボタンをクリックし、(略)

自分の家で(近くで)このボタンを押せば、もちろん、家のアクセスポイントが登録されてしまうわけだが、このボタンを押さなくても、PlaceEngineで位置情報を得るだけ(「現在地を取得」ボタンを押すだけ)でも、家のアクセスポイントはPlaceEngineサーバに登録されてしまう。このことは、PlaceEngineの論文で次のように説明されている。

  • 暦本純一, 塩野崎敦, 末吉隆彦, 味八木崇, PlaceEngine:実世界集合知に基づくWiFi位置情報基盤, インターネットコンファレンス2006, pp.95-104, 2006.

    LaMarca らは、GPS を携行して街中を移動しながら得た大量の無線LAN 電界情報のログから、アクセスポイントの位置制約条件を抽出し、アクセスポイントの位置を推定する方式を提案している[5]。しかしながら、アクセスポイント状況は漸次変化していくので、このようなバッチ式の位置更新だけでは変化に追従しきれない。

    本論文では、バッチ式の位置推定方式に加えて、エンドユーザによる位置アクセスによっても位置情報データベースを更新することを特徴とする無線LAN 位置情報システム, PlaceEngine について報告する。

    (中略)

    • 利用者によるデータベース更新は、利用者が電測情報の測定と同時に明示的に位置を登録する場合に行われるが、利用者が単に位置を検索した場合にも発生する

    • すなわち、大量の利用者が継続的にシステム対してに検索要求を発生する行為自体がデータベースを更新・増大させるための重要な情報源となる。

    2.4 利用者の位置登録/検索によるデータベースの更新

    利用者が位置を検索する場合

    (中略)

    まず、検索要求に未知のアクセスポイントが含まれる場合が考えられる。位置情報は既知のアクセスポイント情報から得ることができるが、電測情報にデータベースに登録されていなアクセスポイントが含まれていた場合、推定した位置情報を、そのアクセスポイントの初期登録位置として記録する。図7に典型的な位置検索の際のパラメタの例を示す。検索要求に未知のアクセスポイント情報が含まれている。このような場合、既知のアクセスポイント情報に基づき位置を推定し、未知アクセスポイントの初期位置も推定位置として設定する。

このことは、今年9月のイベントの講演でも示されたようで、記事中のこのスライドに例が示されている。

したがって、自分の家のアクセスポイントがPlaceEngineに登録されることを嫌う人が、既に登録されてしまっていないか確認しようとするときに、PlaceEngineをそのまま使ってはいけない。確認のために使用する行為が、自ら登録する行為となってしまいかねない。

サーバに影響を与えることなく、その確認をしたければ、次のようにすればよい。

未登録のアクセスポイントが検索時に登録されるのは、そのとき同時に観測される周辺の他のアクセスポイントが既に登録されていて、位置を取得できる場合に限られるのであるから、確認しようとするアクセスポイント1個だけしか観測されない状態で、PlaceEngine検索を行えばよい。

つまり、前回の「デイリーポータルZ 記者の家を探しに行く」で行った実験と同様に、アルミホイルで包むなどして、周辺環境に存在する他のアクセスポイントを観測しないようにしたうえで、確認対象のアクセスポイントのビーコンだけが観測される状態を作り出し、PlaceEngine検索を行う。住所が示されれば既に登録されているということであるし、「位置が特定されません」と表示されれば未登録ということになる。

前回と異なり、MACアドレスの変更が可能なアクセスポイント機器は必要ない。確認対象の(自分の)アクセスポイント機器と、観測する側のPC(PlaceEngineを稼動させるPC)を近くに置いて、それら全体をアルミホイルで包めばよい*1

このとき、前回の図6(下の図2)のように、Network Stumblerなどを用いて、たしかに1個のアクセスポイントしか観測されない状態であることを十分に確認してから、PlaceEngineを使うよう注意した方がよいだろう。

図2: 1個のアクセスポイントのみ観測していることを確認した様子(前回の図6)

たしかに1個のアクセスポイントだけで検索を行ったかは、検索後のPlaceEngineの画面で、上段の灰色の縦棒が1本だけかどうかで確認できる。

図3: 1個のアクセスポイントだけを使ってPlaceEngine検索した様子(前回の図7)

検索したタイミングではたまたま2本だった……なんてことになれば後の祭りなので、事前に十分に確認したい*2

ただし、この方法で登録済みかどうか確認できるのは現時点での話だという点に注意したい。もし、今後、PlaceEngineサーバ側が、プライバシー対策として「複数のアクセスポイントが観測されているときにしか位置情報を応答しない」という対策(5月27日の日記の脚注6の対策)をとった際には、上の方法で確認しようとして「位置が特定されません」と表示されても、それは必ずしも未登録ということを意味しない。その状況では、自分のアクセスポイントが登録済みかどうか確認することは難しくなるだろう*3

もっとも、こうして、自分のアクセスポイントが未登録であることを確認できたとしても、それはあくまで現時点での話である。今後、誰かが(隣人や、通りすがりの人が)家の近くでPlaceEngineを使ってしまえば、そのときに登録されてしまうわけで、それを食い止めるには、司法の力に頼る以外に術がないのではないか。

では、自分の家のアクセスポイントが登録されてしまっているとき、その位置情報を変更することはできるだろうか。たとえば、皇居の中心に変更するとか、沖ノ鳥島に変更してしまえば、誰も本当の位置だと思わなくなると期待できる。

これを故意に行った場合、PlaceEngineサービスに対する業務妨害として責任を問われるおそれがあるかもしれない。ただ、自分のプライベートな情報を無断で勝手に登録されたことに対する対抗措置として、自分の情報についてだけ無効なものに変更するのは、正当な行為であると抗弁できるようにも思える。

もちろん、他人のアクセスポイントに対してまで、位置情報をかく乱させるような変更行為を、故意に継続して大量に行えば、確実に業務妨害行為に当たるだろうし、自分のアクセスポイントの位置情報をかく乱させる行為を組織的に大量の人にさせるよう教唆する行為も、業務妨害行為に当たるおそれがあると思えるので、私はそのような変更行為を推奨しない。

また、技術的観点から言って、そのような変更を行っても無駄である。いずれ、誰か(隣人や通りすがりの人)によって正しい位置に補正されてしまう。このことは、一般向けに書かれた次の記事でも解説されている。

  • 立っている無線LAN APは他人のものでも使え!?, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

    ユーザー参加型のコンテンツの場合,問題となるのが信頼性である。PlaceEngineも,誤操作などによる誤った位置登録や,悪意を持ったユーザーによるニセの位置情報が登録される危険がある。また,無線LAN AP自体が移動する可能性もある。(中略)しかし末吉社長は,「登録件数が増えれば増えるほど,そうした誤った情報は排除されていく」と語る。ソニー本社の“誤登録”も,しばらくたつと解消されたという。

    また位置情報は,ユーザーによる「登録」だけではなく「検索」でも更新されていく。例えば,A,B,CというAPが新宿にあり,これら3つのAP 情報で検索をかけると「新宿」の位置情報をPlaceEngineサーバーが返していたとする。ところが,CのAPを持つ会社が渋谷に移転してX,Y,Z のAPの近くになると,今度は渋谷からX,Y,Z,Cの4つのAPで位置検索がかかるようになる。Cが混ざってはいても,X,Y,Zがある限りは確率的に渋谷の可能性が高いため,位置情報としては「渋谷」を返す。それと同時に,Cの位置が渋谷に移った可能性が高いことをPlaceEngineサーバーが把握するというわけだ。

この記事は、無難なことに、「会社の移転」を題材にしているが、これは個人の家の無線LANアクセスポイントでも同じであることに注意したい。

無線LANのステルス機能ではPlaceEngineに登録されるのを阻止できない

前回の日記に対するリンク元などを見てまわったところ、「ステルス機能でアクセスポイントを隠さなきゃ」といった感想を書いている人がいた。無線LANのいわゆる「ステルス機能」は、SSIDを隠そうとするもの*4であるが、MACアドレスを隠せるものではない。

このことについて、8月に書かれた日経IT Proの記者の眼にも次の記述があった。

  • 立っている無線LAN APは他人のものでも使え!?, 日経IT Pro 記者の眼 安井晴海, 2007年8月1日

    PlaceEngineでは,ビーコン信号中のMACアドレスと電界強度を使って位置を割り出す。ただし,ステルス機能を設定しているAPの場合は位置情報の取得には使えない。ステルス機能とは,ESS-IDの存在を隠すためにビーコン信号の送出を制限するセキュリティ機能のことである。

これは事実に反する誤った記述である。

第一に、無線LANのステルス機能とは、ビーコンパケットの送出を止めるものではない。送出されるビーコン中のSSID欄にSSIDを記載しないようにする機能であり、当然ながらMACアドレスは送出される。

第二に、もしかすると、PlaceEngineクライアントが、傍受したビーコンについて、ステルス機能でSSIDが空になっているものについては、MACアドレス情報をPlaceEngineサーバに送信しないよう、配慮された設計になっている可能性もあるが、現時点ではそのようにはなっていない。

実際に、上に書いた「自分の無線LANがPlaceEngineに登録されていないか確認する方法」の方法で、私の家のステルス設定のアクセスポイントについて確認を行ってみたところ、住所が表示された。ステルス設定のアクセスポイントのMACアドレスがPlaceEngineサーバに送信されたためと推定される。

もっとも、今後、プライバシー配慮の第一歩として、ステルス設定のアクセスポイントの傍受情報をPlaceEngineで窃用しないようにする改善が行われる可能性はあるかもしれない。

その場合、必要な人がその設定変更の必要性を認識できるよう、PlaceEngineサービスの運営者は、その仕様の明確な開示と、それが何のための配慮であるかを説明しなければならない。また、それは、PlaceEngineユーザに説明すれば済むというものではなく、すべての無線LANアクセスポイント設置者に対して必要な説明である。

ユビキタス社会の歩き方(4) 他人から貰う無線LAN機器に警戒する

モテ頃の女性(など)は、知人男性(など)から無線LANアクセスポイント機器をプレゼント(など)された際には、プレゼント主がMACアドレスをメモするような人物でないか注意した方がよいかもしれない。

貰い物を自宅で使用していると、しばらく経過した後(つまり、誰かが自宅近所でPlaceEngineを使用して、そのMACアドレスがPlaceEngineサーバに登録されるに至った後)には、プレゼント主に自宅の場所を検索されてしまいかねない状態となる。

箱が未開封であること、また、箱にMACアドレスやSSID初期値が書かれていないことを確認した方がよい。

一般にこの種のリスク(譲渡されるIT機器によるストーカー行為のリスク)は、通常、初期化した後に設定を変更して使用することで回避されるものであったが、この問題(PlaceEngineによって新たに生じ始めた問題)においては設定変更で対応できない。なぜなら、たいていの独立型アクセスポイント製品には、無線側MACアドレスの変更機能がないからだ。

同様に、使用済みの無線LANアクセスポイントを他人に渡す場合にも、自宅の場所が知られてかまわない人だけにした方がよいだろう。

類似の話:

*1 全体を包むのが困難でも、観測側のPCだけをアルミホイルで包んでも十分な場合がある。観測側を軽くアルミホイルで包むことにより、家の外にあるアクセスポイントの電波を弱めて観測されないようにしつつ、かつ、近くに置いた確認対象のアクセスポイントだけ観測されるようにできる場合がある。家の中に複数のアクセスポイントがあって複数が観測されてしまうときは、確認対象以外のアクセスポイントの電源を切ればよい。

*2 事前の確認には、図2のNetwork Stumblerを使う方法以外にも、インターネット回線を切断した状態でPlaceEngineの「現在地を取得」ボタンを押す方法もある。この場合、観測したアクセスポイント数を灰色の縦棒を表示した後、PlaceEngineサーバに接続するところで接続エラーとなり、「PlaceEngineサーバに接続できません」と表示される。インターネット接続の設定を誤っていると後の祭りになりかねないので注意が必要。また、複数の無線LANカードを使い分けるときにもミスをしやすいので注意。Network Stumblerでは外付けの無線LANインターフェイスで観測していても、PlaceEngineでは内蔵の無線LANインターフェイスの方で観測していたなどというミスが起きそう。外付けのものを使うときは、内蔵のものが(単にオフになっているだけでなく)「ネットワーク接続」設定で「無効」になっていることを確認した上で、その後にPlaceEngineを起動するのがよいようだ。念のため初回はインターネット回線を切断した状態で「現在地を取得」ボタンを押すとよいだろう。

*3 たとえば、2つ以上ないと応答しないという対策がとられた場合、2台の自分のアクセスポイントを用いてテストすることができそうに思えるが、片方が既登録で、もう片方が未登録であった場合に、応答としては「位置が特定されません」であっても、サーバ側では既登録のアクセスポイントから位置を割り出すことは可能であって、その検索要求の際に、未登録だった方のアクセスポイントをサーバが追加登録してしまう可能性がある。この問題は、PlaceEngineの運営者が、そのような対策をとる際に、このことについての仕様を公開しない限り解決しない。

*4 なお、ビーコン中のSSIDを隠しても(また、ANYプローブ応答などを禁止する設定にしても)、正規利用者の通信中の他の管理フレームパケットからSSIDは特定可能である。昔は、半可通の似非セキュリティ屋が「ステルス設定が常識」などと言いふらしていたことがあったが、それは気休め程度、プライバシー配慮のものであって、攻撃者からの防御にはなっていないことに注意したい。必要なのは(WEPではない)暗号化設定である。

本日のTrackBacks(全60件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20071027]
検索

<前の日記(2007年10月21日) 次の日記(2007年10月30日)> 最新 編集

最近のタイトル

2024年11月11日

2024年07月28日

2024年07月27日

2024年07月07日

2024年04月07日

2024年04月01日

2024年03月23日

2024年03月19日

2024年03月16日

2024年03月13日

2024年03月11日

2023年03月27日

2022年12月30日

2022年12月25日

2022年06月09日

2022年04月01日

2022年01月19日

2021年12月26日

2021年10月06日

2021年08月23日

2021年07月12日

2020年09月14日

2020年08月01日

2019年10月05日

2019年08月03日

2019年07月08日

2019年06月25日

2019年06月09日

2019年05月19日

2019年05月12日

2019年03月19日

2019年03月16日

2019年03月09日

2019年03月07日

2019年02月19日

2019年02月11日

2018年12月26日

2018年10月31日

2018年06月17日

2018年06月10日

2018年05月19日

2018年05月04日

2018年03月07日

2017年12月29日

2017年10月29日

2017年10月22日

2017年07月22日

2017年06月04日

2017年05月13日

2017年05月05日

2017年04月08日

2017年03月10日

2017年03月05日

2017年02月18日

2017年01月08日

2017年01月04日

2016年12月30日

2016年12月04日

2016年11月29日

2016年11月23日

2016年11月05日

2016年10月25日

2016年10月10日

2016年08月23日

2016年07月23日

2016年07月16日

2016年07月02日

2016年06月12日

2016年06月03日

2016年04月23日

2016年04月06日

2016年03月27日

2016年03月14日

2016年03月06日

2016年02月24日

2016年02月20日

2016年02月11日

2016年02月05日

2016年01月31日

2015年12月12日

2015年12月06日

2015年11月23日

2015年11月21日

2015年11月07日

2015年10月20日

2015年07月02日

2015年06月14日

2015年03月15日

2015年03月10日

2015年03月08日

2015年01月05日

2014年12月27日

2014年11月12日

2014年09月07日

2014年07月18日

2014年04月23日

2014年04月22日

2000|01|
2003|05|06|07|08|09|10|11|12|
2004|01|02|03|04|05|06|07|08|09|10|11|12|
2005|01|02|03|04|05|06|07|08|09|10|11|12|
2006|01|02|03|04|05|06|07|08|09|10|11|12|
2007|01|02|03|04|05|06|07|08|09|10|11|12|
2008|01|02|03|04|05|06|07|08|09|10|11|12|
2009|01|02|03|05|06|07|08|09|10|11|12|
2010|01|02|03|04|05|06|07|08|09|10|11|12|
2011|01|02|03|05|06|07|08|09|10|11|12|
2012|02|03|04|05|06|07|08|09|
2013|01|02|03|04|05|06|07|
2014|01|04|07|09|11|12|
2015|01|03|06|07|10|11|12|
2016|01|02|03|04|06|07|08|10|11|12|
2017|01|02|03|04|05|06|07|10|12|
2018|03|05|06|10|12|
2019|02|03|05|06|07|08|10|
2020|08|09|
2021|07|08|10|12|
2022|01|04|06|12|
2023|03|
2024|03|04|07|11|
<前の日記(2007年10月21日) 次の日記(2007年10月30日)> 最新 編集