崎山伸夫のBlog

高木さんの日記で、無線LANアクセスポイントと位置情報を結びつけるサービスによるプライバシー問題、というのが扱われていた。家庭内無線LANアクセスポイントと精度の高い位置情報の組が個々の家庭の同意無く収集されることについての問題だ。ここで高木さんは

「MACアドレスは個人を特定するものではない」と言えるだろうか？もし、別のネットサービスで、何らかの目的で家庭の無線LANのMACアドレスを登録して使うサービスが始まったとする。そのサービスもまた、「MACアドレスから個人が特定されることはありません」と主張するだろう。このとき、PlaceEngineとこのサービスの両者が存在することによって、わからないはずの住所が特定されてしまう事態が起きてくる。

PlaceEngineのプライバシー懸念を考える

と述べている。高木さんの論考で、おそらくここは、「あくまでも仮定に過ぎない」という話になりかねず、また「別のネットサービス」について、その現実性についてネガティブな評価をされるのではないか、と思った。そこで、この部分についていろいろ想像をめぐらしてみて、若干違う想定ながら、この高木さんの懸念が現実化しうる状況について具体的に思い描くに至ったのでここで書いてみる。

今、多くの人が家庭で利用しているインターネット環境はIPv4だけれども、いよいよIPv4のアドレスがあと数年で枯渇するぞ、という話が割り当て機関を中心としたインターネット運用者のコミュニティの中で起きている。JPNICとかの割り当て機関での枯渇とISPレベルでの枯渇は時期がずれるとはいえ、2011年ぐらいには IPv6 のほうへの切り替えが進行している状況、という予測のようだ。現状では商用のIPv6接続サービスはごく一部で、とくに家庭用となるとかなり限定されているけれども、それがいよいよ変わる、ということ。現状ではIPv6というとISP閉域網やNTT地域会社のフレッツ閉域網を使った動画ストリーミングサービスやIP電話サービスでのIPv6利用がある程度なので、家庭用のブロードバンドルータではIPv6対応のものは少なく、ほとんどがそのような閉域網サービスにAV機器などを接続するためのIPv6ブリッジ機能のみを持っている、という状況で、こと無線LANアクセスポイントの機能を持つ家庭用ブロードバンドルータでIPv6をルーティングする機能を持つものとなると、ヤマハのかなり前に販売終了しているものか、アップルのAirMacシリーズぐらいだろうが、それも変わることだろう。ここでは、そういう状況を仮定している。

IPv6では機器の個々のネットワークインターフェースは、リンクローカルというローカルなネットワークだけで有効なアドレスと、あとはグローバルアドレスを持つことになる。アドレスの上位64ビットがネットワークを表現していて(network ID)、下位64ビットはInterface IDと呼ばれていて、IEEE EUI-64という形式になっている。ここは、MACアドレスがあるようなネットワークではそれを使ったIDとなる。衝突検出と回避のためのプロトコルは必ず使われるのだけれども、基本的にはそのまま。こうすることで、ネットワーク設定でDHCPサーバを用意する必要がなくなっている。

IPv6の世界では、従来のような契約に対してIPアドレス一つを割り当てるようなサービスは想定されていない。ネットワークが単位となっていて、基本的に上位48ビットを割り当てるという話になっている。個々の組織で多数のサブネットを容易に作ることができてNATが要らない世界を前提としている。ただ、小規模なネットワークしかないという前提のもとに64ビット単位で割り当てていくということも許容されていて、OCN IPv6などは固定64ビット1つと動的64ビット1つ、という割り当てを行うようだ。現在、家庭で動的IPアドレス1つの割り当てを受けているような需要の移行は、こういったサービス形態のほうが自然だとも言えるだろう。

一方、家庭での無線LAN環境利用のほうは、というと、最近はどんどんと無線LANの高速化がすすんでいる。こうした状況を踏まえると、家庭内のライトユーザがネット利用にブロードバンドルータからデスクトップパソコンまで床にネットワークケーブルを這わせて固定し、といったことをあえてせず、デスクトップパソコンであれ、ノートパソコンであれ、ネットワークは無線LANで済ませて有線LANは利用しない、という環境もかなり一般的なものになる、という想像も、あながち非現実的とも言えないだろう。

ここで、無線LANルータとISPの間の設定がどうなるか、というのが今回の話に関係するのだけれども、現在のIPv4の世界で複数のIPアドレス割り当てを受けるサービスを利用するさいにごく普通の、 unnumberedというPoint to Pointのリンクにアドレスを割り当てない設定と同様の unnumberedというのもありうるし、また、IPv6 として通常のネットワークに見えるようにリンクローカルアドレスをユーザ側とISP 側でともに割り当てるのだけれども、グローバルアドレスはあえて割り当てない、という設定もありうる。いずれにせよ、ISPルータのポートと家庭内ルータの入口の両端にグローバルなアドレスを割り当てない、という方法は可能で、実際そういう商用サービスもあるようだ。もちろん、グローバルなアドレスを割り当ててもいいのだけれども、ここではそうでないケースがそれなりに多い、と仮定する。

