最新 追記

高木浩光@自宅の日記

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

2007年09月23日

対策にならないフィッシング対策がまたもや無批判に宣伝されている

  • 「PCからオンライン取引、ケータイで認証」−ソフトバンクBBの新発想・認証サービス, Enterprise Watch, 2007年9月20日

    「同サービスはまったく新しい認証の手段だ。暗号化技術にも依存しないので、クラッカーとのいたちごっこにもならず、これまでの認証の問題を一挙に解決することが可能。本当の意味でIT革命が起こせると期待できるサービスだ」と意気込みをあらわにしながら説明を行った。(略)

    「PCを標的にしたハッキングやDoS攻撃を受ける可能性がゼロになる」(中島氏)。また、偽サイトとはシンクロしないため、フィッシング詐欺を100%防止することも可能だ

  • ソフトバンクBB、携帯活用認証システムでWebサイトログイン対応に, ケータイWatch, 2007年9月20日

    今回の新機能は、安全・簡便・低コストで、そういった課題をクリアするとして「SyncLock側でエンドユーザーの個人情報はいっさい保有しない。フィッシング詐欺に対しては正規のシンクロ番号が発行されないため、被害がでない。またKeyIDが流出しても、携帯電話本体がなければ意味をなさない」と述べ、仕組みはシンプルながら、パソコンと携帯電話を組み合わせたことで、高い安全性を確保したとアピールした。

  • 「2年、200億円をかけてシステムを構築した」、住信SBIネット銀行が24日に開業, 日経IT Pro, 2007年9月20日

    同ネット銀行のユニークな点は、セキュリティ強化のため携帯電話機を認証に用いているところ。(略)2系統の認証を利用することで、フィッシング詐欺などを防ぐことが目的だ。

またか。何年も前から繰り返し言ってきたように、それはフィッシング対策にならない。対策になっていないものが「フィッシング詐欺を100%防止する」などと宣伝されている。これまでに、

で言ってきたように、フィッシングの被害を防ぐには、偽サイトが本物サイトに通信を中継する攻撃(man-in-the-middle attack ― 中間者攻撃)を防がなくてはならない。

フィッシングを防止するには、原理的に言って、ブラウザに組み込まれている機能(アドレスバー等やアドオン)を頼りにするか、さもなくば、使用する端末(ブラウザ)毎に何かを事前に登録しておく(cookie等を用いて)以外に術がない。

例えば、Yahoo!が今年開始したログインシール(Yahoo! Inc.のログイン画面Yahoo! JAPANのログイン画面参照)は、cookieを用いた仕組み(2004年10月11日の日記の脚注1および「■意見」の節参照)であり、cookieが発行元のサーバにしか送出されないものであるという性質を使って、本物サイトであることを確認できるようにしている。そういう仕組みであるため、説明ページにあるように、「パソコンごとに設定が必要」という制約がある*1

それに対し、このソリューションは、使用するパソコンに事前の準備をしておかなくてもどこでもすぐ使えることを謳い文句にしている(事前の登録は携帯電話側の1回)のであるから、原理的に言って中間者攻撃によるフィッシング(携帯電話側の偽サイトではなく、PC側の偽サイトでのフィッシング)を防ぐことはできない。

「シンクロック」のパンフレット(2007年9月20日版)の3ページ目には、

シンクロ認証が動作するのは正規サイトのみ。
フィッシングサイトも確実に排除します。

「シンクロック」のパンフレット(2007年9月20日版)

という記述があるが、そんなはずがないのでデモサイトの「書留.com」で試してみたが、やはり、別サイト上に設置したHTTPサーバから中継する(ホスト名の変換処理をしながら相互中継する)だけで、認証は正常に動作したし、その結果として、ログイン後に現れるコンテンツが別サイト上に表示されることも確認できた。

図1: 別サイト上でSyncLockの認証機能が動作する様子

図1は、自分で作成した文書を「書留.com」で自分宛に送り、それを自分で開くにあたって、自分のWebサイト上に設置した中継サーバ経由で閲覧しようとしたときの様子である。赤矢印で示したように、これらは「http://202.181.….…:10080/」のサーバ上で表示されている。「シンクロNo.」は正常に表示されているし、これを携帯電話側で入力すると「認証OK」となり、図2の画面が現れる。

図2: 別サイト上でログイン後のコンテンツを表示した様子

図2は、認証後に表示される(秘密であるはずの)コンテンツである。これが、別サイト「http://202.181.….…:10080/」上に表示されたということは、別サイトの設置者は、この画面のデータを入手できてしまうということであるし、それだけでなく、これはセッションハイジャックが可能ということであるから、本物サイトを自由に操作できてしまうことを意味する。

こうしたことをやりにくくするいくらかの小手先の改良の余地はある。Flashが使用されているのでURLをFlash埋め込みとするなどすれば、Flashまで書き換えないと中継できないようにできるが、所詮は小手先の策であって、その他のいろいろな策を施したとしても、それらは回避されてしまう。

