最新 追記

高木浩光@自宅の日記

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

2007年05月12日

ログイン成功時のリダイレクト先として任意サイトの指定が可能であってはいけない

これが「脆弱性」として合意されるかどうかわからなかったが、脅威と対策をまとめてIPAに届け出てみたところ、受理され、当該サイト(複数)は修正された。以下、この問題がどういうもので、どうするべきなのか、はてなのケースを例に書いておく。

4月にこんな話が盛り上がりを見せていた。*1

  • ソーシャルブックマークユーザーのIDとPASSをいとも簡単に抜き取る手口, ホームページを作る人のネタ帳, 2007年4月6日

    Bボタンフィッシングとは何?

    記事の最後には私のブログでもおなじみの、はてなブックマークへ追加ボタンや、バザールのブックマークボタン(Bボタン)を設置しているブログを最近良く見かける。何気なく私はそれを利用したりしている。(略)『あれ?セッションがきれたのかな』と思い、自分のIDとパスワードを入れてログイン。すると次の画面へ飛ぶ。(略)

    見事な流れにフィッシングに気づかなかった (略)

    よくよくはてなの画面を見るとURLが全然違う画面が一つだけある。それはログイン画面だ。(略)

どこかのブログに貼られた「B!」ボタンを(はてなブックマークに追加するつもりで)押したときに、はてなのログイン画面のようなものが出たら、それが偽サイトであってもIDとパスワードを入れてしまう人が続出するだろうという話だ。

言うまでもなく、こういうのは、パスワードを入れようとする際にその画面のアドレスバーのURLを見てドメイン名を確認することが鉄則であり、それでよい。どこから飛んだ場合であっても、常日頃からそれを徹底しておくべきである。

ところが、はてなのログイン画面には次の問題があった。(現在は修正されている。)

まず、正規の動作がどうなっているかというと、たとえば http://example.com/ をブックマークしようとするときは、次のURLにアクセスすることになる。

http://b.hatena.ne.jp/add?mode=confirm&title=&url=http://example.com/

このときに、はてなにログインしていない状態だった場合は、

ゲストさん、はてなブックマークへようこそ。この操作ははてなにログインしていただくことでご利用可能です。

という画面が出る。ここで、「ログイン」の部分のリンクをクリックしてジャンプすると、

https://www.hatena.ne.jp/login?backurl=http%3A%2F%2Fb.hatena.ne.jp%2Fadd%3Fmode%3Dconfirm%26
title%3D%26url%3Dhttp%253A%252F%252Fexample.com%252F%26is_bm%3D

へ移動し、ログイン画面となる。ここで、正しいユーザ名とパスワードを入力してログインが成功すると、

http://b.hatena.ne.jp/add?mode=confirm&title=&url=http%3A%2F%2Fexample.com%2F&is_bm=

に自動的にジャンプする(ログイン前の画面へ戻ってくる)ようになっている。すなわち、ログイン画面の /login というCGIプログラムのパラメータ「backurl」は、ログイン成功時に自動的にジャンプする先のURLとして使用されているわけだ。

しかし、このパラメータ「backurl」に任意のURLを指定するとどうなるか。つまり、例えば

https://www.hatena.ne.jp/login?backurl=http://takagi-hiromisu.jp/exploit

にアクセスした場合にログイン成功後どこへ飛ぶか。以前は、この指定された任意のサイトへジャンプする状態だった。(現在は修正されている。)

これがなぜ問題なのか。以下に、届出時に使ったデモの画面で示す。

phishing詐欺師が、どこかのサイトから以下のURLへの罠リンク(「B!」ボタンなどで)を仕掛けていたとしよう。

https://www.hatena.ne.jp/login?backurl=http%3A%2F%2Ftakagi-hiromitsu.jp%2Fsecurity%2Fvuln-info%2F
20070408-hatena%2Flogin.html

これにアクセスすると図1の画面が出る。

はてなのログイン画面のキャプチャ画像
図1:罠リンクを踏んで本物のはてなのログイン画面にジャンプした様子

安全なWebサイト利用の鉄則に従いアドレスバーを見ると、確かに hatena.ne.jp ドメインの画面であるから、本物サイトであると確認できるので、ユーザ名とパスワードを入れて「ログイン」ボタンを押したとする。すると、図2の画面が一瞬だけ現れるが、すぐに図3の画面に自動的にジャンプする。

「ログインしています」と書かれた、はてなの画面のキャプチャ画像
図2:一瞬だけ現れる画面の様子

「ユーザ名またはパスワードが違います」と書かれた、はてなのログイン画面そっくりの画面のキャプチャ画像
図3:パスワードを入れた後に現れた画面の様子

ここで、一瞬現れた図2のことを気に留めることなく、図3の画面を見たならば、「パスワードの入力を間違えてしまった」と普通は認識するだろう。そして、もう一度ユーザ名とパスワードを入れてしまう。

しかし、図3のアドレスバーを見るとわかるように、これは偽サイトである。

さて、どうだろうか。どこのサイトでも、ログイン画面でパスワードを打ち間違えると、このように「ユーザ名またはパスワードが違います」というメッセージが出るようになっているものだが、打ち間違えて再度パスワードを入れるその都度、毎回アドレスバーのURLを確認しなければならないのだろうか?

それを「安全な利用の鉄則」とするのは、さすがに酷な話だ。

これは、「backurl」に信頼されていない任意のURL(はてな以外のサイト)を指定できてしまうことが誤りであり、はてなのこの仕組みの方を修正するべきであると考えた。

現在は、はてな以外のサイトを「backurl」に指定すると、(ログイン成功時に)はてなトップページへジャンプするように修正されている。

ちなみに、Yahoo! JAPANの場合は、以前から対策されていたようで、「backurl」相当のパラメータにYahoo! JAPAN以外のURLを指定してアクセスするとその時点で、

お客様がご覧になろうとしているページは、
Yahoo! JAPANのサービスではありません。

以下の可能性が考えられます。
・Yahoo! JAPANを装うウェブページに掲載されている偽のリンクをクリックしてしまった。
・メールや掲示板などに掲載されている偽のURLをクリックしてしまった。
・直接URLを入力した際に誤ったURLを指定してしまった。
(略)

というエラー画面が出るようになっていた。

はてな以外にも、私の知る範囲で同様の問題のあるサイトがあったので、IPAに届け出たところ修正された。

あるサイト(現在は修正済み)では、図2相当の画面が存在せず、正しいパスワードを送ると直接図3相当の画面が出るようになっていた。この場合はより騙される危険が高いだろう。

もし他にもこの問題を抱えているサイトがあった場合、そのようなサイトを使う利用者は、次のことが回避策となる。

回避策: パスワード入力ミス後の再入力の画面も含めて、常にいかなる場合も、パスワード入力の際には画面のアドレスを確認する(再確認する)。

