<前の日記(2005年12月23日) 次の日記(2005年12月25日)> 最新 編集

高木浩光@自宅の日記

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

2005年12月24日

Phishing対策ツールバーなんていらない! 元々あるIEの機能を使う

安全なWebサイト利用の手順

の講演で述べた「シンプルな安全確認ルール(手順)」というのがどういうも のかというと、まず、次の2つの状況によって手順を分ける。

  • 初めて訪れたサイトを利用しようとするとき
  • 既に何度か使ったことのあるサイトを利用しようとするとき

初めて訪れたサイトでは、サーバ証明書の内容を読んで、書かれている会社名 や住所が、自分が今使おうと想定している相手なのかどうかを確認し、間違い なければ利用を開始し、次回に備えてそのドメイン名を暗記しておく――(A)。

既に使ったことのあるサイトに訪れたつもり(偽サイトかもしれない状況で) のときは、アドレスバーに表示されたドメイン名を見て、記憶しているものと 同じかを確認し、重要な情報を入力するときは、錠前アイコンの存在を見て、 SSLが使用されているかを確認する――(B)。

この手順は、Web黎明期から変わることなく暗に求められてきた、利用者の基 本リテラシである。

特に(B)の手順は、先日話題にした三井住友銀 行のセキュリティ教室に書かれている通り(そこではsmbc.co.jpに特化 して書かれているが、上の手順はそれを一般化したもの)であり、(B)に補足 すべき「ポップアップウィンドウを信用しない」といった事項は、三井住友銀 行のセキュリティ教室に書かれている。

手順の困難さ

とはいえ、こうした手順を踏むことに困難さがあったため、phishingの被害が 拡大したのだろう。その困難さとは次のものと考えられる。

まず難しいのは、(B)の手順において、

  1. アドレスバーに表示されたURLからドメイン名部分を正しく抽出すること
  2. ドメイン名のアルファベット文字を間違いなく読み取ること
  3. 記憶しているドメイン名と一致するかを間違いなく判断すること

であろう*1。1.については、

先頭から順に見て「//」より後ろに現れる最初の「/」より前の部分のうち 最後の部分

という文法を知っていないといけないし、2.は、「l」と「1」を判別できるか という問題で、現在も残る困難性である。3.は、「example.com」 「example.net」「example.co.jp」「example.jp」のどれだったか覚えていら れないという困難性である。

この困難性ゆえに騙されてしまうケースを救うためにしばしば呼びかけられる 注意喚起として、「必ずブックマークからアクセスしてください」というもの があるが、昨年12月5日の日記に書いたイー バンク銀行の送金通知メールのように、ブックマークからでは利用できない利 用形態があるのであって、だからこそphishing被害が止まらないのだから、そ のような注意には実効性がなく、それは単に「いちおう注意喚起はしましたの で」というアリバイ作りにしかなっていない。

そこで登場したのがいくつかのphishing対策ツールバーであろう。たとえば、 「PhishWall」の仕組みを見てみる。

PhishWallデモページ」に書かれている説明によると、 PhishWallツールバーをブラウザにインストールしておくと、PhishWall対応サー バに初めて接続したとき、ツールバーに黄色の「●●●」マークが表示され、 「このWebサイトと信頼関係を結ぶためには登録作業を行ってください」とい うダイアログウィンドウが現れる。ここで「登録する」ボタンを押すと、次回 以降も含めて、そのサイトに訪れると「●●●」マークが緑色で表示されると いう。

つまり、PhishWallのこの仕組みは、前述の(B)の手順を機械化して、1.〜3.の 困難性を排除するものと言える。

元からある機能で困難を克服

だが、そんな機能はいらない。元々あるInternet Explorerの機能を使えば同 じことができるのだ。

それは、「信頼済みサイトゾーン」(図1)を活用することである。

図1: IEの「信頼済みサイトゾーン」

まず、初めてサイトを訪れたとき、利用者は前述(A)の手順にしたがって、そ のサイトを今後を含めて使うかどうか判断する。今後も使うと決めたとき、 「次回に備えてドメイン名を暗記しておく」の替わりに、次の操作をする。

図1の「サイト」ボタンを押し、信頼済みサイトゾーンに現在表示中のサイト を追加する(図2)。

図2: 信頼済みサイトゾーンに追加する

このようにしておけば、次回以降このサイトを利用する際、必要な(B)の手順 は、ステータスバーを見るだけで済むことになる。つまり、図3のように、ス テータスバーに緑色のマークと「信頼済みサイト」という表示が現れるのを 確認する。

