高木浩光＠自宅の日記

■ EZwebのsubscriber IDを変更するには

6月25日の日記の最後で書いた、

ここで気づいたが、EZwebの「subscriber ID」も、IDの変更ができるようにしたらどうだろうか。あるいは、既に変更できる仕組みが用意されているのだろうか。今度問い合わせてみよう。

の件、翌日、au のコールセンターに問い合わせてみた。「subscriber IDを変更したいのですが、変更する方法はありますか？」との問いに対し、即答で次の回答が得られた。

EZwebオプションをいったん解約していただき、再度利用登録をしていただくと、別のIDになります。

なるほど。それを実行するとどんなデメリットがあるかを尋ねたところ、EZwebのメールアドレスが、以前と同じものを取得できないとのこと。一定期間待って、先に誰かに取られなければ、取れるということだが、それはちょっと実用的でない。

subscriber IDは、いまさら廃止できない機能なのかもしれないが、とりあえず、ID変更のサービスを提供した方がよいように思う。それは本質的な解決ではないけれども（変更の必要性を理解していないユーザは変更しないだろうから）、架空請求詐欺なんかをやっている連中に気づかれたら、どんどん真似されて大規模に影響が出かねないわけで、そのときに、回避手段としてsubscriber ID変更サービスが用意されていれば、大きな救いになるはずだ。

■ 今日ご挨拶した方々

日記らしくこんなことも書いてみよう。

• セコムトラストネット(株) 代表取締役会長 田尾様 （会長にご就任とのことで新しいお名刺を頂戴した）
• 情報処理振興事業協会セキュリティセンター 新センター長 早貸様 （本日付けでご就任）
• KDDI技術開発本部情報セキュリティ室長 中尾様

■ アクセスカウンタを設置した

なんでもネットランナー8月号にこの日記の紹介が掲載されるのだそうで、ソフトバンクから連絡があった。

雑誌からのアクセス数は、はてなの「リンク元」情報からでは予測できないので、アクセスカウンタを付けさせてもらいました。「Webバグだろ」とか言わないでね。cookieを使用しないカウンタを選びました。使用しているカウンタは、「すごい!!カウンター」です。これによって、アクセス者のIPアドレスが私にも見える状態となりました。求めていたわけではないのですが、見る機能がカウンタサイトにあるため見えてしまいます。ただし、直近の20件しか見えないようです。数値形式のアドレスが表示されるようなので、逆引きして調べないとどこのドメインかはわかりません。たぶん調べることはないでしょう。また、IPアドレスは、カウンタサイトにも記録されてしまうことになります。

■ 日経ミッドイヤー・フォーラムに行ってきた

今日は、日経新聞社主催の世界情報通信サミット2003 ミッドイヤー・フォーラム（このURLは流動的っぽいので注意）に出席してきた。テーマは「IT新世紀への挑戦　〜無線ICタグとトレーサビリティー」となっている。会場の日経ホールの定員が600名のところ、なんと応募が6,000人もあり、倍率10倍の抽選になったそうだ。この種のイベントで6,000人というのはちょっとすごすぎでは？ 企画したデジタルコア代表幹事の坪田さんは、東京国際フォーラムの大ホールにすればよかったと悔やんでらした。それでも1,000席足りないようだけど。

目玉はやはり、「坂村健 vs. 村井純」の対談なのだろう。例によって「対立しているわけじゃないよ」といったメディア向けのけん制から始まるわけだが、坂村さんはそれなりにやはり何か言いたいことがある様子だった。もうちょっとズバリ言っても良いのではないかと私なんかは感じたが、村井さんの方からいまひとつ具体性のあるコメントが出てこないので、突っ込み難いのかなと思った。IPv6とRFIDの関係は謎のままだ。表層的には面白い対談だったと評されるだろうが、私は物足りなかった。

デジタルコアのメンバーは最前列に席が用意されて、後半のパネル討論「トレーサビリティー：応用可能性と課題」で、発言の機会が与えられた。議論のテーマは、(1)コスト負担モデル、(2)標準化と国際競争力、(3)セキュリティ（含むプライバシー）の3本立てで、私も、プライバシー話で最後の発言として以下のコメントをした。

泉田さんのお話の中で、IDだけでもやはり追跡できてしまう場合があるということについて、既に結論を出されたと思います。つまり、監視ができるのは政府くらいであろう、あるいは大きな通信会社や電力会社くらいであろうと。そういうところについては法的な縛り、もしくは事故があったときは訴訟で解決するといった案が出ていましたけども、それは、短期的にはそのくらいの普及かもしれませんが、もっと先の、さきほどの坂村先生が未来を語っていらしたような時代には、もっと個人がいろいろなセンサーを持ち歩いているという時代が来るのではないかと。そのときに、現在の、もし今普及させてしまったIDがいろんな物に付いているというのが、10年後にたとえばそれを回収できるかといった事態が起きるんではないかと思うんですね。技術的には実はRFIDの固定IDの問題を解決する方法はあって、IDが毎回変化するようにすることは、暗号技術を使えばできるわけですね。ただそれは、チップにコストがかかると。で、今日ずっとテーマになっていましたが、コストを安くしないと普及しないという問題があって、そうするとどうしても、危ないと言われているところをあえて見ないでですね、行ってしまおうというような力がどうしても働くと思うんですね。ここでベネトンの事例を挙げたいと思うんですが、ベネトンはある意味、恥をかかされてしまったんだと思います。これはおそらく、ご存じなかったんだろうと思います。そういう批判が起き得るということを気づかないままやり始めてしまって、引っ込めるしかなくなった。これは、システムを開発して売り込もうとしている、問題をわかっている人たちが、ベネトンに対してよく説明しておくべきだったと思うんですが、それを怠ったためにこういう結果になったんだと思います。つまり今やるべきことは、ちゃんと現実を見せた上で、しかしまあ現状では大丈夫ですよという説明の上で始めるといった、そういう説明が重要だと思うのですが、いかがでしょうか。

泉田さんとはこの後の懇親会、さらには2次会で、いろいろな論点にわたって議論した。他にも、たくさんの方々といろいろ議論した。誰からの情報なのか、意見なのかを明示してしまうのはまずいかもしれないので、それはあえて挙げずに、自分用の備忘録的にいくつか書きとめておく。

まず、どうも、プライバシー懸念の話が広く認識され過ぎたのか、RFID普及に否定的な人が現れてきたという状況があるらしい。それは私も望むところではない。大雑把な議論で単に否定の態度をとるのはよろしくない。6月27日の勉強会でも、「商品トレーサビリティーの向上に関する研究会中間報告書」のとりまとめをなさった村上敬亮氏のご講演を聴いた際ににも、ユーザ企業が心配しすぎている話をちらりと聞いた。例の、「何ら問題がないことはいうまでもない」の件に突っ込みを入れたとき、私のネット時評での批判のことはご承知の様子で、その上でそれについて頂いた説明は、「研究会のユーザ企業の方々が元々プライバシーをとても心配していたから活性化のためにネガティブなことを書かないようにした」という趣旨のものだった。たしかに、産業振興の点からそうした面はやむを得ないところもあるし、私としては、ネット時評での批判を繰り返してもしょうがないので、それ以上言える言葉が見つからなかった。ちなみに、そのやりとりは、日経ネットには以下のように報道されている。

個人情報の保護も大きな課題だ。村上氏によれば、今回の中間報告ではあまりネガティブな側面を強調することは避けたというが、氏名など、個人情報そのものをタグに書きこむことは、セキュリティー技術が万全でない現在の状況では避けるべきである、としている。しかし、個人情報そのものをあまり広い意味で考えることには反対の立場をとっており、同報告では「消費者の趣味・嗜好や購買履歴、家電等の使用履歴など、個人の特定に結びつかない情報は、個人情報には該当しない」と明確に述べている。

日経新聞 デジタルコア・リポート (6/27)ＩＣタグ、実用化に向け積極的な議論を ――デジタルコアが勉強会

念のため再掲しておくと、これに対する私の見解は以下の通りだ。

確かに、RFIDタグが無造作に置かれている場面を想定すれば、それがだれの情報なのかは不明かもしれない。しかし、ある人が目の前にいる場面で、その人の持ち物に付いているらしきRFIDタグから「使用履歴情報」が送られてきたならば、その履歴情報がその人のものであることは自明である。つまり、研究会の結論は、「環境が既に個人を特定している場面」を想定できていない。...

プライバシーの定義を示してくれということだろうか。プライバシーの概念が技術に左右されないのならばそれもよかろう。しかし、ここまでに述べてきたように、「何が（どの情報が）プライバシーか」という考え方では、正しい結論を導き出せない。「IDはプライバシーか」と問われたら、「それ単体では個人名まで特定できないので個人情報には該当しない」ということになってしまう。

固定IDは“デジタル化された顔”――プライバシー問題の勘所

話を今日の議論に戻す。プライバシー侵害の脅威はは民事法上の争訟解決でバランスをとればよいという話が出てくるのだが、その一方で、個人情報保護法では、自動車のナンバープレートの番号は個人情報にあたらないのだそうだ。ましてや、法的定義の何もないRFIDの番号やcookieの番号なんぞは、全く個人情報でないのだろう。民事訴訟で解決するというのは現状では実効性があるとは到底思えないのだけれども、将来にはなんとかなるのか。

番号を氏名などとひも付けすると個人情報になるのだが、しないかぎり個人情報にはあたらないのだそうだ。これに対して出てくる想定脅威事例は、「あの場所に行った人のIDリスト」という名簿（それぞれが誰なのかは特定されていない）が、別の場所で価値を持ってしまうという話なのだが、「そんなこと本当にやる人がいるのか」とか、「収集コストが見合わないはずだ」といった展開になる。

別の話題。暗号回路を内蔵させればIDを固定にせずに済むという話が、現実的ではないかもしれないという指摘があった。ICカードならいざ知らず、アンテナを含めた物理サイズの小ささを要求されるタグでは、電力が足りないという話。CMOSにすると壊れやすいという話も。どうなのだろうか。

あとは、カナダのSIN (Social Insurance Number) の実情の話。なんら問題と感じなかったといった話が出てくるのだが、米国のSSN (Social Security Number) 同様に、誤った使われた方を招く場合があって問題という議論になる。

• 参考資料: 電子政府・電子自治体のプライバシーに関する調査研究報告書 カナダにおけるプライバシー

この種の議論はもう散々行われてきたわけで、大量の論点が出てくるわけだが、「結局、私には、何も問題と感じなかった」と言われると、「そうですか」としか言いようがなくなる。それでもなお、問題点を指摘するのがなぜかをあらためて考えてみると、より良い設計があるはずなのに、テキトーな実装で始めてしまうのがよろしくない、といったところか。考えがまとまらない。

その他、太田秀一さんに、1 to 1マーケティングとプライバシーの関係について教えを請うたが、時間切れ。頂いた参考情報。そういう議論は話題性としてはだいぶ古いらしい。

• Accelerating.com もうなくなっているようだ。
• AdTech Conference (?)

全然別の話題。最近、楠正憲さんといろいろなところでお目にかかる。昔、Java Houseでもご発言されていて、印象に残っていた方だ。今日は遅くまで飲んだ。

■ 昨日のフォーラムの記事

昨日のフォーラムの様子が日経NETに出ている。映像あり。パネル討論での発言もレポートされている。

• 特集 世界情報通信サミットミッドイヤーフォーラム
• パネルセッション　「トレーサビリティー：応用可能性と課題」 「ビジネスモデル」「標準化」「セキュリティー」が共通課題

■ Auto-IDセンターの資料

6月29日の日記の最後で、

これについて以下の文献が紹介されている。が、ログインしないと入手できないようなので、残念ながらタイトルも不明だ。

と書いた点について、木下さんから連絡があった。記事に書いたURLを間違えていたとのこと。以下が正しいURLであり、誰でも読める。

• Public Policy: Understanding Public Opinion
• Options for Regulation of the EPC Network

■ ネタメモ

• 中島洋, 庄司昌彦, 対談：無線タグで実現する社会と制度設計 プライバシーと自由に対する懸念
• http://www.human.mie-u.ac.jp/~goodaki/rf.htm （大学1年生のレポートで、プライバシーがどう考察されているか興味深い）

■ 追記 続・通信キャリアの独占型PKI

6月25日の日記で書いた、FirstPassの件で、小島さんの取材によると、任意のクライアント証明書の組み込み機能についても、要望があって検討中だそうだ。

■ とうとうsubscriber IDの収集が始まったのか？

知人のJ-PHONE携帯電話に、怪しげな無差別迷惑メールが届いたというので、資料として転送していただいた。以下のメールが届いたそうだ。（「m=」以降の部分は適当に変更してある。）

30pt無料!!DRYな関係だからこそ時を忘れて淫らに…あなたもその１人…
http://avalanche54.com/index.php3?fr=dm&m=jaCFuhkyff8iCL
7

下線部はおそらく、送信先ごとに別々のIDなのだと思われる。一種の「Webバグ」だ。携帯電話ではHTMLメールは使えないので、このように怪しい仕掛けは目に見える。「見えるWebバグ」といったところか。

私もこれまで、ドコモのｉモードメールについて、わざとメールアドレスを電話番号形式のままにして、無差別迷惑メールを収集し、こうしたWebバグ入りのものが来ないかウォッチしてきたが、今まで見かけたことはなかった。先月も、au の Cメールに迷惑メールが大量発生したという報道があったが、手元に来た30通あまりを調べてみたところ、Webバグ入りのものは見当たらなかった。

今回、知人のJ-PHONEの事例を聞いて、もしやと思い、au のEZのメールについて調べてみたところ、7月2日に以下の怪しいメールが来ていた。（「X」はこちらで伏せた文字。）

From: XXXX_XXXX314@hotmail.com
Date: Wed,  2 Jul 2003 20:01:45 +0900 (JST)
To: XXXXXXXXXXXXXXXXX@ezweb.ne.jp
Subject: Fw:完全無料びっくりでしょ？


┏━━┓
  ＼／
┗━━┛
完全無料\0・
出会い・・
だから安心・
・を見ながら
・が出来る・
http://XX.bz/a.cgi?XXXXXXXXXXXXXXXXX@ezweb.ne.jp


配信拒否t@XX.bz

「XXXXXXXXXXXXXXXXX@ezweb.ne.jp」の部分は、To: のアドレスと同一文字列となっていた。これはあきらかに、メールアドレスの収集を目的とした罠メールだ。このURLに不用意にもアクセスしてしまうと、迷惑メール業者のサーバに、このアドレスが「新鮮な」ものだということ、つまり、存在して、読まれて、不用意にアクセスするような人のメールアドレスだということが記録されてしまう。

さて、これはEZのメールであるから、このURLにアクセスすると、サーバには「subscriber ID」も送信されてしまう。この迷惑メール業者がそれを理解しているかは定かでないが、意図してその記録がなされているなら、subscriber IDとメールアドレスの対応表が迷惑業者の手元に蓄積されてしまったことになる。すなわち、1年前に恐れていたことが現実になった可能性がある。

この事例では、メールアドレスがそのまま入っているので、警戒する人も多いだろう。それに対し、上のJ-PHONEに届いたというメールのように、暗号化したり、ID番号で管理するようにすると、一般の人達の警戒を掻い潜れてしまう。

J-PHONEでも、一部の機種では、電話機の製造番号をデフォルトで自動送信してしまうらしい。こちらは設定で送信しないようにできるらしい。しかし、このことをいったいどれだけのJ-PHONEユーザが知っているだろうか。

---

