コンテンツにスキップ

Forward secrecy

出典: フリー百科事典『ウィキペディア（Wikipedia）』

これはこのページの過去の版です。Bcxfubot (会話 | 投稿記録) による 2022年9月22日 (木) 16:09 （個人設定で未設定ならUTC）時点の版 (外部リンクの修正 http:// -> https:// (www.itmedia.co.jp) (Botによる編集))であり、現在の版とは大きく異なる場合があります。

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]。

適用可能なプロトコル

  • IPsecではオプションとなっている（RFC 2412）。
  • SSH
  • SSL/TLSにも適用可能である（後述）。

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]。

脚注

注

  1. ^ a b Eはephemeral（一時的）の略であり、forward secrecyを実現するためには鍵が一時的である必要がある。

出典

  1. ^ IEEE 1363-2000: IEEE Standard Specifications For Public Key Cryptography. Institute of Electrical and Electronics Engineers, 2000. http://grouper.ieee.org/groups/1363/
  2. ^ “TLSにおけるForward Secrecyの利用に関する実証的研究調査”. 日本ベリサイン株式会社. 2014年6月12日閲覧。
  3. ^ Symantec (2013)、p.6。
  4. ^ Why the Web Needs Perfect Forward Secrecy More Than Ever 電子フロンティア財団、2014年4月8日（2014年6月12日閲覧）。
  5. ^ Diffie, Whitfield; van Oorschot, Paul C.; Wiener, Michael J. (June 1992). “Authentication and Authenticated Key Exchanges”. Designs, Codes and Cryptography 2 pages=107–125 (2): 107. doi:10.1007/BF00124891. http://www.scs.carleton.ca/%7Epaulv/papers/sts-final.pdf 2013年9月7日閲覧。. 
  6. ^ Jablon, David P. (October 1996). “Strong Password-Only Authenticated Key Exchange”. ACM Computer Communication Review 26 (5): 5–26. doi:10.1145/242896.242897. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.81.2594&rep=rep1&type=pdf 2013年9月7日閲覧。. 
  7. ^ a b c d SSL Labs: Deploying Forward Secrecy クオリス、2013年6月25日（2014年6月12日閲覧）。
  8. ^ Symantec (2013)、p.9。
  9. ^ Discussion on the TLS mailing list in October 2007
  10. ^ a b Symantec (2013)、p.14。
  11. ^ Update adds new TLS cipher suites and changes cipher suite priorities in Windows 8.1 and Windows Server 2012 R2
  12. ^ “[MS14-066 SChannel の脆弱性により、リモートでコードが実行される (2014 年 11 月 11 日)]” (2014年12月12日). 2014年12月26日閲覧。
  13. ^ “Microsoft Security Bulletin MS14-066 - Critical (Section Update FAQ)”. Microsoft (2014年11月11日). 2014年12月26日閲覧。
  14. ^ Thomlinson, Matt (2014年11月11日). “Hundreds of Millions of Microsoft Customers Now Benefit from Best-in-Class Encryption”. Microsoft Security. 2014年12月26日閲覧。
  15. ^ “NSS 3.8 Release Notes” (2003年4月10日). 2014年6月21日閲覧。
  16. ^ “Bug 195135 - Add support for Elliptic Curve Cryptography to NSS & SSL”. 2014年6月21日閲覧。
  17. ^ “TLS/SSL Cryptographic Enhancements”. 2014年6月21日閲覧。
  18. ^ a b “Protecting data for the long term with forward secrecy”. 2012年11月5日閲覧。
  19. ^ “GnuTLS 3.0.0 released” (2011年7月29日). 2012年11月5日閲覧。
  20. ^ Vincent Bernat. “SSL/TLS & Perfect Forward Secrecy”. 2012年11月5日閲覧。
  21. ^ Google、GmailやGoogle+のセキュリティを強化　「forward secrecy」を採用　ITmedia、2011年11月24日（2014年6月12日閲覧）。
  22. ^ Hoffman-Andrews, Jacob. “Forward Secrecy at Twitter”. Twitter. Twitter. 25 November 2013閲覧。
  23. ^ “Tech/News/2014/27/ja - Meta”. Wikimedia Foundation (2014年6月30日). 30 June 2014閲覧。
  24. ^ “The Current State of SMTP STARTTLS Deployment”. 7 June 2014閲覧。
  25. ^ 2016年6月2日現在 “SSL Pulse: Survey of the SSL Implementation of the Most Popular Web Sites”. 2016年6月18日閲覧。

参考文献

外部リンク

アルゴリズム
理論
標準化
関連項目
カテゴリ カテゴリ
プロトコル
技術
歴史
実装
公証
脆弱性
理論
暗号
プロトコル
実装
「https://ja.wikipedia.org/w/index.php?title=Forward_secrecy&oldid=91587701」から取得