man-in-the-middle攻撃とはまさに「間に人が入っているよ」という状況を言うのであって、図3のように、犠牲者から送られてくる通信内容を、時には手を加えながら本物サーバに送信して、本物サーバから返ってくる通信内容を、同様に手を加えながら犠牲者へ送り返すというものであり、本物サイト側で小手先の策をとったとしても、間の人がそれをうまく変換してしまう知性をもっていれば、その策は回避されてしまう。実際には、それがプログラムで処理されるよう自動化されない限りフィッシング詐欺犯達にとってコストが見合わないということはあるかもしれないので、いくらかやりにくくする策に意味もあるかもしれないが、原理的に中間者攻撃に脆弱な方式は対策し切ることができない。

図3: 「間に人が入ってるよ攻撃」(man-in-the-middle attack)

こうしたことをなぜ声を大にして言うのかといえば、フィッシング対策にならないソリューションを導入して、「フィッシング詐欺を100%防止する」だの「被害がでない」だの「フィッシングサイトも確実に排除」だのと宣伝したら、ユーザが信じて安心してしまい、偽サイトに対する警戒を怠ってしまい、かえって危険を増大させかねないからだ。

フィッシングとは厄介な問題であり、だからこそ英語圏でさえ未だ確固とした解決策が確立していないわけで、現時点では、基本的にユーザが本物サイトであることの確認を怠らないように促さなければならない。

それがどうだろうか、図1の画面にあるように、このソリューションはポップアップウィンドウを使用したうえ、アドレスバーも隠している。URLの確認という基本的なことをおろそかにしていることの表れではないか。

このソリューションが銀行に導入される際に、「フィッシングは100%防止するので」という過信から、もしアドレスバーを隠す画面設計にするようなことがあれば、本末転倒だ。

金融機関の責任者は、こうした業者の売り文句を鵜呑みにすることなく、何が本当に解決されているのかを自力で見極め、本来やらなければならないことは何かを常に把握しておくべきだろう。

ユーザも、こうした宣伝に惑わされることなく、安全な手順を踏んでWebサイトを利用するよう心がけたい。安全なWebサイト利用の鉄則の手順で利用できないようなサイト、例えばアドレスバーを隠すようなサイトは、使わないようにするのがよいだろう。

ちなみに、フィッシングの観点を除けば、この携帯電話を用いた認証方式は他の方式に比べて優れた点のあるものであることに間違いない。

ユーザがパスワードを自己管理するのは難しく、安易な弱いパスワードを使ってしまったり、どこのサイトにも同じパスワードを登録したりしてしまうのはなかなか避けられそうにないところ、ワンタイムパスワード方式と同様にこのソリューションは、ユーザに認証用秘密情報を決めさせないので、その意味での危険をなくすことができる。

シンクロックの導入例のページにも書かれているように、ワンタイムパスワード生成器(物理トークン)に比べると、配布コストがかからないし、持ち運ぶ際に忘れても携帯電話ならすぐ気づけるというのはその通りだろうし、乱数表では乱数の数に限りがあって弱いのに比べれば安全性が高いというのもその通りだろう。パンフレット(2007年9月20日版)の2ページ目に書かれていることには誤りがない。

また、ワンタイムパスワード方式では、オンライン総当り攻撃に備えて一定回数の入力間違い時にロックアウトする対策をとった場合には、ロック解除の運用コストがかさんでしまうのに対し、携帯電話を用いたこのような方式であればロックする必要がない*2というのも利点であり、Enterprise Watchの記事で、「鍵穴が存在しないことになるので(中略)DoS攻撃を受ける可能性がゼロになる」(このスライド参照)というのはそのことを言いたいのかもしれない。

だが、そこに、フィッシングの防止を付け加えたのは勇み足だ。シンクロックの導入例のページには次の記述がある。

一例としてキーホルダー型のハードウエアトークン(ワンタイムパスワード発生装置)が挙げられますが、(中略)トークンを配布する手間やコスト、お客様側の操作・管理の煩雑さなどの問題も見られました。

また、初期コストが安価なカード型トークン方式(マトリックスカード)の場合は、乱数表(マトリックスカード)をコピーされた場合、脆弱性がID・パスワードと変わらないという課題がありました。さらに、どちらもフィッシング詐欺に対して脆弱な面があり、いずれも同行のニーズと一致しないものでした。(略)

IDやパスワード、乱数表などが不要で、複製できない携帯電話端末を認証のカギとして利用し、独自の通信構造とすることによって、フィッシング詐欺を排除するなど、従来のシステムでは実現できなかった最高水準のセキュリティを可能にしています。

シンクロックの導入例のページ

これによると、ワンタイムパスワード生成器でフィッシングを防げないという認識があるようだ。有効期限の短いワンタイムパスワードであるSecurIDのような方式でフィッシングが防止できないとすれば、それは中間者攻撃を想定した場合である。同じ前提条件の下で、SecurIDが脆弱としながら、SyncLockは安全であるとするのは根拠がわからない。

では、フィッシング対策を語るときに、中間者攻撃を抜きに語ってはいけないのかというと、やはり抜きには語れない。

例えば、PassLogicという携帯電話を利用した同様の目的の製品があるようだが、製品ラインアップのページを見ると、「ライト版」、「PassLogic」、「PassLogicII」という3つの製品があり、「PassLogicII」だけが「フィッシング詐欺(マンインザミドルなど)にも有効な高機能アンチフィッシングを搭載」と書かれており、普通の方法ではフィッシング対策ができないこと、man-in-the-middle攻撃に対策する必要があるという業界の認識が伺える。(なお、この「PassLogicII」がどうやってman-in-the-middleによるフィッシングを防いでいるのか私は知らないし、本当に有効なのかについても知らない。)