EZだけじゃない (スコア:2, 参考になる)
Anonymous Coward のコメント: 2002年08月07日 9時37分 (#141136)

J-PHONEもJ-*51系はデフォルト垂れ流し、しかもHTTP_USER_AGENTに [j-phone-east.com]。

---

Re:EZだけじゃない (スコア:2, 参考になる)
360d のコメント: 2002年08月07日 9時40分 (#141138) J-Sky の J-Phone カウンターから「製造番号通知設定」にて「通知を許可しない」が選べます。

---

スラッシュドット: 非公式サイトにも契約者ID垂れ流しのEZWeb, EZだけじゃない

上の「デフォルト垂れ流し、しかも……」の部分のリンク先がなくなっている。どこに公式情報があるのだろうか。「J-*51系」というのは古い機種なのだろうか、それとも新しい機種なのだろうか。

■ すごくないらしいカウンタ

3日に取り付けた「スゴいカウンター」、あまりすごくなかったらしい。ユーザ掲示板の反応によると、カウントが止まったり、0になったりするとか。この日記のカウントも変な気もしなくもないが、よくわからない。

そのユーザ掲示板は荒れ気味。とうとうカウンタコントロールパネルのログインページからリンクが外されてしまった。

掲示板に関して - FC2社員 (男性) -2003-07-08 12:23:13

恐れ入りますが、現状では掲示板は混乱を招くだけですので、暫く停止させて頂きますが、サービスを中止する方向性ではありません。

新しいプログラマの導入で改良を進めております。

http://fc2bbs.com/bbs?action=reply&uid=9283&tid=566760

ありゃりゃ。

■ ツーカーセルラー東海に期待

subscriber IDのプライバシー問題は、EZwebの問題であるので、au だけでなく、TU-KA にも同じ問題がある。先週、ツーカーセルラー東京と、ツーカーセルラー東海のコールセンターに、7月1日の日記と同様の問い合わせをした。

両者とも最初に出たオペレータでは即答できなかったため、技術担当者やコールセンター責任者と話すことになり、単にIDを変更する方法という話ではなく、プライバシーについてどう考えるかという、より深い話になった。結論から言うと、ツーカーセルラー東京は、「問題なし」という結論ありきの拒絶モードに陥ってしまったが、ツーカーセルラー東海のコールセンター責任者は極めて良心的な対応で、あちらから文書による回答をくださるという話になった。

まず、ツーカーセルラー東京の場合。以下は電話のやりとりの要旨である。

Q. subscriber IDにはプライバシーの問題があるのではないでしょうか？

A. ないと認識していただいて結構です。

Q. ないと認識するべきだという意味ですか？

A. はい。
 Q. 勝手サイトにも送信されますが、問題ありませんか？

A. 勝手サイトが何をするかには感知しない。

Q. 勝手サイトへのアクセスを許しているわけですから、それは、勝手サイトへアクセスする機能というのもEZwebの機能のひとつですね。EZwebとしてのサービス、つまり、ウリのひとつですね。勝手サイトへアクセスするときのプライバシーの保護というのも、通信事業者に求められる通信の秘密に関係するのではないでしょうか？

A. サブスクライバーIDからお客様の個人情報というのは一切わからないようになっている。

Q. メールアドレスはどうか。

A. お客様からメールを送らない限り、わからない。

この後、subscriber IDからどうやってメールアドレスを盗まれるかを説明した。最終的に以下の点を上に報告してもらうことになった。

「勝手サイトにアクセスした際に、サブスクライバーIDを公開する件」
「勝手サイトにアクセスした際に、サブスクライバーIDをメールアドレスと結びつけることができるのではないかというご指摘」
「お客様のプライバシーを相手の方にわかってしまうのではないかという懸念があるという指摘があったと伝える」

また、subscriber IDの変更方法についても尋ねた。7月１日の auの場合では、EZwebのオプションを解約して再び契約した場合にsubscriber IDが変わるという話だったが、ツーカーセルラー東京の場合は、変わらない場合もあるし、変わる場合もあるという説明だった。電話の相手は技術の担当者らしき様子だったが、本当にわかっていて変わらない場合があると言っているのか、単に一般論として言っているだけ（たとえば、乱数で割り当てる場合、原理的に非常に低い確率で同じ値になるわけだから）なのか、そこがわからなかったが、「ある条件に基づいてサブスクライバーIDを決めているので、IDが同じになる場合もある。ある状況に一致しなければ異なるIDになる。」という話だった。どういう条件なのかこちらから、「5分で再契約すると同じ番号になるとかそういうことか？」と尋ねたが確かな回答は得られなかった。

次に、ツーカーセルラー東海の場合。東京と違い、東海のコールセンターの対応はとても良心的だった。「subscriber IDを変更したいのですが」と言うと、どんな事情があって変えたいのかとあちらから尋ねてくる。まずユーザの意図を汲みたいという対応で、これは最後まで一貫していた。最初に出たオペレータも物事をよく理解していた。こんな感じのやりとりになった。

Q. 非公式サイトへもsubscriber IDは送信されますよね？

A. サブスクライバーIDを非公式サイトに流して欲しくないというご希望でしょうか？

Q. そうです。

A. 通常流しているものですから、流さないようにする方法があるかということですね。

Q. はい。subscriber IDは、個人情報ではないでしょうか？

A. サブスクライバーIDは、たくさんいるお客様から、このお客様だと特定する番号ですから、個人情報といえますね。

ここで、コールセンターの責任者と代わることになった

Q. subscriber IDはプライバシーの問題があるのではないでしょうか？

A. お一人様におひとつのものであるかぎり、プライベート性はある。

Q. subscriber IDは個人情報ですか？

A. サブスクライバーIDを追っていけばどこかにいきつくわけだから、個人情報と言えると思いますね。

Q. subscriber IDというのは、Webサーバにアクセスしたときに、自動的に送信されていますよね。X-UP-SubNo: で常時送信している。それはまずいのではありませんか？

A. お客様の意思に関係なくWebサーバに送信されるわけですね。おっしゃりたいことはわかります。

Q. 電話番号も発信者番号通知というのがあるが、これは発信者側の意思で止められる。それに対して、subscriber IDは隠せないわけですね。それは事実であると。個人情報管理の観点でどうなのか。

A. サブスクライバーIDの露見について、個人情報の漏洩にならないのかなあと思っていた。

Q. 以前からそう思ってらしたということでしょうか？

A. IPアドレスを追っていくと誰だかわかるという話があるが、そういう意味で言った。

Q. IPアドレスの場合は、ダイヤルアップ接続の場合では、毎回アドレスが変わるので、法執行機関の介入などによってISPから記録を提出させないと、個人を特定する情報にはならない。それに対して、サブスクライバーIDは値が固定だ。

A. なるほどよくわかりました。

この後いろいろ説明して、この方には、問題点を完全に理解していただいた。すると、あちらから、回答を文書で返したいので期限を設けて欲しいとおっしゃるので、十分に検討していただくために1か月とした。ツーカーセルラー東海の対応に期待できる予感がした。

ところで、subscriber IDの変更については、au と同じ回答だった。「『EZweb@mail』をサービスメニューから一旦削除して、もう一度追加をすると、サブスクライバーIDは別のものになる」とのこと。「なぜそれがわかるのか？」と確認してみたところ、「メールアドレスを変更したいという要望があり、そのときにそういう手続きを案内している。このときにサブスクライバーIDがかわってしまうということを把握している。有料コンテンツが自動的に退会になるため、再登録が必要ですよと案内している」とのことだった。

■ J-PHONEの「ユーザーID通知設定」を試した

一昨日の日記に頂いたコメントによると、J-PHONEでユーザIDが通知されるのは、新しめの機種からだとのこと。J-PHONE Developer Programの技術資料「ユーザーエージェントについて」によると、「パケット対応機」の場合に、IDが User-Agent: に含められて送出されるらしい。

知人のJ-PHONE端末を借りて、実際にどのように送出されるのか試してみた。使用した機種は、「J-P51」。一年ほど前に購入したものだそうだ。アクセスログにはこう記録された。

"GET /mmmm HTTP/1.0" 404 268 "-" "J-PHONE/4.0/J-P51/SNJMAA30XXXX7 MA/JDP51A36 Profile/MIDP-1.0 Configur ...
"GET /mmmm HTTP/1.0" 404 268 "-" "J-PHONE/4.0/J-P51 MA/JDP51A36 Profile/MIDP-1.0 Configuration/CLDC-1.0 ...

上が、デフォルト設定の場合、下が、「ユーザーID通知設定」を「OFF」に設定した後の場合だ。後者では下線部がなくなっている。この下線部の「SN」以降の文字列（英字4文字と数字7桁）が、電話機の電池の下に貼られたシールに書かれている「製造番号」と一致していた。設定画面では「ユーザーID」と表記されているが、端末の製造番号のようだ。技術資料では「端末シリアル番号」と表現されている。

このアクセスの際、「ユーザーIDを送信してよいですか？」といった確認画面は出なかった。URLを入力してボタンを押しただけで、製造番号がサーバのアクセスログに記録された。この端末の持ち主である知人は、この「ユーザーID通知設定」のことは今まで存在すら知らなかったそうだ。ちなみに、この設定を変更するには4桁の暗証番号の入力が必要になっていた。それだけこの設定が重大なもの（不用意に他人に設定を変更されては困るもの）ということなのだろう。一方、位置情報の通知の設定では、暗証番号の入力は不要になっていた。

ところで、J-PHONEのユーザ向けFAQには、こんなQ & Aが用意されている。

Ｑ3： ウェブ画面で「ユーザーID通知する事を同意するか？（はい/いいえ）」と表示される場合があるが、これは何ですか？

Ａ3： ユーザーIDとは、コンテンツパートーナーがお客さまを特定する為の認証番号（電話番号ではありません）です。ユーザーID通知を拒否した場合は、有料無料問わず情報提供がされない場合があります。

同意確認が出るという話のようだが、今回の実験では出なかった。このQ & Aは、旧機種（あるいはパケット非対応機）の話だろうか？

この回答文だが、質問の真意は、どういう場合に「はい」を選び、どういう場合に「いいえ」を選んだらよいのか？ というものだろう。それに答えていない。つまり、

信用できないサイトにアクセスしたときには「いいえ」を選択してください。

と説明するべきところだろう。それを書かないのは、「お客様に余計な心配をおかけするから」といったところか。「いいえ」を選ぶ必要のある場面などないというのであれば、この同意確認は何のためにあるのか？

また、単なるユーザID（10桁程度の製造番号）を「認証番号」と呼ぶのは、セキュリティというものをまるで理解していないことのあらわれだろう。

■ 続・とうとうsubscriber IDの収集が始まったのか？

「じぶん日記」の7月9日の日記に、

これらはなぜか、同じ文面で別々のIDを持った2通が続けて送られてくる特徴を持っている。

とあった。私が知人から提供していただいたものも、同じものが2通だった。それらは、それぞれ、メールの宛先が、ニックネーム形式のアドレスになっているものと、電話番号形式のアドレスになっているものだった。そして本文中のIDが異なっている。

これらの両方にアクセスしてしまうと、電話番号とメールアドレスの対応表も作られてしまうことになる。

■ アドレスバーをどうするか

日経IT Proの7月10日の記者の眼に、「Flashに感じる不安」というコラムが出ていた。その読者コメントを見ると、コラムの趣旨を正しく理解できていないシステムインテグレータのSEが少なくないことがわかる。

著者の尾崎氏は、日経システム構築5月号に「警鐘●危険なネット銀行を作るな」という記事を書かれた方だ。そこには、「サイトなりすましの死角」という節で、アドレスバーを隠すことのセキュリティ上の問題点が書かれている。

今回の記者の眼は、「Flashに感じる不安」というタイトルになっているが、指摘されている問題点は、アドレスバーを隠すことの一点に尽きる。その意味では、Flashそのものが本質なのではない。

このコラムが誤解を招いたのは、まず第一には以下の部分が原因だろう。

サイト運営者や開発者によれば，セッション管理で問題を発生させないために，URLを表示しないのだという。...

ところがFlashの場合，HTMLのページ単位ではなく，オブジェクト単位でサーバーと通信したり再描画したりできる。...

つまり，ページ単位でのセッション管理という概念が無い。... このため，その通信の最中に，利用者にブラウザの「戻る」ボタンを押されたり，勝手なURLを記述されたりしてページを移動されると，トランザクション処理が途中で失敗する可能性がある。

「トランザクション処理」が途中で失敗するのはHTMLでも同じだ。ブラウザウィンドウが通信の途中で閉じられたときの不整合の回避は、開発系メーリングリストでよく出てくる質問で、それはいずれにせよ必要な対策だ。

この部分は、「トランザクション処理」と書かなければ誤解を招かなかったかもしれない。記者の取材に対して「サイト運営者や開発者」がしたであろう説明は、おそらく、「戻る」ボタンが押されたりURLが変更されると、元のページに再び戻ったときに、Flashムービーが再スタート状態になってしまうことではなかろうか。

通常のWebアプリケーションの操作に慣れている消費者は、操作を間違えると「戻る」ボタンを押す癖がついているだろう。多くのWebアプリケーションでは、それで問題なく操作を続行することができる。しかし、アプリケーション全体が1個のFlashムービーとして作られている場合、途中で「戻る」ボタンを押すと、Flashムービーより前のページに戻ってしまい、「しまった」と気づいて「進む」ボタンを押しても、Flashは先頭から再生されてしまう。このことは、コラム中では以下のように書かれている。

ECサイトで住所や商品を途中まで入力したところで処理が失敗し，いきなりログイン画面に戻ってしまうと，利用者もやりきれないだろう。怒った利用者がそのサイトを立ち去る恐れもある。これを考えれば，アドレス/メニュー・バーを非表示にしたくなる開発者の意図が分からないでもない。

ちなみに、こうしたことはJavaアプレットでは起きない。起きないように作ることができる。「戻る」を押して、「進む」を押したとき、前の状態を継続できるように作ることができる。Flashではそれができないのだろうか。そういう意味では、これは Flashならではの問題と言えるかもしれない。

これに対して、読者コメントには次のような声があがっている。

「戻るボタンを押さないでください」とかいくら注意書きを大きい字や目立つ色で書いても、それを守ってくれるのは、一部の良くわかってる人だけで,一般ユーザは絶対押すし、「戻れないのはおかしい」とか「何にもしてないのに(!)おかしくなった」等のクレームが必ずくる。

まあそうなのだろう。だが、「戻る」ボタンを押せなくすることと、アドレスバーを隠すこととは別だ。「戻る」ボタンを消す、つまり、ツールバーを隠して、アドレスバーは隠さなければいい。具体的には、次のようなJavaScriptコードにすればよい。

window.open("http://...", "...", "location=yes,toolbar=no,status=yes, ...");

そうすると、サイト運営者は、

勝手なURLを記述されたりしてページを移動されると，

という懸念を主張するのだろう。だが、わざわざアドレスバーのURLを書き換えてページ移動した人が、「戻れないのはおかしい」とか「何にもしてないのに(!)おかしくなった」とかの文句を言うだろうか？

記者がそこまで突っ込めなかったのは残念だ。相手の主張をあっさり認めてしまっている。その結果、「Flashに感じる不安」と矛先が Flashに向いてしまい、論点がぼけている。

「銀行」、「Flash」と言えば、ソニー銀行が該当する。http://moneykit.net/ で右上角の「ログイン」の部分をクリックすると、アドレスバーなどが隠されたポップアップウィンドウが開く。ここでログインすると、Flashムービーで作られたアプリケーションが起動するようになっている。たしかにこのサイトでツールバーが表示されていると、「戻る」ボタンを押し、操作を途中でパーにしてしまう輩が続出するだろう。だが、それはアドレスバーを隠す理由にはならない。百歩譲って、URLを書き換えて文句を言う人がいるとしよう。では、ソニー銀行がステータスバーも隠している理由は何か。理由はないだろう。SSLの鍵マークすら消し、サーバー証明書の確認すらできないようにして平気な面をしているのは、なぜなのか？

結局のところ、サイト運営者や開発者の説明はその場しのぎの言い訳でしかない。セキュリティに無頓着に作ったものの、後でそれを指摘されても、直さない。直さないことを正当化することからまず考えるというわけだ。

ちなみに、アドレスバーを隠す行為を増やしていると考えられる、もうひとつの原因がある。それは、ウィンドウサイズを指定した window.open のデフォルト動作にある。以下のコードのように、ポップアップウィンドウを開くとき、ウィンドウのサイズは、3番目の引数に文字列として指定する

window.open("http://...","...","width=100,height=100")

このとき、デフォルトで、ツールバーも、アドレスバーも、ステータスバーも表示されない。これらを表示させるには、わざわざ次のように書いてやる必要がある。

"width=100,height=100,location=yes,toolbar=yes,status=yes,menubar=yes"

この方法を知らない（調べるのをサボる）開発者がいることも影響しているのではなかろうか。「ポップアップウィンドウとはアドレスバーを表示しないもの」という流行ができてしまったのは、ここに原因があるように思える。

さて、そのアドレスバーを隠すことの危険性だが、これは6月14日の日記「HTMLメールマガジンのもうひとつの危険性」でも述べた。

どうにもこう、アドレスバーを隠したポップアップウィンドウがやたらと不用意に使われているという実態がある。警察庁ですら警戒が足りないようで、警察庁の「@police」サイトの中央下に並んでいる「topics」というところの「重要」情報のリンクをクリックすると、アドレスバーを隠したポップアップウィンドウが現れる。この画面に見慣れている人は、「平成１５年６月１０日 警 察 庁」とさえ書かれていれば、本物と信じてしまう習慣が身についているかもしれない。このような「重要なお知らせ」を、ポップアップで出す意義がいったいどこにあるのだろうか。...

今回のコラムの読者コメントを見ると、URLを隠すことの問題点を理解していないものが少なくない。

フレームを使えば単なるＨＴＭＬだけでもＵＲＬを隠すことはできますし、本質的な問題ではないように思います。「セキュリティや安心感」は、そういう外観上の問題では全くありません。 ...

(30代，その他，研究・開発部門 )

---

Flashに限らず、根本的なHTTPの限界であると思います。この問題の回避策はサイトのデザイナーよりも、開発側が行うべきでしょう。セキュリティに不安のないシステムならURLを隠しても大丈夫では？ ...

(30代，システム・インテグレーター，システムエンジニア )

---

URLが隠されていること、Flashだけで構成されていること、そんなところが問題だと思うのは、やはり「昔から」ブラウザに依存しているベテランだと思います。 ...

(20代，システム・インテグレーター，システムエンジニア )

---

URLどうこうというのはシステム屋っぽい発想だなと。一般の人がURLを頼りにしているというのは、本当だろうか？ ... 私の皮膚感覚では、URLなど誰も見ていない。

(20代，その他，システム企画部門 ) 


たしかに、URLを見ていないユーザは多いだろう。しかし、URLを見ない限り、偽サイトに騙されることは防ぎようがないのだ。ユーザがそう心がけるように常識を作っていくしかない。

その一方でこんなコメントもあった。

ん？HTTPSの最初のページだけフレームもFlashもなくアドレスバーを表示した状態（ようするにURLをアピールした状態）で表示していれば問題ないのでは？ユーザはHTTPSの最初のページを開いたときにアドレスバーのURLを確認します。そこからのリンクをたどって表示されるものはフレーム、Java、Flashによらず信頼できることになります（サイトがちゃんとHTTPSから出ないようにできていればですが）。 ...

(40代，ハード・ソフトベンダー，経営者 )

これはその通りだ。ユーザが必ずそうするならば問題ない。しかし、アドレスバーを隠したポップアップウィンドウが流行していることの問題は、アドレスに無頓着なユーザを増やす悪影響があるという点だ。IT Proにコメントを書くようなシステムインテグレータのSEでさえ、その意味を理解していないのだから。

ところで、携帯電話のブラウザの場合、そもそもURLは画面上に表示されない。URLを確認する機能はメニューから呼び出せるようだが、ほとんど誰も使ってないだろう。これは画面が狭いことが原因なのだろうが、これでいいのだろうか。

PC用のWebブラウザにアドレスバーが付いているのは、飾りなのではない。アドレスバーのことを「URLを入力するところ」と理解している人が多いだろうと思うが、大昔の1994年ころのブラウザは、アドレスバーはURLを表示するだけで、書き換えることはできなかったものだ。つまり、WWWという仕組みを考え出した人達は、初めから、ユーザがURLを目視することの重要性を意識してこの機能を設けていたはずだ。

携帯電話の画面が狭いとはいえ、最下部にはアクセス中の状態を表示する部分がある。そこに、ドメインだけでも表示させることはできるのではなかろうか。

■ ベリサインのルート証明書配布

1か月半ほど前の話になるが、ソニー銀行から「ログインに関する重要なお知らせ」というメールが来た。要点はこうだ。

2003年5月27日以降、一部のブラウザーをお使いのお客さまがサービスサイトにログインしようとすると、「セキュリティの警告」メッセージが表示され、ログインが拒否される場合がございます。...

※Microsoft Internet Explorer5.01以降、またはNetscape4.7以降のブラウザーをお使いの場合、この問題は発生しません。...

インターネット上でDigital ID（電子証明書）の発行を行っている日本ベリサイン株式会社発行の最新の電子証明書に、上記のブラウザーが対応していないことが原因です。...

以下のいずれかの対応をお願いいたします。
(1)ご利用のブラウザーのバージョンアップ
(2)ご利用のブラウザーへの最新電子証明書のインストール

そして、次のように案内されていた。

なお、詳細・解決手段については日本ベリサイン社のホームページに掲載されています。大変お手数ではございますが、お客さまご自身でご確認いただき、ご対応くださいますようお願いいたします。
http://www.verisign.co.jp/server/cus/rootcert/for_ie4xuser.html

その日本ベリサインの説明ページを見てみると、「最新ルート証明書」というところに、「インストールページ」というリンクが用意されている。ここには、

お客様が自らの責任で独自にルート証明書をインストールすることに同意された上で、以下のボタンをクリックしてください。

と書かれており、これは、ルート証明書を手作業でインストールする行為が危険を伴うものであって、通常の行為ではないということを、「自らの責任で...」という文章によって暗に示したものだ。

しかしそのことにいったいどれだけの人が気づくだろうか。この「同意する」ボタンと説明は、責任を回避するためのものでしかない。もうちょっと、しっかりと、これは通常とるべき行為でないことを説明してはどうか。日本ベリサインは、PKI文化を安全に広める主導的立場にあるのだから、そうした説明も重要な仕事のひとつだろう。

で、この「同意ボタン」を押すと、ルート証明書がダウンロードされるわけだが、このリンク先は、https://www.verisign.com/...となっている。HTTPSでダウンロードさせるのはよいことだ。だが、これだけでは安全なものにはならない。

ルート証明書のダウンロードという（盗聴が問題にならない）場面でHTTPSを使うのは、通信路上での改竄を防止するためと、DNSスプーフィング攻撃などにより偽サイトにユーザが騙されることを防止するためなのだが、いくらこの「同意する」ボタンのリンク先だけを https://...にしても、元の画面（ポップアップしたウィンドウ）が http://であれば、そのウィンドウが偽の可能性があるのだから、安全になってはいない。

こういうとき、消費者がとるべき行動は、ウィンドウのアドレスバーで、「http:」の部分を「https:」に変更してアクセスしてみて、間違いなく本物にアクセスしていることを確認した上で、「同意する」ボタンを押すことだ。そうすれば、改竄やなりすましが起きていないことが保証される。

これは本来、消費者が自らの責任で安全確認をすべきことなのだが、そうは言ってもなかなかそれは認識されていない。であれば、より安全にするため、日本ベリサインや、ソニー銀行は、次のようにすることができたはずではなかろうか。

日本ベリサインにできたはずのこと

「インストールページ」で開くポップアップウィンドウのURLを https://にしておく。そして、ユーザへの説明として、「このウィンドウのURLがhttps://www.verisign.co.jp/... であることを確認し、この画面が間違いなく日本ベリサインのものであることを確認してください」などといった説明をする。

たとえこのようにしても、ユーザが見ている画面がはじめから偽サイトであれば、この説明も現れないわけで、騙されてしまうかもしれない。しかし、偽サイトへの誘導という攻撃にさらされていない大多数のユーザには、こうした説明が教育的効果をもたらす点で意義がある。

ソニー銀行にできたはずのこと

お知らせメールで、URLを次のように、https://にしておき、はじめから安全な通信となるようにする。
https://www.verisign.co.jp/server/cus/rootcert/for_ie4xuser.html

■ 国際化ドメイン名のセキュリティ不安

「Netscape 7.1リリース、国際化ドメイン名を標準サポート」という記事が出ていた。これで思い出すのは、「Mozilla dot Party in Japan 4.0」に参加したときの、桃井さんとの会話。

桃井さん曰く、Netscape社内ではいつもセキュリティについて真剣に議論しているとのこと。新しい機能を入れるときにはそれがセキュリティ上の問題を招かないか喧々諤々の議論をしているのだそうだ。例えばどんな話題で？とたずねたところ出てきたのが、国際化ドメイン名の話だった。

US-ASCII以外の文字列をドメイン名に使うことになれば、似ているが異なるドメイン名というのが、これまで以上に増えるおそれがある。おそらく、日本語ドメイン名の仕様を検討していた人達が、そのあたりに注意して、記号文字の排除など、使える文字を限定しているだろうとは思うのだが、次の例の後者のようなドメイン名は取得できてしまうのではなかろうか。

http://日本レジストリサービス.jp/
http://日本レジストリサ一ビス.jp/


http://日本語ドメイン名協会.jp/
http://日本語ドメイソ名協会.jp/

ドメイン名を国際化するにあたっては、サイバースクワッティング問題に配慮するだけではだめで、ドメイン名がセキュリティ上、重要な信頼の基点であるということを忘れてはならない。国際化ドメイン名関連のRFCを見てみたところ、RFC 3491に次の記述があった。（日本語訳は私によるもの）

9. Security Considerations

The Unicode and ISO/IEC 10646 repertoires have many characters that look similar. In many cases, users of security protocols might do visual matching, such as when comparing the names of trusted third parties. Because it is impossible to map similar-looking characters without a great deal of context such as knowing the fonts used, stringprep does nothing to map similar-looking characters together nor to prohibit some characters because they look like others.

UnicodeとISO/IEC 10646のレパートリーは、似たような見栄えの沢山の文字を持つ。多くの場合において、セキュリティプロトコルのユーザは、信頼できる第三者の名前を比較するなどの際に、視覚的な照合をするかもしれない。似て見える文字をマップすることは、使用しているフォントを知っているなど多量の文脈を使うことなしには不可能であるから、stringprepは、似て見える文字のマップについて何もしないし、他の文字に似ているからといってある文字を禁止することもしない。

Security on the Internet partly relies on the DNS. Thus, any change to the characteristics of the DNS can change the security of much of the Internet. ...

インターネット上のセキュリティは部分的にDNSを頼りにしている。したがって、DNSの性質に対するいかなる変更も、インターネットのほとんどのセキュリティを変えてしまい得る。 ...

Current applications might assume that the characters allowed in domain names will always be the same as they are in [STD13]. This document vastly increases the number of characters available in domain names. Every program that uses "special" characters in conjunction with domain names may be vulnerable to attack based on the new characters allowed by this specification.

現在のアプリケーションは、ドメイン名に許される文字が常に[STD13]にあるのと同じだろうと想定しているかもしれない。この文書は、ドメイン名に使用できる文字の数を膨大に増加させる。「特別な」文字をドメイン名と共に使うすべてのプログラムは、この仕様によって許された新たな文字に基づいた攻撃に対して脆弱な場合がある。

Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN), RFC 3491

このRFCには、懸念の指摘は書かれているものの、じゃあどうすればよいのかということについては書かれていない。

日本語ドメイン名協会、JPNIC、日本レジストリサービスあたりに、そういったことについての消費者向けの注意喚起の解説といった文書はあるのだろうか。

■ 追記

国際化ドメインの導入にどのような利点があるとされてきたかというと、広告媒体等で表示されるドメイン名を消費者が覚えやすいという点だろう。たとえば、日本レジストリサービスの「日本語JPドメイン名はこんなに良い！」という説明にこう書かれている。

日本語JPドメイン名は誰にでも「分かりやすい」「覚えやすい」というよさがあります。広告やパンフレット・名刺掲載も今なら注目度抜群。印象に残る日本語JPドメイン名で、見た人を確実にWebサイトに誘導することができます。

つまり、入力するための利便性として国際化ドメイン名は考えられてきたと言える。しかし、ドメイン名の役割には、入力する（アクセス先を指定する）ことだけでなく、表示する（今アクセスしているところがどこか確認する）ことにもある。後者の視点で、国際化ドメインのことが十分に考えられてきたのかどうか。「http://総務省.jp/」にアクセスしてみると、即座に http://www.soumu.go.jp/ へリダイレクトされる。これは、入力のための日本語ドメインとしてだけ活用されていると言える。

名前を国際化したいという話は、ドメイン名だけでなく、PKIの証明書にもある。例えば、サーバ証明書では、Webブラウザで確認する際に、現在では英語名称の組織名での確認を強いられている。日本人にとって英語名称の組織名に馴染みがあるはずもなく、消費者がサーバ証明書の目視確認の意義を理解することの妨げになっているだろう。例えば、https://www.shinsei.soumu.go.jp/ のサーバ証明書のSubject名は、

CN = www.shinsei.soumu.go.jp
OU = MPHPT
O = Japanese Government
C = JP

となっており、「MPHPT」の意味を理解できる国民は皆無に近いだろう。ここに、

CN = www.shinsei.soumu.go.jp
OU = 総務省
O = 日本国政府
C = JP

と表示できるようになることの意義は大きい。

同様に、ドメイン名を日本語で確認できるようになることにも、セキュリティ上のメリットがあると考えられる。これまでは、ドメイン名を英数字記号として暗記して確認する必要があった。

問題は、「よく似た文字が存在し得る文字列を本物かどうか目視確認する」という作業に、人々はまだ慣れていないという点だ。これまでに、そういう必要性のある機会は存在していなかったのではなかろうか。「イソターネット」と「インターネット」を見分ける必要性はもはや洒落ではなくなってくるということだ。見分けを補助する技術の開発、採用が必要となるのかもしれない。

あるいは、ドメイン名の見分けは無理があると諦めて、「http://総務省.jp/」のように、US-ASCIIドメインのサイトへリダイレクトする使い方しかしないということも考えられる。この場合、消費者は、信頼するサイトのUS-ASCIIのドメイン名を覚えなくてはならず、日本語ドメイン名は、初めて訪れるときの暗記用キーワードとして使われることになる。

■ 追記2

今年4月に行われたらしい日本語ドメイン名協会の講演会での、桃井さんらのプレゼンテーション資料が、同協会のサイトにあった。

• MozillaにおけるIDNのサポート: その歴史と現状

そういえば、cookieのドメイン指定への影響も考えないといけないと、あのときも桃井さんが言っていたような。

■ CASPIAN uncovers major security hole on Auto-ID Center's website

時間がないのでリンクだけ。

• CASPIAN uncovers major security hole on Auto-ID Center's website -- Confidential documents available with just two mouse clicks

私も一つ、穴を知っているのだが、どうするべきなのだろうか。やはり、連絡を入れて、こっそり直す機会を与えるべきなのだろう。しかし、そうすると、安全性に対する世間の評価、認識が、実態からズレることになってしまう。直った後で、穴があったことを世間に伝えればよいわけだが、それはそう簡単なことではない。信憑性をどうやって確保するか、もし「そんな事実はない」と言われたときどうやって証明するか、直ったのに世間に伝えることの意義をどう説明するか、など。

■ ネタメモ

• 小松裕司, 山田肇, RFIDの動向, 社会に普及していく為には, 文部科学省 科学技術政策研究所 科学技術動向研究センター 「科学技術動向」 2003年5月号

■ いろいろな人に会うということ

CSEC/ISEC合同研究会に行ってきた。今回もたくさんの大切な方々と貴重なお話しをした。議論、雑談、与太話、そして不本意にも激しく問い詰めてしまったり。（フゥー）

一般に、当事者な人とお話しすると、日記に書けないことを増やしてしまう。

セキュリティ脆弱性の問題に初めて足を突っ込んだ3年半前、別業界にいた私に人脈は全くなかった。某社の製品の穴を知ったときは、一般消費者向けコールセンターに電話し、話を理解できる担当者に代わらせるまで、素人オペレータを説得するしか手立てはなかった。

「後になってみれば実は知り合いが関係者だった」ということもあったりしたが、最近では、はっきりとしたチャネルがあちこちにできてしまった。「この問題はあの人が関係者っぽい」と頭をよぎることが起きてくる。こういうときどうするべきなのか。

「問題を見つけたら当事者サイドの知人に内々に知らせるのが最も早い解決の道だ」という考え方をする人がいるかもしれない。しかし、それは得策でないことがある。それは、知人が解決できなかった場合だ。

当事者サイドといっても、その知人がどのくらい最終決定に寄与できるかは、問題の性質によっても異なる。誰の目にも明らかに致命的で今すぐ解決が必要といった問題では、知人に伝えるだけで解決される可能性は高い。例えば、名簿丸見え問題（Webの通常アクセスでファイル丸見え）なんかはそのタイプだろう。しかし、攻撃されるのが今すぐではないとか、問題の仕組みが複雑すぎて理解されにくいとか、プライバシー関連の問題などでは、知人が努力しても組織としては対応しないという展開が予想される。

知人が解決に失敗した場合に、その後どうするか。世間に事実を公表して問題提起したとする。そのとき、知人の立場はどうなるだろうか。解決が確実でないケースでは、あえて知人に伝えず、その組織の公式な窓口に報告するのがよい。

しかし、専用窓口のない組織も多い。一般的な窓口経由では、事の重要性が正しく認識されないまま、適切な人の耳に入らないという事態が起き得る。そうであるがゆえに（かどうかはわからないが）、「何かありましたら私に言ってください」と有り難いお言葉を頂くことがある。そうした言葉を頂いていながら、知人には伝えず、公式窓口に連絡したり、世間に問題提起するという行動をとるのも、これまた心苦しい。だが、伝えても解決されず後になって公表するときの苦しさよりはましだ。

ただし、以上の話は、あくまでも解決されることだけを目的とする場合だ。この種の問題では、個々の事例が単に解決すればよいというものではない場合がある。その問題が、既に広く世間に認知されたものであるなら、個々の事例は解決されるだけでよい（と言えるかもしれない）。しかし、そうした問題の存在自体がまだ認知されていない段階では、問題が存在した事実が世間に公表されることに意義がある。この場合に、知人に内々に伝えることは、問題があったことの公表も知人に期待することになる。それはあまりに知人に負担をかけすぎのように感じる。

もうひとつ、公平性という観点から、知人がいるかいないかで対応方法を変えるというのは正しくないだろう（もちろん、全く個人的で単発の行為ならば正しくなくはない。）

一方、既に公開の場で問題提起されたものがまだ解決されていないという状況でならば、人脈を活用するというのも、問題がないし効果的なのかもしれない。

■ 「というもの」禁止令

学生の学会発表によくある耳障りな言葉遣いに、「……というもの」の連発というものがある。（おっと、そう言いながら使ってしまった。でもこの用法は正しいはず。）

以前から気になっていたが、どんどんひどくなっているようだ。どういう心理的背景からこの表現が出てくるのか。

おそらく、自分の中で消化しきれていない用語を使うときの表現なのだろう。「……というもの」というのは、聴衆にとって常識的ではない用語や表現を使う場合に、後で定義する意思を暗示するために使うものだろう。だが、学生達は、ありとあらゆるテクニカルタームに「……というもの」を付けて喋っている。これでは、「私はこの言葉をつい最近知りました」と白状しているようなものだ。

もっと重症になると、一般名詞にまで付けている。「……というものがあるのですが、」は、「……ってやつがあるんだけどさー」の丁寧表現なんじゃなかろうか。タメ口会話をそのまま丁寧表現に翻訳しただけの発表が流行っているようだ。

「というもの禁止令」でも出して矯正したらいいと思う。

■ ドメイン名とサーバ証明書こそが信頼の基点だということをまだわかってないらしい

6月2日の日記に「日本は平和なのか、それとも単に遅れているだけなのか」というのを書いたが、昨日、ソニースタイルからこんなメールが来た。

Received: from jp.sonystyle.com (sscjmlout0.jp.sonystyle.com [211.125.129.235])
 by mail1.accsnet.ne.jp (8.9.3/3.7W-ns)
 with SMTP id SAA12508 for ;
 Fri, 18 Jul 2003 18:45:13 +0900 (JST)
Received: (qmail 24563 invoked by uid 101); 18 Jul 2003 18:45:12 +0900
From: info@jp.sonystyle.com
To: takagi@mail1.accsnet.ne.jp
Subject: 【重要】「Sony Style」を詐称した悪質なメールおよびウェブサイトに対する注意のお願い
Message-ID: <20030718094512.24561.qmail@jp.sonystyle.com>
Date: 18 Jul 2003 18:45:12 +0900


----------------------------------------------------------------------
　　「Sony Style」を詐称した悪質なメールおよびウェブサイトに対する
　　　　　　　　　　　　　　注意のお願い
----------------------------------------------------------------------
最近、海外のある国において、「Sony Style」を詐称した悪質な事件が発生
しております。日本国内でも同様の事件発生の可能性がございますので、充分
ご注意くださいますようお願い致します。

これは、ソニースタイルのWebサイトにも掲載されている。

この注意喚起は、以下の事件報道をふまえてのものだろう。

• ソニー米国法人，顧客サービスを騙る詐欺メールについて警告, 日経IT Pro US NEWS FLASH, 2003年7月5日

  ソニーの米国法人Sony Electronicsは，Sony社が発信元であるかのように見せかけた詐欺メールが出回っていることを米国時間7月3日，警告した。「Sonystyle user and email address」という件名のこの詐欺メールは，SonyStyle Customer Serviceからのメッセージであると偽り，ユーザー名やパスワード，電子メール・アドレスなどの個人情報を求めるというもの。

この記事は、以下の点が気になる。

Sony Electronics社e-Solutions事業プレジデントのMike Fasulo氏は，...

また，「Sony Electronics社のすべてのWebサイトでは，確固たるセキュリティ対策を講じている。Sonystyle.comや同サイトのデータのセキュリティが侵された形跡はない」と付け加えた。

詐欺メールが出回ったという話なのに、「確固たるセキュリティ対策を講じている」は関係ないだろうに。ユーザ名とパスワードを盗まれたかもしれないのに、「セキュリティが侵された形跡はない」というのは、どうして言えるだろうか？

その点、日本のソニースタイルからの連絡には、そういう珍妙なことは書かれていなくて、さすがだと思った。国外での事件なのに国内にも注意喚起するというのは、よいことだ。

だが、これはどうなのか。

個人情報やＩＤおよびパスワードの入力・提示にあたっては、今まで以上に慎重を期してください。弊社が運営するウェブサイト「ソニースタイル」および「ソニードライブ」では、お客様への重要なご案内などを行う場合、ウェブサイトのトップページにてその旨告知をしております。電子メールに「ソニースタイル」の名が付いていても、個人情報を特定の電子メールアドレスやウェブサイトに提供するよう誘導されている場合には、いったん保留とし、電子メールと当社のウェブサイト上の情報が一致しているかどうか必ずご確認ください。もしくは、お手数ではございますが、ソニースタイルカスタマーセンターまでご照会くださいますようお願い致します。

「Sony Style」を詐称した悪質なメールおよびウェブサイトに対する注意のお願い

「重要な案内をする場合はウェブサイトのトップページで告知している」というのは、どういう意味か？ 偽サイトへ誘導されるのは、なにも、特殊な個人情報入力だけではなかろう。本物とそっくりに作られたログイン画面かもしれない。「ログインするときは、毎回トップページで告知を確認せよ」と？ 意味がわからない。

おそらく、この告知は、今回の事件だけを念頭に置いて書かれているのだろう。今回の事件が、明らかにソニースタイル以外のサイトへ誘導するものだったのだろう。「ただ今、アクセス集中によりつながりにくくなっています。こちらの臨時サイトをお使いください」といったように。

しかし、そういうあからさまな詐欺以外に、ごく普通のソニースタイルのメールマガジンを装って、微妙に異なるドメインの偽サイトへ誘導するということが起こり得る。したがって、ソニースタイルとしては、ドメインが本物かどうかを確認することを、消費者に促すべきである。このことについて、今回の注意メールは、なにも書いていない。

書くべきは次のことだっただろう。

お客様がアクセスするウェブサイトが、本物のソニースタイルサイトであるかどうかを次の方法で確認してください。

• アクセス先のURLが、www.jp.sonystyle.com になっているか。
• パスワードを入力する画面で、ブラウザの「鍵マーク」をダブルクリックし、証明書の「サブジェクト」が「Sony Marketing (Japan) Inc.」になっているか。

せっかく毎年8万円あまりを支払って、信頼感の高い認証局からデジタルID証明書を購入しているのに、こういうところで活かさないとは、じつにもったいない話だ。6万円分くらいをドブに捨てている。この注意喚起メールを書くにあたって、セキュリティ担当者や、技術者は助言しなかったのだろうか。技術者の助言など聞く必要ないというのであれば、ずいぶんナメた話だ。

■ 偽サイトは容易に作られる

これで思い出したのだが、ずいぶん前からこんなサイトがあるのだ。

• SonyStyle

これを見て、どう思うだろうか？ 偽物か？ 本物か？ 謎を解くには、2年前のこの記事の存在を知っておくほかないかもしれない。

偽サイトへのアクセスを本物サイトに中継するように構成すれば、こんな感じに見える偽サイトを作ることは容易だろう。

また、Yahoo! Styleでは新システム「Remote Merchant Integration (RMI)」を導入する。これは、Yahoo!Styleのフレームの中に協賛企業のページがそのまま表示されるという形だ。このシステムを利用することにより、Yahoo!ショッピングのシステムを利用しつつ自社のサイトの特徴を活かした出店が可能になる。

Yahoo! JAPANとソニースタイルが提携〜「Yahoo! Style」を開設〜, INTERNET Watch, 2001年7月19日

消費者の混乱に配慮を欠いた不用意なシステムに思える。これに慣れている消費者は、偽サイトを偽と見破ることができるだろうか。

ついでに言えば、http://r1.jp.rmi.yahoo.co.jp/rmi/http://www.jp.sonystyle.com/Guide/Customer/index.html で変更や閲覧をしたときや、注文を実行したときは、個人情報が、Yahoo! のコンピュータ上を流れる（SSLで暗号化されたデータはYahoo!のサーバ上で復号される）わけだが、これは、ソニースタイルのプライバシーポリシー上、問題ないのだろうか。

■ JALからも注意喚起メール 発信源は？

昨日は、日本航空からも注意喚起メールが来た。

Received: from mta2.primary.ddc.dartmail.net (mta2.primary.ddc.dartmail.net [146.82.220.42])
 by mail1.accsnet.ne.jp (8.9.3/3.7W-ns)
 with ESMTP id WAA25042 for ;
 Fri, 18 Jul 2003 22:46:57 +0900 (JST)
Message-Id: 
From: JALマイレージバンク 
To: takagi@mail1.accsnet.ne.jp
Reply-To: JMB CYBER  FLASH 
Subject: 【ご注意】ジャルシステムカードを名乗る団体について
Date: Fri, 18 Jul 2003 22:46:55 +0900


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【ご注意】ジャルシステムカードを名乗る団体について
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

発信源をReceived:フィールドで確認すると、謎のドメインだ。

Reply-To:が「jal.co.jp」でなしに「jal.com」になっている。jal.co.jp以外にjal.comも日本航空のドメインだということを客は知っておけということか。難儀な話だ。

■ 最後の切り札を最初に使わせてどうする

つくば市在住の人なら多くが利用しているであろう大手地銀の常陽銀行。その常陽銀行からこんなメールが来た。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
常陽ダイレクトバンキング「アクセスジェイ」をご利用の皆さまへ
■「アクセスジェイご契約者カード」再発行受付サービス終了のお知らせ■
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
...
本サービスは５月１２日より、お客さまにより安心してご利用いただくため、
ネットアクセス（インターネットバンキング）ご利用時に従来のログイン
パスワードに加えて、「アクセスジェイご契約者カード」記載の番号を
入力していただく等のセキュリティ強化対応を行っております。

以前から常陽銀行は、三井住友銀行などの例と同様に、乱数表を記載したカード「アクセスジェイご契約者カード」を、ネットバンキング契約者に配布している。

これまで、この契約者カードがどのように使われてきたかというと、「テレホンアクセス」という、電話のプッシュ音で操作するシステムで、振込みなどの重要な操作をするときに、乱数表の番号を押させていた。このことは、archive.orgに残っている去年3月の時点のページで確認することができる。

〈２〉 テレホンアクセス（テレホンバンキング）

４桁の暗証番号に加え、都度指定の振替・振込の場合は「ご契約者カード」に記載のお客さまごとに異なる可変暗証番号により本人確認いたします。

2002年3月の時点の http://www.joyobank.co.jp/access-j/gaiyo.html

これは、電話のプッシュ音が、一部の電話機では容易に盗聴され得ることに配慮した対策であろう。

これが、今回、インターネットバンキングのログインのときにも使うようになった。このことは、常陽銀行のニュースリリースにも記載されている。

４．ネットアクセスログイン時のセキュリティ向上

インターネットバンキングをより安心してご利用いただくため、従来のログインパスワードに加えて、ご契約者全員に配布している「常陽ダイレクトバンキングご契約者カード」記載の「テレホンバンキング確認番号」10桁のうち毎回異なる２桁をネットアクセスログイン時に入力していただくようになりました。本方式は「ワンタイムパスワード方式」「乱数表方式」などと呼ばれ、安全性の高い認証方式です。

ニュースリリース: 常陽ダイレクトバンキング「アクセスジェイ」の機能拡充について

何のためにこの機能を取り入れたのかは、以下のページで説明されている。

２．契約者カードでのワンタイムパスワード認証

ログイン時に10桁の契約者カード番号のうち毎回異なる2桁を入力する方式（ワンタイムパスワード方式・乱数表方式）を採用させていただいております。これにより、お客さまご利用のパソコンにキーボード入力を記録するようなソフトを仕掛けられ、入力したパスワードが盗まれた場合でも、不正利用されにくい仕組みとなっております。 常陽ダイレクトバンキング アクセスジェイ 主なセキュリティ対策

つまり、この事件が起きたために打ち出された対策のようだ。

• 不正にソフト仕掛け暗証番号入手、1600万円を詐取, 毎日新聞, 2003年3月6日

  容疑者は、パソコンに入力した記録を後に取り出せる「キーロガー」と呼ばれるソフトをあらかじめ都内のインターネット喫茶店などのパソコンに仕掛け、被害者らが利用した後に暗証番号などのデータを入手していた。719件の銀行口座や証券会社のネット取引の個人情報を取得していたといい、警視庁は余罪を追及するとともに、インターネット喫茶などのパソコンを使った金融取引について注意を呼びかけている。

常陽銀行のアクセスジェイのトップページには、

インターネットカフェなど不特定多数の方が使用するパソコンではご利用にならないよう、強くお勧めいたします。

と注意書きされているが、自宅パソコンにウイルスメールやトロイの木馬で仕掛けられる可能性にも配慮したのだろう。

しかし、ちょっと驚いたのは、三井住友銀行などの他の銀行では、乱数表を使うのは、ログイン時ではなく、振込みなどの重大な操作の最後のステップになっているのに対して、常陽銀行の今回の措置は、ログイン時にいきなり入力させるという点だ。

はたしてこれは、本当に安全性を高めているだろうか？

乱数表の安全性は、5月12日の日記にも書いたように、

こうした方式がとられている銀行をネットカフェで利用し、キーロガーによってタイプした文字を盗聴されたとしよう。しかし、犯人は、不正ログインできても、サーバが偶然に同じ2つの枠を指定してこない限り、送金を実行できないことになる。むろん、正規利用者がネットカフェで何度も繰り返し取引を実行すると、16か所の枠がビンゴカードのように次々と盗まれていくことになるので、安全性は徐々に低下していく。このあたりの確率計算の試みが文献*1にある。

ということがある。

常陽銀行は、ログイン時に乱数表を使わせることによって、ビンゴカードの穴を開ける機会を増やしてしまった。本来、乱数表カードは、最後の切り札として温存しておくべきものなのに、常時使わせている。

つまり、残高照会や、入出金明細照会や、ポイントクラブのポイントを確認するためだけにログインするときにも、切り札を使わざるを得ない。しかも、途中で戻るボタンを押してしまったりしてログインからやり直すことになると、それだけで何度も切り札を出さないといけない。

なぜこんなシステムにしたのだろうか。これは次の事件の手口に配慮したためかもしれない。

• 不正アクセス新たに300万円被害、35歳を追送検 警視庁, 毎日新聞, 2003年5月1日

  容疑者は01年12月、ネットバンキングを専業とする都内の銀行が神奈川県内に設置したサーバーに、インターネット喫茶で盗み取った兵庫県の男性会社員（31）のパスワードを使って侵入。男性の住所を自分の私書箱に変更し、キャッシュカードを「紛失した」として再発行させ、私書箱に送らせた。昨年1月25日、このカードを使い、便利屋に依頼して口座から約300万円を引き出した疑い。

常陽銀行の今回の連絡メールには続きがあって、

これに伴い、「アクセスジェイご契約者カード（お申込み後ご契約者全員
に配達記録でご郵送しております）」を紛失されたお客さま向けに
「ご契約者カードの再発行を電話で受付するサービス」をご提供して
参りましたが、７月３１日をもって再発行受付サービスを終了させて
いただきますのでご連絡申し上げます。

となっていた。再発行をインターネット経由で受け付けないことにしたというのは、上の事件の手口への配慮と考えられる。

常陽銀行のインターネットバンキングのサービスにログインすると、住所変更の機能がある。住所変更届を出すには、最後のステップで「取引用確認番号」の入力が必要になっているが、キーロガーが仕掛けられている環境を想定するなら、こうした固定パスワードでは成りすまされることになる。そのため、住所変更も困難にする必要があるというわけで、ログイン自体に乱数表を使うようにしたのだろう。

これは賢くない選択だ。そういう配慮なのなら、住所変更届けや、メールアドレス変更、出金操作など、重要な操作の最後のステップで乱数表を参照するようにすればよい。ログイン時に求めない方が安全性が高い。住所変更やメールアドレス変更は、そう頻繁に使うものではあるまい。

ところで、この乱数表を「ワンタイムパスワード」と呼ぶのはいかがなものか。10個の枠から2か所を順に選ぶ組み合わせは90通りしかないので、数十回利用すれば次第に「ワンタイム」でなくなってくる。

というか、1回に2枠ほどバレていくので、5回 + 数回ほど利用した時点でほぼ全桁がバレてしまう。3回ほど利用すると、半分ほどの枠がバレていることになるので、そのときは、1/4ほどの確率で2桁とも知れているし、1/2ほどの確率であと1桁がわからないわけだが、0〜9を選ぶだけなので、×1/10の確率で突破できる。2回まで間違えられるようになっているとすると、×3/10 の確率で突破できてしまう。つまり、1/4 + 1/2 × 3/10 = 40% ほどの確率で突破できる。いくらなんでも弱すぎないか？

ただでさえ弱い乱数表を、入出金明細照会のたびに使わせるのでは、もうほとんど存在価値がなくなってしまっているのではなかろうか。

今回の措置で、

なお８月以降は、ご契約者カードを紛失された場合、従来通り一度解約して
再度新規でお申込いただくこととなりますので、あらかじめご了承ください。

ということになったので、乱数表を新しい番号のものに取り替えることもできない。同じ表をずっーと使うわけだ。

あと、一般論だが、日本銀行金融研究所の「インターネットを利用した金融サービスの安全性について」には、

しかし、もしも金融機関側のシステムが、攻撃者にとって都合のよい値が出るまで、「チャレンジの出し直し」をさせることができる作りであった場合、問題が発生する。こうした認証方式では、通常、暗証番号を試行錯誤的に入力する攻撃を回避するために、「チャレンジに対するレスポンスの入力エラーは3回以内」などといった制限を設け、制限値を超えると入力を規制するといった仕組みを採用することが多い。しかし、「チャレンジを表示させる回数」については、制限を設けていないシステムが存在するようである。

という指摘もあるのだが。これって、1年半も前に日本銀行のシンポジウムで話された内容なんだが。これを「知らなかった」で済ませられるのだろうか。

■ 銀行がこんなメールでいいのか

常陽銀行からの告知メールも、発信源が怪しげだ。

Received: from agent1104f.smp.ne.jp ...
Message-Id: 
Date: Thu, 17 Jul 2003 15:05:19 +0900
From: "常陽銀行" 
Subject: 常陽ダイレクトバンキングご契約者カード再発行受付サービス終了のお知らせ

そもそも、差出人アドレスからして、「biglobe.ne.jp」ドメインというのがスゴイ。こういうのに慣らされている預金者は、何の疑いもなく本物と信じるんだろうか。

もっとすごいのは本文だ。

　　　　　↓↓↓↓↓【重要】↓↓↓↓↓
★「ご契約者カード」を紛失されているお客さまにつきましては
　　お早めに再発行のお手続きをお願いいたします。
◇◆手続方法詳細はこちらから
[]http://r11.smp.ne.jp/u/No/10082/5D378869_10387/access-j.html[]

手続きのために、「smp.ne.jp」という謎のドメインにアクセスしろというのだ。

しかも、Webバグ（Web盗聴器）付きだろうか？ 「5D378869」あたりが受信者ごとに異なるっぽいが、確認できていない。

■ 「answer.or.jp」なんてドメインがあったら紛らわしくて困る

http://www.joyobank.co.jp/access-j/index.html で「ログイン」のところをクリックすると、https://www2.paweb.anser.or.jp/BS?CCT0080=0130 にジャンプするのだが、「anser.or.jp」がNTTデータのサービスであることを知っていないと、信用してよいかを判断できない。http://www.anser.or.jp/ に説明があるわけでもないという、秘密主義の徹底ぶりである。

http://www.joyobank.co.jp/access-j/index.html はSSLではないので、通信路上で改竄されている可能性を否定できない。もし、このページに書かれたリンク先URLの「anser」が「answer」に改竄されていたとして、はたしてジャンプ後に見分けがつくだろうか。

そういうことのないように、https://www.joyobank.co.jp/ に自力でSSLでアクセスして、そこからジャンプすればよいわけだが、このURLは Not Foundになってしまう。せっかくサーバ証明書をとっているのなら、活用したらいいのに。もったいない。

■ 追記

ちなみに、常陽銀行のセキュリティについての説明ページは、けっこう真摯な態度で書かれているように思う。特に、「クッキー（Cookie）について」で、以下の点に触れているのは、他に見たことがない。

クッキー（※）をお取引画面間の情報引継ぎ管理等に利用すると、お客さまがセキュリティ対応されていないブラウザを利用されている場合に、クッキーの機能を悪用して悪意の第三者に不正使用される可能性があることが指摘されております。

ただ、文章がうまくないので、読者に理解できるかは疑問だが。

■ 追記2

日経BPのWPC ARENAに、「ネットバンクで1600万円が突然消える」という記事が出ている。ここには、都市銀行とネット銀行の各行が、乱数表を使っているか否かの一覧表が示されている（下の方）。

すばらしい。ようやくこういう意味のあるセキュリティレベル比較をメディアがやってくれる時代になったかと感慨深い。というか、ようするに単に、事件が起きてからしかメディアは書かないということなのだが。

知識豊かな本誌読者なら、そういった危険を100％否定できないネットカフェで、無防備に銀行口座のIDとパスワードなど入力しないはずだ。

...
 事件後、「不特定多数が利用するネットカフェなどからの利用はお勧めできない」といった注意書きをネットバンキングのサイトで見かけるが、遅きに失した感は否めない。

(原　隆、日経パソコン編集)

ネットバンクで1600万円が突然消える 利用者、銀行、ネットカフェに問われる危機管理意識, 日経BP

マスメディアの銀行比較も遅きに失したと思うのだが。次には、ぜひとも、上に紹介した、「チャレンジを表示させる回数については制限を設けていない」銀行をリストアップして公表してほしい。

■ 訂正

「10個の枠から2か所を順に選ぶ組み合わせは90通りしかないので」と書いたが、ここの場合、2つの枠番号が、左より右が大きいという順でしか現れないようなので、45通りの組み合わせしかない。40% という数字も、正確にはもう少し大きめになる。

■ 続・最後の切り札を最初に使わせてどうする

一昨日の日記の続きだが、22日付けの「マネーメモ」によると、りそな銀行のtype blue（旧大和銀行）のシステムも、ログイン時に乱数表を使うのだそうだ。

他にも、東京三菱銀行もログイン時に乱数表を使うようだ。このことは、体験版の画面で、「OK」ボタンを押してみればわかる。

他にもあるか調べようと、一昨日紹介した、「ネットバンクで1600万円が突然消える」に行ってみると、なんだ、表に載っているではないか。表には「ログイン時のセキュリティ」の列があって、そこに「乱数表」と書かれたところが該当する。この中では、旧大和銀行と東京三菱銀行だけのようだ。

ここのシステムを作った人達は何を考えているのだろうか。常陽銀行の場合では、キーロガー事件を受けて急遽対策したんだろうから、まあ、ありがちなミスだなと思ったが、大和や東京三菱は、最初からこの設計でシステムを構築したんだろう。

ところで、これらの乱数表がキーロガーだけを想定した対策であるなら、「繰り返し使うとビンゴカードのように次々と盗まれていく」という心配は、実は杞憂なのだ。なぜなら、キーロガーだけでは、盗んだ入力番号が、どの枠のものであるかを知ることができないからだ。

しかし、キーロガーを仕掛けられるような環境では、他にどんな罠をしかけられているかわからない。例えば、キーロガーと同時に画面をキャプチャーするものを仕掛けられていれば、枠の位置と同時にコードを盗まれるだろう。他にも、ブラウザの表示内容と入力内容をキャプチャするプラグインを開発してブラウザに組み込んでおけば、両方とも盗めてしまうし、ブラウザのプロキシサーバの設定を変更して、SSL復号・再暗号化機能付きプロキシを仕掛け、偽サーバ用の偽ルート証明書をインストールしておけば、https:// の画面であろうが、通信内容をすべて記録できてしまう。消費者は、ネットカフェなどにある信用できないコンピュータを使うときは、これらの可能性を意識しておかねばならない。

やはり、最後の切り札を最初に使わせるような設計は避けるべきだろう。センスのない人間が設計し、運用しているとしか思えない。

■ 乱数表が持ち腐れの銀行

これは個人の日記だ。個人の責任で余暇に書いている文章だ。個人が気軽に書いている日記なのだから、読者はあまり本気で信じてはいけない。組織の重厚な判断の下で慎重に書かれているのとは違うのだ。読者自らが再検証し、それが何を意味するか読者自身が考察するというのが、他人の日記を読むときの心得だろう。

一昨日の日記では、ぼかして書いたが、どうやら全然特殊な事例ではないようなので、はっきりと書くことにする。

まず、復習。日本銀行金融研究所の「インターネットを利用した金融サービスの安全性について」の p.219 には次のように書かれている。

しかし、もしも金融機関側のシステムが、攻撃者にとって都合のよい値が出るまで、「チャレンジの出し直し」をさせることができる作りであった場合、問題が発生する。こうした認証方式では、通常、暗証番号を試行錯誤的に入力する攻撃を回避するために、「チャレンジに対するレスポンスの入力エラーは3回以内」などといった制限を設け、制限値を超えると入力を規制するといった仕組みを採用することが多い。しかし、「チャレンジを表示させる回数」については、制限を設けていないシステムが存在するようである。そうしたシステムの場合、攻撃者は、不都合なチャレンジであればそれに応答しないで入力をキャンセルし、次のチャレンジを表示するよう依頼することにより、自分が正答できるチャレンジが表示されるまで、何度もチャレンジを表示させるという攻撃が可能となる。

松本勉, 岩下直行, インターネットを利用した金融サービスの安全性について, 金融研究第21巻別冊第1号, 2002年.

UFJ銀行の「これまでの改善内容」にはこんなことが書かれている。

今後、ログインパスワードを忘れたり、連続して間違えて入力し、インターネットバンキングが利用できなくなっている(ロックされている)場合は、 オンラインサインアップ(利用開始登録)画面より、再度オンラインサインアップ(利用開始登録)をすることによりインターネットバンキングがすぐにご利用いただけます。

UFJ銀行 ログインパスワードロック(6〜12桁)解除手続の変更について

なるほど便利な改善だ。

UFJダイレクトの「オンラインサインアップ」の画面の一番下にある「同意する」ボタンを押してみる。次の画面で、

ご契約カードの乱数表で、 8行目の6列目 の数字から右へ４桁（確認番号）を入力してください

といった表示が出る。ページを戻って、もう一度「同意する」ボタンを押してみると、今度は、

ご契約カードの乱数表で、 10行目の4列目 の数字から右へ４桁（確認番号）を入力してください

と、先ほどとは異なる場所が指定される。これは、何回でも繰り返せるようだ。

つまり、一回でも盗聴（キーロギングや画面キャプチャやプロキシ盗聴を含む）されて、X行Y列から右へ4桁の数字を盗られてしまったら、犯人は、上の画面でX行Y列が出るまでボタンを押し続けるだろう。乱数表には10行10列の100個の数字が書かれているようだが、「右へ4桁」という指示を出すからには、列番号は1〜7の範囲だろうから、70通りしかない。

りそなダイレクトの「type blue」と書かれた部分をクリックしてみる。

りそなダイレクトお客様ご利用カードを参照して、ひらがなの表示に該当する数字を入力してください。

ての数字
あの数字

などと指示される。ウィンドウを閉じて、もう一回クリックしてみると、今度は、

りそなダイレクトお客様ご利用カードを参照して、ひらがなの表示に該当する数字を入力してください。

かの数字
いの数字

と出る。欲しいものが出るまでいくらでも繰り返せる。この説明によると、「あ」〜「と」までの20個の枠で構成されているようなので、380通りしかないようだ。

こういう画面設計をしては駄目だ。ユーザ名の入力と同じ画面で乱数表の値を入力させる設計は駄目だ。ユーザ名を入れた次の画面で、乱数表を使わせるようにすればよい。そうすれば、ユーザが特定されているので、そのユーザ向けに前回に提示したのと同じ場所を指示するように作ることができ、そうすればこの問題は回避できるだろう。

「そんなことを日記に書くな」などと言われるかもしれないが、先に復習したように、この話は、2002年2月28日に日本銀行で開催された第4回情報セキュリティ・シンポジウムでとっくに指摘済みの話だ。もう1年半も経っている。たくさんの金融システム構築関係者が聴講していただろうし、全国銀行協会の人も聴いていただろう。何をやっているんだ。

やんわりとそれとなく指摘していたのでは永遠に修正されることはないのだろう。マスコミが扱うまで修正することはないのだろう。スラッシュドットでコケにされるまで直すことはないのだろう。

■ 奥ゆかしきエラーコード

システムを開発する際、ユーザ名とパスワードを受け付けた画面で、「ユーザ名が間違っています」とか、「パスワードが間違っています」という表示をしてはならない、つまり、「ユーザ名またはパスワードが間違っています」と表示すべきだという話は、基礎中の基礎だ。

常陽銀行のログイン画面というか、NTTデータのANSERシステムで、「利用者ID」と「パスワード」を入力するとき、どちらか一方を間違えると、どんなメッセージが表示されるか。

ユーザ名が間違っているときは、

入力項目が誤っています。
再度入力して下さい。

理由コードはB33です。

と表示される。そして、ユーザ名が正しく、パスワードが間違っているときは、

入力項目が誤っています。
再度入力して下さい。

理由コードはBXXです。

と表示される。一応、「XX」の部分は伏字にしておいた。「B33」とは異なる文字列が表示される。

これは、「ネットアクセス（インターネットバンキング）に関するお問い合わせ先」に、

なお、パスワード等が入力エラーになってしまう場合など、「エラー理由コード（例：Ｂ０３）」が画面上に表示されることがありますので、お申し出いただきますとより迅速にご対応できると思われます。ご協力のほどお願い申し上げます。

と書かれているように、エラーの原因を特定するためのものだろう。

ならば、ずばり「ユーザ名が違います」、「パスワードが違います」と表示すればいいものを、「理由コードはB33」などと奥ゆかしく表示するのはなぜなのか？ ずばり表示するのがセキュリティ上問題があると知っているからじゃないのか？ だが、それで理由がバレないと思っているのなら、かなり知能が低いと言わざるを得ない。

■ 署名欄付き乱数表カード

常陽銀行から送られてきた「ご契約者カード」の裏面には、署名欄がある。どうして署名なんかしなくちゃいけないのか。名前なんか書いたら、落としたときに危ないだけだろ。

これを作った人は、「カードってものは裏に署名欄を付けるものだ」とかいうレベルの認識なのだろうか。

■ ドイツのネットバンキング事情

ドイツ在住のOliverさんから、ドイツにおけるネットバンキングの様子をメールで頂いた。

それによると、ドイツのネットバンキングのほとんどでは、「TAN」（トランザクション番号）という、使い捨てのワンタイムパスワードが使われているそうだ。TANは、B6サイズほどの紙に100個の5〜7桁の番号が書かれたもので、それぞれ1回しか使えないそうだ。どの順番で使ってもよく、残りが少なくなると自動的に新しい紙が郵送されてきて、新しい方の番号を使うと、古い紙の残りは無効になるそうだ。

彼が使っている銀行では、ログイン用の固定暗証番号を3回間違えると、アカウントはロックされ、有効なTANを3個入力すると、ロックは解除され、もし、TANを3回間違えると、アカウントは完全にロックアウトされ、身分証明書をもって支店にいかないと解除できないそうだ。

きっと、TANの紙には、口座番号も契約者番号も氏名も書かれていないのだろう。拾っても誰のものかわからないように。

また、一部の銀行では、時刻で変化する10桁の番号を表示する電卓サイズのカードをユーザに配布しているところもあるそうだ。

この話を聞いて不思議に思ったのは、日本ではどうしてこう、まやかしの安全システムがまかり通って、ドイツではこうも確かな方法が選択されるのだろうか？ ということだ。どういう文化的相違からくるものなのだろうか。

■ HTMLメールのリスクとWebビーコン

先週、Japan.internet.comに、「HTMLメールのリスクとWebビーコン」というコラムが出ていた。これは、6月18日の日記の「ルートコミュニケーションズがやってくれるらしい」で、

「プライバシーについての配慮や取り組みについて、メディアやクライアントに説明できているつもりであったが、第三者から指摘されてそれが足りていなかったことに気づいた」とのことで、次の取り組みを進めているそうだ。

として紹介した、

「HTMLメールマーケティングガイド」やInternet.com掲載のコラムに、新しい記事として、Webビーコン使用時のプライバシーポリシー記述に関するものを執筆する。

が実現したもののようだ。

内容を拝見すると、

まずは、HTML メールの効果測定を行う際に一般的にどのようなことが行われているか、もう一度確認してみましょう。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

として、

図のような仕組みを用意すれば、どの ID を持ったメールが表示（＝開封）されて、どの ID を持ったメールが表示されなかったかを把握することができます。また、上図の f で cookie を発行する場合、これを追跡することで、ユーザーが会員登録した、購買行動を起こした、などの情報を取得することもできます。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

というように、Webバグ（Web盗聴器）の仕組みが包み隠さず書かれている。

これまで、こうした追跡の可能性は、傍から見て、原理的にそのようなことが可能なはずで、やっているのではないか？ という疑いに過ぎなかったのだが、メールマガジン配送システムの構築に携わる当事者からこのような説明が出たことは、それがただの疑いではなく、事実であることをはっきりさせた。

また、コラムは、

Web ビーコンはマーケティング的にはきわめて強力な仕組みであり、うまく活用できればメールマーケティング効果を大きく向上できるものですが、その反面、自社顧客の意図を越えてプライバシーに踏み込んでしまう危険性もあります。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

と続いている。

私としては、冒頭部分の、

ここ半年で HTML メールの導入事例は一気に増えました。しかし、その一方で送り手側がエンドユーザーにそのリスクを正しく伝えることができていない、または送り手自身それを認識していない、という現状を危ぶむ声も聞かれます。

阿部樹, 塚田耕司, HTMLメールのリスクとWebビーコン

という点が重要だと思う。

このコラムは次回に続くようなので、今後の展開に期待大だ。

■ 日本の銀行には安全基準がない？

22日の日記の「ドイツのネットバンキング事情」で、

この話を聞いて不思議に思ったのは、日本ではどうしてこう、まやかしの安全システムがまかり通って、ドイツではこうも確かな方法が選択されるのだろうか？ ということだ。どういう文化的相違からくるものなのだろうか。

と書いたが、これについて、山根さんの日記に反応があった。

私見では，ドイツでは第三者専門機関によるセキュリティ評価が義務づけられているからではないかと．たとえばこれは基幹システムの例だが， ドイツでは銀行間のネットワークに加入するにはEAL5が要件と法律で義務づけられている．

だそうだ。続いて、

日本の場合，金融ネットワークのセキュリティ基準を定めた法律はありません． (努力目標は定められていますが．) 国会で決める法律ではなく監督官庁による通達で指導を行うのが日本流です．

とある。

日本のネットバンキングの安全対策について文書化された基準らしきものは、私の知るところでは、日本銀行考査局が2000年4月に出した、「情報セキュリティ対策のチェックポイント ──インターネットを利用した金融サービスを中心に── 」と、財団法人金融情報システムセンターが発行している、「金融機関等コンピュータシステムの安全対策基準」くらいしか思い当たらない。

後者は入手していないので内容がわからない。前者については、「インターネット利用システムにおける情報セキュリティ対策のチェックポイント」という別添資料が付属しているのだが、技術面で挙げられているチェックポイントが、

1. ファイアウォール
   (1)ファイアウォールの導入および運用に当たり、適切な対策を講じているか
   (2)ファイアウォールのセキュリティホール等に関する情報を収集し、所要の対策を講じているか
   (3)専門家等による侵入テストを実施するなど、ファイアウォールの信頼性を定期的に確認することが望ましい
2. 暗号
   (1)機密性の高い情報を送受信する場合に、情報を暗号化しているか
   (2)暗号の利用および管理において、適切な運用ルールを整備し、適切に運用しているか
   (3)暗号を利用するに当たっては、適切なセキュリティ評価を行うことが望ましい
   (4)公開鍵を使用する場合に、ペアとなる秘密鍵について適切に取り扱っているか
   
3. 電子署名
   (1)高額な資金移動を伴うなどリスクが極めて大きな場合には、電子認証書等による利用者の認証を行っているか
   (2)重要な情報を送受信する場合には、漏洩や改竄等を防止するため、電子署名を利用することが望ましい
   (3)独自にＣＡ局（Certification Authority：認証局）を運営する場合には、運営方法に関するルールを整備し、ルールに沿って適切に運用しているか
   
4. 業務妨害対策
   (1)サーバをダウンさせる目的で短期間にシステムの許容量を超えるアクセスを集中する攻撃を想定し、代替的な業務遂行策を立てているか
   (2)組織全体としてウィルス検知体制や同対策に関する運用ルールを整備し、適切に運用しているか

インターネット利用システムにおける情報セキュリティ対策のチェックポイント IV．新たな情報セキュリティ対策のポイント

という内容で、典型的な駄目パターンに陥っている。

重要なのは、22日の日記に書いた乱数表の使い方の事例のように、個別に設計されたシステムの安全性評価であるが、上の基準では、「セキュリティホール等に関する情報を収集」や「専門家等による侵入テスト」が、ファイアウォールのところに分類されてしまっていることからして、そのことが認識されていないことがわかる。

ただ、これが書かれたのが2000年という、ちょうど日本の省庁でWebサイト改竄事件が連続発生したころで、インターネットを利用したサービスの脅威がようやく世に認識され始めたばかりのときであるから、この程度の脅威しか想像できなかったのもやむを得ないことだとは思う。

しかし、このような、「インターネットのセキュリティと言えば、ファイアウォールと、暗号/署名、そしてウイルス対策だ」で満足してしまうパターンは、今も根強く残っている。

例えば、村岡先生のところで行われていたという「平成14年度 セキュリティ技術者養成センター 実施計画」のシラバスを見てみても、

・情報セキュリティとは
・個人情報保護法と不正アクセス防止法 （※正しくは「禁止法」）
・暗号化技術
・ネットワーク高信頼化技術
・ウィルスとは
・ファイァウォール技術
・その他
・実験・実習： ウィルス検知、ファイァウォール設定、ログ解析など ・暗号技術
・個人認証
・PKI
・ディジタル署名
・ファイァウォール
・Kerberos
・ウィルス
・ログ解析（不正侵入検知）
・セキュァOS
・セキュァネットワーク
・セキュァアーキテクチャ
・その他

という構成になっていて、欠陥の存在への対応や、欠陥を作らない開発という視点が欠けているように見える。（「セキュア○○」のところに含まれているのかもしれないが。）

このような、ステレオタイプ化した「セキュリティ対策」のイメージは、都市伝説のごとくはびこっていて、払拭するのがとても大変だ。ひとつひとつ欠陥事例をおおやけにして、欠陥がそこらじゅうに存在するのだという現実を認識していただくしかないだろう。

ところで、EAL5のような「Common Criteria」で解決するのかということを考えたとき、いまひとつ希望が持てないのは、コストと時間がかかりすぎて敬遠されるのではないかということと、本当に例えば「乱数表をログイン時に使う」という脆弱点を指摘できるのだろうかという疑問だ。ISO 15408には、具体的なセキュリティ対策項目がリストアップされているわけではないと聞く。

日本では政府系のガイドラインが多数ある。

• 情報システム安全対策基準, 通商産業省, 昭和52年制定 平成7年8月改定
• コンピュータ不正アクセス対策基準, 通商産業省, 平成8年8月
• 情報処理サービス業情報システム安全対策実施事業所認定基準, 通商産業省, 平成9年7月
• 情報通信ネットワーク安全・信頼性基準, 郵政省, 昭和62年
• 地方公共団体コンピュータセキュリティ対策基準, 自治省, 昭和62年7月
• 情報システム安全対策ガイドライン, 総務庁, 平成元年9月
• 情報システム安全対策指針, 警察庁, 昭和61年1月制定 平成9年9月改定 平成11年11月改正
• 金融機関等がＶＡＮシステムを利用する場合の安全対策基準, 金融情報システムセンター, 昭和62年3月

日本にはこうしたガイドラインの方が向いているという気もしないでもない。しかし、このように既存のものは、5年〜15年も前のもので、あまりに古びている。今日の、インターネットで、サービス提供者とユーザとが直接対面するシステムには、対応できていないだろう。

■ メールマーケティングとプライバシーを両立させる方法

CNET Japanに「アフェリエイトが好調な三井物産、今度はEメールマーケティングで攻勢」という記事が出ていた。引用すると、

miemsの特徴は、各URLのクリック率や購買行動へ結びついた割合（コンバージョン率）が図れるほか、HTMLメールであれば開封率も計測できる点にある。さらに、各利用者がどのURLをクリックし、どんな商品をどれだけ購入したかというデータも追跡できるという。

とある。これはべつに「miems」特有の特徴ではないだろう。他でもやっていることだ。それはともかく、続いて

最初の3回に送信したメールに反応したユーザーと反応しなかったユーザーに分け、内容の異なるメールを送信したところ、大きな効果が出たという。過去3回のメールに対して何らかの反応をしたレスポンスユーザーには、反響の高かったDVDを前面に押し出したメールを配信し、何の反応も示さなかったノンレスポンスユーザーに対してはプレゼントを前面に押し出した内容のメールを配信したのだ。

とある。

この事例では、Webバグ（Web盗聴器）が、統計情報を得るためではなく、一人一人の購読者の行動を追跡し完全に区別するために使われている。プライバシーポリシーがどうなっているか、また、購読者がその事実を認識しているかどうかが興味深いところだ。

プライバシーポリシーを見てみたいのだが、どこの事業者でサービスしているのだろうか。とりあえず、miemsを提供する三井物産株式会社ITマ−ケティング事業部インタ−ネットサ−ビス事業室Ｅマ−ケティング事業推進チ−ムのプライバシーポリシーを見てみたが、Webバグ（Web盗聴器）に関する記述はない。個人情報の定義が

お客様を識別できる情報で、お客様の氏名、生年月日、年令、電話番号、メール・アドレス、住所、勤務先、家族構成、趣味、嗜好、クレジット・カード番号、銀行口座番号、お客様が購入された製品やサービスに関する情報、お問合せ等の情報でこの内の1つ又は複数の組み合わせにより、お客様個人を特定することのできる情報を意味しております。

となっているので、Webバグ（Web盗聴器）に仕込まれたID付きのWebアクセス記録は、ここで言う「個人情報」に該当することになる。その収集にあたって、「個人情報の収集と利用」で、

個人情報を直接収集する場合は、その利用目的を明確にし、お客様の承諾を得て必要な範囲の個人情報を収集し、その目的の範囲内でのみ利用いたします。

とあるので、メールマガジン購読申し込みの画面には、「Webバグ（Web盗聴器）を使用してお客様の嗜好を収集しています」といった説明があるはずだ。

本当にきっちりとその説明をできるのだろうか。一人でも客を逃がしたくないと考えれば、意図的にわかりにくくプライバシーポリシーを書きたくなるのが人情というものだ。プライバシーポリシーでは、この種の問題は本質的に解決されないように思える。

プライバシーを維持したまま、一人一人の顧客を追跡してマーケティングに活かすことは、技術的に可能ではなかろうか。

メールアドレスごとに異なる内容のメールを送るとなると、個人を特定しないわけにはいかなくなってしまうので、メールの内容はまず全部同一とする。メールでは、6月6日の日記に書いたように、新着情報が出たということだけを伝え、Webサイトへ誘導する。そのWebサイトは、永続型cookieを発行してアクセス者を分別するが、一切のユーザ登録機能を持たないようにして、cookieからそれが誰であるかは特定不能にする。メールマガジンの登録も、cookieと結びつかない別ドメインで行うようにする。そしてそのWebサイトでは、アクセス者がどのリンクをクリックするかなどを記録し、過去の動向に応じた広告を表示するようにする。つまり、匿名のままユーザの行動に応じた広告を表示する。ここで、同じドメインを複数のショップ用に共用すると、バナー広告と類似のプライバシー懸念が生じてくるので、ショップごとに別ドメインを使うようにする（ショップのドメインを使えばよい）。こうすれば、真に必要な最低限の情報しか蓄積されない。

こうすることで、CNET Japanの記事に書かれていた、「顧客の反応の違いによって内容の異なるメールを送信する」のと同等のことを実現しつつ、それが誰であるか（どのメールアドレスの人か）を特定せずにおくことができるだろう。

「購買行動へ結びついた割合」を求めるには、購入画面に広告ページのcookieが送られないようサブドメインで分けた上で、購入完了時に広告ページにアクセスを発生させて記録（誰だかはわからないがその人が購入したということを記録）すればよい。（ただ、同じIPアドレスからのアクセスを同じ人とみなすことで、結びつけることはできてしまうなあ。広告ページ側では一切のIPアドレス記録をとらないようにするしかないかな。）

■ 問い合わせをうまくやるには

松阪大の奥村先生が、アップルコンピュータにWebバグについて問い合わせをなさったそうだ。しかし、回答は、

このような匿名による情報収集につきましては、製品登録情報等、その内容が直接的に個人の特定に結びつくものではないため、プライバシーポリシーの内容の範囲外と考えております。

となっている。いかにもありがちな展開だ。

これは問い合わせ手法がうまくない。私なら次の手順で問い合わせる。

1. プライバシーポリシーに書かれている、「アップルは特定の項目に対するお客様の興味を知り、アップルとお客様とのコミュニケーションをスムーズにするためにURLを通じたアクセスを行っています」が、具体的に何のことを指しているのかを質問する。
2. 内容を教えてもらったら、それがプライバシーとどう関係があり、なぜプライバシーポリシーに書く必要のあることなのかを尋ねる。このとき、「お客様のためにプライバシーポリシーにきちんと示している」のだとアップルコンピュータ側が胸を張って答えられるよう、誘導する。
3. プライバシーポリシーに書く必要性を教えてもらったところで、HTMLメール版のマガジンでは、URLをクリックしなくてもIDが送信されることを指摘し、プライバシーポリシーが「お客様がそれらURLをクリックされると」と状況を限定しているのが誤りであることを指摘する。

一般に、単刀直入に問題点を指摘すると、相手は「問題ない」とする言い訳から考えてしまう。言い訳の矛盾を後から指摘しても、「今回頂きましたご意見は課題として検討させて頂きます」で終わってしまうだろう。そうさせないためには、まず、相手が今何をやっているのかを相手自身に考えさせ回答させた上で、間違っている点を指摘するのがよい。

■ 「ハッカー甲子園」なのか「セキュリティ甲子園」なのか

昨日、「16歳の高校生です。よろしければセキュリティ甲子園延期について質問に答えてください。」という表題のメールが来た。その内容は、スラッシュドットでセキュリティ甲子園の延期を知ったとのことで、「高木様がセキュリティ甲子園を延期するように経済産業省のほうに言ったということを耳にしたのですが」というのだ。なんでここで私が出てくるのだ？

スラッシュドットを見に行ってみると、「セキュリティ甲子園が来年に延期」というストーリーがあり、「高木ひろみちゅ先生のゴネゴネ攻撃らしいですが」などと書かれている。

「ゴネゴネ」の意味がわからないが、私が「経済産業省に働きかけをしたか」ということで言えば、そのような事実は一切ない。

そもそも、産総研の研究員に経済産業省の役人さん達がそうしたことで相談してくるということはまずもってない。関係機関であるはずでありながら、両者はそういう関係にないのだ。同様にこちらから役人さん達に働きかけようと思っても、そのようなチャネルは存在しない。

それ以前に、経済産業省に働きかけするほどまでにセキュリティ甲子園は実施してはならないとする考えが、私にあるわけでない。

スラッシュドットによると、話のソースは東京新聞の記事なのだろうか。だが、私は、これとは異なる考えを持っている。せっかくなので、私の意見を書いてみるとする。

まず、世の中のセキュリティ対策を実のあるものとするにあたって、優先しなくてはならない課題と私が常々考えてきたのは、一般の人々の頭の中から「『ハッカー』という虚像」を払拭することだ。

このことについて、昨年9月の日経ネット時評で次のように書いた。

「ハッカー」という虚像

これらのファイル流出事故の報道では、たびたび、「不正侵入されたのが原因」とする当事者の言い分が伝えられた。ある事例では、「何者かが暗証番号がなくてもアクセスができるようプログラムを書き換えたらしい」という具体的な原因を示唆するコメントも伝えられた。...(略)

では、なぜそのような知識に欠ける担当者が、「プログラムを書き換えられた」という発想を持ってしまうのだろうか。これは、世のかなり広い層の人々の間に、「ハッカー」という得体の知れない虚像が広まってしまっているためではなかろうか。「ハッカーは人知を超えた高度な技術で攻撃してくる」、「ハッカーなら何でもできてしまう」といったイメージを持つ人は多いはずだ。「ハッカーの攻撃を防ぐことは無理」と端からあきらめている人もいるかもしれない。

なぜこのような虚像が生まれてしまったのか。ひとつにはこれまでのマスメディアの報道に原因があったと筆者は見る。しばしば新聞紙面を踊る「ハッカー攻撃」、「ハッカー被害」などの文字。「ハッカーとは元々は高度なコンピュータ技術を持つ人の尊称だ」とする意見もある中で、日本語の文法的にも奇異な「ハッカー被害」などという言葉が繰り返し使われるのは、それ以外の表現手段を報道側が持ち合わせていないのであろう。「他の言葉を使っても読者が理解できないからだ」という理由もあるかもしれない。しかし、いずれにしても、「何だか実態は不明だがとにかくいわゆる『ハッカー』の仕業」という程度の意味で使われている。こうしたことの繰り返しが、消費者に、企業担当者に、そしてマスメディア自身にも、「ハッカー」という虚像を当たり前のものとして定着させてしまったのではないだろうか。

そのおかげで、昨今では、何でもハッカーの仕業とすれば責任を免れられるという思い込みが生まれているようにも思える。５月の漏洩事故では、...(略)

情報セキュリティー侵害の実態とマスメディア報道, 日経ネット時評

「ハッカーの攻撃を防ぐことは無理と端からあきらめている人」については、実際に思い当たる人物がいて書いたものだ。私があるWebアプリケーションの発注者側の立場にいたとき、元受業者に対して、ずさんな欠陥ぶりを指摘したところ、営業担当者は苛立ちながらこう言い返してきた。「お客様はどのレベルまでのセキュリティをお求めですか？」と。指摘した欠陥は、アクセス制御が全くなされていない最も初歩的なパターンだったのに、その営業は、私が特殊な能力を持っているからそれができていると理解したようだった。

同様の発想は金融機関にさえ見られる。以下のように、ハッカーによる攻撃は不可抗力であり、責任は負えないとしているのだ。

• 群馬県信用組合インターネットバンキング Q & A

  Ｑ インタ−ネットを利用するとセキュリティが心配なのですが？

  Ａ ＳＳＬ（128bit）を採用し、お客様の重要な情報を保護するために世界標準のインターネット暗号技術を使用しセキュリティ対策を行っています。

  しかし、インターネット上の内容は完全な専用線接続と異なり、技術的に他(サイバーテロ：ハッカー、クラッカー等の不可抗力)に漏洩する危険性はあります。

  当組合では当該情報セキュリティに関し責任を負いかねますのでご了承ください。

• 東和銀行インターネットバンキング

  ○ご注意

  当行では、お客様が入力されました店番・預金口座番号・暗証番号等は機密面での配慮を、最新技術により最高度にセキュリティを確保しております（ＳＳＬ１２８ビット暗号化や電子認証等）が、インターネット上の内容は完全な専用線接続と異なり、技術的に他（サイバーテロ：ハッカー、クラッカー等の不可抗力）に漏洩する危険性はあります。当行では当該セキュリティに関し責任を負いかねますのでご了承ください。

セキュリティ対策として真に必要なのは、個別に作りこまれたシステムの脆弱性監査であるわけだが、それにかかるコストの価値を評価しない経営者が多いために、監査業の需要は十分に喚起されていないという話をよく耳にする。監査の価値を感じない理由のひとつに、「どんなに対策したってハッカーには歯が立たない」という思い込みもあるのだろうと、私は考える。

だからこそ、「ハッカーという虚像」をまず払拭しなくてはならないのだ。

欠陥のあるシステムはザラに存在し、それを不正に利用する手順がいとも簡単なものであることが少なくない。「侵入」は誰にだってできる。神業ではないのだ。単に手順を知っているか知らないかでしかない。

「高校生ハッカー」と聞いて一般の人は何をイメージするだろうか。おそらく、「若人の柔軟な頭だからこそハッカーぶりを発揮できる」とイメージするだろう。

セキュリティ甲子園の開催が発表されたとき、新聞でどのように報道されたかを見れば、一般の人が、ハッカーにどのようなイメージを抱いているかを窺い知ることができる。たしか最初の報道は朝日新聞のこの記事だった。リンク先は既に消えているので、同じ記事と思われるものを探してみたところここにあった。引用すると、

ハッカー顔負けのコンピューター知識や技術を持った若者を発掘し、優秀な開発者に育てる――。 こんな狙いから経済産業省はこの夏「第１回セキュリティー甲子園」を開く。全国の高校生、専門学校生の２０チームが、お互いのサーバーに侵入する腕前を競い合う。優勝者はコンピューター研究で有数の米カーネギーメロン大やダートマス大に留学させる計画だ。 ...

大会を通じて優秀な人材を集め、英才教育を受けさせることで、ソフトウエア産業の国際競争力をつけるねらいだ。

「ハッカーの甲子園」でサーバー侵入の腕競べ　経産省, 朝日新聞 5月23日朝刊1面

とある。

朝日新聞のIT関連記事は素人同然であるので、これが本当に経済産業省の考えを正しく表したものかどうか疑わしい。しかし、いずれにせよ、一般の人が「ハッカー甲子園」をこのように受け止めたという点が重要である。

そもそも、「セキュリティ甲子園」という名称なのに、どこの新聞でも「ハッカー甲子園」という表題で報道しているのが、なぜなのかを考えてみるとよい。朝日新聞と違ってITに詳しい記者もいる共同通信でさえ、「「ハッカー甲子園」８月開催へ 経産省、国主催は世界初」と報道している。専門家の集まりであるスラッシュドットジャパンでさえ、編集者がセキュリティ甲子園のことを指して「ハッカー甲子園」と書き、指摘されて訂正している。それでもなお、その編集者は「間違えた訳ではありませんが、指摘はもっともなので」と訂正している。専門家から見てもこれは「ハッカー甲子園」で間違いないのだ。

なぜこうもわざわざ名前を取り違えて扱われるかというと、「セキュリティ甲子園」という名前が、どうにも据わりの悪い名前からだろう。そもそも「セキュリティ」という言葉は非常に広範な意味で使われる言葉で、最低でも「情報セキュリティ甲子園」という名前にしないと正しくない。当然そのような名前は語呂が悪いので採用されない。最初から「セキュリティ甲子園」や「セキュリティスタジアム」という名前で考え出すはずもなく、意識的にであれ無意識的にであれ、最初に頭にイメージした名前は「ハッカー甲子園」であり「ハッカースタジアム」であるはずだ。「ハッカー甲子園」ではマズいことを認識しているから、代替名として「セキュリティ甲子園」ということになる。そのことは世間の人々に見え透いているから、いくら「セキュリティ甲子園です」と言っても、「ハッカー甲子園」と呼ばれてしまう。

「ハッカー甲子園」では何がマズいのか。「『ハッカー』という言葉はいろいろな意味で使われているから」という理由だけではなかろう。たしかに「ハッカー」は昔から多義的な言葉だ。ハッカー達はその多義性を楽しんでハッカーという名称を使ってきただろう。だが、「甲子園」という別の言葉と結びつくことで、多義性は失われ、セキュリティホールを突く技術を持つ者という意味に収束するのであり、言葉の多義性が理由ではなかろう。その競技が世間に批判されることを予想できているがゆえに、あくまでも「セキュリティ甲子園」でなくてはならないのだろう。

実際、セキュリティ甲子園で予定されていた内容を見てみると、

競技の実施に先立ち、情報セキュリティのルールやモラルについての有識者からのセミナーや、一線で働く企業の方々等とも懇談の機会を設けることにより、情報セキュリティに対するバランスのとれた理解や、セキュリティを守る現場についての認識を深める機会を提供します。

と、競技そのものよりもこうした点が重要だとする気遣いが見て取れる。

これが中止と報道されると、「防衛のためには攻撃の方法を学ぶのが不可欠だというのがどうしてわからないのか」といった反発の声が多数出ていた。「防衛のために攻撃方法を学ぶことが不可欠」というのは、独立した論理としては真であるが、次の必然性を説明するものにはなっていない。

• なぜ高校生に学ばせるのか
• なぜ講習会ではなく競技会なのか

なぜ高校生に学ばせることに世間が関心を持つかといえば、「ハッカーの養成は若いうちからやる必要がある」という思い込みがあるからだろう。主催者にその考えがあったかは知らないが、少なくとも朝日新聞はそのように報道している。

ハッカー顔負けのコンピューター知識や技術を持った若者を発掘し、優秀な開発者に育てる――。こんな狙いから経済産業省はこの夏「第１回セキュリティー甲子園」を開く。

大会を通じて優秀な人材を集め、英才教育を受けさせることで、ソフトウエア産業の国際競争力をつけるねらいだ。

「リナックスのように、革新的なソフトを開発するスーパーハッカーが、大会から生まれてほしい」と期待を込める。

「ハッカーの甲子園」でサーバー侵入の腕競べ　経産省, 朝日新聞 5月23日朝刊1面

高校生ハッカーが世間を騒がす事件がかつては多発していた。これは、頭の柔軟な高校生だからハッキングできたというわけではなく、社会性のない、あるいは失うものがない、もしくは、法やモラルに対する認識が不十分な者が犯しやすい行為であるがため、発生率が高いというだけだろう。たいていの成人の技術者は、侵入方法を知っているが、行使していないというだけだ。

そもそも、システムの開発に携わる技術者は、どういう欠陥を作ってはならないのかを知っている。知っていなければまともなシステムを作ることができない。

技術を全く知らない人達からすれば、テレビや携帯電話やコンピュータがどうして作れるのか不思議でならないだろう。作り方が全くわからない人からすれば、セキュリティホールを突くハッカーが天才のように思えてしまうかもしれないが、実際はそれとは違う。

正しいシステムの作り方や、正しいシステムの設定方法の習得は、知識の積み重ねであって、天才的センスを必要とするものではない。誤解を恐れずに極端に言えば、詰め込み型の教育で可能なことだろう。

ただし、ここまでの話は、既知のセキュリティホールを突いたり埋めたり、作らないようにすることの話だ。未知のセキュリティホールを見出すことには、独特のセンスが必要であり、若い人材を発掘することにも意義があるだろう。ただし、ここで言う「未知のセキュリティホール」とは、既知のパターンの未知の穴（例えば、製品に存在する典型的なバッファオーバーフロー穴など）のことではない。未知のパターンの穴のことだ。個別システムにおける設計上の弱点を探すのにも、独特のセンスが必要だ。

そうしたセンスを持つ人材を育てることは急務であるが、競技会というスタイルでそれを発掘するのは無理がある。少なくとも、「セキュリティ甲子園」の競技ルールは、そうしたセンスを引き出すものではないだろう。セキュリティ甲子園の概要には次のような競技だと説明されている。

(2) 事務局から提供される「安全なサーバー構築の手引き」を参考にして、実施日までに、このサーバーを可能な限りセキュアなものとするための設定を練習していただきます。

(3) 実施日には、当該サーバーは一度クリーンアップします。参加者は、練習の成果に基づき、再度、「安全なサーバー」を構築していただきます。自分のサーバーを守りきると同時に、他の参加者のサーバーの脆弱性を探索することによってポイントが得られます。相手方から自らのサーバーのセキュリティホールを探索された場合には、それを検出し、復旧させるスキルを試されることとなります。

このタイプの競技は、かつて存在したコミュニティ「電脳火消隊(Firewall Defenders)」で「運動会」と呼ばれていたもののように、日ごろ蓄えたテクニックを披露したり試すというお楽しみ会のためには適合しているが、人材発掘目的には無理がある。

毎日新聞の報道によると、

来年度は、セキュリティーを含めたITの幅広い分野を競技対象にする予定で、「与えられた制約条件の中で最高の性能を発揮するプログラムをオープンソースで開発するコンテストなど、技術の悪用が強調されにくい形」に変更される予定だ。

「セキュリティ甲子園」 悪評判で今年は中止, 毎日新聞

とあるが、それはもはや、普通のプログラミングコンテストであって、上に述べたセンスを有する情報セキュリティの人材を育成するものではない。後退しすぎだ。

私は、「裏をかくセンス」や「裏をかいて先回りするセンス」を磨いたり発掘する何がしかをやったらいいと思う。専門的な知識を前提とせずにこれらのセンスを引き出す、面白い競技は考えられないものだろうか。

このように、セキュリティ甲子園は必然性に欠けていたにもかかわらず、その一方で、世間の人々に「ハッカーという虚像」をますます増長させる結果をもたらした。朝日新聞の報道には、

学校の教師や専門家から「学校のセキュリティーが破られたら困る」「防衛庁がハッキングされたらどうするのか」などの抗議が相次いだ。

ハッカー甲子園、「犯罪誘発」と抗議相次ぎ断念 経産省, 朝日新聞

とある。こうした抗議は、（ある一面で）頓珍漢なものであるが、経済産業省がこのようなイベントを発表したことで、「やはりハッカーとは高校生から発掘しなくてはならないような天才で、不可抗力を生むものだ」という虚像が拡大した結果だろう。

この虚像の拡大はイベントを中止したところで消えるものではない。計画を発表した時点で虚像は拡大してしまった。

今後の経済産業省に期待したいのは次の点である。

• セキュリティホールを突く「ハッカー」は普通の技術者であり、超絶的な能力者ではないというイメージを常識化すること。
• 正しい防衛設定や、正しいシステム設計・開発の手順を定型化し、詰め込み型教育により、平均的な人材を大量に確保すること。
• 先端的セキュリティ技術者を育成するため、裏をかいて先回りするセンスを持つ人材を発掘すること。

「平均的な人材を詰め込み型教育で確保」というのは、なんともつまらないことのように思えるかもしれない。「セキュリティ技術者を「憧れの職業」にするには？」にあるように、「子どもの夢にはならないセキュリティ技術者」という問題を解決したい中で、このように「詰め込み型で」とするのは、夢を打ち砕く話のように聞こえるかもしれない。だが、だからといって、「ハッカー（穴を突ける人）＝憧れの的」であってはならないのだ。この記事の中でキムタクの話が出てくるが、これは基本的にはジョークであるが、あり得ない例を示すことで、「カッコいい」では解決しそうにないことを示唆した発言でもある。

■ 追記

7月7日の毎日新聞の記事にはこう書かれていた。

セキュリティ甲子園に関しては、高校生による「ハッカー甲子園」になりかねず、教育上の疑問を上げる声もあるが、同省では「守る技術がしっかりあることが前提で、攻撃だけでなく、全部の要素が入っている。イベントを通じて、セキュリティーを守るということはどういうことかを分かりやすく説明したい」としている。

経済産業省、高校生らの「セキュリティ甲子園」開催, 毎日新聞

また、現在のセキュリティ甲子園事務局のページには、次のように書かれている。

競技会当日には、専門家からの情報セキュリティに関するルールや心構えについてのレクチャーなど、健全な情報社会を構築する担い手を育むための教育プログラムも予定しておりました。

「セキュリティ甲子園」の延期について, セキュリティ甲子園事務局

つまり、参加者には心構えをきちんと教え込むから問題ないということを説明しているのだろう。しかし、参加しない者にはそのレクチャーは届かない。参加しない者には、「日本政府が高校生向けハッカー甲子園を主催するほど、ハッカーとはそういうものなんだ」という理解だけが残る。

■ 追記2

「専門家の集まりであるスラッシュドット」と書いたことについて、28日の「k3cの日記」などで、「そうではない」と話題になっている。「専門家」という言葉の定義にズレがあったようだ。朝日新聞の「ネット最前線」がコンピュータ利用の素人と言いたいのに対比させるために、スラッシュドットをコンピュータ利用の「専門家」と表現したのだった。撤回して、「ハイテクオタクの集まりであるスラッシュドット」としましょうか。これに対比するなら朝日新聞のネット最前線は、「デジタルデバイドの負け組」といったところか。

ところで、最初の朝日新聞の報道を読み返してみると、改めてそのデジタルデバイドぶりにあきれてしまう。

ハッカー顔負けのコンピューター知識や技術を持った若者を発掘し、優秀な開発者に育てる――

「ハッカーの甲子園」でサーバー侵入の腕競べ 経産省, 朝日新聞 5月23日朝刊1面

「ハッカー顔負けの」ということは、朝日新聞ネット最前線の人達からすると、「この世で最高のコンピュータ技術を持つ者はハッカー（侵入技術を持つ者）である」という認識らしいことがうかがえる。ここで「ハッカー」が「寝食を忘れてソフト開発などに没頭する人」のことを指しているとは思えない。そうならば「顔負け」とは書かないだろうし、「開発者に育てる」と続けないだろう。「ハッカーという虚像」を払拭するには、こういうデジタルデバイド新聞に梃入れすることから始める必要がありそうだ。まずは、いかなる意味であれ「ハッカー」という言葉の紙面での使用を禁止したいが、どうにかならないものか。

それにしても、どうして最初の報道は朝日の単独だったのだろう？ 私なんぞは、こういったレベルの新聞社から取材が来るかもしれないと思うと、徴兵の召集令状を待つかの如くガクガクブルブルしてしまうのだが。

ところで、

来年度の実施に当たっては、例えば、与えられた制約条件の中で最高の性能を発揮するプログラムをオープンソースで開発するコンテストなど、

「セキュリティ甲子園」の延期について, セキュリティ甲子園事務局

この場合の「オープンソースで開発する」というのは何を意味しているのだろう？ プロプライエタリなプログラミングコンテストってのがあり得るのか？

■ 追記3

たしか最初の報道は朝日新聞のこの記事だった。リンク先は既に消えているので、

と書いたが、別の場所にまだ掲示されていた。「ハッカー」の用語説明がついている。

• 朝日新聞 ネット最前線, 「ハッカーの甲子園」でサーバー侵入の腕くらべ　経産省

■ 高度バーチャル化社会における墨塗りテクノロジー

総務省総合通信基盤局電波部電波政策課が7月3日に発表した、情報通信審議会電波政策特別部会の「「電波政策ビジョン(素案)」に対する意見募集の結果」の意見提出者一覧に、北陸無線データ通信協議会の小西氏の意見書(PDF)が置かれている。このPDFファイルだが、3ページ目と4ページ目に墨塗り部分がある。ここで、Acrobatの検索ボタンを押して「ソフトバンクBB」、「株式会社メルコ」で検索してみるとどうだろうか。

その段落の下には、

※事務局注：個別の企業名につきましては、削除させていただきます。

とあるが、削除せずにフォントの背景色を黒にしたといったところか。このケースではたいして問題でないが、以下のような先例もあるだけに、行政文書の墨塗り方法は、やはり、ガイドライン化と、セキュリティポリシーへの盛り込みが必要ではなかろうか。こういうのはISMSには含まれているだろうか。

• 岩手県 情報公開の請求者名を誤ってHPに表示, 毎日新聞, 2002年5月
• 岩手県が氏名を「非表示」にしただけで個人情報を公開, スラッシュドット, 2002年6月

  朝日新聞の記事から引用すると、「担当者が表計算ソフトで開示状況の一覧を作る際、氏名部分を削除せずに「非表示」の操作をしただけだったため、ＨＰにアクセスした人が画面を操作すれば、再び「表示」に切り替えられた」のだそうだ。...

  ---

  操作なんかしなくても丸出しなんですけど (スコア:4, 参考になる)
  Anonymous Coward のコメント: 2002年06月02日 3時19分

  今時の Excel は、ファイルを .html で保存しても、もう一度 Excel で開けばまた元のワークブックに戻るようになってる。

  数式も振り仮名も非表示セルのコンテンツも、全部 .html 中に保存しているんだ。元データなんかいらない。

  だから非表示にしたデータは、.html をExcel で開いて再表示すれば何の苦労も無く読み出せる。むしろ Excel なんか使わなくても、html ソースを見れば丸出しっす。

• 大道芸人154人分の個人情報流出 東京都のホームページ, 毎日新聞, 2002年10月

  都によると、25日から公開された一覧表には（1）個人またはグループ名と人数（2）大道芸のジャンル（3）連絡先――が掲載されていたが、一定の操作をすれば「非表示」となっている本名、職業、住所などの情報が閲覧できるようになっていた。

• 『ニューヨーク・タイムズ』紙サイトがCIA諜報員の氏名を公開, WIRED NEWS, 2000年6月

  ニューヨーク・タイムズ紙は、200ページにわたるPDFファイルの中に登場する諜報員たちの氏名を黒く塗りつぶしていた。ところが、ダウンロード中にページを「フリーズ」させると、下に書かれている名前がはっきり読みとれたのだ。

• 『カーニボー』監査チームのメンバー情報が漏れる, WIRED NEWS, 2000年9月

  26日(米国時間)、司法省はオンラインに51ページのPDFファイルを掲載した。この文書の中では、メンバーの氏名、電話番号、それに米政府の秘密情報取り扱い許可といったプロジェクト情報が、太い黒線で消されていた。
  しかし結局のところ、この情報は「削除」などされてはいなかった。米アドビシステムズ社が提供するソフトウェア――あるいはテキストエディターとほんの少しの時間――があれば、誰でも元のままの文書を見ることができるのだ。

■ はてなダイアリーへの要望

5月12日の日記に頂いたコメントによれば、「はてなダイアリーへの要望」というキーワードをこのように本文中に書いておくと、運営者の目にも触れるらしい。

編集画面に表示される「リンク元」の数には上限があるらしい。350件ほどを超えるとそれ以上表示されなくなる。ちょっと寂しい。個人的にはアンテナのリンク元は非表示にしたいところ。だけど、アンテナかどうかはアドホックにしか判定できないだろう。とりあえず、はてなアンテナだけでも非表示にする機能は加えられないものだろうか。

あと、既に多数出ている要望と思われるが、「/~foo」と「/%7Efoo」が別々に集計されてしまっているのは簡単に解決できるのではないか。

■ 村井先生の講義で取り上げられていた

6月30日に行われたという村井純先生の講義「自律分散協調論」第11回（テーマ:「安全」）の中で、私の4月の日経ネット時評の件を取り上げていただいていたようだ。（35枚目のスライドより。）ビデオ映像もある。

RFIDタグの話題は31枚目のスライドから始まっている。「所有者の意思に反して読むことができる」、「安価な市販の装置でだれでも読むことが可能」といったことから書かれている。

37枚目のスライドのところで、「プライバシーを定義しない」とある点（今掲載されているスライドには書かれていないので、後で修正されたのかな？）について、論点が揺れていたようだ。（ビデオ映像。）

「プライバシーを定義しない」というのは、ネット時評で冒頭に書いたことなのだが、村井先生はネット時評の最後の部分のことと理解なさったようだ。講義の中で村井先生は、

技術者がプライバシーをきちんと定義して、それに対応する技術を作って、それからやれと。だけど、「おまえらが（世論が、法律が、あるいは業界が）プライバシーを定義してくれないから、ちゃんとした技術を俺たち（技術者）は作れないんだよね」と、そういう言い訳はすんなよなと。というのがいつも高木さんの言っていることだと僕は思います。

とおっしゃっている。たしかに、「そういう言い訳はすんなよ」という点は、ネット時評の最後の部分で述べた。だが、「プライバシーをきちんと定義して、それに対応する技術を作る」というのは、ちょっと私の主張とは異なる。

プライバシーを先に定義してしまうと、それが硬直した基準となってしまって、時に免罪符として使われてしまう心配がある。たとえば、業界団体でプライバシーを定義しようとすれば、できるだけ狭い定義としたいという力は働くであろう。固定IDについて、「これはランダムな番号であり個人を特定するものではない」という定義を先に決めて、それに準拠したものだとしてシステムが作られるといったことが起きてしまうだろう。36枚目のスライドに紹介されている事例はまさにそのパターンだったのではないか。

私の考えは、技術を議論する上では、プライバシーを定義することは必須ではなく、様々な条件の下でできる限りプライバシーを広く想定して、（コストとのトレードオフを含めて）可能な限りの技術的解決策を考えておくことが重要というものだ。現在置かれているスライドは、そのようにまとめなおされているようだ。

先日、東工大のシンポジウムの席でも、会場から、暗号研究に携わる研究者から、「プライバシーあるいは個人情報とは何なのか？」という質問が出た。やはり、技術者にはそれを明確にして欲しいという思いがあるようだ。その質問には、上のように「（技術の議論では）定義しないでおくべきである（法律の議論では定義せざるを得ないが）」と答えた。