図3: ステータスバーに表示される信頼済みマーク

これで、(B)の1.〜3.の困難は克服できる。


注意: 信頼済みサイトゾーンにサイトを登録する場合、必ず、信頼済みサイト ゾーンのセキュリティレベルを「中」以上にすること。また、インターネット ゾーンでユーザ独自に無効に設定している機能は、信頼済みサイトゾーンでも 無効に設定した方がよい。設定の注意点については「やってはいけないセキュリティ設定指示 Top 15 (Windows XP SP2編)」を参照。


次に、この記事に図解されているように、PhishWallのシステムは、他のいくつかの類似ツール バーと違って*2、サーバ側にも専用ソフトを 設置して公開鍵暗号を使い、サーバが偽でないことの確認を安全なものにして いる(通信路上でのパケット改竄などによる攻撃を防止している)ようである が、これも、Internet Explorerが元々持っている機能でほぼ同等のことを実 現できる。

つまり、図4のように、信頼済みサイトゾーンの登録サイト設定で、「このゾー ンのサイトにはすべてサーバの確認(https:)を必要とする」のチェックをオン にしておくことが、それに相当する。

図4: 信頼済みサイトゾーンにおけるhttps:の扱い

日本語版のWindowsではここが「確認を必要とする」と曖昧な表現になってい るが、英語版Windowsでは、「Require server verification (https:) for all sites in this zone」と書かれており、「server verification」とは、 サーバ証明書のPKIとしての検証処理のことを指すのだろう。

ここがチェックされている場合、信頼済みサイトゾーンには https:// のペー ジしか登録できなくなり、https:// のページに正常にアクセス*3したときだけ、信頼済みサイトゾーンの緑マークが表示される。

このように、PhishWallがやっている鍵の検証は、従来からWindowsが備えてい たWebブラウザ用PKIによって、同じように検証できるのである。

初めて訪れたサイトの信用をどう確認するか

そうすると、PhishWallの存在意義は何だろうか。

(B)の手順の困難さを解決するものとしての意義はほとんどない。

強いて挙げるならば、信頼済みサイトゾーンへの登録は手作業で行わなければ ならないところが、ボタンひとつでできるようになることと、もうひとつは、 認証局の信頼性の影響*4であろう。

有意な違いは、サイトを初めて訪れたときの効用にある。

ツールバーがないときは、(A)の手順で、サイトが自分の意図したところかど うか調べることになるが、ここで、正規のサーバ証明書があるからといって、 信用できるサイトだということにはならない。なぜなら、Web用サーバ証明書 を発行する認証局は、基本的には、発行先の組織の社会的信頼について確認し ないからだ。

ただ、一部の認証局が、組織の社会的信頼も評価して、一定以上の水準の組織 に対してだけ、証明書を発行するサービスを提供することはあり得る。この場 合、そのことを知ったうえ、そのサービスにより発行された証明書であること を示す記述がサーバ証明書に書かれているのを読んで、ユーザが確認すること になる。

しかし現実問題として、詐欺師たちがそれらしい名前のペーパー会社を作って、 正規の実在証明付き証明書を手に入れて、偽サイトを立ち上げる可能性は否定 できない。それをどうやって防止できるだろうか。SSLを公平に誰でも使える ようにと敷居を下げれば詐欺師に悪用され、詐欺師に悪用されないようにと敷 居を高くすれば、誰もSSLを使わなくなりオレオレ証明書が蔓延してしまう。

PhishWallは言わば、極めて限定した相手にしか販売しない認証局のような働 きをしている。

今の段階はそういう仕組みも成り立ち得る。銀行とクレジットカード会社だけ に販売しているうちは、売るか売らないかの判断を客観的に行うことができる。 だが、将来こうしたシステムが普及していって、我も我もとPhishWallサーバ を買いたいと言い出したらどうなるだろうか。「お前には売らない」という判 断基準を、どうやって設けるかという問題に直面することになる。

客観的基準がなくても自動的にそれを決定できるメカニズムがある。それは、 価格だ。ライセンス料が、数百万円から数千万円に設定されていれば、詐欺師 達はそれを買いに来ないだろう。詐欺師達は、詐欺行為によって得られる不正 利益の期待値と、詐欺行為にかかる費用を天秤にかけて、見合う手段でしか詐 欺をはたらかない。