中間者攻撃によるフィッシングは、英語圏では既に現実の脅威となっている。2006年2月には、フィッシングではなくファーミングにおいて類似の手口が話題になった。

  • 口座預金を略奪するトロイの木馬がまん延--セキュリティ研究者が注意を呼びかけ, CNET News, 2006年2月20日

    サイバー犯罪者がユーザーとともにオンラインバンキングを利用し、口座の金を盗むという事態が起こっている。(略)

    Shippは米国時間2月16日、当地で開催された「RSA Conference 2006」において、「最近では、ユーザー名やパスワードの盗難は減少している」と発言した。代わりに、「(口座から金を盗む目的で作成された)トロイの木馬」が、ユーザーがオンラインバンキングを利用するのを待ち受けるようになり、「金を外部へ送金している」のだという。

    「いかなる認証システムが導入されていようと、ちょっとした仕掛けが施されていようと、生体認証が適用されていようと、役に立たない。犯罪者はユーザーを待ち伏せて、口座預金を盗み出している」

原理的にはこれと同様に、トロイに侵されていなくても、偽サイト上で同様に「ユーザーとともにオンラインバンキングを利用し口座の金を盗む」という中間者攻撃があり得るのであり、このことは研究者なら昔からわかり切っていたことだし、Bruce Schneierも2005年3月に次のように予言して警鐘を鳴らしていた。

そして2006年7月、米国のCitibankをターゲットとした中間者攻撃によるフィッシングが現れ、二要素認証が役に立たなかったということで騒動になった。

2007年1月には、中間者攻撃型フィッシングの構築キットが現れていると、RSA Securityが警告を出している。

こういう状況があったので、今年のIPAの「情報セキュリティ検討会」でこのことを白書に入れるよう提案したところ、「情報セキュリティ白書 2007年版」に次のように記載された。

第5位 ますます多様化するフィッシング詐欺

(略)海外では、偽サイトが本物のサイトと利用者の間に入り込む、中間者攻撃(→用語集参照)という手口でのフィッシング詐欺が問題となりました。2006年7月に米国の大手銀行が被害に遭った事件では、銀行がワンタイムパスワード方式による二要素認証(→用語集参照)システムを導入していたにもかかわらず、被害を受けてしまいました。セキュリティトークン(→用語集参照)を使用したワンタイムパスワード(→用語集参照)方式は国内でも使われていますが、中間者攻撃によるフィッシング詐欺に対しては効果がありません(参考資料[39])。

情報セキュリティ白書 2007年版

また、日本銀行の「日銀レビュー・シリーズ」の2006年7月発行の「インターネットバンキングの安全性を巡る現状と課題」でも次のように述べられている。

二要素認証はフィッシングに対する有効なセキュリティ対策であるが、利用者と金融機関の間に不正に介在して取引指図を改竄する中間者攻撃やPCハイジャック型の「トロイの木馬」(不正プログラム)に対してはあまり効果がない。本人認証をパスする手順自体は正規の利用者に実行させ、認証が通ってから不正行為を働くからである。

このようなPC ハイジャック型のトロイの木馬等に対しては、通常の方法で本人認証のセキュリティを強化するだけでは限界があり、被害を防ぐことは困難である。

こうした攻撃に対応する一つの解決方法は、異なる通信経路を組み合わせる二経路認証の採用である。たとえば、インターネットで取引指図が送られると、事前に登録してある携帯電話にコールバックを行い、確認に対する返事の声で自動的に認証する(ボイス認証)方法なども考えられている

また、すべての資金移動の取引指図をチェックする「トランザクション監視」を行うことも有効である。これは(以下略)

インターネットバンキングの安全性を巡る現状と課題, 日銀レビュー・シリーズ, 2006年7月28日

金融機関の責任者はこうしたことを当然に把握しているべきだろう。

SyncLockも二経路認証のひとつには違いないが、先に書いたように、単に二経路を使っていれば安全(中間者によるフィッシングに対して)というわけではない。乗っ取られたPC側のセッションでの操作を、携帯電話で単に承認だけするのであれば、乗っ取られていることに気づかずに承認してしまう。上の記事で書かれているのは、おそらく、携帯電話側で取引内容を確認(振込先等を確認)する方式のことだろう。使い勝手が面倒そうではあるが、携帯電話側では中間者攻撃は不可能だとすれば(コールバックを利用したり、キャリアからのアクセスに限定していることが拠り所となれば)、防止できる方法があるかもしれない。

いずれにしても、インターネットにおけるフィッシングというのは、どこまで技術で対策しても、最後のどこかはユーザによる識別(偽でないことの何らかの確認)に頼らざるを得ない。技術はそれを最小限に留めて、可能な限り容易なものとするよう、人を補助するものでしかない。

