forward secrecy（perfect forward secrecy、略してFSあるいはPFSとも呼ばれるIEEE 1363-2000: IEEE Standard Specifications For Public Key Cryptography. Institute of Electrical and Electronics Engineers, 2000. http://grouper.ieee.org/groups/1363/。日本語で前方秘匿性とも）は、長期的な鍵対からセッションキーを生成した際に、のちに長期鍵の安全性が破れたとしてもセッションキーの安全性が保たれるという、の持つ性質である。この特性を守るためには、データを暗号化するための鍵から別の鍵を生成してはならないし、そしてデータを暗号化する鍵の素材となる秘密は一度だけの使い捨てにしなければならない。そうすることで、1つの鍵が破れたとしても被害がほかの鍵に及ばないようになる。
概要 インターネットへの盗聴が懸念される中、たとえ秘密鍵が判明したとしてもそれだけでは解読できないForward secrecyに注目が集まりSymantec (2013)、p.6。、2014年には実際に秘密鍵が漏洩しうるバグであるハートブリード（英語: Heartbleed）が発見された結果、その傾向がさらに強まっているWhy the Web Needs Perfect Forward Secrecy More Than Ever 電子フロンティア財団、2014年4月8日（2014年6月12日閲覧）。。ただし、適切でない設定により、かえって安全性を下げている事例も存在する（後述）。
歴史 Forward secrecyは、Whitfield Diffie、Paul van Oorschot、Michael James Wienerによって作られた概念であり、 (STS)の持つ性質を示すために使われたが、このSTSでは長期間保持される秘密は秘密鍵である。
この語はまた、が同様に持つ性質（ここでの長期的な秘密は共有したパスワード）を表すためにも使われた。
IEEE 1363-2000のAnnex D.5.1では、各種の鍵共有プロトコルについて、forward secrecyの性質を議論している。
Perfect forward secrecy forward secrecyの中でも、 鍵合意のために公開可能な、ランダムな値を使う。 鍵合意の過程で決定的なアルゴリズムを一切使わない。 これらの条件を満たす場合、1つのメッセージが危殆化したとしてもそれが他に及ぶことはなく、また、これ1つで複数のメッセージを解読可能な秘密情報も存在しない。
「perfect」と付いているが、これはワンタイムパッドのような完全暗号とは別の概念である。
攻撃法 forward secrecyは秘密鍵の危殆化からセッションキーを守ることはできるが、セッションキーを使わずに1つのメッセージへ暗号解読を行う試みに対しては無力である。また、実装によっては計算負荷を軽減するためにセッションキーの再利用が行われており、不適切な設定ではforward secrecyの安全性が脅かされることとなるSSL Labs: Deploying Forward Secrecy クオリス、2013年6月25日（2014年6月12日閲覧）。。また、2013年に行われた調査では、DHEによりSSL上でのforward secrecyを実装していたサーバのうち実に82.9%で、DHのパラメータ長がRSAの鍵長より小さくなっていた、すなわち総当たり攻撃への耐性を大きく下げるような設定となっていたことが判明しているSymantec (2013)、p.9。。
適用可能なプロトコル IPsecではオプションとなっている（）。 SSH SSL/TLSにも適用可能である（後述）。
SSL/TLSにおけるforward secrecy SSL 3.0時点でも、仕様上forward secrecyを実現可能なは存在したのだが、実装がなされていない、あるいは暗号化強度が弱すぎるなどの問題を抱えていたDiscussion on the TLS mailing list in October 2007。
SSLでforward secrecyを実現可能なアルゴリズムとして、ディフィー・ヘルマン鍵共有（DHEEはephemeral（一時的）の略であり、forward secrecyを実現するためには鍵が一時的である必要がある。）と、それを楕円曲線暗号で実現した楕円曲線ディフィー・ヘルマン鍵共有（ECDHE）が存在する。この2つのアルゴリズムについては、以下のような特徴・実装上の特性を持つ。 DHE RSAで署名されたサーバ証明書と組み合わせたDHE-RSA、およびDSAで署名された証明書と組み合わせたDHE-DSSの2種類があるが、実運用においてサーバ側で使用されるのはDHE-RSAがほとんどであり、DHE-DSSが使用されることは少ない。DHEを用いない場合と比較して計算負荷が大きいSymantec (2013)、p.14。。また、Internet Explorerは2014年現在の最新であるWindows 8.1を含むすべてのバージョンのWindowsにおいてDHE-DSSのみに対応しており、DHE-RSAは利用できなかったが、2014年4月8日リリースのパッチでWindows 8.1 / Server 2012 R2においてUpdate adds new TLS cipher suites and changes cipher suite priorities in Windows 8.1 and Windows Server 2012 R2、続く2014年11月11日リリースのセキュリティパッチでWindows 7 / Server 20008 R2および8 / Server 2012においてDHE-RSAに対応した（ただしAES-GCMとの組み合わせのみ有効）。 ECDHE RSAで署名されたサーバ証明書と組み合わせたECDHE-RSA、および楕円曲線DSAで署名された証明書と組み合わせたECDHE-ECDSAの2種類があり、DHEとは異なりサーバ側での実運用ではどちらも使用されている。クライアント側では、Mozilla製品で用いられているライブラリであるNetwork Security ServicesではFirefox 1.0リリースより前の2003年にリリースされた3.8から、Internet Explorerにおいては2007年にリリースされたWindows VistaからECDHEは実装されていたが、サーバ側のTLS/SSLライブラリとしてシェアの大きいOpenSSLにおいてTLS/SSL向けに実装されたのは2010年にリリースされた1.0から、GnuTLSでは2011年にリリースされた3.0.0からと比較的最近のことである。ECDHE-RSAでは通常のRSAと比べて負荷は15%程度増すが、ECDHE-ECDSAではむしろforward secrecyなしのRSAより高速化しうる。
実運用も徐々にではあるが普及しており、Googleでは、GmailやGoogle+などの自社サービスに対して、2011年11月22日以降forward secrecyを有効としているGoogle、GmailやGoogle+のセキュリティを強化 「forward secrecy」を採用 ITmedia、2011年11月24日（2014年6月12日閲覧）。ほか、Twitterでは2013年11月に導入している。2014年7月1日から、ウィキメディア財団によって運営されるすべてのプロジェクトにおいてforward secrecyが有効となった。2014年5月時点でSTARTTLSを有効にしているメールサーバのうち74%でforward secrecyが有効となっているという、facebook社による報告もある。2016年6月時点で、最新のウェブブラウザとの組み合わせによってHTTPSのWebサイトのうち51.9%がforward secrecyを利用可能である2016年6月2日現在 。
脚注 注
出典
参考文献 シマンテック、2013年（2014年6月12日閲覧）。
外部リンク 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