そうすると、専用のサーバシステムを販売しなくても、単に高額な登録ライセ ンス料を受け取るだけのサービスを始めることで、同等のphishing対策ビジネ スを展開できるのではないかと思えてくる。このとき、技術的には既存のSSL のサーバ証明書を使えばよい。高額料金の支払い能力によって「認証」済みの サイトの、証明書リストを提供するサーバを用意しておき、それをダウンロー ドして照合するだけのツールバーを配ればいい。正規サイトの管理者が行う手 順は、(1)普通の認証局から数万円でSSLのサーバ証明書を買ってSSLサーバを セットアップし、(2)phishing対策ビジネス会社に1千万円払って自分のサイト の証明書を登録してもらう――と、これだけだ。

だが、技術的にも管理的にも何もやっていないに等しい(ツールバーは開発し て配っているにしても。サーバも準備しているにしても)単なる登録業務の会 社に、1千万円払うということに納得できる管理者はいないかもしれない。セ キュリティモデルとしては正しいが、釈然としない。せめて、技術的に意味が あるかのような専用システムを買わないと納得できないのではなかろうか。

公式サイトの垣根で奪われる自由

もうひとつの道は、高額料金で「認証」するのではなしに、主観的基準によっ て、販売先を選ぶという方向性である。これは、携帯電話会社の「公式サイト」 のモデルに似ている。しかしそれは、「インターネット的」でない代物だ。

インターネットが旧来の電話会社がやってきたことと根本的に異なっていたの は、常に自由と平等が尊重され、独占を避けるよう技術が設計されてきたこと だ。だからこそこれまでのような発展があったはずだ。

WebブラウザにSSLが初めて搭載されたときにも、ブラウザ製造者が自ら認証局 ビジネスも展開するなどということはしなかった。規格をオープンにして、広 く認証ビジネスに参入できるようにした*5

携帯電話上のサービスは所詮、電話会社の恣意的なコントロールの下に置かれ たものであり、自由がない代わりに一定の安全が安易に得られている。

インターネットを電話のようにしてしまえという発想をする人もいる。通信路 だけでなく、ユーザ認証やコンテンツまで通信会社がコントロールすることで、 「インターネットの危険をなくせ」という発想だ。自由を削がれたそれは、も うインターネットとは似て非なるものである。

このまま、phishing対策を大義名分として、特定の著名事業者を恣意的に優遇 する仕掛けが広範囲にわたって導入される(パソコンにそれがプリインストー ルされて出荷されるなど)ようになると、やがて人々はそれを拠り所とするよ うになり、それなしにはネットを利用しないようになり、インターネットの自 由(インターネットで(他と平等に)サービスを提供する自由)は事実上消滅 することになるかもしれない。

そんなはずではなかった。Webを安全に利用できるための仕掛けは、初めから 組み込まれていたのだ。(A)の手順で確認し、(B)の手順で確認する。それを単 に知らされていない人達がたくさん使い始めたという理由で、このまま電話世 界へと堕ちていってしまうのか。

リテラシー向上では無理なのか

安全な利用の手順が一般の人には覚えられないなんていうのは嘘っぱちだ。 「覚えられない」なんて言う人は、必要でない確認方法を挙げて「そんなのは 無理だ」と言っている*6三井住友銀行のセキュリティ教室に示されている単純な心得だけで、 安全に利用できるよう、Webサイトの方が構成されているべきなのだ。

もっとも、現にそうなっていないWebサイトがある(11月30日の日記参照)わけで、そうしたサイトで、「製品を買うだけで安全対 策ができる」というところが、phishing対策製品のひとつの売りなのだろう。 だが、そういう製品に毎年ライセンス料を支払うのと、画面構成を一回改修す るコストとどちらが大きいのか検討しているだろうか*7

それでもなお、対策製品の意義はある。

ひとつは、何らかの理由で古いWindowsを使っている人達を助けることだ。ア ドレスバーにウィンドウを被せてURLを偽装する手口は、Windows XP SP2での 修正で対策されたが、Windows Meをまだ使っている人にはどうすることもでき ない。これは、まだしばらく、皆でコストを負担していかないといけないのだ ろうか。

もうひとつは、対策製品を消費者のパソコンにインストールすると、安全確認 の方法を自然に教えてくれるようになるという点だ。phishing対策ツールバー を導入しても、そのツールバーの見方を知らなければ安全にならないわけで、 ユーザはそれを学ぶのだろう。お金を出して買っただけに、その機能を勉強す ることになる。だが、それは、元々あるブラウザの安全な使い方を学ぶのとど う違うのか。