昨年の預金者保護法の施行で、銀行はキャッシュカードについてのセキュリティ改善に取り組まざるを得なくなったが、インターネットバンキングは同法の適用外となっている。中間者フィッシングや、トロイの木馬による乗っ取りの問題は、原理的に言って、銀行側でどんなに対策を施しても、ユーザ側の落ち度がある限りどうやっても防げないものであるから、被害を銀行が補償するというのも酷な話だ。おそらく、インターネットバンキングでの被害の補償を求めて訴訟を起こしても、ユーザ側に落ち度があり、銀行側に対処のしようがなかったという理由で、敗訴するという事態が今後出てくるかもしれない。

そういう状況で、「フィッシング詐欺を100%防止する」だとか、「被害がでない」、「フィッシングサイトも確実に排除」などと宣伝するのは自殺行為ではなかろうか。訴訟で、「100%防止すると宣伝されていたので安心して使っていた。アドレスバーを確認しなかったのはそのため。」と原告に主張されたら、どう応じるつもりなのだろうか。

追記(26日)

遅れて25日付けで掲載されたITmediaの記事でまた「フィッシング詐欺サイトではそもそもSyncLockが利用できない」と書かれてしまった。

  • 携帯さえあればIDとパスワードが不要に──ソフトバンクBBの「SyncLock」, ITmedia +Dモバイル, 2007年9月25日*3

    (略)2種類の異なる鍵を使わないとアクティベートしないので、「しくみとしては核ミサイルの発射ボタンと同じ」と中島氏は言う。

    またシンクロサーバは、偽のサービスサイトとは通信を行わないため、フィッシング詐欺サイトではそもそもSyncLockが利用できない。仮に Key IDを盗まれたとしても、登録された携帯電話がなければ認証できないため、深刻な影響はない。(略)

    しかもやり取りする情報はそのつど変わる4ケタの数字だけで、そのほかの認証情報はネットワークには流れない。通信が暗号化されていなくてもまったく問題がないわけだ

加えて新たに「通信が暗号化されていなくてもまったく問題がない」などという出鱈目な話も出てきた。「そのほかの認証情報はネットワークには流れない」というのは虚偽で、目に見えないだけで、PC側のセッションIDと、携帯電話側の本人確認用ID(サブスクライバIDや端末ID)がこの方式の認証情報となっている。PCサイト側でセッションIDを含む通信が暗号化されていなければ、(インターネットでの盗聴の脅威を想定する環境では)セッションハイジャックされてしまうし、携帯電話側で https:// ページになっていなければ、(キャリアと認証サーバ間の通信に盗聴とパケット改竄の脅威があると想定する場合には*4)本人確認用IDを盗聴され再使用されてしまう。

また、25日に別の記者発表があったようで、新たな記事も掲載されていた。日経ソリューションビジネスとマイコミジャーナルが、フィッシングを防止できると書いてしまっている。

以下の他の記事はフィッシングについて触れていない。

*1 イーバンク銀行のIPアドレスによるアクセス制限の対策も、使用する端末ごとにIPアドレスを登録しておく必要がある点で、同じ制約がある。

*2 携帯電話側のサイトには総当り攻撃はないだろうという前提の場合。PC側サイトへの総当り攻撃の対象となるのは、この方式ではセッションIDへの総当りのみであり、これはロックアウト処理する必要がない。

*3 ちなみに、「しくみとしては核ミサイルの発射ボタンと同じ」というのは、記事中10枚目の写真のスライドで説明されていたようだ。核兵器炸裂時の写真を使うとは不謹慎な人なんだなと感じた。他のメディアはこの写真を載せていない。

*4 もっとも、この想定においては、6月29日の日記「サブスクライバーIDをパスワード代わりに使うべきでない理由」の後半(「もうひとつ、次の理由がある」以降の部分)で書いていたように、アクセス元をキャリアのIPアドレスに限定する策も回避されるので、本人確認用IDを悪意ある者に何らかの原因で知られている状況(例えば、信用できないサイトにサブスクライバIDや端末IDを送信してしまった過去があるなど)では、たとえ https:// のページにしていたとしても、その本人確認用IDで成りすまされる危険がある(携帯電話を盗まれたのと同等の状況)。本人確認用IDを不用意に送信しないことを徹底するのが非現実であるとするなら、キャリアと認証サーバ間を専用線ないしVPN接続とするべきかもしれない。SyncLockがそうしているかどうかは知らない。

本日のリンク元 TrackBacks(100)

2007年09月30日

緑シグナルが点灯しないのに誰も気にしていない?という不思議

フィッシング対策ソフトの導入動向

最近、金融機関が「PhishWall」や「PhishCut」を導入したというニュースをよく見かけるなあと思っていたら、どうやら、金融庁の監督指針の今年の改定でフィッシング対策について明記されたことが関係しているらしい。

  • 主要行等向けの総合的な監督指針(平成19年6月版), 中小・地域金融機関向けの総合的な監督指針(平成19年8月版), 金融庁

    III-3-7 インターネットバンキング

    III-3-7-2 主な着眼点

    (2) セキュリティの確保

    ホームページのリンクに関し、利用者が取引相手を誤認するような構成になっていないか。また、フィッシング詐欺対策については、利用者がアクセスしているサイトが真正なサイトであることの証明を確認できるような措置を講じる等、業務に応じた適切な不正防止策を講じているか。

