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％防止する」などと宣伝されている。これまでに、
- 素人がやってはいけないセキュリティの「大発明」, 2004年10月11日の日記
- ヤフーからの通知を装った日本語フィッシングで何が起きていたか, 2004年12月5日の日記
- 銀行やマスコミは対策の有効性の範囲で嘘を書いてはいけない, 2005年10月17日の日記
- ワンタイムパスワードは何のためにあるのか, 2006年10月21日の日記
で言ってきたように、フィッシングの被害を防ぐには、偽サイトが本物サイトに通信を中継する攻撃（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は、自分で作成した文書を「書留.com」で自分宛に送り、それを自分で開くにあたって、自分のWebサイト上に設置した中継サーバ経由で閲覧しようとしたときの様子である。赤矢印で示したように、これらは「http://202.181.….…:10080/」のサーバ上で表示されている。「シンクロNo.」は正常に表示されているし、これを携帯電話側で入力すると「認証OK」となり、図2の画面が現れる。
図2は、認証後に表示される（秘密であるはずの）コンテンツである。これが、別サイト「http://202.181.….…:10080/」上に表示されたということは、別サイトの設置者は、この画面のデータを入手できてしまうということであるし、それだけでなく、これはセッションハイジャックが可能ということであるから、本物サイトを自由に操作できてしまうことを意味する。
こうしたことをやりにくくするいくらかの小手先の改良の余地はある。Flashが使用されているのでURLをFlash埋め込みとするなどすれば、Flashまで書き換えないと中継できないようにできるが、所詮は小手先の策であって、その他のいろいろな策を施したとしても、それらは回避されてしまう。
man-in-the-middle攻撃とはまさに「間に人が入っているよ」という状況を言うのであって、図3のように、犠牲者から送られてくる通信内容を、時には手を加えながら本物サーバに送信して、本物サーバから返ってくる通信内容を、同様に手を加えながら犠牲者へ送り返すというものであり、本物サイト側で小手先の策をとったとしても、間の人がそれをうまく変換してしまう知性をもっていれば、その策は回避されてしまう。実際には、それがプログラムで処理されるよう自動化されない限りフィッシング詐欺犯達にとってコストが見合わないということはあるかもしれないので、いくらかやりにくくする策に意味もあるかもしれないが、原理的に中間者攻撃に脆弱な方式は対策し切ることができない。
こうしたことをなぜ声を大にして言うのかといえば、フィッシング対策にならないソリューションを導入して、「フィッシング詐欺を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月に次のように予言して警鐘を鳴らしていた。
- Bruce Schneier, Two-Factor Authentication: Too Little, Too Late, Communications of the ACM, vol.48, No.4, (2005).
- Schneier: 'Two-factor security is not our saviour' （Schneier曰く「二要素認証セキュリティは我々の救世主ではない」）, ComputerWeekly.com, 2005年3月21日
- Banks 'wasting millions' on two-factor authentication（銀行らは二要素認証で億単位の金をドブに捨てている）, The Register, 2005年3月15日
- More on Two-Factor Authentication, Crypto-Gram Newsletter, 2005年4月15日
そして2006年7月、米国のCitibankをターゲットとした中間者攻撃によるフィッシングが現れ、二要素認証が役に立たなかったということで騒動になった。
- Citibank Phish Spoofs 2-Factor Authentication, washingtonpost.com blog, Brian Krebs on Computer Security, 2006年7月10日
- Man-in-the-middle attacks Citi authentication system, Finextra Research, 2006年7月12日
- ワンタイム・パスワードでは防げない“中間者攻撃フィッシング”が出現, 日経IT Pro, 2006年7月13日
- Man-in-the-middle attack on Citibank users concerns experts, SC Magazine US, 2006年7月14日
- Phishers Beat Citi's Two-Factor Authentication, Bank Systems & Technology, 2006年7月18日
- Phishing and forward looking financial institutions, Financial Services Tecnology US edition, 日付不明
2007年1月には、中間者攻撃型フィッシングの構築キットが現れていると、RSA Securityが警告を出している。
- RSA Alert: New Universal Man-in-the-Middle Phishing Kit Discovered, RSA Security Inc. Press Release, 2007年1月10日
こういう状況があったので、今年のIPAの「情報セキュリティ検討会」でこのことを白書に入れるよう提案したところ、「情報セキュリティ白書 2007年版」に次のように記載された。
第5位 ますます多様化するフィッシング詐欺
（略）海外では、偽サイトが本物のサイトと利用者の間に入り込む、中間者攻撃（→用語集参照）という手口でのフィッシング詐欺が問題となりました。2006年7月に米国の大手銀行が被害に遭った事件では、銀行がワンタイムパスワード方式による二要素認証（→用語集参照）システムを導入していたにもかかわらず、被害を受けてしまいました。セキュリティトークン（→用語集参照）を使用したワンタイムパスワード（→用語集参照）方式は国内でも使われていますが、中間者攻撃によるフィッシング詐欺に対しては効果がありません（参考資料[39]）。
また、日本銀行の「日銀レビュー・シリーズ」の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日に別の記者発表があったようで、新たな記事も掲載されていた。日経ソリューションビジネスとマイコミジャーナルが、フィッシングを防止できると書いてしまっている。
- 日本HPとソフトバンクBB、携帯電話を使ったWeb認証基盤で協業, 日経ソリューションビジネス, 2007年9月25日
それ単独で「鍵」となるデータをネットワーク上に流さずに認証できるうえ、「偽サイトによるフィッシングを排除できる」（ソフトバンクBB）。このため、高度な認証を必要とする金融機関や、ECサイトなどに向くという。
- 日本HPとソフトバンクBB、携帯電話を利用するWeb認証システムを発表, マイコミジャーナル, 2007年9月25日
本システムにおいては、別々に管理されたシステムがシンクロして初めて認証が行える仕組みを利用しており、例えばフィッシング詐欺などで使われるニセのサイトとはシンクロしない。
以下の他の記事はフィッシングについて触れていない。
- 携帯電話を利用した多次元認証システム、日本HPとソフトバンクBBが提供, @IT, 2007年9月25日
- 携帯電話をWebサイトの2要素認証に利用，日本HPのSSOソフトに認証オプション, 日経IT Pro, 2007年9月25日
- 日本HPとソフトバンクBB、携帯電話におけるSSO認証で協業, ITmedia, 2007年9月25日
- 日本HPとソフトバンクBB、携帯電話を活用したウェブ認証システムで協業, CNET Japan, 2007年9月25日
*1 イーバンク銀行のIPアドレスによるアクセス制限の対策も、使用する端末ごとにIPアドレスを登録しておく必要がある点で、同じ制約がある。
*2 携帯電話側のサイトには総当り攻撃はないだろうという前提の場合。PC側サイトへの総当り攻撃の対象となるのは、この方式ではセッションIDへの総当りのみであり、これはロックアウト処理する必要がない。
*3 ちなみに、「しくみとしては核ミサイルの発射ボタンと同じ」というのは、記事中10枚目の写真のスライドで説明されていたようだ。核兵器炸裂時の写真を使うとは不謹慎な人なんだなと感じた。他のメディアはこの写真を載せていない。
*4 もっとも、この想定においては、6月29日の日記「サブスクライバーIDをパスワード代わりに使うべきでない理由」の後半（「もうひとつ、次の理由がある」以降の部分）で書いていたように、アクセス元をキャリアのIPアドレスに限定する策も回避されるので、本人確認用IDを悪意ある者に何らかの原因で知られている状況（例えば、信用できないサイトにサブスクライバIDや端末IDを送信してしまった過去があるなど）では、たとえ https:// のページにしていたとしても、その本人確認用IDで成りすまされる危険がある（携帯電話を盗まれたのと同等の状況）。本人確認用IDを不用意に送信しないことを徹底するのが非現実であるとするなら、キャリアと認証サーバ間を専用線ないしVPN接続とするべきかもしれない。SyncLockがそうしているかどうかは知らない。
