Lavabit事件
Lavabitという名前をみなさんご存知だろうか。NSAの監視活動について内部リークを行った Edward Snowden氏が利用していたメールサービスとして今年の夏に一躍有名になったところだ。Snowden氏は香港に滞在して複数のジャーナリストにNSAの内部情報を提供したあと、現在はロシアに一時亡命しているが、亡命が認められる前にモスクワ空港にしばらく滞在していたことがある。7月12日に空港内でプレスカンファレンスを行ったのだが、その時複数の人権団体に送った招待状が “edsnowden@lavabit.com” というメールアドレスからだった。この事が報道されると、「あの」Snowden氏が使っているメールサービスということで、利用希望者が殺到したらしい。(それまで新規登録は 200人/日だったのが、4,000人/日と20倍になった。)
しかしそんな表の騒動の影で、裏では Lavabitと FBIとの間でバトルが繰り広げられていた。Snowden氏によるリークの報道がはじまったのは 6月だが、実はその前の 5月から FBIは Lavabitのオーナーである Ladar Levison氏に接触していた。そして Snowden氏は内部告発者として 6月9日に名乗り出たが、その翌日の 6月10日には Lavabitに対して Snowden氏のアカウント*1に関する情報 (住所や氏名などの個人情報、IPアドレスやメールの送受信ログなど、ただしメールの中身は含まない) を要求する裁判所命令が出されている。Levison氏は命令に従い、1日1回これらの情報を FBIのサーバにアップロードして対応した。しかし FBIの要求はさらにエスカレートし、Snowden氏のアカウントのメール送受信をリアルタイムに盗聴できるようにすることや、当局が暗号化されたデータを復号するために SSL秘密鍵などの提出を命令してきた。Lavabitのユーザはこの時点で 40万人に増えていたが、Levison氏はこれら全ユーザのプライバシーを危険にさらすことから命令に従うことを拒否。しかし裁判所は Levison氏の主張を聞きいれてはくれなかった。ここで Levison氏は奇策にでる。秘密鍵の提出方法が指定されていなかったことから、複数あるSSLの秘密鍵を OCRで読み取ることができないように 4ptで印刷した11ページのプリントアウトで提出した (図1)。しかし電子データで提出しないと1日あたり $5,000の罰金を課せられることになり万事休す。Levison氏はやむなく秘密鍵を提出し*2、その2日後の 8月8日にサービスの終了を発表した*3。サービス停止を発表した際の Levison氏のコメント「アメリカ市民への犯罪行為に加担するか、10年も続けてきた Lavabitのサービスを終了するか、非常に難しい決断をせまられた」には、苦悩のあとが伺える。
サービス終了時の Lavabitから顧客へのメッセージ (2013-08-08)
I have been forced to make a difficult decision: to become complicit in crimes against the American people or walk away from nearly ten years of hard work by shutting down Lavabit. After significant soul searching, I have decided to suspend operations. I wish that I could legally share with you the events that led to my decision. I cannot. I feel you deserve to know what’s going on--the first amendment is supposed to guarantee me the freedom to speak out in situations like this. Unfortunately, Congress has passed laws that say otherwise. As things currently stand, I cannot share my experiences over the last six weeks, even though I have twice made the appropriate requests. (下線は筆者による)
(図1) Levison氏が提出した SSL秘密鍵の一部。(注：一度印刷されたものをスキャナーで読み込んでいるので、元の資料よりさらに読みにくくなっている。)
公開された裁判所の資料はココから読める。
この事件はさまざまな影響を及ぼしたが、一つは Silent Circle*4もメールサービス (Silent Mail) を終了すると8月9日に発表したことだろう。Silent Circleは Lavabitのサービス終了の状況を見て、もし同様のことが自分達に起こった場合、ユーザのプライバシーを保護することができないと判断したようだ (Silent Circleのブログ参照)。
もう一つは SSLの秘密鍵に関することだ。Levison氏はその後のインタビュー等で、Lavabitで Diffie-Hellmanをサポートするべきだったと話している。これは何のことを言っているのだろうか? それが次の話題の Forward Secrecyである。
ちなみに Lavabitと Silent Circleは 10月30日に DarkMail Allianceの立ち上げを発表した。来年を目処に現在の古くてセキュアではないメールプロトコルに代わる新しいプロトコルを XMPPベースで開発することを目指している(彼らは ‘Email 3.0’と呼んでいる)。こちらの動きにも今後要注目だろう。
Silent Circle and Lavabit launch “DarkMail Alliance” to thwart e-mail spying | Ars Technica (2013-10-30)
“Knowing that they’re coming after SSL keys—for starters I would have made sure that all my systems support Diffie-Hellman,” he said. “The recent addition that provides an extra exchange for a negotiation process that makes it impossible to find out the session key, even if [the authorities] have the private key. It effectively would have forced them to do a man-in-the-middle attack instead of a third-party eavesdropping. It also means that if you’re forced to turn over keys in the future, they wouldn't be able to go back and decipher.” (下線は筆者による)
Announcing The Dark Mail Alliance – Founded by Silent Circle & Lavabit | Silent Circle Blog (2013-10-30)
Silent Circle and Lavabit, as privacy innovators have partnered to lead the charge to replace email as we know it today – fundamentally broken from a privacy perspective – we have collaborated in developing a private, next-generation, end-to-end encrypted alternative.
Forward Secrecy
ブラウザが Webサーバと TLS/SSLで通信を行う場合、セッション毎に異なる暗号鍵が生成されるが、クライアントとサーバが同じ鍵を共有するために最初に鍵交換のプロセスが必要になる。現状最もポピュラーな鍵交換の方法は RSAを利用したものだろう (ここでは RSA鍵交換とよぶことにする)。この場合、クライアントが生成した 48byteの Premaster SecretがサーバのRSA公開鍵 (最初にサーバから送信されるサーバ証明書に含まれる)で暗号化されてサーバに送信される。サーバは自身のRSA秘密鍵でこれを復号し、互いに共通する Premaster Secretが手に入る。これを Master Secretに変換して、暗号鍵の生成に利用する。
RSA鍵交換の問題は何かというと、すべてのセッションにおいて Premaster Secretの暗号化に同じ鍵 (サーバのRSA公開鍵) が利用されるという点である。ここで WebサーバのSSL通信をすべて盗聴できる攻撃者がいたと仮定しよう (NSAがまさにこの攻撃者に該当する)。この攻撃者はサーバの秘密鍵を持っていないので、盗聴した暗号通信を復号することはできない。しかし将来なんらかの手段によって攻撃者がサーバの秘密鍵を入手できた場合、この攻撃者はそれまでに保存したすべての暗号通信を復号して見ることができてしまう。
この問題は20年前からすでに知られており、鍵交換プロトコルが備えるべき性質のひとつとして Forward Secrecy (または Perfect Forward Secrecy、FSや PFSなどと省略する) が挙げられていた。
Authentication and Authenticated Key Exchanges
Perfect Forward Secrecy
An authenticated key exchange protocol provides perfect forward secrecy if disclosure of long-term secret keying material does not compromise the secrecy of the exchanged keys from earlier runs. The property of perfect forward secrecy does not apply to authentication without key exchange.
WebサーバのSSL秘密鍵など比較的長期間にわたって使用される鍵が外部に漏洩したとしても、それ以前のセッションにおいて利用された暗号鍵にはなんの影響も及ぼさない、というのが FSの性質だ。さきほどの RSA鍵交換はこの性質を満たしていない。つまり FSを達成できない。
一方、Ephemeral Diffie-Hellman鍵交換 (EDHまたは DHE) は FSを達成できる。セッション毎に鍵交換に必要なパラメータを生成し、クライアントとサーバがそれぞれ計算した値を交換することにより共通の Premaster Secretを生成する。このときサーバの秘密鍵 (RSAまたはDSA) はサーバから送信されるDHパラメータの署名にのみ使用され、暗号化には使われない*5。また楕円曲線暗号を利用した Diffie-Hellman鍵交換 (ECDHE) も DHEと同様に FSを達成できる*6。
(注: サーバ証明書に DH公開鍵が含まれている場合、その固定パラメータを使って鍵交換を行なうことができる。しかしこの場合にはRSA鍵交換と同じで FSは達成できない。またこのタイプの証明書は現在ほとんど使われていない。TLS/SSLでは DH_RSA, DH_DSSによる鍵交換がこれに該当する。また ECDH_RSA, ECDH_ECDSAも同様。)
| 鍵交換方式 | サーバ認証 | FS (PFS) | |
|---|---|---|---|
| RSA鍵交換 | RSA | RSA | × |
| DHE鍵交換 | DHE | RSA or DSA | ○ |
| ECDHE鍵交換 | ECDHE | RSA or ECDSA | ○ |
RSA鍵交換の場合、サーバの秘密鍵が漏洩する (または鍵が解読される) とすべてのセッションが復号できてしまうのに対して、DHE/ECDHE鍵交換であればセッションを復号するためにはそれぞれセッション毎の暗号鍵を解読する必要がある。NSAによる包括的な監視が行われている実態が明らかになったことを考えると、通信データの機密性がサーバの秘密鍵だけに依存するのはなんとも心許ない話だ。もし Lavabitが FSに対応していれば、つまりDHE/ECDHEによる鍵交換をサポートしていれば、たとえサーバの秘密鍵を当局に渡したとしても各ユーザのセッションを復号されることはなかったはずだ。(ただしこの場合、FBIは Lavabitのサーバになりすますことができるので MITMは可能。)
Forward Secrecy への対応状況
Webでの通信においてFSを実現するには、ブラウザ等のクライアントとWebサーバの双方で対応する必要がある。ではこれらのFSへの対応状況はどうなっているのか。2つのデータを紹介しよう。
1つめは Netcraftが今年の 6月に公表した調査データ。約240万の SSLサイトに対して 5種類の主要なブラウザ (Firefox, Chrome, Opera, Safari, IE) でアクセスした結果、およそ 2/3は FS対応の暗号スイートを利用していなかった。ブラウザ別では特に IEの成績が悪くなっているが、これは他のブラウザが FS対応の暗号スイートをFS非対応のものより優先しているのに対し、IEはそうではないためである。また DHE_RSAに対応した暗号スイートを IEはサポートしていない。
一方で Webサーバ側が FSに対応していないのは、DHE鍵交換の処理が重くパフォーマンス的に不利になるためだと考えられる。しかし比較的新しい ECDHEでは処理速度が早くなっており、RSA鍵交換との差は縮まっていると言えるだろう。
Netcraftの発表内容
http://news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-decrypted-tomorrow.html
http://www.netcraft.com/internet-data-mining/ssl-survey/
2つめは Qualysが公開している SSL Pulseの調査データ。直近の 10月のデータによると、約16万サイトを調査した結果、54%のサイトが FSに対応していなかった。しかし FSに対応しているサイトのほとんども対応は不十分で、多くのブラウザとの通信において FS対応の暗号化スイートが使われていない。これはサイト側が ECDHEに対応していないためだと思われる。その結果、全体の 95.8%で FSが使われていないという状況になっている。
Qualysの発表内容
https://community.qualys.com/blogs/securitylabs/2013/10/09/ssl-pulse-now-tracking-forward-secrecy-and-rc4
https://community.qualys.com/blogs/securitylabs/2013/06/25/ssl-labs-deploying-forward-secrecy
主要なサービスの対応状況
こういった取り組みにいつも先行するのはやはり Google。2010年に他のサービスに先駆けて GmailのデフォルトHTTPS対応をはじめたが、2011年には Gmailなどの主要なサービスで FSにも対応している。
Google Online Security Blog: Protecting data for the long term with forward secrecy (2011-11-22)
Last year we introduced HTTPS by default for Gmail and encrypted search. We’re pleased to see that other major communications sites are following suit and deploying HTTPS in one form or another. We are now pushing forward by enabling forward secrecy by default.
Facebook, Twitter, Yahoo!, Apple, Microsoftなどのサービスでは 6月の時点では主要なブラウザにおいて FSは利用されていなかったようだが、その後 Facebookと Twitterは対応するようになった。おそらく今後他のサービスでも対応がすすむと考えられる。ちなみに日本の状況はどうかというと、Yahoo! Japan、楽天、mixiなどはまだどこも FSに対応していない。
(例) Chromeでアクセスした際に使われる鍵交換の方法 *7
| Yahoo! | Apple | Microsoft | Yahoo! Japan | Rakuten | mixi | |||
| ECDHE_RSA | ECDHE_RSA | ECDHE_RSA | RSA | RSA | RSA | RSA | RSA | RSA |
(図3) Yahoo! Japanに Chromeでアクセスした場合
まとめ
以上、Lavabit事件とその影響、Forward Secrecyへの対応状況などについて紹介した。今後は主要な Webサイトにおける FS対応がさらに進むことが予想される。なお Forward Secrecyはなにも TLS/SSLに限定した話ではなく、メッセージングの世界でも対応がすすんでいる。次回はこの話題 (OTR: Off-the-Record Messageing) について取り上げる予定。予定は未定。
(参照)
Edward Snowden’s E-Mail Provider Defied FBI Demands to Turn Over Crypto Keys, Documents Show | WIRED
As F.B.I. Pursued Snowden, an E-Mail Service Stood Firm | NYTimes
Edward Snowden has applied for asylum in Russia: Russian media (LIVE BLOG) | GlobalPost
SSL/TLS & Perfect Forward Secrecy | Vincent Bernat
Geekなぺーじ:スノーデン事件の裏で起きていたSSL秘密鍵を巡る戦い
*1:裁判所から公開された資料では個人情報がマスクされているが Snowden氏のアカウントだと考えられている。
*2:Lavabitのサーバ証明書は GoDaddyが発行したものだが、この事件が報道されるとすぐに証明書を無効にしている。https://lavabit.com/ を参照。
*3:この時点では gag orderによりサービス停止の理由について Levison氏は一切しゃべることができなかった。事件の概要がわかったのは 10月になって裁判所が機密指定を解除してから。
*4:PGPの開発者である Phil Zimmermann氏が共同創業者の一人である。
*5:サーバから送信される ServerKeyExchangeメッセージで署名された DHパラメータが送信される。RSA鍵交換では ServerKeyExchangeは送信されない。
*6:TLS/SSLで FSに対応している鍵交換の方式は DHE_DSS (EDH_DSS), DHE_RSA (EDH_RSA), ECDHE_RSA, ECDHE_ECDSA の4つである。
*7:Version 32.0.1685.0 dev版を使用して 11月3日に調査した結果。