*1 1つ目のYouTube風画像リンクの話はどうでもいい。「再生ボタンを押すとウィルスのダウンロードが始まる」というが、ダウンロードが始まることは何ら問題がない。キャンセルすればいいのだから。そもそも、この画像の貼られたページを見に行ったのなら、その時点で別の方法でダウンロード開始させることが可能なわけで、こういう画像が云々という話は全くセキュリティリテラシに関係がない。単に素人を面白がらせるだけの話で役に立たない。

本日のリンク元 TrackBacks(4)

2007年05月13日

役所のPKIの出鱈目ぶりも末期的 佐賀県警察本部の場合

この日記が扱うテーマのひとつは、「ひとたび発生した誤り解説は作業員のコピペによって際限なく広がっていく」という現象の社会的危険性(止めることの困難性)についてである。

その意味で、真似されやすいインチキ文を最初に書いた者の罪は重い。

昔、2002年3月に総務省が電子申請システムを最初に公開したとき、ルート証明書をインストールするよう一般市民に指示しているのを見て、「これは絶対ろくなことにならない」と予感した。「安全にインストールさせれば別に問題ない」といった技術論はいかにも出てくるわけだが、ろくでもない説明が書かれて伝染することは目に見えていた。その末路が上の広島市、高知県、埼玉県などの事例であった。

2002年に総務省はこういう解説ページを作っていた。

こんな文章が想定される読者達に理解されるはずもないわけだが、「安全な通信を行うための証明書」などという珍妙な用語がこのとき創造され、これがその後、他の省庁や地方公共団体にコピペされて伝染していった。

これらの中には劣化コピーもあり、証明書の真正性の確認方法が出鱈目だったり、そもそも確認の必要性が省略されていたりした。

そして去年、総務省CAとLGPKIについては一応の解決(Windows XP + IE 限定)がなされた。

さて、話を現在に戻す。

佐賀県警察本部のWebサイト http://www.saganet.ne.jp/kenkei/ *1 に「佐賀県警察電子申請システム」というコーナーがある。

佐賀県警の画面
図1: 佐賀県警がSSLを使用している理由を説明している様子

佐賀県警察電子申請システムでは、インターネット通信の安全を確保し、盗聴等を防ぐために、SSL暗号化技術を導入してデータの暗号化を行っています。こちらをご覧ください。

と書かれているのだが、「こちらをご覧ください」をクリックすると、オレオレ証明書の警告が出る(図2)。

警告と証明書の画面
図2: 「佐賀県警察本部電子ポータルサイト」で出るオレオレ警告と証明書

よく見ると、発行者が「SecureSign Public CA1」となっている。これは、日本認証サービスが発行する証明書の場合と同じ発行者名だ。日本認証サービス発行の証明書なら警告は出ないはず(IEでは出ない)なのに、この警告が出るというのは、おそらくこれは第六種オレオレ証明書なのだろう*2

第六種オレオレ証明書

正規の認証局(中間認証局)から取得したサーバ証明書であるが、中間認証局の証明書をサーバに設置していないため、クライアントが認証パスを検証できないもの。

一般に、サーバ証明書を設置するときは、サーバ証明書だけでなく、認証局の証明書(中間認証局の場合)も一緒にサーバに設置することになっている。このことは、例えばベリサイン社が次のように説明している。

  • 中間認証局の証明書はなぜ必要なのでしょうか, 日本ベリサイン ヘルプデスク

    Q:中間認証局の証明書はなぜ必要なのでしょうか

    グローバル・サーバIDを取得した場合は、中間CA証明書のインストールが必要とあります。 中間CA局の証明書はなぜ必要なのでしょうか。

    A: グローバル・サーバIDは、以下のように 3段階の階層で証明書を検証する構造になっています。 3段階の階層構造のサーバIDをウェブサーバにインストールする場合、中間認証局の証明書(中間CA証明書)もあわせてインストールする必要があります。(以下略)

この作業を怠ると第六種オレオレ証明書の警告が出る。民間サイトでこのミスをしているところに出くわすことは滅多にない。

で、この警告を無視して先に進んでみると、リンク先のページは驚くべき内容になっていた。

もうどこから突っ込もうか目移りしてしまうほど滅茶苦茶に出鱈目なことばかりが書かれている。*3

まず、「証明書のダウンロードはこちらより行い」とあるリンクをクリックすると、証明書ファイル「PWSCA.cer」が得られる。この証明書ファイルは何だろうか。内容を見てみると図4のようになっている。

証明書を表示した画面
図4: 佐賀県警がダウンロードさせている証明書の中身

これは、日本認証サービス(株)の中間認証局証明書だ。つまり佐賀県警は、自分のサーバに設置するべき中間認証局証明書を、自分はやらないで、ユーザに入れろと指示しているのである。

しかも、これのことを「アプリケーションCAの自己証明書」だとか言っている。「アプリケーションCA」とは何のこと(のつもり)かというと、LGPKI(地方公共団体組織認証基盤)の「アプリケーションCA」のことだろう。しかし、佐賀県警はSSLにLGPKIを使っていない。(日本認証サービスから証明書を買っている。)

このことについて、4月16日に佐賀県警に電話して「間違いだよ」と伝えた。電話に出たのはヘルプデスク担当の人で、県警職員ではなく業者の者だという。

話をちゃんと聞いてくださる方だったので話はわりと早く通じた。中間認証局証明書のサーバへのインストールが必要なことも理解してもらえたし、この解説が滅茶苦茶に間違っていることも理解してもらえた。

話を聞いてみると、システム開発はNEC九州だが、サーバ証明書を設定したのは別の業者で、この説明ページを書いたのは(また別の業者である)ヘルプデスク担当の自分だという。どうしてこんな内容のことを書いたのかを聞いてみたところ、他のサイトに書いてあったのを参考に書いた(真似した)のだという。

2002年の総務省文書から始まった劣化コピーもここまで行き着いたわけだ。おそらくこれ以上酷くはなりようがないだろう。

ヘルプデスクの人は、「指摘された事項を報告書に書いて県警職員に渡す」と言っていたが、あれから4週間経った今、証明書の設定も直っていないし、出鱈目解説も削除されていない。

佐賀県がCP/CPSなしに独自CAのルート証明書を市民に入れさせていた

佐賀県は今年1月の時点で、図5のように、「Spade CA」などと自称する独自CAのルート証明書を一般利用者にインストールさせていた。

その画面

安全なインストール方法の説明も見あたらないが、それ以前に、CP(証明書ポリシー)もCPS(認証局運用規定)も見あたらない。そこで、メールで以下の質問を送ってみた。

Date: Mon, 15 Jan 2007 22:25:36 +0900
From: Hiromitsu Takagi <********@takagi-hiromitsu.jp>
To: denshi-kencho@pref.saga.lg.jp
Subject: Spade CAの証明書ポリシーおよび認証局運用規定について

電子申請システムについてお尋ねします。

電子申請システムApplet証明書の設定方法
https://www.pref.saga.lg.jp/citizenH/help/appletnavi/appletsign.htm

