HTTPパスワード相互認証プロトコル
産総研 > RCIS > フィッシング対策のためのHTTP相互認証プロトコル > プロトコルの設計に関する詳細のFAQ

プロトコルの設計に関する詳細のFAQ

目次

この技術ですべてのフィッシング被害を防止できるとは思えないのですが。

たしかにその通りです。一般的に言って、どんな技術を導入するにしても、ユーザは何らかの使い方を知っていなければなりません。そして、正しい使い方ができなければフィッシング被害は避けられないでしょう。技術で解決を図るときは、できるだけ単純な使い方が望まれます。

Mutual アクセス認証では、

  1. 「パスワードはアドレスバー領域の専用入力欄にしか入力しない」
  2. 「個人情報やクレジットカード番号などを入力するときは、必ず、Mutual アクセス認証でログイン中であることを確認して行う」

という、2 つの使い方のルールでフィッシング被害を防止しようとするものです。

この技術で救われるのはどんな人たちですか。

偽サイトに注意が必要であることを知っている人、つまり、「Web サイトにカード番号や個人情報を入力する際にはサイトが本物かどうか確認する必要がある」ことを心得ている人が対象です。そんな人でも、うっかり確認を間違えてしまうことはあるかもしれません。Mutual アクセス認証は、そうしたミスを防止します。

従来では、サイトが本物かどうかは、アドレスバーに表示される URL のドメイン名を見ることで確認していますが、似通ったドメイン名が使われていると偽サイトだと気付かなかったり、急いでいるときには見間違えてしまうこともあるでしょう。Mutual アクセス認証が用いられていれば、本物サイトであることは緑色の表示によって確認できます。また、パスワードの入力を、アドレスバー領域の専用入力欄に入力するようにしていれば、サイトが本物かどうか確認しなくても、いつでも安心して入力してよいことになります。

初期登録はどうするのですか。

よい質問です。初期登録で個人情報を入力するときには、「Mutual アクセス認証でログイン中であることを確認して行う」というわけにはいきません。サイトには、まだアカウントがないのですからログインができません。

この場合は、従来の方法でサイトの真偽性を確認するほかありません。一般的に、初期登録の際には、偽サイトか本物サイトかという以前に、そのサービス自体が信用に値するものかを見極める重大な決断を必要とするはずです。よく知らないサイトであるなら、世間的に信頼に足るとされているサービスであるかどうかを確認する必要があるでしょう。著名なサイトに初期登録する場合ならば、ドメイン名を確認するか TLS (SSL) のサーバ証明書の内容を確認して、本物サイトかを確認することになります。

フィッシングは通常、普段使用しているサービス(既にアカウントを持っているサービス)の偽サイトに誘導されることで騙され易くなるものであり、Mutual アクセス認証は、そうした状況で偽サイトを見抜けるようにするものです。

Mutual アクセス認証を使えば TLS は不要になるのですか。

Mutual アクセス認証は、暗号技術を用いて認証を実現しますが、通信内容の暗号化は行いません。したがって、従来 TLS が必要だった状況では、従来通り TLS との併用が必要です。

どんな場合に TLS の併用が必要ですか。

従来 TLS が必要とされてきた状況においては、同様に併用が必要です。たとえば、公衆無線 LAN のアクセスポイントからインターネットに接続しているときや、ホテルや空港などの有線 LAN で接続しているとき等、盗聴されたり改竄される危険性が現実的に高い場合があります。一般的に、通信路が安全でない場合には TLS が必要であり、Mutual アクセス認証を使うときも、それは同じです。

TLS を併用しない場合にはどんな危険が生じ得ますか。

通信路が安全でない場合に TLS を併用しないと、通信内容を盗聴されたり改竄されたり、ログインセッションをハイジャックされる可能性があります。また、DNS 応答を差し替えるなどの手口によって、偽サーバに接続させられた際に、偽サーバが本物サーバに通信を中継する中間者攻撃を行っている場合、偽サーバであるにもかかわらず、 Mutual アクセス認証の認証が成功する(緑色表示になる)ことがあります。その結果として、入力データを盗聴されたり改竄されたり、ログインセッションをハイジャックされる可能性があります。なお、Mutual アクセス認証のために入力したパスワードについては、盗まれることはありません。

