Fail-Safe C の研究を始めるに当たって「C言語を対象にする」と決めた時点で、 実用に供するというのは大前提の1つです。これからも Fail-Safe C の開発は継続して 進めていきますので、暖かいご声援を頂ければと思っています。

■ [Work] MutualTestFox 公開

で、立て続けのプレスリリース第2弾が、「パスワード相互認証プロトコルの技術評価用ソフトウェアを公開」です。

こちらは、RCIS に入ってから始まった共同研究の成果ソフトウェアの第1弾で、 フィッシングを認証プロトコルを使って何とか防げないか、という着眼点からの研究です。

技術的な肝の部分は、暗号プロトコルをうまく使うことで、ユーザが間違ってフィッシングサイトを 踏んでしまってそこで認証を行おうとしても、(1) パスワードの情報が相手に伝わらず、かつ (2) サーバ側に パスワードDBがない限り必ず認証が失敗する（フィッシングサイトが騙そうと思っても「認証成功」と嘘をつけない） という性質を実現していることです。

(1) に関しては、たとえ8文字程度の辞書探索可能なパスワードを使っていても、 通信されたデータからは正規のパスワードを復元できないように加工されているのがミソです。 普通に APOP (例の脆弱性は除外しても) や CRAM-MD5 などのハッシュを使ったアルゴリズムでは、 1回通信した情報を記録しておいて後から辞書攻撃を行えばパスワードがバレますが、 今回のプロトコルでは予めパスワードDBを事前に持っていないと認証が成功せず、 後から辞書攻撃ができないようになっているのです。

(2) に関しては、相互認証の結果を表示するUIまで含めて偽装を防ぐために、 UI設計から変更しています。また、HTTP 認証プロトコルの拡張として実装することにしたので、 その前提で本物サイトへの中継攻撃をうまく防ぐように設計したのがポイントです。 実際に最近のフィッシングサイトは本物サイトを使ってパスワードの正誤を調べている ことがありますが、そのような攻撃ができないようになっています。 通常 PAKE は鍵交換と暗号化を組合わせることが前提になっていて、 そちらで中間者攻撃を防ぐのですが、今回は HTTP レイヤで認証を行い、 暗号化は別途 TLS (HTTPS) を使うように設計しているので、 PAKE で交換した鍵に基づく暗号化を行わずに攻撃に対応できるようにしたのがミソです。

ちなみに、別に証明書をどこかから買ったりしなくても導入できるんで、 商業サイトから個人サイトまで自由に使えるプロトコル、というのも売りの一つです。

こちらは昨年度に Internet Draft を出したところで、 本当にまだまだスタートラインから1歩踏み出したところですが、 興味を持って頂ければ、と思っています。 簡単なお試しサーバも公開しましたので、遊んでみてください。