によれば、佐賀県電子申請システムを利用するにあたっては、「佐賀県独自CA
(Spade CA)のルート証明書のインストールが必要とのことですが、

「Spade CA」の証明書ポリシーおよび認証局運用規定(CP/CPS)はどこにあり
ますか?


以上の点、お尋ねします。

すると、翌日に、佐賀県統括本部情報・業務改革課から、以下の内容の回答があった。

現在、電子申請システムでアプレット署名に使用するコーザサイニング証明書に
ついては、佐賀県独自のプライベートCA証明書spadeCAを用いていますが、
ご質問の「Spade CA」の証明書ポリシーおよび認証局運用規定(CP/CPS)が
ないことなどから、LGPKIでコードサイニング証明書を発行する予定としており、
できるだけ早い時期に移行するため、現在作業を行っているところです。

残念ながらどういう経緯で独自CAにしたのかは聞きそびれた。

その後、「Spade CA」は廃止され、佐賀県から「電子申請システムApplet証明書の設定方法の変更について」という告知が出ている。

佐賀県といえば、かつて、「電子申請システムのモニターアンケート」を実施して、「証明書のインストールは簡単」という結論を出していたところだ。

都道府県単位で比較すると、最近では佐賀県が最も劣悪と言える。

*1 2007年5月13日の時点で。www.saganet.ne.jp は民間のISPであり、今後このURLが他の者の手に渡る可能性があるので注意。

*2 もしくは、私のこのときのアクセスが、通信路上で攻撃されている最中であったか。

*3 さて、間違いは全部で何個だろうか。

本日のリンク元 TrackBacks(2)

2007年05月21日

住民票コードを市町村が流出させても全取替えしない先例が誕生する?

愛媛県愛南町の住基情報がWinnyネットワークに流出させられた事故では、住所、氏名、生年月日、性別と共に住民票コードも流出しているとのことだが、報道によると、愛南町は、「住民票コードの変更を求める住民については変更に応じる」とされていた。愛南町の発表文を確認してみると次のように書かれている。

愛南町では今後、5月21日(予定)から職員全員で関係する全世帯を訪問し、情報が流出したことについての説明とお詫びに伺う所存でございます。また、住民票コードの変更を希望される方には、変更申請を行っていただくようお願いいたします。

愛南町の住民の個人情報の流出に関するお詫びとお知らせ, 愛媛県愛南町, 2007年5月18日

「変更に応じる」と言っても、今回の事故の対応措置というわけではなく、元々、住民票コードの変更は平常時から用意されている手続き(住民基本台帳法第30条の3)であるし*1、希望する者には応じると言っても、変更する必要性に理解が及ばない住民は希望を出すはずもない。

これはおかしいと思ったので、全部取り替える予定が本当にないのか、愛南町に確認すべく電話したところ、概ね*2以下のような内容のやりとりとなった。


私: Winnyへの流出事故で住民票コードも流出したとのこと。住民票コードを全部付け替える措置はとらないのですか?

町: 変更を希望する住民については変更を受け付けている。

私: 希望すれば変更してもらえるのは元々用意されている制度ですよね。希望のあった住民についてだけ変更するといっても、変更する必要性を住民が自発的に思い付けるかという疑問がある。

町: 総務省に相談したところ職権で取り替えるのは適切でないとのこと。全部取り替えると、住基カードを使用している住民の住基カードが全部無効になってしまう。住基カード利用者に対してまで職権で変更するのは適切でない。

私: しかし、報道で「住民票コードの変更を希望する場合は速やかに手続きする」と伝えられているように、住民票コード変更の必要性というものは存在するのですよね? どのような危険性を想定して「速やかに応じる」としているのですか?

町: 住民票コードから個人が特定されることはない。

私: え? 意味がわからないのですが、今回流出したことによって、住民票コードからの個人特定が可能になったのではありませんか?

町: 住民票コードだけからでは個人を特定することはできない。

私: いや、ですから、今回の流出では、住所氏名等と住民票コードとが一人毎にペアになった一覧表が漏れたのですよね? まさか、住所は住所、氏名は氏名、住民票コードは住民票コードで別々に独立な塊のデータだったとか、そんなわけはないですよね。だから、住民票コードからの個人特定が誰にでも可能になったのではありませんか?

町: 住民票コードは行政機関以外では使われていないので、問題ない。不安に感じた住民については変更を希望してもらっているが、希望者はごく僅か。

私: いやちょっと待ってください。まずひとつひとつ論点を確認していきましょう。さきほど、「住民票コードから個人は特定されない」とおっしゃったのは誤りだった、取り消すということでよろしいですか?

町: ……。行政機関以外では住民票コードが使われることがないので、住民票コードがあっても意味を成さない。

私: 民間での利用は禁止されていますからね。それはわかりますよ。では、行政機関に対しての使用はどうですか? 住民票コードは本人確認情報として取り扱われているわけですよね。住民票コードがなかった時代と比べて、住民票コードの記載を条件に手続きを簡略化した行政手続きがありますよね(後述)。住民票コードは言わばパスワードとして用いられているわけで、これが流出したということは、行政手続きに対するなりすましのセキュリティリスクが新たに生じているのではありませんか?

町: 明日もう一度総務省に確認する。

私: そのリスクについて住民が理解していると思いますか? リスクを理解していなければ、自ら変更の請求を出すはずがないわけですが。

町: 今日はこれ以上答えない。

私: 住基カードを無効化して住民に不便をかけることが問題であるなら、「住基カード保有者のうち変更しないことを希望した人だけ変更しない」「それ以外は全部付け替える」という選択もあるはずで、そちらが正しい措置ではありませんか?

町: 今日はこれ以上答えない。

私: このような事態における対応の規定はないのですか?

町: 今日はこれ以上答えない。


念のため総務省自治行政局市町村課にも電話で取材した。担当の方とお話ししたところ、各市町村で判断することであって総務省が指導する立場にはないとのことで、総務省の見解はないとのことだった。規定もないということのようだ。

住民票コードの記載を条件に本人確認手続きを簡略化した行政手続きとしては、例えば以下などがある。

  • 年金の裁定請求等における住民票コードの利用について, 社会保険庁, 2003年

    一部の手続きにおいて、住民票コードを記載していただくことで市町村長の証明書等の提出を省略できるようになりました。

    (略)これにより、一部の手続については、住民票コードをご記入いただくことで、本人確認情報を証明する市町村長の証明書等(戸籍抄本や住民票の写し等)の添付が省略できます。(略)

    住民票コードについては、申請書・届書の余白部分にご記入いただくか、住民票コードをご記入いただいた用紙を申請書・届書に添付していただくようお願いします。

    なお、住民基本台帳カードをお持ちいただいても、住民票コードが券面表記されておらず、社会保険事務所等では住民票コードを確認することができませんので、市町村長から通知された住民票コードのご記入をお願いします。

朝日新聞報道によると、町長が次のように述べたとされている。

「住民の不安を解消するため」に職員がして回る説明とは、ようするに、「住民票コードから個人が特定されることはありません」だとか、「住民票コードは行政機関以外では使われていないので問題ありません」とかいう説明なのだろうか。