なぜ通信内容も暗号化するように設計しなかったのですか。

よい質問です。PAKE 方式は認証と同時に鍵交換を実現するものですから、PAKE を採用した Mutual 認証は、認証成功時にクライアントとサーバで安全に鍵を共有することが可能です。そして、この鍵を用いて通信内容を暗号化するプロトコルとして設計することも可能でした。しかし、私たちはそのような設計を避けました。理由は以下の通りです。

1. 一般に Web において暗号化を行う場合、暗号化されていることが利用者の目で確認できなければ意味がありません。たとえば、フォームに入力されたデータを POST する Web ページがあるときに、その Web ページの作者が POST 先を https スキームの URL として指定していても、入力データは必ず暗号化されるとは限りません。なぜなら、フォームのページが http スキームで受信したものならば、そのページが通信路上で改竄されて、POST 先の URL を http スキームに書き換えられる可能性があるからです。フォームのページを https スキームの URL に置いていても、そのページに到着する前のリンク元のページが http スキームで受信したものであれば、同様に、リンク元のページが通信路上で改竄されてリンク先 URL が http スキームに書き換えられる可能性があります。したがって、結局のところ、利用者が、フォームに入力しようとするときに、現在のページの URL が https スキームであることを目で確認する以外に、安全に使える手段はありません。

したがって、もし Mutual 認証でデータの暗号化を行う設計とした場合、「TLS は使用していないが、Mutual 認証による暗号化はなされている」という状況を、利用者にどう見せるかが問題となります。Mutual 認証による暗号化がなされている場合に、暗号化されていることを示すマーク表示をブラウザの UI に設けたとしても、利用者はそれを理解できるかという問題があります。「アドレスバーの URL は http スキームで、TLS の錠前アイコンも現れないが、Mutual 認証の暗号化マークはある」という状況がどんなセキュリティレベルを意味するのか、利用者にとって理解はたやすくないと考えました。「Mutual 認証による暗号化がなされているときはアドレスバーの URL を https:// として表示する」という案も検討しましたが、https スキームの意味を変更してしまうような提案は、標準として受け入れられないだろうと考えました。また、PAKE で暗号化されていることを示す新たなスキーム「httpp」を用意するという案も検討しましたが、http、https、httpp と 3 つものセキュリティレベルを利用者に理解してもらうのは酷である(http と https を見分けるのが限界)と考え、それらの案は破棄しました。

2. 「アドレスバーの URL は http スキームで、Mutual 認証の暗号化マークを示す」という案には、別の問題もあります。JavaScript 等の same origin ポリシーがセキュリティに影響します。JavaScript の same origin ポリシーでは、http スキームのページと、https スキームのページは、別の origin のものと解釈されています。これは、同じホスト上のページであっても、http ページの JavaScript が https ページのコンテンツにアクセスできないことを意味します。もしそれを許してしまうと、通信路上の盗聴者は、http ページをブラウザに送り込んでそこに攻撃用の JavaScript を書き込んでおくことにより、同じホスト上の https ページの内容を DOM 経由で読み取ったり書き換えたりできてしまいます。同じ問題が、Mutual 認証で暗号化されたページにも生じます。暗号化されていないページから、Mutual 認証で暗号化されたページへの、DOM 経由でのアクセスを禁止する必要があります。スキームを httpp などとすれば簡単にそれは実現できそうですが、スキームを新たに設けないとすると、origin を区分けする新たな枠が必要となります。既存の JavaScript 処理系に変更を必要とするそのような提案は、標準として受け入れられないだろうと考えました。