こういった場合に、その無線LANアクセスルータがどういうグローバルアドレスを持つかというと、ISPから割り当てられたネットワークIDとローカルなinterface IDの組み合わせになる。そのうちの一つは、ネットワークIDと無線LANのアクセスポイントとしてのMACアドレスの組み合わせとなっている。 その上で、有線LANのポートを持っていなかったり、あるいは持っていてもIPv6用に使用していない、という状況を仮定すると、それが唯一のグローバルアドレスであるという状況になる。

次に、こういうアドレスをどう収集するか、という観点から。IPv4の世界では traceroute というアプリケーションが有名だけれども、同様の traceroute6 というアプリケーションがあって、送信パケットの hop limit値を変化させて、経路の途中で ICMPv6 Time Exceeded メッセージを発生させることで経路情報を収集できる。これと同じ仕組を使えば、「ネットワークIDと無線LANアクセスポイントのMACアドレスの組み合わせの候補」の収集は可能だろう。どこかのWebサーバにアクセスしてきたアドレスを対象としてもいいし、あるいはISPのサービス用アドレスブロックを狙ってもいい。集中的なアクセスを行わなければISPのネットワークオペレータの関心をひくようなこともないだろう。何より、この手法では個々の対象アドレスの同意無しで収集できる。収集したアドレス群は「無線LANアクセスポイントのMACアドレス」であることが保証されるわけではないが、「MACアドレスをキーとして位置情報を得る検索」との組み合わせを前提とすれば、単に検索して当たった情報を記録すればいいという話になる。

こういう情報収集が大規模に行われる可能性がどれだけあるか、というと、網羅性が必ずしも高くないと考えると単独でのサービスを前提とした収集は考えづらいけれども、需要は確実にあるのではないかと思う。現在でもIPv4アドレスから国情報やもう少し細かい地域情報を検索するというサービスは存在していて、特定国のみに対してのみ許可されたサービスの運用に利用しているケースもあれば、Web広告での地域絞り込みに利用されているケースもある。とくにWeb広告のようなものでの利用は、細かければ細かいほどデータとしての価値を持つので、他のさまざまな手法との組み合わせのなかで用いられるように思う。

ちなみに、ルータ側でこの問題を回避するのは極めて容易なはずで、まず、IPv6のinterface IDは、MACアドレスから自動生成以外に、手動で付けることができる。ただ、手動で付けると、IPv6の「エンドユーザは設定不要」という利点は失われることになるので、家庭用ルータの販売時のデフォルトとしては厳しいだろう。また、IPv6のプロトコルという観点でいえば、アドレス設定について「プライバシー拡張」が存在していて、乱数を用いる手法が用意されてはいる。ただ、これはIPv6ホストを想定しているので、ルータで単純に利用できるかどうかは（私はそちらは専門ではないので）よく分からないし、また、ルータ製品で実装例があるかどうかも知らない。あとは、ICMPv6 Time Exceededをフィルタして外部に出さないという方法もあるとは思うが、これをデフォルトにするのはそれはそれで問題があるような気がする。家庭で箱から出した時点で対策済となるにはどうしたらいいかは、がんばって誰かが考えてくださいというところか。

追記(6月3日): mixiのあるコミュニティでitojunさんがIPv6 Transition/Co-existence Security Considerationsというインターネットドラフトを本件と関係なく紹介されているのを見たのでそれを見たところ、そもそも無線LANのような信頼できないリンク層の上ではIPv6の標準的なアドレス設定方法では危ないね、ということで、リンク層の保護に加えて、SEcure Neighbor Discovery (SEND, RFC3971)というやや複雑なプロトコルでアドレス設定する方法が出ていた。その枠組だと interface IDはMACアドレスそのままということはない（RFC3972のCryptographically Generated Addressesというのが使われるようだ）ので、この問題は発生しない。ただ、この方法はオプションなので必ずしも実装されるとは限らず（AirMacについては未確認。ヤマハの場合は時期的に実装されていないように思われる）、また、2年前の時点で「このアドレス設定をセキュアにするSEND技術（RFC3971 Secure Neighbor Discovery）も存在するが、利用に関する権利上の問題や、設定が複雑になるといった問題から、普及には至っていない。」と解説されていたものが現状どうなっているのか、近い将来解決するのか、私は情報を持っていない。