説明しても理解しない住民が「不安がる住民」であり、そういう人達についてだけ変更を受け付けておけばいいと。そういうことだろうか。

追記

上の電話のやりとりの記録は脚注にも書いたように表現のニュアンスまで再現したものではない。先方がこのような口調で述べたわけではなく、このような内容の発言があったという程度の意味である。「住民票コードから個人が特定されることはない」という趣旨の発言はあったし、「行政機関以外の手に住民票コードが渡っても意味を成さない」という趣旨の発言も確かにあった。

なぜこのような誤った思考を招いてしまうのか。

憶測するに、櫻井よしこ氏に代表される住基ネット反対運動の「牛は10桁、人は11桁」といった情緒的なやり口に辟易させられ続けたために、反射的に「住民票コードから個人が特定されることはない」「住民票コードは行政機関以外では使われないので問題ない」と反応するシナプスが出来上がってしまっているためではなかろうか。つまり、「住民票コードが漏れたくらいで不安がる住民 = 櫻井よしこレベル」という図式が出来上がっているのではないか。

さて、改めて考えてみるに、行政機関に対して住民票コードを本人確認情報(パスワード)として使用する手続きの存在が、この漏洩事故の危険度をどの程度のものにしているだろうか。

上に挙げた社会保険庁の例では、本人確認情報を証明する市町村長の証明書等の添付を省略できる手続きは、一部の手続きに限定されているようだ。これが何のために限定されているのかは知らない。つまり、仮になりすまし申請が行われても住民に大した被害が出ないような手続きに限定されているのかどうかだ。

もし、現状で、そのような省略が認められた手続きがごく僅かしか存在せず、いずれも大した実害のないものであるのならば、役所の方が言うように、「住民票コードが流出しても問題ない」という理屈を立てることが可能なのかもしれない。

たしかに、Web検索で調べた限り、住民票コードで本人確認とする手続きは他に見当たらなかった。おそらく、電波系サヨク運動家らの住基ネット反対運動のせいで、住民票コードの利活用を拡大することが抑制され、限定的なものに止められているためではないだろうか。

そうすると次のことが重要となる。

もし、今回の事故で、住民票コードの全取替えを行わないのが妥当とする判断(他の行政機関手続きに対するリスクは十分に小さいという理由による判断)が確定するならば、今後、新たに住民票コードを利活用する手続きをどこかの行政機関が追加する際には、愛媛県愛南町の住民(および元住民等)の住民票コードは公開状態にあることを前提にしなければならない。

つまり、住民票コード利活用の発展はもう見込めないということだ。電波系サヨク運動家の思う壺ではないか。それを避けるためには今回流出した住民票コードを全部付け替えるしかない。

*1 住民基本台帳法で、住民が自身の住民票コードの変更を請求できるようになっているのは、次のような事態に備えてであろう。同法は、住民票コードの民間利用を禁止しており、契約に際して住民票コードの提示を要求するような行為が禁じられている。しかし、これを守らない業者が現れたときに、住民がこのことを知らずに要求に応じて住民票コードを告げてしまうことが起こり得る。そのような場合に、住民が後になって問題に気づいた際に、住民票コードを変更することでそれ以降のトラッキングを断ち切るという仕組み(Webブラウザにおけるcookieの削除機能に相当する)だろう。この場合は、自分の住民票コードを告げてしまった当人に責任があるのだから、当人の請求があったときに変更すればよい。それに比べて今回の事故は、住民に責任がない。行政機関が使用するための秘密情報を行政機関が漏らしたという事態であるのに、住民の請求を待つというのはおかしい。

*2 表現のニュアンスは正確に再現していない。

本日のリンク元 TrackBacks(5)

2007年05月26日

続・住民票コードを市町村が流出させても全取替えしないのが標準となるか

これまでの先例では全取替えだった

住民票コードが市町村単位で流出した事例は過去に1件ある。2002年12月26日に、福島県岩代町の住民基本台帳のバックアップデータを格納したDATテープが、ジュラルミンケースごと運搬中の業者の自動車から盗まれるという事件が起きた。岩代町は、事件発生の報告から46時間後、住民票コードを全部変更する方針を決定して記者会見を開いている。

ただし、このときも職権による変更*1はできなかったようで、変更の申請を住民から集めるということが行われたようだ。

  • 岩代町、住民基本台帳コード変更へ全戸説明, 福島中央テレビ, 2002年12月30日

    変更には町民からの申請が必要なためきょうから役場職員が1世帯ずつをまわり、新しいコードへの変更申請書を集めてまわっています。

  • 情報はここから漏れる, 日経コンピュータ, 2003年6月30日号

    盗難から4日後の12月30日、福島市内の河川敷で、鍵がこじ開けられたジュラルミン・ケースとDAT3本が見つかった。残り2本はなかったが、「警察によるとDATケース内のテープにさわった形跡はなかった」(総務課の遠藤清一主幹兼情報管理係長)。データも暗号化されていたため情報の漏洩はないように思われたが、住民票コードをすべて振り直すことにした。

    「福島県を通して総務省に相談したところ、情報漏洩の可能性が低いため、本人の要請なしに変更はできないと言われた」(遠藤係長)。そこで職員を総動員し、約2300ある全戸を訪問。住民票コード変更の手続きをした。

  • 福島・岩代町、住民票コードを変更し住基ネットに再接続, 毎日新聞 2003年1月7日 大阪朝刊

    全町民の住民基本台帳データを記録したテープが盗まれた福島県岩代町は6日、全町民の96.7%に当たる9278人分の住民票コードを変更し、住民基本台帳ネットワーク(住基ネット)に再接続した。(中略)町職員が全世帯を回り、コード変更請求書への記名押印を求めたが、5日夜までに、11世帯25人が住基ネットからの離脱を望んで記名押印を保留し、92人は現行コードを希望、204人は不在で、記名押印を得られなかった。

「本人の要請なしに変更はできない」(職権による変更ができない)の理由はいまひとつよくわからない。日経コンピュータの記事によれば、「情報漏洩の可能性が低いため」との理由が付けられているが、制度上不可能なのにそれが正しく伝えられていない可能性もあるような気がする。もし、岩代町の事例で職権による強制変更が妥当でないとされた根拠が、「回収されたテープ3本に犯人が手を付けた様子がなく、かつ、暗号化されているので漏洩はない」というものであるのなら、今回の、愛南町のWinnyネットワークへの流出はどうなのか。

住民票コードは公開してもよいものなのか

前回の日記に対して武田圭史さんから「住民票コードはパスワードなのか?」というトラックバックを頂いた。

まず、パスワードという言葉の定義だが、明確な定義があるわけではなく、もし狭義のパスワードを定義するならば、不正アクセス禁止法2条2項が定義する「識別符号」の1号のものだろう。この場合は定義は明確で、「当該アクセス管理者によってその内容をみだりに第三者に知らせてはならないものとされている符号」である。しかし、広い意味でのパスワードは、例えば文化庁のスローガン「著作権 〜新たな文化のパスワード〜」に代表されるように、単に何かをパスするためのワードというような意味しかない。