3. Web で暗号化を行う場合、暗号化する旨の指示はブラウザ側から行うものでなければなりません。なぜなら、HTTP のリクエスト中に含まれるデータを暗号化する必要があるからです。HTTP over TLS は、https スキームの URL にアクセスしようとするブラウザの指示によって暗号通信が開始されますので、とくに問題がありませんでした。それに対し、Basic/Digest アクセス認証の枠組みに沿った Mutual アクセス認証で暗号化通信をしようとした場合、Mutual 認証をするかしないかは、サーバ側から指示されるものであるため、問題が生じます。HTTP リクエストを送信する際に、それを暗号化して送信するべきかは、そのレスポンスに「WWW-Authenticate: Mutual」が含まれていることを確認するまで不明であり、リクエストを送信する前にレスポンスを得ることはできないことから、Basic/Digest アクセス認証の自然な拡張として設計する場合、リクエストを暗号化できるよう設計することはできないと考えました。

以上の理由から、Mutual アクセス認証では、認証処理だけを暗号プロトコルで行い、通信内容の暗号化は行わない設計を選択しました。

TLS と Mutual アクセス認証の位置づけを簡潔に説明してもらえますか。

TLS は、通信路上の攻撃者から保護します。Mutual アクセス認証は、偽サイト上の攻撃者から保護します。TLS は、偽サイト上の攻撃者からの保護には十分ではありません。なぜなら、正規の TLS サーバ証明書を使用するサーバ上に偽サイトが作られることがあるからです。通信路上の攻撃者の脅威よりも、偽サイト上の攻撃者の脅威の方が現実的に大きいとの問題認識から、私たちは、Mutual アクセス認証を設計しました。Mutual アクセス認証は、通信路上の攻撃者からの保護はしません。通信路上の攻撃者からの保護が必要な状況では、従来通り TLS を併用してください。

サーバを認証するというのは TLS のサーバ認証とは違うのですか。

一般に、接続先のサーバが本物であることをクライアントが確認することをサーバ認証と呼びます。サーバ認証は VPN においても実施されています。一般的な VPN では、クライアントは接続先のサーバを事前に固定的に設定しているので、フィッシングに騙されて接続先を間違えるという心配はありませんが、通信路上に盗聴者がいる場合には、盗聴者が通信路上でサーバになりすましてクライアントと暗号化通信を開始しようとする可能性があります。これを防止するのが一般的なサーバ認証です。

Web における TLS のサーバ認証も、通信路上の盗聴者によるなりすましを防止しています。しかし、VPN と違って Web では、事前の接続先の設定を必要としておらず、初めて訪れた Web サイトでも初めから TLS による暗号化通信が可能であるため、フィッシングに騙されて、ユーザが意図するのとは別の Web サイトに接続してしまうことがあります。その Web サイトが正規のサーバ証明書を用いている場合には、ブラウザが警告を出すこともなく正常に接続してしまいます。このとき行われるサーバ認証が、接続先のサーバが本物であることを確認しているかというと、「ブラウザが接続しようとしているサーバか」という意味では確認していますが、「ユーザが意図するサーバか」という意味では確認しているわけではありません。

これに対して、Mutual アクセス認証におけるサーバ認証では、「ユーザがそのパスワードを過去に登録したサイトのサーバである」という意味で、接続先のサーバが本物であることを確認します。そのため、ユーザが信用する本物のサイトにしかパスワードを登録しないようにしていれば、Mutual アクセス認証のサーバ認証は、接続先が「ユーザが意図する本物のサーバ」であることを確認するものとなります。

EV SSL では不足ですか。

従来の TLS では、ドメイン名を保有している者なら誰でもそのドメイン名のホスト用のサーバ証明書を取得することができました。それに対し、EV SSL では、一定の基準を満たす者に対してしかサーバ証明書が発行されません。これによって、正規のサーバ証明書を用いたフィッシングを防止できると期待されています。しかしながら、EV SSL のサーバ証明書は、誰でも取得できるものではなく、たとえば、個人事業主には発行されないため、著名な Web サイトでも EV SSL を利用できない場合があり得ます。

これに対し、Mutual アクセス認証は誰でも利用できます。フィッシングのターゲットは、必ずしも著名な Web サイトに対する大規模な攻撃だけに限りません。たとえば、個人で運営する自分用のサイトでも、フィッシングの被害はあり得ます。嘘のリンクなどに誘導されて、自分用サイトの偽サイトを訪れ、うっかりパスワードを入れてしまって、サイトを乗っ取られてしまうといった被害もあり得るでしょう。Mutual アクセス認証は、そうした攻撃から守るためにも利用できます。