「ホームページのリンクに関し」という表現のあたり、なんだか書いた人もよくわかっていないようで一抹の不安を覚えるが、これの意味するところは、必ずしも対策ソフトを導入せよという意味ではないだろう。ログイン画面で他社のドメイン名を使用していたりしないかとか、ログイン画面でドメイン名を確認できないようにしていたりしないかとか、そういうことだろう。つまり、わかりやすい自社のドメイン名を使って、普通に画面設計して、適切なサーバ証明書を使用していれば、この要件を満たすということだ。

しかし、どういう事情があるのか理解しかねるのだが、そうした基本が実施できない中小銀行があるようで、そういうところが対策ソフトを続々導入しているようだ。

表1: 対策ソフト導入銀行における本来なすべきことの実施状況
導入ソフト 自社ドメイン名 自社サー バ証明書 アドレスバー 右クリック
常陽銀行 PhishWall × (chance.co.jp) × (Regional Banks and Information Technology Solution Co. Ltd.)
沖縄銀行 PhishWall × (finemax.net) × (Hitachi,Ltd.) × (右クリックは禁止です。)
東邦銀行 PhishWall × (ib-center.gr.jp) × (Hitachi,Ltd.) × × (右クリックは禁止です。)
山陰合同銀行 PhishWall × (ib-center.gr.jp) × (Hitachi,Ltd.) × (右クリックは禁止です。)
武蔵野銀行 PhishWall × (cyber-biz.ne.jp) × (IBM Japan, Ltd.)
静岡銀行 PhishCut × (anser.or.jp) × (NTT DATA CORPORATION)
北海道銀行 PhishCut × (anser.or.jp) × (NTT DATA CORPORATION) ×
第四銀行 PhishCut ○ (ib.daishi-bank.co.jp)
南都銀行 PhishCut × (anser.or.jp) × (NTT DATA CORPORATION)

第四銀行だけが例外で、本来なすべきことを実施している。金を払って物を買うだけなら〓〓でもできるだろうが、アドレスバーを直したり、右クリックを直すということは、なぜかできないらしい。

ちなみに、「nProtect:Netizen」が16もの銀行に導入されているようだが、これは、金融庁の言う「利用者がアクセスしているサイトが真正なサイトであることの証明を確認できるような措置」には当たらないだろう。なぜなら、まず本物サイトへ行ってボタンを押さないと「nProtect:Netizen」が起動しないからだ。*1

ちなみに、「nProtect:Netizen」を導入している銀行における、「真正なサイトであることを確認できるような措置」の対応状況を調べてみると、表2のように、認識の低いところばかりだということがわかる。

表2: nProtect:Netizen導入銀行における本来なすべきことの実施状況
導入ソフト 自社ドメイン名 自社サーバ証明書 アドレスバー 右クリック
東京スター銀行 nProtect:Netizen ○ (tokyostarbank.co.jp) ○ (The Tokyo Star Bank,Limited) × × (何も起きない)
りそな銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
福岡銀行 nProtect:Netizen × (finemax.net) × (Hitachi,Ltd.) × × (右クリックは禁止です。)
京葉銀行 nProtect:Netizen × (finemax.net) × (Hitachi,Ltd.) × × (右クリックは禁止です。)
北洋銀行 nProtect:Netizen × (finemax.net) × (Hitachi,Ltd.) × (右クリックは禁止です。)
中国銀行 nProtect:Netizen ○ (chugin.co.jp) ○ (The Chugoku Bank,Ltd.)
第三銀行 nProtect:Netizen × (ib-center.gr.jp) × (Hitachi,Ltd.) × (右クリックは禁止です。)
愛知銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION) ×
八千代銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
常陽銀行 nProtect:Netizen × (chance.co.jp) × (Regional Banks and Information Technology Solution Co. Ltd.)
東和銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
北越銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
岩手銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
青森銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
秋田銀行 nProtect:Netizen × (anser.or.jp) × (NTT DATA CORPORATION)
伊予銀行 nProtect:Netizen × (ib-center.gr.jp) × (Hitachi,Ltd.) × × (右クリックは禁止です。)

ちなみに、りそな銀行以外の都市銀行とネット銀行は、どこもきちんとやっていて対策ソフトを必要としていない。

表3: りそな銀行以外の都市銀行とネット銀行の状況
導入ソフト 自社ドメイン名 自社サーバ証明書 アドレスバー 右クリック
みずほ銀行 なし ○ (mizuhobank.co.jp) ○ (Mizuho Bank,Ltd.)
三菱東京UFJ銀行 なし ○ (mufg.jp) ○ (The Bank of Tokyo-Mitsubishi UFJ,Ltd.)
三井住友銀行 なし ○ (smbc.co.jp) ○ (Sumitomo Mitsui Banking Corporation)
ジャパンネット銀行 なし ○ (japannetbank.co.jp) ○ (The Japan Net Bank, Limited)
ソニー銀行 なし ○ (moneykit.net) ○ (Sony Bank Incorporated)
イーバンク銀行 なし ○ (ebank.co.jp) ○ (eBANK Corporation)
住信SBIネット銀行 なし ○ (netbk.co.jp) ○ (SBI Sumishin Net Bank, Ltd.)

資金力のあるところしかきちんとできないのか、というとそうでもない。4月8日の日記の後半に書いていたように、地方銀行でもこれらをきちんと実施できているところがある。(以下のうち「nProtect:Netizen」を導入しているのは中国銀行だけ*2。)