武田氏は、住民票コードはパスワードではなく「ユーザID」の方だという。

私の理解では、住民票コードはコンピュータでいうユーザID(またはユーザ名)に相当する概念であり、対象者を一意に特定するための符号である。情報セキュリティの用語で表現すれば住民票コードは個人に対する「識別(Identification)」のための符号と言えるだろう。もちろんこの情報を使えば本人を一意に特定できるため、知らせないことで他人の悪用に対する敷居を高めることはできるが、それを知っているからといって本人と認証するには不十分である。

これに対して、一般にパスワードと呼ばれるものは、その情報を知っているということをもって他の手段で識別された本人が間違いなく本人であることを証明する「認証(Authentication)」のための符号である。通常パスワード登録後は、紙に書きだすことを求めたり画面に表示されことはなく、利用者に対して厳に秘密情報として管理することが求められる。

住民票コードはパスワードなのか?, 武田圭史, 2007年5月23

たしかに、行政手続きの一部において住民票の写しを提出することになっている目的のひとつは、その住所氏名の人物が実在することの確認にある。つまり、架空の住所氏名(故意によるものや誤記によるもの)の申請を拒絶するためには、住民票の写しがあればよい。住民基本台帳ネットワークが構築されて以降は、住民票コードが示されればその目的が達成できるようになった(申請を受け付ける行政機関が、住民票コードで検索することで、住基ネット経由で市町村の住基台帳にその人物が実在することを確認できる)ため、その目的での住民票の写しの提出が不要になった。

その一方で、住民票の写しは、一般には、「本人確認」のためにも使用されている。例えば、銀行で口座を開設する際に住民票の写しがあれば十分とされているのは、架空人物でないことの確認と同時に、実在人物へのなりすましの防止をも目的としていることは、銀行口座開設における本人確認の目的からすれば明らかであろう。

ここで、「住民票は誰でも取れる(住民基本台帳法12条2項)のだからなりすまし防止になっていない」という声が聞こえてきそうだが、第三者が請求する際には目的を示してそれが正当と認められる必要があり(同12条3項、5項)、目的を偽った者には10万円以下の科料という刑事罰が科されることになっている(同52条)のであるから、一定のなりすまし防止効果をもたらしているのであり、なりすまし防止目的が存在しないことを意味するわけではない。

もちろん、重大な犯罪の目的でなりすましをする者に対して、10万円の科料という軽微な刑事罰が抑止効果を持つはずがないという指摘は可能だが、カジュアルななりすまし行為を防止することもこの仕組みの目的であろう。

コンピュータの世界で情報セキュリティを議論する際には、こうした中途半端な仕組みを許さない傾向がある。「サイバーノーガード戦法」という隠語があるように、「悪用は法律で禁止されているから技術的な欠陥を直さない」といった態度に対して批判がある。なぜなら、コンピュータ世界を対象とした議論は、技術的な解決策が存在する場合はそれを採用してしかるべきという思想に基づいているからだ。

しかし、実世界における本人確認手続きはどうだろうか。武田氏が言うような、コンピュータの世界の「識別」と「認証」といった区切りを、実世界に適用することは妥当なのだろうか。

まず、そもそもコンピュータ世界における認証というものが何であるのかを改めて考えてみると、それは、所詮、「ログインしようとしている者がユーザ登録時の者と同一か」を確認するものでしかない*2

このことは、「掲示板実名制」の実現方法を考えてみるとわかりやすい。匿名掲示板化するのを避けようとユーザ登録とログインを必要とするようにしたとしても、ユーザ登録が何回でもできる以上は、それによって達成できているのは、ある発言とある発言が同一人物によるものであることを示しているだけで、それ以上のものはない。

武田氏が言う「識別」と「認証」は、情報セキュリティ実現のための部品にすぎない。我々が情報セキュリティを議論するとき、部品に着目しているときは、部品が正しく機能するかを技術的論拠に基づいて検討し、部品が駄目ならばその利用システムも駄目という帰結を導くことができる。そのとき、部品を何の目的で使用するかは独立した議論とすることができる(部品が駄目でないことがその利用システムが駄目でないことを意味しない)ため、この部品の切り分け方は都合がよい。

だが、実世界における人の認証というものは、そんな簡単な話にはならない。

まず、印鑑登録と印鑑登録証明という市町村のサービスがあるが、これは、実印は他人に渡さないという前提(コンピュータ世界で言うところの「みだりに第三者に知らせてはならないものとされている」に相当する)の下、印鑑登録証明と登録印鑑があれば本人であると見なすというものである。印鑑登録証明は、近頃流行りの認証APIにおけるcredentialに相当すると言えるが、コンピュータ世界のcredentialでは技術的にその偽造を防止しているのに対し、印鑑証明の偽造防止は刑罰規定による担保しかされていない。この不完全さを技術的に解決しよう(特に電磁的記録の場合は偽造が容易であるから)というのが、電子署名法で定められた仕組みであり、PKIによる技術的な偽造困難性を背景として、電磁的記録の真正な成立の推定を可能にしている。

これらの仕組みも上に述べた意味で「部品」に過ぎない。これらを利用するにも初期登録が必要であって、初期登録のためにこの認証の仕組み自身を使うことはできず、従来通りの何らかの「本人確認」を前提として成り立っている。

また、現実の世界は、この部品を常に使用するわけではない。従来より、実印を必要とするような契約はごく一部に限られていたし、今後も、電子署名法に基づく電子署名が技術的に至高だからといって、銀行口座の開設にそれを求められるようになったりはしないだろう。

なりすましが致命的な問題となるような特に重要な手続きにおいては自動車運転免許証や、保険証、パスポートなどの身分証明書の提示が求められるようになってきているけれども、それらの証明書類とて、取得時に他の証明書に基づいて本人確認をしているのであって、部品の技術論における完全性のようなものはそこにはない。なりすまして証明書を取得する(もしくは偽造する)ことのハードルの高さに応じてアナログ的に評価して、それぞれの手続きのリスク毎に、意義ある確認作業であると考えられているにすぎない。

つまり、まあまあそれなりに本人確認になっているようなものが「本人確認」として使われているのが現実であり、それを広い意味でのパスワードとして「言わばパスワード」と表現した。個別のリスク評価をすることなく一律に、狭い意味でのパスワードに当たらないものを本人確認用途として使ってはならないとする主張は、思想に基づく意見ではあり得ても、論理的帰結として導き出される真理とまでは言えない。

武田氏は、米国のSSN(社会保障番号)の過ちを繰り返してはいけないと言う。

「識別」のための情報を「認証」に用いる誤った例としては、米国で社会保障番号がパスワードのように用いられている事例があげられる。(略)