Digest 認証にも相互認証の機能はあったはずですが、Digest 認証では不足ですか。

RFC 2617 によれば、Digest 認証には Authentication-Info ヘッダに「response-auth」ディレクティブが用意されており、これによって、サーバがユーザのパスワードを知っていることをクライアントに証明し、相互認証を実現できるとされています。しかし、response-auth ディレクティブは「optional」とされています。サーバが response-auth を付けずに応答した場合にブラウザがそれを処理するべきかも規定されていません。

PAKE を使わなくても相互認証は実現できるのではないですか。

たしかに、Digest 認証の response-auth ディレクティブを強制したプロトコルや、CHAP のようなプロトコルを採用することも考えられます。しかし、これらのハッシュベースの認証プロトコルでは、オフライン攻撃によるパスワード復元に対して強度が十分でないと考えています。

ハッシュベースの認証プロトコルでは、通信路上で盗聴された場合、または、偽サイト上でパスワードを入力してしまった場合、攻撃者は、パスワードに対する一方向性ハッシュ関数の計算値を入手することになります。攻撃者にとって、その一方向性ハッシュ関数の式は既知であるため、総当たり式に、あるいは辞書攻撃手法などを併用して、多数のパスワード候補で計算してみることで、入手した値を導き出すパスワードを探し当てることができる場合があります。

暗号学研究者によれば、今日では、80 ビットのパスワードエントロピーでは危険であるとされており、安全であるためには 100 ビットのエントロピーが必要であるとされています。NIST SP 800-63 の Appendix A によれば、一般的なパスフレーズでは 40 文字でも 62 ビット程度のエントロピーしかなく、100 ビットのエントロピーとするには、ランダムな文字列でも 16 文字が必要とされています。

これに対し、PAKE による認証プロトコルでは、盗聴者や偽サイトが入手できるデータは、パスワードの一方向性ハッシュ関数ではありません。Diffie-Hellman 鍵共有アルゴリズムなどと同様に、各々が選択した乱数によって加工されたデータが得られるのみであるため、盗聴データからパスワードを復元することが困難です。

PAKE を使うなら既に TLS-SRP があるのになぜ TLS-SRP を使わないのですか。

たしかに、TLS-SRP というプロトコルが 2007 年 11 月に Informational RFC となりました(RFC 5054: Using the Secure Remote Password (SRP) Protocol for TLS Authentication)。SRP は PAKE の一種で、パスワードによる相互認証と鍵交換を実現します。これを TLS の鍵交換と認証に用いることで、PKI がなくても、つまり認証局発行のサーバ証明書を用いなくても、セキュアな TLS 通信を実現できるというものです。TLS-SRP の用途としては、IMAPS や POPS などのように、クライアントが 1 本の接続をシーケンシャルに使うタイプのプロトコルにはうってつけと思われます。しかしながら、Web アプリケーションのログイン機構のために用いるには向いていないと私たちは考えます。以下がその理由です。

TLS-SRP はコネクション指向なプロトコルです。つまり、接続の開始時に認証処理があり、認証完了に続いてコマンド送信等が行われ、接続を閉じることでログアウトします。IMAPS や POPS で用いる際にはまさにそのような動作をします。Web アプリケーションはそれとは対照的です。Web アプリケーションは複数の HTTP 接続を同時に使用します。このとき HTTP は、パケットベースのプロトコルのような働きをします。Web アプリケーションにおいては、1 つの Web サーバ上の複数の Web アプリケーションに対するいくつもの同時並行的なリクエストが、1 本または数本の HTTP トランスポートを相互に混ざり合いながら共有して送信されます。その上、HTTP/1.1 の keep-alive 機構によって、1 本の接続にいくつものリクエストがパイプライン状に流されます。

