自堕落な技術者の日記 : ECDHE - livedoor Blog（ブログ）

SSL/TLS CipherSuiteウォッチャーの@kjurです。

TechCrunch JPに昨日こんな記事が掲載されました。

Twitterが将来の暗号解読を防ぐため全サイトにわたってPerfect Forward Secrecyを採用 (2013年11月23日)
http://jp.techcrunch.com/2013/11/23/20131122twitter-enables-perfect-forward-secrecy-across-sites-to-protect-user-data-against-future-decryption/

最近、SSL/TLS のCipherSuiteについて、いろいろ趣味で調べているんですが、そんなに大騒ぎするような事なんかなと思ったのでブログに書こうかと思います。

PFSとは

記事にある通り「Perfect Forward Secrecy(PFS)」は確かに決まった訳語が無いようで単に「PFS」という略語で呼ばれたりしています。私は「将来に向けた機密保護機能」と訳すのが良いかと思っています。

IPsecVPNでは既にいろんな製品で組み込まれていて、オプションでこれを有効にすることができ、SSL/TLSの場合には、鍵交換に「ECDHE」か「DHE」を使った場合に「PFS」を有効にしたと言う事ができます。

鍵交換にECDHE、DHE、ECDH、DHを使わずに認証の公開鍵暗号と同じ物(RSA、ECDSA、DSS(DSA))を使った使った場合 (例えばTLS_RSA_WITH_AES_128_CBC_SHAなど)、あるときSSL/TLS通信の全てを記録しておいて、後で認証に使った秘密鍵が漏洩した場合、通信の全てを復号することができます。

この問題が最近フォーカスされるようになったのは、エドワード・スノーデン氏の NSA情報漏洩事件に端を発しており、NSAが巨大なデータセンターで市民の全ての通信内容を「将来になって解析できるようにSSL/TLS暗号通信のまま」保管しているという噂があるようですが、通信内容を暗号化したまま全て記録されていたとして、「将来になって」公開鍵暗号の秘密鍵が漏洩したり解読されたりしても通信内容が漏洩する事は無いという機能が「Perfect Forward Secrecy」です。

鍵交換にECDHやDHを使った場合、認証に使う鍵と鍵交換の鍵は別になるので、通信の漏洩の可能性はすくなくなります。これを「(Perfectでない)Forward Secrecy」を持つというようです。

鍵交換にECDHEやDHEを使った場合、ECDHやDHと使った場合に比べて一定時間の後に定期的に異なる鍵で鍵交換を行い「将来に向けて機密保護されている(Perfect Forward Secrecy)」ことになります。 "E"はephemeral(一時的)の"E"です。

DH、DHEは鍵長1024bitで80bit相当の暗号強度があると言われていますが、 RSA 1024bitと同程度の暗号強度で昨今では十分な暗号強度でないとされています。 ECDH、ECDHEでは256bitの曲線が使われRSA暗号で言えば3072bitのRSA鍵に相当する 128bit暗号強度があるのでDH、DHEよりはECDH、ECDHEを使うべきだと言われています。

鍵交換にRSAを使うよりもECDHEやDHEを使った方が余分に計算コストがかかりそうなことは想像できると思います。今回のECDHEやPerfect Forward Secrecyの問題について詳しく技術的に解説しているリンクとして1年前に公開された以下のページがあります。

SSL/TLS & Perfect Forward Secrecy
Vincent Bernat
http://vincent.bernat.im/en/blog/2011-ssl-perfect-forward-secrecy.html

この中で、鍵交換にRSAそのものを使った場合に比べて、サーバーにおいて DHE_RSAの場合3倍、ECDHE_RSAだと1.27倍の計算コストがかかるそうです。 DHEだとかなりの負荷になりますが、ECDHEならそれほどの負担にはならなそうだという事になります。

最後に、証明書を発行するサービスの人でも平気で「ECDHEを使うにはECDSAの楕円暗号の証明書が必要だ」と誤解している人がいますが、鍵交換と認証に使う証明書の暗号は全く独立です。鍵交換が楕円(ECDHE)でもサーバー証明書はRSAが使えます。

で、TwitterのPFSつまりECDHE対応は?

というわけで、ECDHE対応になったらしいという

https://twitter.com
https://api.twitter.com
https://dev.twitter.com

を見てみました。結果からいうとPFSに対応したのは twitter.comとapi.twitter.comだけであって、dev.twitter.comは PFS対応ではないことがわかりました。従って「全サイトにわたってPerfect Forward Secrecyを採用」というのは間違っていることになりますよね。

twitter.comとapi.twitter.comのSSL/TLS CipherSuiteやプロトコルのサポート状況の特徴をまとめてみました。

SSLv3.0、TLSv1.0、TLSv1.1、TLSv1.2をサポート
PFS対応としてECDHEをサポートするがECDH、DHE、DHはサポートしない
AES_GCM、SHA2をサポート
3DES_EDE、RC4-SHA、RC4-MD5など弱い暗号もサポート

特にRC4-MD5をサポートしている事は以前のブログで紹介したようにJava、AndroidなどのAPIから利用した場合にRC4-MD5といった弱いCipherSuiteが優先的に選択されてしまう可能性があるので注意してください。 (参考: JRE 1.4-1.6やAndroidのAPIを使ったHTTPS接続のCipherSuitesがRC4-MD5を優先しているかなりヤバい話(2013.11.17))

dev.twitter.comについては全く上とは独立でなかなか面白いです。

SSLv3.0、TLSv1.0のみサポート
ECDHE、DHE、ECDH、DHをサポートしない
3DES_EDE、RC4-SHA、RC4-MD5など弱い暗号もサポート
CAMELLIA、SEEDもサポート

各ブラウザで繋いでみると

各ブラウザで繋ぐとどうなるのかツイッターのサイトをウェブブラウザで開いて通信のプロパティをそれぞれ見て見ましょう。最初はChromeです。
pfs_chrome
ちゃんとChromeはECDHEになっています。AES GCMを使っているのでさらに良いですね。
pfs_firefox
FirefoxもちゃんとECDHEになっていますね。ただ、RC4なんでちょっと残念。

IE8 on Win7ではECDH_P256と表示されます。NIST P-256曲線の楕円暗号で鍵交換しているのがわかるのは良いですが。ECDHと表示されちゃいますね。ただ、パケットキャプチャしてみるとわかるんですが、ちゃんとECDHEで鍵交換しています。 IE8はECDHやDHなどephemeralではない鍵交換はサポートしていないので。

おわりに

以上、TwitterがPFSに対応したというので、ちょっと調べてブログ書いてみました。 ECDHEをサポートするサイトなんてちっとも珍しくもないので「PFSに対応した」と大声でいうのも恥ずかしい話だと思うのですが、 PFSに端を発して問題が理解されECDHEなどのCipherSuiteが注目されるのは良い事だなと思いました。

残念だったのはこうした移行の前にtwitter.comのサポートするCipherSuiteの魚拓を取っとかなかったことです。自動的に情報収集する仕組みを作るかなぁ・・・

今日はこのへんで