「住民票コード」がパスワードとして利用されているケースが実際に存在するのであれば、まず修正すべきはその「住民票コード」の利用方法ではないだろうか?米国の社会保障番号と同じ過ちは避けるべきだろう。

住民票コードはパスワードなのか?, 武田圭史, 2007年5月23

米国のSSNの問題は、次の3つに分けられる。

  1. 民間事業者が重要でないサービスにおいてまでSSNの提示を求めるようになったため、名寄せによりプライバシーの問題が生ずるという問題。
  2. 民間事業者が、SSNの提示によって本人確認しようとしても、広く他の民間でも使われてしまっているため、なりすましを防止できないというセキュリティ問題。
  3. 公的機関が、SSNの提示によって本人確認しようとしても、民間で使われてしまっているため、なりすましを防止できないというセキュリティ問題。

これらは日本の住民票コードには存在しない。住民基本台帳法30条の43で、民間での住民票コードの利用が禁止されている。

では、上記 3. の変形として、「公的機関が、住民票コードの提示によって本人確認しようとしても、他の公的機関で使われてしまっているため、なりすましを防止できない」ということを、セキュリティ問題として主張することができるだろうか?

住基ネット反対派はこれを問題だと主張する。公的機関の職員が、業務上知りえた秘密である他人の住民票コードを悪用する可能性を無視してはいけないと彼らは主張する。

現実の社会はコンピュータ世界の技術論のような限定された前提の上で成り立っているのではない。どこまで行っても完全とはなり得ないのであり、どこかに線を引かざるを得ず、それが法律である。住基ネット反対派が言っていることは、現状の制度よりもよい選択肢があるという主張であろうが、それは思想に基づく意見ではあるけれども、論理によって導き出される真理とまでは言えない。

私は、基本的に、可能な限り、論理によって導き出される真理についてだけしか言わないようにしているつもりだ。その立場では、住民票コードの記載で本人確認とする制度設計を選択すること自体は否定されない。

私から言えることは、次のどちらかしかあり得ないだろうという指摘だ。

  • (A) 住民票コードは、本人確認用途として用いられることがない(と制定されている)ので、住民票コードが公開状態となっても問題ない(住所氏名と共に公開状態となった場合において)。

  • (B) 住民票コードは行政機関内で閉じて秘密でなければならない(よう運用されている)ので、住民票コードが本人確認用途として用いられることがあり得る。

現実の制度と運用がこれらのどちらになっているのかは知らない。社会保険庁の「一部の手続きにおいて、住民票コードを記載していただくことで市町村長の証明書等の提出を省略できるようになりました」で挙げられている各手続きがどうなっているか全部を検討する必要がある。

また、仮に現存の手続きの全てを検討して、いずれも住民票コードを本人確認用途で用いていないと確認できたとしても、今後そのような手続きが現れないことを保証する、法令等による定めがない限り、一市町村が上記の(A)だと勝手に解釈*3して、流出した住民票コードの全取替えをしないと決定するのは許されるのか?

と、そのようなこと私は前回の日記で言ったつもりだ。

追記

武田さんから「住民票コードをパスワードにしたくない経済的理由」というトラックバックをいただいたので、追記を。

私自身の考えは、リスク要素も加味した経済合理性の観点から言って(A)を選択するべきと考えている。(略)

特に今回のような情報漏洩が発生する度に住民票コードの総取替が発生し、住民基本台帳カードも全て再発行ということになるのであれば、それこそ「住民票コード利活用の発展は見込めない」ということになってしまう。(本来漏洩があってはならないのだが・・・)

住民票コードをパスワードにしたくない経済的理由

その理屈からすると、認証局の秘密鍵が危殆化しても取り替えないんだろう。

そもそもあってはいけない事態が起きたときの話。本来は、市町村の全住民の住所氏名がその市町村の責任で全部流出したときは、その市町村の大字、小字の名称、番地を全部付け替えるべきと言ってもよいかもしれないところ、それはあまりにも不便になる(住所氏名番地は人が使うものであるし、市町村外の人達、公的機関以外の人達も使っている)ので、しないわけだけれども、それに対し住民票コードは、ただの内部コードなのだから(基本的に機械が使うもので、公的機関の都合で公的機関でのみ使うものだし、既に変更用の仕組みが作りこまれている)、いつでも変えたらいい。「職権による変更はできない」というのがおかしい。

2002年の岩代町のように変更申請書を出してもらうよう全世帯を訪問することが経済合理性がないというのであれば、住民票コードの付け替えが職権で処理できるよう定めておけばよいのであって、ボタン一発で全変更する機能をシステムに作っておくことができるだろう。住民票コードの各住民への再通知の郵送代は、事態の深刻性からすればたかが知れている。

住基カードの取替えというが、住基カードを提示しても(住基ネット端末のないところでは)住民票コードを読むことはできない。社会保険庁もそう言っていた。

なお、住民基本台帳カードをお持ちいただいても、住民票コードが券面表記されておらず、社会保険事務所等では住民票コードを確認することができませんので、市町村長から通知された住民票コードのご記入をお願いします。

年金の裁定請求等における住民票コードの利用について, 社会保険庁, 2003年

そして、住基カードの偽造はできないのだから、住民票コードが漏洩した理由で住民票コードを付け替える場合、住基カード内の住民票コードを変更する必要がない。旧コードの住基カードを提示した際に、住基ネット端末側で新コードとの対応付けができるかと言えば、住民票コードは変更しても旧コードは履歴として住基台帳に記録されているのだから、そのような処理ができる。

公的個人認証を導入している住基カードはどうか。PKIを用いた認証なのだから、そこではもはや住民票コードは本人確認目的に使用していない。

よって、住基カードの取替えは必要ない。

(B)を選択する前提として住民票コードは行政機関内で閉じて秘密として運用されるという前提がある。現在でも行政機関内の個人情報は秘密として扱われているはずだが、実際の運用を考えるといくらか不安な点が生まれる。通常パスワードのような本人確認情報は紙に書いて渡すという行為は行われないが、住民票コードは紙に書いて提示することが求められる。住民票コードを本人確認情報として取り扱うに十分なレベルの保護を行うには従来の事務手続きを大きく見直す必要がありそうだ。

住民票コードをパスワードにしたくない経済的理由

「通常パスワードは紙に書かない」というが、そうだろうか。銀行の暗証番号は登録時には紙に書いて渡すし、ほかにもいろいろある。パスワードは紙に書かないというのは、書かなくて済むコンピュータとネットで完結した世界においてはそうしているという話であって、そうしたある種のセキュリティの掟のようなものは、「可能なことはそうしておけ」というものであって、周りの前提を無視した絶対則ではない。

元々住民票の写しを持ってこさせることだけで本人確認としていた手続き(身分証明書の提示がない)についてだけ、住民票コードが同じ役割用に使われる(ことがあるかもしれない)という話なので、その程度の管理でよいということができるかもしれない。

それに比べて、全情報が流出という事態、本来全変更は簡単という、そういう話だ。