表4: 地方銀行できちんと対応できているところ(4月8日調べ)
導入ソフト 自社ドメイン名 自社サーバ証明書 アドレスバー 右クリック
山形銀行 なし ○ (ynb.yamagatabank.co.jp) ○ (The Yamagata Bank,Ltd.)
群馬銀行 なし ○ (direct.gunmabank.co.jp) ○ (The Gunma Bank,Ltd.)
八十二銀行 なし ○ (direct.82bank.co.jp) ○ (The Hachijuni Bank,Ltd.)
北陸銀行 なし ○ (direct.hokugin.co.jp) ○ (The Hokuriku Bank, Ltd.)
大垣共立銀行 なし ○ (okbnetplaza.com) ○ (THE OGAKI KYORITSU BANK ,LTD.)
スルガ銀行 なし ○ (ib.surugabank.co.jp) ○ (Suruga Bank Ltd. )
百五銀行 なし ○ (www.105bank.com) ○ (THE HYAKUGO BANK LTD )
中国銀行 nProtect:Netizen ○ (direct.chugin.co.jp) ○ (The Chugoku Bank,Ltd. )
宮崎銀行 なし ○ (mib.miyagin.co.jp) ○ (THE MIYAZAKI BANK, LTD. )

この差はどこからくるのか、だ。これらの地銀とて、自社でシステム運用をしているわけではなく、IBMかどこかのASPサービスを利用しているようだ(ASPサービスのホストをDNSで自社ドメイン上に割り当てていると思われる)から、巨額の修正費用が必要とかいった事情があるとは思えない。

それに対し、PhishWallの導入費用は、10万アカウントまでで年額240万円だそうで、常陽銀行の場合導入事例紹介パンフレットによると5万ユーザだそうだから、一人当たり年に50円負担している(私も負担している)ことになる。EV SSL証明書が年額 7万5千円から20万円ほどだから、その10倍から30倍もの値段だ。

緑シグナルが点灯しないケース

ところで、沖縄銀行のトップページには「フィッシング対策ツールPhishWallインストールのお願い」というリンクが目立つように置かれているのだが、そこには図1のように説明されている。

沖縄銀行の説明
図1: 沖縄銀行のPhishWallの使い方説明

「緑色のシグナルが表示されれば安全!」というのだが、左のメニューにある「eバンキング」のところをクリックして、「ログイン」ボタンを押すと、図2の画面となる。

「eバンキング」のログイン画面
図2: 「eバンキング」のログイン画面でPhishWallの緑シグナルが点灯しない様子

PhishWallの緑シグナルが点灯しない。

メニューの「eパートナー」の方ではPhishWallの緑シグナルが点灯するので、新システムのログイン画面だけPhishWall対応にして、旧システム(「平成18年6月以前にご契約のお客様」と書かれている)のログイン画面には対応していないのだろう。

不思議なのは、「フィッシング対策ツールPhishWallインストールのお願い」のページで、「eバンキング」の方には対応していないという注意書きがないことだ。ユーザから「緑シグナルが点灯しません!」という問い合わせは殺到していないのだろうか? もしかして、実はユーザは誰も、パスワード入力時にPhishWallシグナルを気に留めていないのではないか?

もっとひどいのは、(銀行ではないが)オリコでのPhishWall導入事例だ。トップページの「eオリコサービス ログイン」のボタンを押すと図3のようになる。

オリコの「eオリコサービス」のログイン画面
図3: オリコの「eオリコサービス」のログイン画面

PhishWallのシグナルがログイン画面で確認できない。

セキュアブレイン(PhishWall販売元)のオリコについての説明ページによると、オリコ内でも対応しているページと対応していないページがあるそうで、図4のように説明されている。

セキュアブレインによるオリコについての説明
図4: セキュアブレインによるオリコについての説明

ユーザにこれを覚えていろというのだろうか。いったいどういうユーザ層向けのシステムなのか。

フィッシング回避補助ツール「petname tool」

ちなみに、私が最近気に入っているフィッシング対策ツールは「petname tool」だ。Firefox用の機能拡張で、次のようにして使える。

まずログイン画面に行き、「安全なWebサイト利用の鉄則」で言うところの、「(A) 初めて訪れたサイトの場合」の手順で、サイトが自分の意図しているところに間違いないことを慎重に(サーバ証明書等で)確認し、確認できたら、サイトに自分で名前を付ける。最初に訪れたときは、図5のようにpetname toolの領域は黄色*3で「untrusted」と表示されている。

登録前のpetname toolの様子
図5: petname toolの使い方その1

ここは入力欄になっているので、「untrusted」を消して、自分で決めた名前を入力し(図6)、エンターキーで決定する。

登録時のpetname toolの様子
図6: petname toolの使い方その2

エンターキーで決定すると緑色になり、その名前でブックマークされる。(Firefoxの「Bookmark Toolbar Folder」の中の「petname」フォルダの中にブックマークが作成される。)

その後、どこかから(例えばメールから誘導されて)このログイン画面に到着すると、図7のように、ここが緑色になり、過去に自分が付けたブックマーク名が表示される。作者はこれを「bidirectional bookmark(双方向ブックマーク)」と呼んでいて、ブックマーク済みのサイトに到着するとブックマーク名が表示されるというわけだ。*4

