高木浩光＠自宅の日記

■ RFID児童登下校管理システムのクオリティは安心安全ソリューションってレベルか

2004年から2005年にかけてたびたびNHKニュースやテレビ東京で華々しく宣伝されていた、RFID児童登下校通知システムだが、去年あたりから悲惨なことになっていたようだ。

2006年8月13日の日記からリンクしていた個人ブログを再び見に行ってみたところ、その後こんなことになっていた。

• 「情報科な日々のつれづれ」の「ICタグ」カテゴリ

朝、7:36。
ICタグによる登下校システムの停止。（略）

事務所の電話は、鳴りっぱなし。
何とかならないかといわれても・・・・。

とにかく富士通に対応してもらうまで待つしかない。
原因は、どうやら、メールサーバの停止らしい。
7:36に最後の送信をしてから、停止したらしい。
それ以降に登校した子どもには、メールが送信されていません。（略）

27 September ご迷惑をお掛けしました。, 情報科な日々のつれづれ

メールが届くことで「安心」するシステム。子供の身に何かあったときはメールが届かないことで知らせるというシステム。よって、システムトラブルが起きると、「子供に何かあったのか」と保護者からの電話が殺到する。そういうシステムデザイン。

ICタグによる出欠管理システム。
昨日は、登校メールが止まってしまいました。 （略）

前回、不具合があったのは、9月。
その時の症状と、素人目に見れば同じ。

前回の不具合の際に、富士通には対策を指示したにもかかわらず、同じようなことが再び。
その時も、明確な原因にたどり着くことは出来なかったらしい。
多分、今回も同じ。

だからといって、何の報告もないというのは、どういうことだろうか？（略）

共同開発ということでこのシステムを育ててきた。
しかし、「出来上がってしまった」、いまでは、富士通にとってはどうでも良いことのようだ。

何が問題かを、運営を続けながら見守っていかないといけないのに・・・。
子どもの命、ということに関わっているという認識が、富士通にはないとしか思えない。
人として、最も大切なことに関わりもっているという意識の欠如としかいいようがない。（略）

06 December メール停止, 情報科な日々のつれづれ

こういうトラブルが何度か起きれば、保護者は「メールが来ないのはまたシステムトラブルなんだろうな」と思うようになり、「安全対策システム」としての意味を成さなくなる。（なんてことは、はじめから予想されたことだろう。）

（略）今月に入って2回目。
ICタグのために、時間が失われる。

どんなに「完璧」なシステムでも、それを動かすのは人。
運用していくのは、人。 （略）

今回は、これまでの原則を根本から覆すような、とんでもない問題。
当の富士通は、そんな意識は全くない。
危機意識が薄弱。（略）

それに関わる人の懸命さが見えれば、何も言うことは出来ない。
一生懸命な姿があれば、仕方がないことなのです。

あまりに安易な発想が、今月、2回目の不具合を招いた。
1回目の不都合だって、9月に「誠意」をもって対応していれば、起きなかった。
同じことが起こることを、手をこまねいて見ていたとしか思えない。
今回も、不都合が起こることは予想できながら、事前に対処しなかった。（略）

明日からどうするか？

その対処だって、何の具体案も出さない。
出てこない。
セキュリティ上問題はあるけど、という前提では、代替案になるはずがない。
それしか思いつかないようだから、何度も、同じようなミスを犯すに違いない。（略）

良いものを作ろう。

そういう創造力を失った人たちと、一緒に何かをするのは、本当に辛い。
そんな人たちとは、一緒に進んでいけない。
気持ちは、完全に破綻している。 （略）

13 December 虚しく時間は・・・, 情報科な日々のつれづれ

「どんなに「完璧」なシステムでも」というが、こんなのが完璧なシステムと思っていた人がいたのだろうか。インターネットメールで通知するなんて。そんなことははじめからわかっていたはずのこと。

「セキュリティ上問題はあるけど」という前提の代替案というのは、何だろうか。Windows Updateを止めるとか、そういう系統の話か？

「良いものを作ろう。そういう創造力を失った人たち」……どんな部隊なんだろう？

（略）ICタグ、アクティブ型のICタグで、いろいろな面がよくなると思っていた。
自分にとっては、負担でしかないかもしれない。
負荷ばかりがかかって、何のためにやったかのが、まったくわからない。 （略）

14 December 心身共に限界間近, 情報科な日々のつれづれ

ICタグによる出欠管理システム。
再び、メール送信がうまくいきませんでした。
保護者の方には、大変、ご迷惑をおかけしました。
原因は・・・。