*1 ここで言う「職権」とは何か。住民票は、居住実態がない場合等に、職権で削除できることになっている。(住民基本台帳法第18条「戸籍の附票の記載、消除又は記載の修正は、職権で行うものとする。」等)その類推で、住民票コードの変更を住民の申請なしに変更することを「職権による変更」と言っているのだろう。(電話した際に愛南町の担当者は用語の説明もなく「職権」という言葉を使っていた。)

*2 このことは、生体認証を用いた場合でも同様である。生体認証というと、何か、根源的なところで人を認証しているかのように感じられるかもしれないが、実際には、登録時と同じ人であることを確認しているにすぎない。(生体情報が組織横断的に共通化されて管理されるような事態にならない限り。)

*3 実際には総務省の判断を仰いでいるのだろうが、形式的には一市町村の判断ということになっている。総務省に電話で尋ねた際に担当者は、「愛南町がそのように判断されたということでしょう」と言っていた。

本日のリンク元 TrackBacks(100)

2007年05月27日

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

PlaceEngineが研究実験の段階を越えて商用サービスとして提供開始されているということで、「みんなの地図2」を購入した。使用してみて、想像以上に実用になるものであることを知った。東京の都心で試したところ、たいていの場所でかなりの精度で場所を特定してくれる。

PSPでみんなの地図2を使用している画面
図1: IPAのビルの前の公園で使用した際の様子

「みんなの地図2」に付属のPlaceEngineクライアントは、ローカル(UMDもしくはメモリスティック)に保存されたデータに基づいて位置を計算するようになっているが、Windows用のPlaceEngineクライアントは、インターネット経由でサーバに位置の計算を問い合わせるようになっている*1。そのため、ノートPCでもネットがつながってさえいれば、GPSがなくても位置を調べることができ、それはとても興味深い機能であり、今後の応用が楽しみなシステムだと感じた。*2

しかし、このシステムにはプライバシーに関して心配な点がある。といっても、利用者の位置情報の話ではない。

本題の前にまず利用者の位置情報について見てみると、Windows版の場合はサーバに問い合わせるのであるから、サーバ側で利用者の位置情報を記録することが可能であろう。そのことについて、PlaceEngineのサイトのプライバシーポリシーは次のように約束してくれている。*3

PlaceEngineにおける位置情報に関する取り扱いについて

PlaceEngineサービスでは、クライアントソフトと通信を行うサーバーを通じて収集し、分析して得られた情報(Wi-Fi電測情報とそれに対応して推定される位置情報、およびそれらの利用履歴)は、個人を特定するかたちで取り扱うことはいたしません

プライバシーポリシー, PlaceEngine

サービス提供者にプライバシー情報が記録され得る問題は、どんなサービスでも同様であり、サービス提供者を信用できる場合にだけ使用するよう心がける以外にないのは、従来通りである。*4

位置情報は、他のサービスに比べてプライバシー性が高いと考えられ、特に重要視されるだろう。PlaceEngineが研究段階にあったころに書かれた論文にも、今後の課題としてプライバシーについて書かれていた。

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

    5 議論と今後の課題

    プライバシー

    位置情報は、プライバシー情報と成り得るのでその扱いに留意しなければならない。とくにWeb アプリケーションが位置情報を扱えるようになるので、利便性と同時に個人情報保護に配慮したシステムとして構築する必要がある。

「Webアプリケーションが位置情報を扱える」というのは、任意のWebサイトでPlaceEngineを使ったサービス(地図の表示など)が提供されるようになると、悪意あるサイトを訪れた瞬間に位置を調べられてしまうことになりかねないという問題についてのことを指しているのだと思う。その点について、PlaceEngineクライアントは 2006.12.16リリースバージョンで解決していた。

PlaceEngine 新機能 (2006.12.16)

位置取得制御機能

PlaceEngineを使ったサイトごとに、WiFi電測の可否を設定できます。

PlaceEngine バージョン履歴

PlaceEngineクライアントには図2のような「セキュリティ」の設定画面があり、サイトURLごとに「Confirm」(サイトが収集しようとしたときに「Yes」か「No」で選べる)、「Notify」(確認なしで収集されるが通知される)、「Through」(何も出ない)のいずれかを設定できる。

セキュリティ設定のウィンドウの画面
図2: PlaceEngineクライアントのセキュリティ設定

これはプライバシーというより、まさにセキュリティの問題で必要な設定であろう。

さて、本題は、利用者の位置情報の問題ではない。無線LANアクセスポイントの位置情報の話である。

PlaceEngineの特徴は、「位置情報2.0」と評されるように、利用者自身がシステムへの協力者となって、位置測定に必要な情報を収集してサーバに提供しようというところにある。

PlaceEngineクライアントには「ログ」の機能があり、受信した無線LANアクセスポイントからの電波の強度とMACアドレスを記録し、GPSを搭載している場合にはその測位情報も記録し、これをサーバにアップロードして提供できるようになっている。

このアップロード機能について、利用規約に次のように書かれている。

第8条 (利用情報等の管理)

  1. (略)

  2. 当社は、利用者による本サービスの利用中に
    1. 利用者のWi-Fi機器から当社に送信される、Wi-FiのアクセスポイントのMACアドレス、電界強度(以下「電測情報」という)、
    2. 利用者がWi-Fi機器を通じて当社のシステムに入力することのある、住所、ランドマーク名称など利用位置に関する情報(以下「付加情報」という)及び
    3. 当社のシステムが推定する電測情報の送信位置に関する情報(緯度・経度・住所等の情報を指すがこれらに限られない。以下「位置情報」という)を、何等の制限なく、自由に蓄積し、複製し、第三者に送信し(公衆送信を含む)、送信可能とし、加工し、編集し、その他の方法で使用することができます。但し、当社は、利用者個人を特定する方法では、電測情報、付加情報及び位置情報を使用しないものとします。

  3. (略)

PlaceEngine サービス利用規約

利用規約なのだから、同意できない人は利用しなければよい。しかし、アクセスポイントのMACアドレスとその位置情報は、利用者のものだろうか?

PlaceEngineが収集している無線LANアクセスポイントは、公衆アクセスポイントだけではない。ご家庭のプライベートな無線LANアクセスポイントのMACアドレス(とその相対位置情報)も収集されている。暗号化の設定がされているものも収集される。

たまたま家の前を通りがかった、通りすがりのPlaceEngine利用者(利用規約に同意)が、家のMACアドレスと位置(家の人は利用規約に同意していない)をサーバに送信していく。

そして、MACアドレス(と最大の電波強度の値)でPlaceEngineサーバに問い合わせれば、その位置情報が誰でも得られるようになっている。

つまり、家庭の無線LANアクセスポイントのMACアドレスを誰かに知られることは、住所を知られることに等しい。そのような事態をPlaceEngineサービス(および類似のサービス)が新たに作り出したことになる。

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

PlaceEngineなどのサービスが存在する現状、家庭の無線LANのMACアドレスは秘密にしなければならなくなった。*5

対策を考えてみる。

