Forward secrecy
forward secrecy（perfect forward secrecy、略してFSあるいはPFSとも呼ばれる[1]。日本語で前方秘匿性とも[2]）は、長期的な鍵対からセッションキーを生成した際に、のちに長期鍵の安全性が破れたとしてもセッションキーの安全性が保たれるという、鍵交換プロトコルの持つ性質である。この特性を守るためには、データを暗号化するための鍵から別の鍵を生成してはならないし、そしてデータを暗号化する鍵の素材となる秘密は一度だけの使い捨てにしなければならない。そうすることで、1つの鍵が破れたとしても被害がほかの鍵に及ばないようになる。
概要
インターネットへの盗聴が懸念される中、たとえ秘密鍵が判明したとしてもそれだけでは解読できないForward secrecyに注目が集まり[3]、2014年には実際に秘密鍵が漏洩しうるバグであるハートブリード（英語: Heartbleed）が発見された結果、その傾向がさらに強まっている[4]。ただし、適切でない設定により、かえって安全性を下げている事例も存在する（後述）。
歴史
Forward secrecyは、Whitfield Diffie、Paul van Oorschot、Michael James Wienerによって作られた概念であり、Station-to-Station protocol (STS)の持つ性質を示すために使われたが、このSTSでは長期間保持される秘密は秘密鍵である[5]。
この語はまた、パスワード認証鍵共有が同様に持つ性質（ここでの長期的な秘密は共有したパスワード）を表すためにも使われた[6]。
IEEE 1363-2000のAnnex D.5.1では、各種の鍵共有プロトコルについて、forward secrecyの性質を議論している。
Perfect forward secrecy
forward secrecyの中でも、以下の条件を満たすものはperfect forward secrecyと呼ばれる。[要出典]
- 鍵合意のために公開可能な、ランダムな値を使う。
- 鍵合意の過程で決定的なアルゴリズムを一切使わない。
これらの条件を満たす場合、1つのメッセージが危殆化したとしてもそれが他に及ぶことはなく、また、これ1つで複数のメッセージを解読可能な秘密情報も存在しない。
「perfect」と付いているが、これはワンタイムパッドのような完全暗号とは別の概念である。
攻撃法
forward secrecyは秘密鍵の危殆化からセッションキーを守ることはできるが、セッションキーを使わずに1つのメッセージへ暗号解読を行う試みに対しては無力である。また、実装によっては計算負荷を軽減するためにセッションキーの再利用が行われており、不適切な設定ではforward secrecyの安全性が脅かされることとなる[7]。また、2013年に行われた調査では、DHEによりSSL上でのforward secrecyを実装していたサーバのうち実に82.9%で、DHのパラメータ長がRSAの鍵長より小さくなっていた、すなわち総当たり攻撃への耐性を大きく下げるような設定となっていたことが判明している[8]。
適用可能なプロトコル
SSL/TLSにおけるforward secrecy
SSL 3.0時点でも、仕様上forward secrecyを実現可能な暗号スイートは存在したのだが、実装がなされていない、あるいは暗号化強度が弱すぎるなどの問題を抱えていた[9]。
SSLでforward secrecyを実現可能なアルゴリズムとして、ディフィー・ヘルマン鍵共有（DHE[* 1]）と、それを楕円曲線暗号で実現した楕円曲線ディフィー・ヘルマン鍵共有（ECDHE[* 1]）が存在する[7]。この2つのアルゴリズムについては、以下のような特徴・実装上の特性を持つ。
- DHE
- RSAで署名されたサーバ証明書と組み合わせたDHE-RSA、およびDSAで署名された証明書と組み合わせたDHE-DSSの2種類があるが、実運用においてサーバ側で使用されるのはDHE-RSAがほとんどであり、DHE-DSSが使用されることは少ない。DHEを用いない場合と比較して計算負荷が大きい[7][10]。また、Internet Explorerは2014年現在の最新であるWindows 8.1を含むすべてのバージョンのWindowsにおいてDHE-DSSのみに対応しており、DHE-RSAは利用できなかった[7]が、2014年4月8日リリースのパッチでWindows 8.1 / Server 2012 R2において[11]、続く2014年11月11日リリースのセキュリティパッチでWindows 7 / Server 20008 R2および8 / Server 2012において[12][13][14]DHE-RSAに対応した（ただしAES-GCMとの組み合わせのみ有効）。
- ECDHE
- RSAで署名されたサーバ証明書と組み合わせたECDHE-RSA、および楕円曲線DSAで署名された証明書と組み合わせたECDHE-ECDSAの2種類があり、DHEとは異なりサーバ側での実運用ではどちらも使用されている。クライアント側では、Mozilla製品で用いられているライブラリであるNetwork Security ServicesではFirefox 1.0リリースより前の2003年にリリースされた3.8から[15][16]、Internet Explorerにおいては2007年にリリースされたWindows Vistaから[17]ECDHEは実装されていたが、サーバ側のTLS/SSLライブラリとしてシェアの大きいOpenSSLにおいてTLS/SSL向けに実装されたのは2010年にリリースされた1.0から[18]、GnuTLSでは2011年にリリースされた3.0.0から[19]と比較的最近のことである。ECDHE-RSAでは通常のRSAと比べて負荷は15%程度増す[20]が、ECDHE-ECDSAではむしろforward secrecyなしのRSAより高速化しうる[10]。
実運用も徐々にではあるが普及しており、Googleでは、GmailやGoogle+などの自社サービスに対して、2011年11月22日以降forward secrecyを有効としている[21][18]ほか、Twitterでは2013年11月に導入している[22]。2014年7月1日から、ウィキメディア財団によって運営されるすべてのプロジェクトにおいてforward secrecyが有効となった[23]。2014年5月時点でSTARTTLSを有効にしているメールサーバのうち74%でforward secrecyが有効となっているという、facebook社による報告もある[24]。2016年6月時点で、最新のウェブブラウザとの組み合わせによってHTTPSのWebサイトのうち51.9%がforward secrecyを利用可能である[25]。
脚注
注
出典
参考文献
- TLSにおけるForward Secrecyの利用に関する実証的研究調査 (PDF) シマンテック、2013年（2014年6月12日閲覧）。
外部リンク
- RFC 2412 IETF, H. Orman. The OAKLEY Key Determination Protocol
- Forward-secure-survey An overview
- Forward Secrecy can block the NSA from secure web pages, but no one uses it Computerworld June 21, 2013
- SSL: Intercepted today, decrypted tomorrow Netcraft June 25, 2013