どうやら、Bフレッツの障害。
まだ確定には至っていませんが、原因として、一番可能性が高いのは、Bフレッツ。（略）

傷口を広げたのは、証明書の手続きミスで、web上でデータ確認ができなかったことにあることは言うまでもありません。
それさえできれば、対応は、もっと簡潔にできたはず。
そう言う意味で、改めて、富士通のミスの大きさを実感していただきたいのです。

その点で、富士通の罪が消えることはないのです。（略）

20 December メールが止まった, 情報科な日々のつれづれ

「証明書の手続ミス」って何だろう？ SSLサーバ証明書の期限を切らしたのだろうか。

ICタグの不都合。
メール送信のソフトウェアがおかしいということで、バージョンアップ。
確かに、ソフトウェアが止まることはなくなったようなのですが…。

送信が、遅い。
考えられ無いくらい遅い。

バージョンアップは、検証の上ですることは、確認済み。
ところが、聞いてびっくり。
なんと、動作検証をしていない。（略）

もう少し真剣にやって欲しいなあ。
やってもらわないと困るんですよねえ。
保護者の方々は、登下校の通知メールにかなり神経を尖らせているのです。（略）

もはや、我々が当初、出欠管理として意図したことよりも、登下校の安全確認という面の.方が重要度を持ってしまっているのです。
このことを、何度、説いてもわかってもらえない。
どんな風に話しても、理解して、それを行動に移してもらえない。 （略）

10 January 初日から, 情報科な日々のつれづれ

「学校での出欠管理用だから、保護者への通知の完全性は保証していない」とか、そういう説明を受けているのかなあ……。

突然、午後に打ち合わせ。
ICタグの登下校システム安定に向けた話し合い。

提案された内容に具体性がない。
なんともお粗末な内容。（略）

31 January 突然の打ち合わせ, 情報科な日々のつれづれ

なんというか、まあ、そういう業者いますね。ときどきですが。

■ 銀行のフィッシング解説がなかなか正しくならない

みずほ銀行のトップページを訪れたところ、2月26日付けで「セキュリティガイド（4コマ漫画）を掲載いたしました」というお知らせが出ていた。見に行ってみると、「インターネットバンキング編」という解説があり、「 「フィッシング詐欺」に遭わないためには？」というページがあった。この出来が非常に悪く問題がある。

図1: みずほ銀行の「セキュリティガイド」（2007年2月）

まず酷いのが、「電子メールが本物かどうかは、送信元アドレスで確認できます。」という完全に誤った解説だ。

「……@mizuhobank.co.jp」というメールアドレスを From: に書いてメールを送ることは誰にでも可能なわけだが、そんなことさえ知らないド素人に、こんな大事な解説の原稿を書かせる神経が理解できない。セキュリティ専門のコンサルに一読してもらうだけで防げるレベルのミスなのに、なぜそれをしないのか。

URLの確認方法として、「URLには…mizuhobank.co.jp…という文字列が含まれています。」というのも酷い誤りだ。たとえば、「https://www.mizuhobank.co.jp.example.com/」というURLだって mizuhobank.co.jp という文字列が含まれているが、これは偽サイトだ。そんなことがわからないって、どんな人が書いてるの？ 2006年8月5日の日記にも ebay.comの偽サイトの実例を書いていたように、現にそういう偽サイトが出ている。

加えて、フィッシング防止の話なのに、アドレス確認よりも先に SSLの話をするのも誤解を招く。偽サイトだって https:// のページにするだろうし、正規に取得したSSLで南京錠アイコンを出す偽サイトを作ってくる現実があるというのに、こんな解説じゃ、「https:// なら大丈夫」とか、「南京錠があるなら大丈夫」という誤解を招く。あくまでも、アドレスの確認が先で、加えて南京錠（もしくは https://）の確認だ。

調べてみると、全国銀行協会の解説コンテンツ「金融犯罪の番犬「BANK-KEN」の 金融犯罪にご用心」というものがあった。「フィッシング詐欺の防止策」という解説があるが、これの出来も悪い。みずほ銀行はこれの影響を受けている可能性がある。

図2: 全国銀行協会の解説「フィッシング詐欺の防止策」（前半）

「送信元のメールアドレスを確認してください」と書かれている。電子署名付きならともかく、普通のメールのメールアドレスなんか確認したって駄目だ。よく読めば、この文章は「メールアドレスで本物と確認できる」とまでは書いてないわけだが、みずほ銀行はこれを手本にして「送信元アドレスで確認できます」とまで書いてしまったのではないだろうか。