まず、PlaceEngineサーバへの問い合わせのリクエストを暗号化して、任意のリクエストを送信できなくするという案(既にそれは実施されているのかもしれない)だが、これは解決にはならない。暗号化の鍵はクライアントが持たざるを得ないので、リバースエンジニアリングによって探されてしまう。仮にそれができないとしても、無線LANパケット読み取りのAPIをフックして、検索したいMACアドレスに摩り替えることができてしまう。

そうすると、PlaceEngineがプライベートな無線LANアクセスポイントを除外する以外にないように思われる*6。サービスの精度は低下してしまうが、東京の都心であれば、公衆の無線LANだけで位置を測定してもそれなりの精度が出せるかもしれない。(将来的にそうなるかもしれない。)

しかし、公衆のものとプライベートなものをどうやって区別するか。無理な気がする。もし、例えば、livedoor Wirelessのアクセスポイントが同じベンダーの無線LANインターフェイスを使用していて、MACアドレスの上位ビットで判別できるなら、それだけを使うという案が考えられるかもしれない。それは現実的だろうか。

そもそも無線LANが、こうしたプライバシーの問題に配慮することなく普及してしまったことが不幸だ。*7

とりあえず、オプトアウトできるようにしてはどうだろうか。つまり、PlaceEngineのサイトで、自分の家の無線LANアクセスポイントのMACアドレスを登録すると、除外されるようになるという。しかし、手当たりしだいに登録する妨害行為も防がねばならず難しいことになりそうだ。

また、家庭の無線LANアクセスポイントのMACアドレスの電波法上の扱いも気になる。電波法では、特定の相手方に対して行われる無線通信の傍受について、「その存在若しくは内容を漏らし、又はこれを窃用してはならない」とされている(電波法59条)。

無線LANアクセスポイントが放つビーコンパケットは、特定相手方通信か否か。技術的な様態としては公衆に向けた放送になっている(他の端末に自分の存在を知らせるための仕組み*8なのだから)けれども、人が何の目的でそれを設置しているかと言えば、家庭の無線LANの場合であれば、特定の相手方との通信だ。特に暗号化の設定*9をしている場合(関連:電波法109条の2)はその意思も確認される。

こうしたことは既に検討されているに違いないが、PlaceEngine関係の資料を探した範囲では見つからなかった。

先ごろ憲法の改正手続きが整備されたそうだが、「通信の秘密」同様に、「位置情報の秘密」も憲法で謳って欲しいと思う今日この頃だ。

追記(29日)

脚注6で書いた対策方法は、以下の論文で既に論じられていた。

  • Jason I. Hong, Gaetano Boriello, James A. Landay, David W. McDonald, Bill N. Schilit, J. D. Tygar, "Privacy and Security in the Location-enhanced World Wide Web", in Proceedings of the Workshop on Privacy at Ubicomp 2003 (2003).

    MANAGING PRIVACY IN PLACE LAB

    Access Point Privacy

    (...) To address these concerns, we can encode information about MAC addresses as pairs of adjacent or proximal pairs. Thus, if in a given area, we have three APs with MAC addresses P, Q, and R near each other, (...)

    (...) it would not be possible for an adversary to determine a list of positions without knowing specific adjacent PQ values, which would presumably mean that the adversary had access to the physical location of the devices anyway. Therefore, this approach reveals no more information than would be available in any case -- someone would need to actually travel to the location and observe which MAC addresses were adjacent. Note that end-users who are trying to calculate their locations are already able to see access points' MAC addresses.

PlaceEngineの論文等を見る限りでは、PlaceEngineがこうした対策をとっているかはわからなかった。

追記2

もし1個のアクセスポイントだけで位置を検索できたならば、上記の対策がとられていないことを意味するはずなので、PlaceEngineMobileを持ち歩いて試してみた。図3は、上野駅停車中の山手線列車内にて使用した際の様子。緑の棒がひとつのアクセスポイントに対応しているのだと思われるので、これは一本しかない状況で位置の検索ができたことを示しているのだと思われる。(ちなみに、秋葉原駅前で使用すると図4のようにたくさんのアクセスポイントからの電波が得られる。)

アクセスポイントからの電波の強度を示す棒が1本と、位置の検索結果を表示しているPlaceEngineクライアントの画面
図3: 1個アクセスポイントからの電波で位置を検索できた様子

アクセスポイントからの電波の強度を示す棒が沢山表示されているPlaceEngineクライアントの画面
図4: 沢山のアクセスポイントからの電波が得られたときの様子

山手線移動中、他にも1個だけでの検索となるところがあった。場所によっては1個も得られず検索できないところもあった。2個以上ないと位置を検索できないという対策をとってしまうと、現状では使えない場所がかなり増えてしまうのだろう。*10

*1 無線LANアクセスポイントからのビーコンパケットを受信し、その各MACアドレスと電波強度の組をサーバに送信して、それによって計算された位置を得る。

*2 個人的には、EM・ONEで動作すると嬉しい。W-ZERO3用のPlaceEngineクライアントを入れてみたところ、位置は測定できるがOperaにその情報を渡せず、Opera上からの呼び出すこともできなかった(「PlaceEngineクライアントを探しています...」で止まってしまう)。

*3 とはいえ、「個人を特定するかたち……しません」が次のどちらを意味するのかが、このポリシーの文章からでは読み取れないという問題はある。(A) サーバへの位置情報の問い合わせはそれぞれ独立であり、同じクライアントからの問い合わせであることを同定するようなことはしない――という意味である可能性。(B) 同じクライアントからの問い合わせであることは同定する(無線LANアダプタのMACアドレスないしcookieの値などにより)が、それが誰のものであるか、氏名や住所等に結びつけることはしない――という意味である可能性。

*4 利用者の位置情報で何ができるかについては、開発者の暦本純一氏のブログに興味深いエントリがある。

*5 「PlaceEngineがなかったとしても家の近くまで行けばそのMACアドレスを確認できる」という反論が考えられるが、近くまで行って確認できる事態と、インターネット経由でどこからでも場所がわかるという事態には大きな開きがある。

*6 追記(28日): 複数の近隣のMACアドレスをリクエストで送信しないと応答しないという対策を思いついたが、どうか。

*7 無線LANクライアントの電源を入れたまま端末を持って街中をうろうろする行為は、RFIDタグランドセルを背負った小学生と同じ状況だ。しかもID電波の届く距離が数百メートルと長い。

*8 SSIDをビーコンパケットに含めない設定しているアクセスポイントは、その意思がないと判断される?

*9 データに対する暗号化。MACアドレスは暗号化されない。

*10 また、仮に上記の対策をとったとしても、1つの家庭に2個以上のMACアドレスの機器がある場合(例えば、FONルータを設置しているとそれだけで2個のMACアドレスが使われる)もあり、その2個ともが何らかの理由で他人に知られることとなった際には、この対策でも不完全ということになる。

本日のリンク元 TrackBacks(6)

最新 追記

最近のタイトル

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|
最新 追記