パソコンを買っても、Windowsを買っても、その「安全な使い方」はマニュア ルに書いてない。学校でインターネットの使い方を教わっても、「安全な使い 方」は教えてくれない。そこが誤りの根源ではないか。

*1 他にも、アドレスバーを偽装されるとか、「%」エンコード やパスワード部分を使って混乱させられるといった攻撃が一時期流行ったが、 現在ではブラウザ側で対策がとられているか、サイト側でポップアップウィン ドウを使うのをやめるという方向で解決が図られているところなので、これら のケースは除く。それでもなお残る利用手順の困難性について、ここでは述べ ている。

*2 他の類似機能を持つツールバーのいくつかは、 本物サイトかどうかの情報をツールバー製造元のサーバに問い合わせる(ない しそこからダウンロードする)方式を採用しているが、その問い合わせ(ない しダウンロード)を適切に暗号処理していない場合、通信路上でのパケット改 竄によって、偽サイトに接続しようとしているのに本物サイトだとの偽応答に すり替えられる危険性があると考えられる。

*3 オレ オレ証明書の警告が出たときは「いいえ」を押してアクセスを回避しなくては ならない。

*4 (B)を信頼済みサイトゾーンのマークで確認す るときに、それを偽サイトに偽装される可能性があるとしたら、サーバ証明書 の秘密鍵が流出する場合と、認証局が誤って、phishing犯に本物サイトドメイ ン用の証明書を渡してしまう場合である。サーバ証明書の秘密鍵の流出リスク は、PhishWallサーバでも同様にあるように見受けられる。つまり、Windowsに 多数登録されているサーバ証明書発行認証局のどれかひとつが事故を起こす確 率を、どう見積もるかである。PhishWallの場合では、PhishWall販売店が誤っ てphishingサイトの鍵を鍵サーバに登録してしまう事故が、それに相当するだ ろう。どちらの事故確率が低いと見積もるかだ。

*5 といっても、安全基準を満た した事業者しか、ルート認証局に登録するわけにはいかないわけだが。

*6 冒頭で挙げた講演をレポートしたINTENET Watchの記事に、

高木氏は、利用者に対して不要な対策を要求している例もあるとして、DNSキャッシュポイズニングに関して書かれた記事を取り上げた。

という記述があるが、これは、日経IT Proの以下の記事のことを指して発言し たものである。

ユーザーができるDNSキャッシュ・ポイズニング対策はあるだろうか。SANSが 公表した事例のように,全く異なるサイトへリダイレクトされればユーザーも 異常に気付くだろう。だが,本物そっくりの偽サイトへリダイレクトされた場 合には「気が付きにくいだろう」(JPCERT/CCの山賀氏)。「極論すれば, 『HTTPのページは信用しない。HTTPS(SSL)のページでは,ページご とにデジタル証明書を開いて確認する』ということが,ユーザーの対策となる。 だが,これらは理想論。ユーザーに実施させるのは不可能だ」(同氏)。

勝村 幸博, 「悪質サイトへ勝手にリダイレクト」---DNSキャッシュ・ポイズニング攻撃の現状と対策(下), 日経IT Pro, 記者の眼, 2005年4月13日

これは大間違いで、INTERNET Watchの記事にレポートされている通り、

「デジタル証明書は、PKIの仕組みにより自動的に本物であるか偽者であるか を確認できるところにミソがあるのであって、目で確認するものではない。そ れよりも、(デジタル証明書の異常を示す)警告が出るか出ないだけで判断す ればよいこと」と指摘した。

ということだ。目で確認する(「実在証明」の利用をする)必然性があるのは、 初めてサイトを利用するときだけである。

*7 この記事によると、この製品の場合ライセンス料は、ユーザ一人当たり年間 600円にもなるという。これは見えない形で消費者の負担として跳ね返ってく るのだろう。ツールを利用しない人達にまで。

本日のTrackBacks(全2件) [TrackBack URL: http://takagi-hiromitsu.jp/diary/tb.rb/20051224]

Google Toolbar以外のおすすめツールバー ・Ask.jp ツールバー対応ブラウザ種類:Internet Explorer 使える遊べる楽しい機能. 主な機能 ・メールやチャットで使える3000 種類以上のキャラクタ Smiley Central ・ツールバーから直接ウェブ検索、辞書検索 ・ ニュース、ショ..

検索

<前の日記(2005年12月23日) 次の日記(2005年12月25日)> 最新 編集

最近のタイトル

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|
<前の日記(2005年12月23日) 次の日記(2005年12月25日)> 最新 編集