TLS-SRP を Web アプリケーションの認証に用いる場合には、異なる Web アプリケーションに対する 2 つのリクエストは、別々の TLS-SRP 接続で送信しなければなりません。同じホスト上に複数の Web アプリケーションが存在する場合、ブラウザがそれらをどうやって区別するかが問題となります。仮にそれができたとして、認証 realm で Web アプリケーションを区別するとしても、同じホスト上のサーバが、TLS-SRP の認証時にどうやって realm を区別するかが問題となります。TLS のネゴシエーションの段階では、HTTP のリクエストをまだ受信できないので、HTTP のヘッダから realm を取得することはできません。これを解決するには、RFC 3546 (Transport Layer Security (TLS) Extensions) に倣って、ホスト名だけでなく realm も送信できるようにさらに拡張するか、SRP のユーザ名として realm を含ませることで回避するくらいしか方法はなく、エレガントな設計ではありません。

つまり、TLS-SRP を自然な方法で HTTP over TLS として用いる際には、1 つのホスト上に 1 つの Web アプリケーションしか設置できないことになります。また、認証なしのページと認証ありのページが 1 つのホスト上に同居できません。これは、従来の TLS クライアント認証を用いる場合でも同じで、これは、TLS クライアント認証があまり普及していないことの 1 つの要因であると私たちは考えています。それに対して、Mutual アクセス認証は、Basic/Digest 認証と同様に、複数の Web アプリケーションを 1 つのホスト上に同居させることができますし、認証なしのページと認証ありのページを同居させることもできます。

アドレスバーが偽装されたらフィッシングは防げないのではありませんか。

たしかに、2004 年ごろに流行したフィッシングの手口では、アドレスバーの上に枠のないウィンドウを乗せる手法により、偽サイト上でアドレスバーに本物サイトのアドレスを表示していました。しかし、これは、Windows XP SP1 (Service Pack 1) の Internet Explorer 6 SP1 を使用した場合に可能なことで、その後にリリースされた Windows XP SP2 や、Internet Explorer 6 SP2 では、そのような偽装ができないよう対策されています。

Internet Explorer に限らず、アドレスバーを偽装できるようなブラウザは、ブラウザに脆弱性(セキュリティ上の欠陥)があると言えます。現在では、そのような脆弱性が発覚すると修正されるのが業界の流れとなっており、アドレスバー領域はアクセス先のコンテンツによって偽装されることがないと言えます。

Basic 認証や Digest 認証でアドレスバー領域のパスワード欄が使われたら、偽サイトにパスワードを取られてしまうのではありませんか。

ブラウザの実装者は、アドレスバー領域のパスワード欄は Mutual アクセス認証専用とし、Basic 認証や Digest 認証でそこを使うことのないようにしなければなりません。プロトコルの Internet-Draft とは別に、ブラウザの実装において守るべき点をまとめた Internet-Draft を書き起こす予定です。

フォーム認証が主流となり Basic 認証があまり使われていない現状からして、Mutual 認証はあまり使われないのではありませんか。

たしかに、Basic 認証は、古くから Web ブラウザに標準搭載されているものであるにもかかわらず、近年ではあまり使われていません。Web アプリケーションにログイン機能を設ける際には、HTML フォーム認証(Web ページ内にパスワード入力欄を設ける方式)を用いるのが主流となっています。Basic 認証が本格的な Web アプリケーションで使われないのは、次のことが原因であると私たちは考えます。

  1. ログアウト機能がないこと
  2. ログインせずに同じページのコンテンツを閲覧するという使い方(ゲストアクセス)ができないこと
  3. サーバ側からログイン状態を無効にする手段が存在しないこと
  4. ホストをまたがったシングルサインオンが実現できないこと

そこで、Mutual 認証においては、プロトコル設計段階からこれらの欠点を解消するよう工夫し、次の機能をプロトコル仕様に取り入れています。

  1. ログアウト機能: Web サイトにログイン中は、ブラウザにログアウトボタンが現れるようにし、これを押すことで当該サイトからログアウトできるようにした。
  2. ゲストアクセス機能: Basic 認証や Digest 認証にはなかった、「Optional-WWW-Authenticate」レスポンスヘッダを新たに用意することで、ログイン前の状態で Web ページのコンテンツを閲覧しながら、ログイン可能なページではいつでもパスワードを入力してログインできる機能を取り入れた。(2008 年 5 月現在のリファレンス実装では未実装。)
  3. タイムアウト指定機能: ログインしたユーザについて、一定時間操作がなかった時点で、サーバ側からブラウザを強制的にログアウト状態にさせる機能(「logout-timeout」フィールド)を取り入れた。(2008 年 5 月現在のリファレンス実装では未実装。)

