Network Working Group P. Chown Request for Comments: 3268 Skygate Technology Category: Standards Track June 2002 Transport Layer Security (TLS) のための Advanced Encryption Standard (AES) 暗号スイート このメモの位置付け このドキュメントは、インターネット・コミュニティに対し、インターネット 標準化プロトコルを規定し、その改善のための議論と提案を求めるものである。 このプロトコルの標準化状態と位置付けは、"Internet Official Protocol Standards"(STD 1)の最新版を参照のこと。このメモの配布は無制限である。 著作権 Copyright (C) The Internet Society (2002). All Rights Reserved. 要旨 本ドキュメントでは、さまざまな新規暗号スイートを提案する。現在のところ、 Transport Layer Security (TLS) によりサポートされている対称暗号方式は、 RC2、RC4、International Data Encryption Algorithm (IDEA)、Data Encryption Standard (DES)、そしてトリプルDESである。TLSプロトコルは、 Advanced Encryption Standard (AES) 暗号スイートを追加することで拡張 される。 概要 現在のところ、TLSによりサポートされている対称暗号方式は、RC2、RC4、 IDEA、DES、そしてトリプルDESである。TLSプロトコルは、AES [AES] 暗号 スイートを追加することで拡張されるが、この暗号スイートの追加は以下の 理由によるものである。 1. RC2、RC4、IDEAはすべて、知的所有権の請求が行われている。RSA Security Inc. は、RC2とRC4に関する商標権を取得しており、また RC4アルゴリズム自体は企業秘密とされている。 Ascom Systec Ltd. は、 IDEAアルゴリズムの特許を取得している。 2. トリプルDESは、近年の暗号に比べると処理効率が悪い。 3. AES選考プロセスが終了し、選択された暗号を使用することに関する 商業的な要望が高まっている。AESは非常に処理効率がよく、また さまざまな暗号解析攻撃に対して十分に耐えうる。それゆえAESは 非常に好ましい選択である。 4. 現在のところ、DHE暗号スイートでは、トリプルDESのみが許容されて いる（これに加え、いくつかの"輸出可能な"ものがあるが、これらは 満足できるような鍵長を使用しているわけではない）。同時に、DHE 暗号スイートのみが、前進機密性(forward secrecy)をもつ。 本ドキュメントでは、さまざまな新規暗号スイートを提案する。これらの 暗号スイートは、上記の問題を克服することを目的とするものである。 暗号の使用法 ここで提案する新規暗号スイートは、以下の、[TLS]で定義されたものに 非常によく似たものである。 TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_DSS_WITH_3DES_EDE_CBC_SHA TLS_DH_RSA_WITH_3DES_EDE_CBC_SHA TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA TLS_DH_anon_WITH_3DES_EDE_CBC_SHA ここで記述されるすべての暗号スイートは、AESを暗号ブロックチェーンモード (cipher block chaining:CBC) で使用する。さらにこれらにおいては、SHA-1 [SHA-1]を、[TLS]の第5章で記述されているHMAC構造で使用する。 （TLS暗号スイート名には、"SHA"という表記を行っているが、実際にはこの アルゴリズムを修正したSHA-1バージョンを指している。） 暗号スイートは、証明書の型と鍵交換方法により異なる。ここで定義される 暗号スイートでは、プロトコルのこれらの部分において、以下のオプションを 使用する。 暗号スイート 証明書型（適用する場合）と 鍵交換アルゴリズム TLS_RSA_WITH_AES_128_CBC_SHA RSA TLS_DH_DSS_WITH_AES_128_CBC_SHA DH_DSS TLS_DH_RSA_WITH_AES_128_CBC_SHA DH_RSA TLS_DHE_DSS_WITH_AES_128_CBC_SHA DHE_DSS TLS_DHE_RSA_WITH_AES_128_CBC_SHA DHE_RSA TLS_DH_anon_WITH_AES_128_CBC_SHA DH_anon TLS_RSA_WITH_AES_256_CBC_SHA RSA TLS_DH_DSS_WITH_AES_256_CBC_SHA DH_DSS TLS_DH_RSA_WITH_AES_256_CBC_SHA DH_RSA TLS_DHE_DSS_WITH_AES_256_CBC_SHA DHE_DSS TLS_DHE_RSA_WITH_AES_256_CBC_SHA DHE_RSA TLS_DH_anon_WITH_AES_256_CBC_SHA DH_anon RSA、DH_DSS、DH_RSA、DHE_DSS、DHE_RSA、DH_anonの用語の意味については、 [TLS]の第7.4.2、7.4.3節を参照して下さい。 AESでは、128、192、256ビット長の鍵をサポートしている。しかし、この ドキュメントでは、128と256ビットの鍵での暗号スイートのみを定義する。 これは暗号スイートが無駄に増えるのを防ぐためである。Rijndaelでは、 128ビットブロックに加え、AES選定プロセスにおいて必要とされる192と256 ビットブロックサイズもサポートしている。ここで定義するすべての暗号 スイートは、128ビットブロックを使用する。 新規暗号スイートは、以下のように定義される。 CipherSuite TLS_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x2F }; CipherSuite TLS_DH_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x30 }; CipherSuite TLS_DH_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x31 }; CipherSuite TLS_DHE_DSS_WITH_AES_128_CBC_SHA = { 0x00, 0x32 }; CipherSuite TLS_DHE_RSA_WITH_AES_128_CBC_SHA = { 0x00, 0x33 }; CipherSuite TLS_DH_anon_WITH_AES_128_CBC_SHA = { 0x00, 0x34 }; CipherSuite TLS_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x35 }; CipherSuite TLS_DH_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x36 }; CipherSuite TLS_DH_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x37 }; CipherSuite TLS_DHE_DSS_WITH_AES_256_CBC_SHA = { 0x00, 0x38 }; CipherSuite TLS_DHE_RSA_WITH_AES_256_CBC_SHA = { 0x00, 0x39 }; CipherSuite TLS_DH_anon_WITH_AES_256_CBC_SHA = { 0x00, 0x3A }; セキュリティに関する考察 新規暗号スイートは古い暗号スイートに比べ、安全でないとは思われない。 AESは安全であり、そしてさまざまな暗号解析攻撃に対して耐えうると考え られている。 一時的Diffie-Hellmanに関する暗号スイートは、他の暗号分野において、 セキュリティレベルを低下させることなく前進機密性を提供している。これら の暗号スイートから最大限の利益を得るためには、 1. 一時鍵は、一度しか使用しないようにすべきである。現在定義されて いるTLSプロトコルでは、一時鍵を再利用したとしても何の効率も上が らない。 2. 一時鍵が不要になったときには安全に消去するべきである。 3. 一時鍵を生成するために使用される乱数生成器は、その内部ステータス が明らかにされた場合においても、過去の出力結果が明らかとなっては ならない。 [TLS] では、匿名Diffie-Hellman (ADH) 暗号スイートは推奨されないとして いる。ここで定義するADH暗号スイートは推奨されないものではない。しかし、 これらを使用する場合には、特に以下の注意を払う必要がある。 1. ADHにより、データの秘密性が提供されるが、認証は提供されない。 すなわち、（もし認証が必要である場合には）通信を行っている パーティーは、TLS以外の方法により、相互の認証を行わなければ ならない。 2. ADHは、認証が行われないためなりすまし攻撃を受けやすい。それぞれの パーティーは、同じTLSコネクションに関与していることを確認する方法 を持たなければならない。もし同じTLSコネクションでない場合には、 攻撃を受けているものとし、コネクションを中断することになるであろう。 例えば、パーティーがシークレットを共有している場合、TLS Finished メッセージにおけるMACを正しく計算することができる。攻撃者は通信 しているそれぞれのパーティーとの間で、2つの異なったTLSコネクション をネゴシエーションしなければならない。それぞれのケースでは、 Finishedメッセージの値は異なる。なぜならば、これらは（特に） パーティーの公開鍵に依存しているからである。このため、それぞれの パーティーで計算されたMACの値は異なることとなる。 Finishedメッセージを使用しない認証技術では、この攻撃を防ぐことは できないことを特に注意すべきである。例えば、クライアントはパス ワードを使用することで、サーバから認証されることができるかもしれ ないが、それでもなりすまし攻撃を受けやすい状態のままである。 最近の研究において、[TLS]で定義されているCBCモードを使用した すべての暗号スイートで発生しうる選択平文攻撃があることが明らか となった。この問題は、World Wide WebにおいてTLSを使用する場合 には影響しないが、TLSを他のアプリケーションで使用する場合には 影響がある可能性がある。この攻撃が可能なアプリケーションにおいて TLSが使用されたときには、攻撃者は、ある特定の平文が以前その セションにおいて送信されていても送信されなかったかのようにする ことができる。鍵マテリアルへの影響はない。 TLSプロトコルの将来のバージョンでは、CBCに基づく構造が変更される 可能性がある。 知的所有権 IETFは、本ドキュメントで記載されている技術の実装やその他の技術の使用 に対してクレームされている知的所有権またはその他の権利の効力または 適用範囲と、それらの権利に基づくすべてのライセンスが利用可もしくは 利用不可であるかに関して、どのような立場もとらない。これらに関しては、 すべての権利を明確にする努力が行われているわけではない。IETFの標準化 手順と標準化に関連したドキュメントに関する権利情報は、BCP-11より閲覧 することができる。公開され入手可能とされた権利のコピーや利用可能な ライセンスの保証、または本規定の実装者やユーザがそれらの所有権の一般 ライセンスもしくは使用許諾を得るための試みの結果は、IETF事務局から 得ることができる。 IETFでは、この標準規格を実装するために必要となる技術をカバーしている 著作権、特許もしくは特許申請、またはその他の知的所有権に関し、これらの 権利を持つパーティーからの情報提供を要請している。情報に関しては、 IETFのExecutive Directorに提出ください。 AESの開発の際、NISTは知的所有権に関する以下の声明を発表している。 特記事項 - 知的所有権 NISTは、権利をもつすべてのパーティーに対し、AESの採用において はオープンな選考が行われることを改めて明言する。特に、NISTは 権利をもつすべてのパーティーに対し、AESを使用するために必要な すべての特許または発明を明確にすることを要求する。NISTは、 将来において、本情報提供要求に対するNISTへの回答において明記 されていない特許権の適用をAESのユーザに対して要求しようとする パーティーに対しては、合衆国独占禁止法に基づいた是正処置を執行 することをここで明言する。 謝辞 本ドキュメントに対して非常に役立つ提案をしていただいた、ietf-tls メーリングリストの参加者に感謝する。 参考文献 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [AES] National Institute of Standards and Technology, "Specification for the Advanced Encryption Standard (AES)" FIPS 197. November 26, 2001. [SHA-1] FIPS PUB 180-1, "Secure Hash Standard," National Institute of Standards and Technology, U.S. Department of Commerce, April 17, 1995. 著者のアドレス Pete Chown Skygate Technology Ltd 8 Lombard Road London SW19 3TZ United Kingdom Phone: +44 20 8542 7856 EMail: pc@skygate.co.uk 著作権表示 Copyright (C) The Internet Society (2002). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. あとがき RFCの運営基金は現在、Internet Societyによって提供されている。 日本語訳 西原 啓輔 2002年7月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。