続く部分も間違っている。

図3: 全国銀行協会の解説「フィッシング詐欺の防止策」（後半）

「各銀行の電子証明書を確認してください」として、「金融機関名を確認」とあるが、図に示されているものは金融機関名じゃない。ホスト名だ。

図の例からして金融機関名になってないのに、書いてておかしいと思わないかな。セキュリティ専門のコンサルに査読してもらうだけでこういうミスは防げるのに、なぜしないのだろう。

全銀協のサイトを見に行ってみると、3月29日付で、「なぜ？どうして？どうしたらいいの？−銀行Ｑ＆Ａ−」というパンフレットが発行されたとある（ニュースリリース）。そこに「Q8.金融犯罪を防ぐには、どうしたらいいの」(PDF)というページがあり、フィッシングの解説もある。

ここには、「送信元のメールアドレスや指定されたホームページのアドレスを確認して、少しでもおかしいと思ったら、金融機関に問い合わせる。」と書かれている。この文章ならば、字面上間違いは書かれていないことになるが、どうやったらその「確認」とやらができるのかは説明されていない。

ちょうど先週、勤務先の仕事として「安全なWebサイト利用の鉄則」というコンテンツを公開した。これは、まさにこういった解説を書く方々向けに、正しい解説を書くための考え方を解説する目的で書いたものだ。

• 安全なWebサイト利用の鉄則, 産業技術総合研究所 情報セキュリティ研究センター, 2007年3月23日

  どうやってWebサイトを安全に利用するか、その手順のことはあまり広く知られていないようです。技術者達の間では暗黙の了解となっていることですが、市販のパソコンの取扱説明書には書かれていませんし、学校の教科書にも書かれていません。最近では行政機関や企業からフィッシングに注意を呼びかける文書が発表されることがありますが、あまり正しく解説されていないのが現状です。

  この解説は、Webサイトを安全に利用する簡潔な手順を示します。無用で余分な確認手順等は排除しています。必要な手順のみを示します。

  想定する読者： 利用手順をユーザに説明する方、サイトを設計する方

ドメイン名を利用者が覚えることがまず基本であり、ドメイン名を見分ける方法、ドメイン名を覚えきれないあるいは見間違えそうな場合でも、ブラウザの機能を使って機械的に見分ける方法があること、ドメイン名をまだ知らないときにサーバ証明書の内容を確認するのだということ、サイト運営者はドメイン名を周知することが肝要であることなどが書かれている。

FAQも用意していたが、追加しなければならない項目があるようだ。

Q7: メールが本物かどうか確認する方法を説明しないのはなぜですか？

他の銀行にもおかしな解説が蔓延しているのではないかとちょっと調べたところ、新生銀行に別の杜撰な解説があった。

図4: 新生銀行「しっかり知って、しっかり守る 実際の金融犯罪事例と対処法 1.フィッシング犯罪とは？」

ステータスバーなんか確認に使っちゃ駄目だ。ステータスバーというのはJavaScriptでどんな内容でも表示できる場所だ*1。このFAQも必要そうだ。

Q8: リンク先にジャンプする前にリンク先URLを確認する方法を推奨しないのはなぜですか？

というか、そもそも、「フィッシングかな？怪しい！と感じたら、そのアドレスを注意深く確認してみましょう」じゃねーよ。怪しけりゃ確認するまでもないし、怪しいと感じないときに確認することが肝心だってのに、何言ってんの？ お祭り見物気分で解説書くな。

■ IE 7日本語版のEV SSL証明書表示はベリサイン従業員も混乱する

EV SSLサーバ証明書の日本での発行が各社で開始された。日本ベリサインも28日から開始したというので、同社の解説ページを見に行った。すると、こんなページがあった。

図5: ベリサイン サーバID Windows(R) Internet Explorer 7.0対応について

「ウェブサイトを運営する組織」と「証明書を発行した認証局」が逆だ。

元の英語版の解説と見比べてみるとどうだろうか。

英語版では「Identified by VeriSign」と出る。これが日本語版では「VeriSignによって識別」と出る。先に固有名詞が来て「によって識別」というのはわかりにくいのではないか。こうした、英語の語順で設計されたUIを日本語の語順で単純に翻訳することの罪は、今に始まったことではない。マイクロソフトの日本語訳作業の無神経ぶりはどうして治らないのだろう？ 「識別元: VeriSign」とか「身元確認者: VeriSign」などとしたほうがよいのではないかとか、考えないのか。