独立鍵: HTTPS と電子メールを安全にするための提案

The Electronic Frontier Foundation (translated by Takayuki Kawamoto)

Last modified: 2011-11-18 13:59
Last modified as a translation into Japanese: 2012-02-14 15:03:28
Translated from https://www.eff.org/deeplinks/2011/11/sovereign-keys-proposal-make-https-and-email-more-secure.
Original document by Peter Eckersley is distributed under Attribution 3.0 United States (CC BY 3.0),
and this translation is also redistributed under the same license.

本稿は「HTTPS と TLS/SSL のセキュリティ」という連作の第二部である。[第一部(の翻訳)]

前回の記事で、我々は HTTPS と TLS/SSL にある幾つかの構造的な不安要素を論じて、それらがウェブのセキュリティにとって深刻な問題を引き起こし始めている様子を見た。

この記事では、私は「独立鍵」と呼ぶ新しい提案を紹介する。これは認証に使われる暗号化のインターネット・プロトコルに内在する弱点を系統立てて解決するように意図されたものだ。この提案は「草稿」であり、「試験的なもの」として考えてもらいたい。広範囲に実装できるだけの十分な水準にまでアイディアを組み立てて試験するには、少なくとも何年かはかかるだろう。だから、独立鍵の設計がうまくいっても、暫くのあいだは HTTPS の不安要素に何らかの応急処置だけをあてがうことになるだろう(そのような応急処置として何があるかは、後の記事で紹介する)。現在、独立鍵プロジェクトの設計文書は草稿として公開している。そして、この記事では設計の目的と要点について高レベルかつテクニカルでない要約を与えようと思う。また、我々はいまのところプロトタイプの実装にとりかかっており、このプロジェクトを支えていただける資金を募集している。そして、改良もしくは試験的に使ってみられるていどに十分なものができれば、コードを公開する予定だ。

独立鍵の設計では、クライアントとサーバの通信においてサーバが独立鍵を生成した後は、サードパーティに全く依存せずに暗号化のプロトコルを使えるようになっている。しかしこの設計は他にも幾つかの目的をもっており、認証局の増殖という問題を解決する提案や、ドメインの妥当性を解決しないという提案を含んでいる。いちばん大きな要点は、証明書の問題を全く警告しないということであって、それを攻撃からの自動的な回避手段へと置き換えることにある。

証明書に関する警告がなぜいけないのか? どうやってそれをやめるのか?

調査によると、人というものは証明書に関する警告を理解しておらず、しばしば警告に何が表示されていてもスルーしてしまう。これは別に驚くべきことではない。例えば x.509 の証明書などは度外れに複雑で、それを支える規格も仕組みの不明瞭な公開鍵基盤である。ふつう、我々が証明書について何かエラーメッセージを受け取ったとき、そのエラーは自分のせいで起きたのではないと考えるし、そこでやるべき理にかなった反応は、サイトへ行くために警告をスルーすることだと思うだろう*1。しかしそれが意味しているのは、証明書に関する警告が現実の深刻な攻撃を人々に教えようとしているときでも、そうした警告は十分な予防策にはなっていないということだけであり、スルーしてもよいという話では断じてない。

*1擬陽性の判定によって証明書の警告が出てしまう原因としては、証明書の期限切れだとか、それまで使っていたよりもカバーする範囲が狭い証明書を使っているとか [訳者注:ワイルドカードを使える高価な証明書でないかぎり、"www.united.com" と "united.com" には別々のSSL証明書を購入しなければならない]、それから我々が妥当性の転嫁と呼ぶケッタイな現象、つまり幾つかの証明書が妥当であるのはあなたのブラウザがハンドシェイクする前に中間認証局の正しい証明書をキャッシュしていなくてはならないようなものを使っているとか(SSL Observatory ではおおよそ 10 万のサーバがこうした証明書を使っていて、これが怪しげなエラーの原因となっている)、一部のブラウザしか信用を与えていない認証局を利用しているとか、あるいはウェブサーバのオペレータが費用をケチってオレオレ証明書を使っているとかいったことがある。

このような問題の一例として中間者攻撃があり、今年の5月にシリアの Facebook ユーザが発見したものがそれにあたる。その攻撃は好き勝手な証明書を使って組まれており、信頼された認証局がサインした証明書を使っていない。したがって、標的となったユーザは以下のようなものと同じ警告メッセージを目にしていた筈なのである。

Screenshot of a certificate warning in IE7

しかし、カーネギーメロン大学の Usable Privacy and Security 研究室が行った調査が示すように、このように大きな警告画面が出ていても、人々はそれを気にせずにクリックして Facebook へログインしてしまうようなのである。このときに現れている警告画面だけが、彼らのうち何人かを守ってくれたかもしれないのに。

ブラウザの開発者たちは、こうした問題があることはとうに承知していたので、証明書の警告表示を有効にはたらかせようとして、煩わしく思われず、クリックするのが難しくないように、これまでずっと変更してきたのであった。そうした努力は少しずつ効力を発揮してきてはいるのだが、それでもこうしたやり方は賢明な方法ではない。なぜなら証明書の警告をどのように改善しようと、それがたいていユーザにとって何の意味があるのか分からない事務的な理由によって表示されているだけだという事実は変わらないのであって、いまや多くのユーザは警告表示の必然性などおかまいなしに、あるいは実用に駆られてクリックしているだけなのである。