登録後のpetname toolの様子
図7: petname toolの使い方その3

論文に書かれているように、同じサイトであることの判別はSSLのサーバ証明書の内容で行われているため、direct.smbc.co.jp の https:// ページで登録した名前が www.smbc.co.jp の https:// ページ上でも有効となるようだ。*5

When the user creates a new petname, the petname tool creates a new bookmark to the current page. The "Name" field of the bookmark is the user chosen petname. The "Description" field of the bookmark contains the hash of the CAs public key and the subject's O, L, ST and C certificate fields. If the subject has no O (Organization) field, the CN (domain name) field is used instead. On each page transition, the petname tool looks at the certificate chain of the SSL connection that delivered the page and searches for a corresponding bookmark. If one is found, the petname field is populated with the bookmark's "Name". Otherwise, the petname field is populated with the string "untrusted".

The petname tool uses the CA (Certificate Authority) and subject DN (Distinguished Name) as the secure identifier for a relationship because many secure sites use multiple domain names and multiple public keys. Further, it is important that sites be able to replace key pairs without breaking their user's petnames.

Tyler Close, Petname Tool: Enabling web site recognition using the existing SSL infrastructure, W3C Workshop on Transparency and Usability of Web Authentication, March 2006

ユーザは、パスワード入力の直前にここが緑色になっていることを確認すればよい。これだけだ。紛らわしいドメイン名によるフィッシングが横行していても、(二度目以降については)すばやく本物サイトであることを確認することができる。

これは、「安全なWebサイト利用の鉄則」で言うところの、「今見ている画面が過去に訪れたサイトかどうか機械的に見分ける方法」の機能を果たしていると言える。Internet Explorerの信頼済みサイトゾーンを使う方法は、セキュリティレベルと同時に管理する必要があるので、いまひとつであったが、petname toolのように専用になっていると使いやすい。*6

自分で登録するか勝手に登録されたものを見るか

この点について、PhishWallの導入事例紹介パンフレットにこんな記述がある。

巧妙に偽装されたフィッシングを簡単に防止できるようにしたい

フィッシングを防ぐのは簡単ではない。それは、利用者が自分で意識して、ひっかからないようにしなくてはならないからだ。サイトごとに信頼済サイトとしてIPアドレスを登録しておくのは、利用者にとってわずらわしい作業だ。また、目的のWebサイトにアクセスするたびに、開いたページのURLを確認する手法では、正しいWebサイトかを見分けるのは非常に困難だ。「フィッシング対策は利用者に依存する場合が多いのですが、PhishWallのクライアント用ソフトは無料で、利用者が一度インストールするだけで他に手間はかかりません。そこが一番大きいところだと思います。インターネット上のどのWebサイトに行っても、ブラウザ上に緑のシグナルが出ているかぎり、お客様は騙される心配がありません」(関氏)。

PhishWallサーバ 導入事例, セキュアブレイン

「IPアドレスを登録」?というのはげせないが、それはともかく、サイトごとに登録するのが煩わしいというが、その単純なことさえできないユーザに、はたしてPhishWallの緑シグナルの確認ができるかどうか疑問だ。なにしろ、正規サイトであっても緑にならない画面もあるわけだから、どこで出るはずなのかは自分で把握しておかざるを得ない。常陽銀行のケースでも、インターネットバンキング以外のページではPhishWall非対応になっている*7ため、例えば、資料請求のページでは本物サイトであっても緑シグナルにならないことを知っておかなければならない。

常陽銀行の資料請求の画面
図8: 資料請求のページでは緑シグナルにならない様子

2005年12月24日の日記「Phishing対策ツールバーなんていらない! 元々あるIEの機能を使う」では、次のように書いていた。

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

当初の設計ではユーザの意思で登録する方式だったのが、現在は最初から緑シグナルという仕様に変更されていたようだ。

まあ、ぶっちゃけ言っちゃうと、EV SSLと同様の仕組みだ。サイト運営者を一定の基準で審査することによって緑シグナルを表示するか否かを決定するもの。PhishWallは何やら独自の技術的認証方式を用いているようだが、SSLのサーバ証明書情報を使って同じことはできるのになぜわざわざ独自方式を使うのか当初から理解しかねた。その方式自体にはおそらく意味がないだろう。ブラウザやWebサイトに脆弱性がある場合に影響を受けないとかいった利点が存在する可能性はあるが、仕様が公開されていないので評価できない。

いくらかPhishWallの勝る点はある。EV SSLでは、証明書の内容の表示が現状では英文でしか表示されないのに対し、PhishWallでは日本語で組織名が表示される。これは、EV SSL対応のブラウザがなんとか日本語表示に対応してほしいところ。

また、PhishWallはWindows 98にも対応していることを売りにしている。導入事例紹介パンフレットでも常用銀行が「Windows 98のお客様もいらっしゃるので、そういう方々を置き去りにするのも当行の理念に反しますし」と言っているのだが、そもそもサポート中止となって脆弱性修正パッチも出ていないWindows 98は安全に使えないわけで、本来ならば、銀行としては、顧客の安全確保のために、「当行のインターネットバンキングをお使いの際には Windows 98を使用しないでください。安全にお使いになることができません。」とアドバイスするべき立場にあるはずで、常陽銀行は本当に客のことを想ってくれているのか疑わしく感じる(一人の預金者として)。

