Baldanders.info

産業技術総合研究所が発表した 「フィッシング対策のための HTTP 相互認証プロトコル」 の実証実験が Yahoo! Japan で行われているようです。

• パスワード相互認証プロトコルの技術評価用ソフトウェアを公開
• 誕生！フィッシング防止ブラウザ （Yahoo!オークション - 安全対策研究所）
• 2008年6月27日「フィッシング詐欺防止技術の公開テスト開始」　サイエンスポータル編集ニュース

恥ずかしながらこの話， 全くノーチェックでした。 昨年の時点で相互認証プロトコルを IETF へ Internet Draft として提出しているようです。 アンテナ感度落ちたなぁ... orz

個人的には IE や Firefox じゃなくて Lunascape というのが気になります。 既に Firefox 用の「MutualTestFox」とかも用意されているのに（Firefox 3 には対応してなさそうだけど）。 ブラウザの作者が日本人で連携しやすいからとか？ それとも実証実験なので一般的なブラウザは使いたくないとか？

で， ここでも書かれているのですが， なんぼなんでも「アドレスバーの入力欄なら URL を確認せずにいきなり入力しても大丈夫」ってのは言い過ぎだろう， と思うのですが， ほんじゃあどういう仕組みなんだ？ と思って少し調べてみました。 幸い（英語の資料を読まなくても）「暗号と情報セキュリティシンポジウム（SCIS） 2008」の講演論文が PDF で公開されていて， これがなかなか分かりやすかったので， 以降はこの論文をベースに考えていきます。

そもそも， Phishing というのはソーシャル・エンジニアリングの一種であり， それっぽい Web ページを演出することによってパスワードやクレジットカード番号などの秘密情報を盗み出そうとするものです。 論文では Phishing の手口を5つ挙げています。 すなわち

1. 認証を要求せずに，直接クレジットカード番号や個人情報等を入力させ，これを騙し取る。
2. 認証を要求し，入力されたユーザID とパスワードを騙し取る。
3. 認証を要求するが，入力したパスワードによらず認証が成功したと見せかけ，続く画面でクレジットカード番号や個人情報等を入力させ，これを騙し取る。
4. 認証を要求し，入力されたパスワードを正規サイトに中継し，パスワードが正しいときだけ， 1 および 2 と同様にパスワードやクレジットカード番号等を騙し取る。
5. 認証を含むすべての通信内容を正規サイトに中継し，通信内容の窃取，セッション識別情報を窃用したセッションハイジャック，リクエスト内容の改竄等を行う。

です。 最後の2つは中間者攻撃（man-in-the-middle attack）と呼ばれるもので， 一番最後の手口では， ワンタイムパスワードなどを用いた， いわゆる「2要素認証」も突破できます。

Phishing は今や完全に組織犯罪化している点は注目すべきです。 サイエンスポータルの記事によると， Phishing の被害についても

「国家公安委員会などが毎年公表する「不正アクセス行為の発生状況」によると、2007年に検挙された不正アクセス事件1,438件のうち1,157件がフィッシングでパスワードを詐取した手口によるもので、インターネットオークションのサービスが標的とされたケースが大半を占めている。」

そうです。 中間者攻撃は Script Kiddy が安易に手を出せるようなものではなく， それなりのリソースを用意する必要がありますが， Phishing が組織犯罪化している現在， それだけのことをするインセンティブが存在するというわけです。

産総研が発表した「フィッシング対策のための HTTP 相互認証プロトコル」（面倒なので，以降 MutualAuth と略称します）では， 上述の5つの手口のうち2～5を防ぐことができます。 残念ながら最初の手口は防ぐことができません。 これは認証を伴わないアクセスだからです。 したがって， やはり「アドレスバーの入力欄なら URL を確認せずにいきなり入力しても大丈夫」ってのは言い過ぎな気がします。 まぁ， 認証も行わずに秘密情報を入力させるようなサービスは使わないほうがいいと思いますが。

MutualAuth は PAKE （Password Authenticated Key Exchange; ISO/IEC 11770-4）の一種である KAM3 （Key Agreement Mechanism 3）をベースにしています。 MutualAuth の特徴は以下のとおりです。

• クライアント（ブラウザ）とサーバが事前に同じパスワードを共有し，この情報を相互に確認しあうことで認証を行う。
• 認証の過程においてパスワードを直接送信することがなく，パスワード情報が盗聴者および中継者によって盗まれることが無い。また，窃取した情報を元にオフライン攻撃による全探索を行った場合でも，正規のパスワードに関する情報を入手することが不可能。
• 通信の暗号化機能はなく，既存の TLS を用いる。
• クライアント側は，ホスト名・（ホストから送られて来る） realm 値・ユーザ名・パスワードを組み合わせ Hash した値を weak secret として用いる。ホスト名を結びつけることで中間者攻撃を防ぐことができる。

また， ユーザ名およびパスワードの入力インタフェースについても， アドレスバーの横に配置することで入力欄を詐称しにくくしています。 認証が成功すると結果が同じくアドレスバーの横に表示されます。 ユーザはその部分を見ることで認証済みのサイトかどうか確認できるわけです。

ざっと見た感じでは仕組み自体はとてもよくできていると思います。 Phishing の何が問題かというと， サーバからユーザを認証する仕組みはあるのにユーザからサーバを認証する統一的な仕組みがないことです。 SSL/TLS があるじゃないか， と言う人もいると思いますが， 件の論文にも書かれているように， 証明書が（CA で証明された）正しいものであることは Phishing サイトでないことを保証しませんし （EV SSL も審査基準をどこに置くかでどうにでもなる。 個人的には EV SSL も， なるべく多くのサイトで使えるようにするために， 審査基準を甘くせざるを得なくなるようになり， 文字通り「屋上屋を架す」結果になりそうな気がするのだが）， クライアント認証を使うにしても鍵の管理が煩雑になって（鍵は使用するマシンごとに個別に管理する必要がある）あまり使い勝手が良くありません。

MutualAuth の問題は普及率がどうなるかだと思います。 上述のように MutualAuth ではユーザ操作も変わってきます。 認証方式が新旧混在の状態だとユーザの意識もなかなか変わらず， うっかり Phishing ページを踏んでしまう事故も減らないのではないでしょうか。 あと， Web サービス側がつくりを変更しなければならないのも問題でしょう。 決済系のサービスから地道に啓蒙していくのがいいかもしれません。 そのためには日本のサイトじゃなくて国外のサイト（Yahoo! Japan じゃなくて Yahoo! とか PayPal とか）にアピールすべきと思います。 わたしも Yahoo! Japan の認証が必要なサービスは全く使ってないので， 実証実験に参加することはないでしょう。

まっ， 今後の動向には期待しています。 まずはドラフト案を通して RFC として認可されるところからでしょうか。