独立鍵の設計においては、証明書の警告表示は不要である。独立鍵を発行しているウェブサイトにおいては(どうやって独立鍵を発行するかは設計文書を参照のこと)、そこへブラウザやメールクライアントでアクセスしても証明書の警告は表示されない。その代わりに、もし或るセッションで TLS を使う通信が通信元と通信先によって独立鍵でサインされていないなら、ブラウザは自動的にその攻撃を回避できる。その場合に最も強いやり方は独立鍵のハッシュ値を計算することであり、それを Tor の秘匿サービスで使う .onion アドレスとして使えばよい。あるいは、通信を保護するもっと弱いやり方としてプロキシや VPN も使えるだろう(今後の記事で、なぜ独立鍵を使った通信には Tor の秘匿サービスを使うことが望ましいかを説明する)。ただし、これらの方法を使うと通信が遅くなるかもしれないので、ユーザは「このサイトへの安全な接続を確立することが困難です。もう暫くお待ち下さい・・・」といったメッセージを、ぐるぐる回るつまらないグラフィックと共に見ることになったり[訳者注:原文を皮肉と解して訳した]、あるいはせいぜい攻撃を迂回する処理の経過をリアルタイムで見せられることになるかもしれない。

攻撃を回避した後であってもブラウザがサーバへの妥当な接続を確立できない場合は、ブラウザがこのサーバに到達出来なかったというエラーをレポートする。

技術的な概要:どうやって独立鍵を生成するのか? クライアントはそれをどう学ぶのか?

設計の上では、独立鍵は妥当なデータの追記だけを認める準中央集権的なデータ構造に生成される。そうするために必要とされる主な要件は、適切なドメインに対して認証局がサインしたサーバ証明書を部分的にコントロールできるよう要求すること、あるいは DNSSEC でサインされた鍵を使ってドメインをコントロールできると示すことである*2

*2現時点の草稿では、更に OSCP による証明書の失効確認をパスすることとか、そのドメインへの全てのトラフィックが HTTP から HTTPS へリダイレクトされており、過去2週間に渡ってHSTS ヘッダがサーバから返されていることといった要件がある。

追記だけを許すデータ構造のマスターコピーは、「タイムラインサーバ」と呼ばれるマシンに維持される。そうしたサーバは、おおよそ 10 ~ 20 台ていどの少ない数で構成される。これらタイムラインサーバにあるマスターコピーの信用度はとても低い。なぜなら、独立鍵のプロトコルは重要な機能の振る舞いを暗号学的に検証できるからだ。独立鍵は、少なくとも一つのサーバが妥当な状態であり続ければ維持される。安定性、検証、そしてプライバシーという目的のために、追記のみを許すタイムライン構造の膨大なコピーは、「ミラー」と呼ばれるマシンにストアされる。そういうタイムラインデータ構造は数百ギガバイトものサイズに肥大化するかもしれないが、目下のところその容量であっても 100 ドル出せば足りるようなストレージに入ってしまうのだ。

クライアントは(暗号化された)クエリをミラーに送ることによって独立鍵を学習する。ひとたび或るドメインの独立鍵をクライアントが学習したら、その事実は後から偶然に独立鍵をチェックするクエリが送られるまでは長い期間にわたってキャッシュされる。この方法は、仮にミラーが不正だったり、ブロックされていたり、あるいは単に信用できない場合でもプロトコルを極めて強固にする、幾つかの好ましい性質をもっている。クライアントのユーザは、抑圧的な条件の(ちょうどシリアやイランやビルマのような)ネットワーク下においても、長い期間にわたってこのプロトコルを使える。なるほど、時としてクライアントがよいミラーを見つけられない場合もありうるが、そのときは全てのミラーを信頼しないようにする。

独立鍵で実現するセキュリティはどれくらい強いのか?

現行の TLS 認証システムには、攻撃者が証明書の信頼性を下げる方法が幾らでもある。独立鍵の設計においては、攻撃者はそうした攻撃を一つは成功させる必要があるだけでなく、追記だけを許すデータ構造に攻撃対象の独立鍵が追記されるよりも前に攻撃できなくてはならないので、時間を遡るタイムマシンという便利なものをもっていなくてはならない。

これが意味するのはこういうことだ。ウェブサイトは、もしそうしたいのであれば、暗号化の安全性をサードパーティに依存する必要がなくなるということである。実際には、我々は独立鍵を運用するサードパーティのサービスプロバイダを利用したドメインにアクセスするだろうが*3、そのドメインの保有者は信頼したいと思うサービスプロバイダを正確に選択できる。あらゆる HTTPS のウェブサイトはコントロール不能で膨大な数のセキュリティインシデントや違法行為に対して脆弱であるという現状に比べると、これは全く違う状況を意味する。

*3独立鍵はとても強力なので、冗長にバックアップを取ったり、有効性や再発行の確認をうまく運用する必要がある。このようなことは誰でもできることではないが、特別なサービスプロバイダであれば最低限の労力でこれを運用できるだろう。

前途瞥見

独立鍵の基本的な考え方はとてもシンプルなのだが、それを現実的な状況へ落とし込むに当たっては(鍵の有効性や更新あるいは転送、スケーラビリティ、DOS 攻撃への耐性、システム管理者がこれらの対策や処置を単純に行えるような良いツールをつくることといった)、このプロジェクトが或る程度は大掛かりになる。

我々は目下、実験的なプロトタイプの実装に従事していて、このプロジェクトをサポートするために募金を募っている。多くの人に使ってもらえるようなコードがあれば、もっと声を大きくして言いたいところだ。当面は、DNSSECPerspectives/Convergence プロジェクトといった、現行の公開鍵基盤の危険性を問う他の提案と独立鍵の設計を比較しながら、独立鍵について事後報告したい。

冒頭に戻る


※ 以下の SNS 共有ボタンは JavaScript を使っておらず、ボタンを押すまでは SNS サイトと全く通信しません。

Google+ Twitter Facebook