それから、審査基準の違いを見ておくとよいかもしれない。PhishWallの審査基準では、「「その他会社」については、各種主要任意団体に加盟していることが必要」といったことが書かれている。EV SSLの審査基準については、日本電子認証協議会の公開資料で閲覧できる。

まあ、標準化を目指していないような閉鎖的独自方式があんまり広く普及しちゃうのはどうかと思う。少なくとも技術者ならそういうセンスを持ち合わせているのではないか。金融庁殿には、そのあたりを把握して、踏み外した監督指針になってしまわないように配慮願いたい。

一方的に提供されたものが理解されるか

(JWordのプリインストールでお馴染みの)NECが、「VALUESTAR」、「LaVie」シリーズにPhishWallクライアントをプリインストールしているようで、次のような質問がFAQになっているようだ。

  • インターネットを開いた最初に(PhishWallの最新バージョンがダウンロードできます..., Yahoo!知恵袋, 2006年11月10日

    インターネットを開いた最初に(PhishWallの最新バージョンがダウンロードできます。最新版にアップデートするには「ダウンロード」をクリックしてください)
    と小窓が開いてメッセージが表示されるのですが、yesでアップロードしてもいいのでしょうか?、又この表示を出さなくする方法もご指導下さい。

  • QNo.2214115 以下のアップデートがあります。ダウンロードしますか?, OKWave, 2006年6月13日

    以下のアップデートがあります。ダウンロードしますか?
    PhishWallのアップデートプログラム
    ファイルサイズ: 1526454 バイト

    ------------------------------------
    上記の内容がホームページを見るたびに出てきます
    何をダウンロードしますかと?出てきているのか意味が分からなくて
    困っています。よろしくお願いします

  • QNo.3106838 ウイルスバスターについて。, OKwave, 2007年6月22日

    パソコンを購入したのですが、インターネットに接続するとphishwall(SecureBrain)を、最新版にダウンロードしますか?とでます。
    すでにウイルスバスターをいれているのですがダウンロードしてもいいのでしょうか?

  • PhishWallのダウンロード, パソコン初心者@2ch掲示板, 2007年6月7日

    インターネットに繋げたときに
    PhishWallのアップデートプログラム
    ファイルサイズ: 2229916 バイト
    ダウンロードしますか?
    とでてくるんですがどなたか知っている方はおられますか?

それが何かすらわからない状態でユーザに使わせることが、はたして幸せなのかどうか。

追記

petname toolについて、脚注4の訂正が酷くなったので、本文中に反映しつつ加筆した。正式名称は「Petname Tool」ではなく「petname tool」のようなので修正した。

小見出しを追加。アンカーを置いた。

また、2005年12月24日の日記の件以下の部分を追記した。

*1 「nProtect:Netizen」の導入意義は、キーロガー対策などにあるということなのだろう。よく知らないが。

*2 中国銀行は、「セキュリティソフトを起動する」というページで、「「スパイウェア」や「フィッシング詐欺」等の被害防止に効果がある(中略)「nProtect Netizen」(エヌプロテクトネチズン)を導入いたしました」と言っているが、どのようにフィッシングに効果があるのか理解して言っているのだろうか? 本物サイトで起動してから偽サイトに誘導されるという状況をどう考えているのか。

*3 https:// のページでのみ黄色でこのように表示され、http:// のページでは灰色で入力することはできなくなっている。

*4 以下訂正により削除(30日16時42分):同じサイトであることはドメイン名単位で判定しているようだ。その場合、Cookie Monster問題が解決しにくいのと同じく、管理ドメインのレベルがどこかがはっきりしないという問題がありそうに思えるが、ちょっとだけ試してみたところ日本の地域ドメインにも対応できているようだ。ただし、きちんとは検証していない。 以下追記に伴い本文へ移動につき削除:訂正(30日16時42分):同じサイトであることは、サーバ証明書の内容を見ているっぽい。バージョン履歴に、それらしきことが書かれている。開発ページにも正式な説明はないっぽい。追記(30日17時20分):論文にちゃんと書いてあった。(略))

*5 CAの公開鍵が異なると別サイトとみなされるようだが、その挙動をユーザが予測できないことが混乱を招いたりはしないだろうか。

*6 Internet Explorer版も誰か作ればいいのにと思うが、このくらいだと無料で配布せざるを得ないので、お金にならないので誰もやらない。サイト運営者側からしか料金を取れないとなると、販売数が限られるので、高額な価格設定とせざるを得なくなる。となると、あまりに簡単な機能やシステム構成では料金に見合わないから、無駄な機能を付けてでも大掛かりなものにせざるを得なくなる。

*7 資料請求ページは稀にしか使わないからすぐに真正性の確認ができなくてもかまわない――という理由でログインページだけをPhishWall対応とするというのは理解できるし、ログインページは「chace.co.jp」だからPhishWallが必要だったのに対して資料請求ページは「joyobank.co.jp」のサーバ証明書があるからPhishWallは不要――というのも理解できるけれども。

本日のリンク元 TrackBacks(54)

最新 追記

最近のタイトル

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