また、4. のホストをまたがったシングルサインオンについては、「WWW-Authenticate」レスポンスヘッダで「auth-domain」パラメータを指定することにより、同じドメイン上の異なるホストをまたがってログイン状態を継続させる機能を、次の draft バージョンでプロトコル仕様に導入する予定です。

これらの機能が搭載されることにより、フォーム認証に換わって、HTTP Mutual アクセス認証が用いられるようになるものと期待しています。

フォーム認証を使わないとすると、ワンタイムパスワードを使いたいときはどうすればいいですか。

アドレスバーのパスワード入力欄にワンタイムパスワードを入力することで Mutual 認証を処理できるよう、Mutual 認証のプロトコルを一部拡張することを検討中です。

シングルサインオンとの親和性はどうなっていますか。

同じドメイン名上のホストをまたがるシングルサインオンについては、上に述べた通り、「auth-domain」パラメータでシングルサインオンを実現しています。これは従来、cookie の「domain」属性の指定によってなされてきたものに相当します。さらに広い範囲でのシングルサインオン、つまり、ドメイン名をまたがったシングルサインオン(Liberty や OpenID などに代表されるもの)については、近年需要が高まっていることを認識しています。これらと Mutual アクセス認証との親和性については検討中であり、それらとの連携のための小さな機能を加える可能性はあります。

サーバ側でパスワードはどのような形式で保持するのですか。

一般に、サーバ側でユーザのパスワードを保持するときは、可能であれば一方向性関数などで変換した値を保持して使うようにするのが、セキュリティの定石となっています。Mutualアクセス認証においても、専用に設計された一方向性関数で変換した値を保持して使います。

サーバのパスワード DB が漏洩したときのリスクはどうなっていますか。

サーバのパスワード DB に格納される値は、Mutual アクセス認証用に設計された一方向性関数でパスワードを変換した値です。チャレンジレスポンス型の認証プロトコルでは、サーバのパスワード DB が漏洩すると、漏洩した情報を直接用いて認証を突破されますが、Mutual アクセス認証で採用している PAKE 方式の ISO 11770-4 KAM3 では、そのようなことはありません。

また、この一方向性関数は、そのサーバのホスト名も入力の一部としているので、作成されたパスワード DB エントリは、そのホスト名のサーバ以外では使用できないものになっています。したがって、もしサーバのパスワードDBが漏洩して、攻撃者がそのパスワード DB を使って偽サイトを設置したとしても、そこで Mutual 認証のログインが成功することはありません。

もちろん、漏洩した情報に対するオフライン攻撃が試みられた場合には、いくらかの時間の後にパスワードが復元されてしまいますが、このリスクは従来と同様で、防ぎようのないものです。なお、ハッシュ演算のキーにホスト名とユーザ名が含まれているので、いわゆるレインボーテーブルを用いた高速なパスワード復元も防止されています。

ドメイン名を変更するとき、既存のアカウントはどうなりますか。

デフォルト設定での運用では、サーバのパスワード DB に格納される値は、ホスト名をキーにした一方向性関数で変換されているため、パスワードDBはホスト名の異なるサーバでは使用できません。ただし、プロトコル仕様の次の draft バージョンで導入する予定の「auth-domain」パラメータによるシングルサインオン機能を用いれば、同じドメイン上のホストである限り、同じパスワード DB を共用できます。

しかしながら、ドメイン名の異なるホストでは「auth-domain」を用いてもパスワードDBを共用することはできません。したがって、もし、Mutual アクセス認証で運用中の Web サイトでドメイン名を変更する必要が生じた場合には、パスワード DB を継続して利用できなくなり、ユーザのパスワードの再登録が必要になってしまいます。この問題の回避策としては、将来のドメイン名変更に備えて、ユーザのパスワードを、公開鍵暗号などで暗号化して、別途データベースに保管しておき、復号鍵を別の場所で厳重に管理しておく方法などが考えられます。