ネットワーク WG
Request for Comments: 3268
分類: スタンダードトラック

P. Chown
Skygate Technology
2002年 6月

English

TLS 用 AES サイファースイート
(Advanced Encryption Standard (AES) Ciphersuites for Transport Layer Security (TLS))

このメモの位置づけ

本書は、インターネットコミュニティに対してインターネットスタンダードトラックのプロトコルを定義するとともに、それを改良するための議論や提言を求めるものである。このプロトコルの標準化状態およびステータスについては、「Internet Official Protocol Standards」 (STD 1) の最新版を参照すること。このメモの配布に制限はない。

著作権表記

Copyright (C) The Internet Society (2002). All Rights Reserved.

要旨

本書は、いくつかの新しいサイファースイートを提案する。現在、TLS(Transport Layer Security)によってサポートされている共通鍵暗号は、RC2、RC4、IDEA(International Data Encryption Algorithm), DES(Data Encryption Standard)および Triple DES である。本プロトコルは、AES(Advanced Encryption Standard) サイファースイートの追加により拡張される。

概説 English

現在、TLS によってサポートされる対称鍵暗号は、RC2、RC4、IDEA、DES および Triple DES である。本プロトコルは、AES サイファースイートの追加により拡張される。その理由を以下に示す 。:

  1. RC2、RC4 および IDEA は、いずれも知的財産権の主張の対象である。RSA Security 社は、RC2 と RC4 の商標権を取得しており、RC4 アルゴリズム自体は、営業秘密であるとしている。Ascom Systec 社は、IDEA アルゴリズムに関する特許を取得している。
     
  2. Triple DES は、最近の暗号に比べ処理効率が悪い。
     
  3. AES の選定プロセスが完了したため、選択された暗号の利用に対して商業的な要望が高まっている。AES は、処理の効率が高く、広範に渡る暗号解析に耐えている。それゆえ AES は、望ましい選択といえる。
     
  4. 現在のところ DHE サイファースイートにおいては Triple DES のみが許容される(これに加えて十分な鍵長を用いていない、いくつかの「輸出」版も利用できる)。また、「 フォワードシークレシー(forward secrecy)」を持つのは、DHE サイファースイートのみである。

本書は、これらの問題を克服する目的で、いくつかの新しいサイファースイートを提案する。

暗号の用法 English

ここに提案する新たなサイファースイートは、[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

ここに記述された全てのサイファースイートは、CBC(Cipher Block Chaining)モードで AES を用いている。さらに、これらは [TLS] の 5 章に示された HMAC 構造において SHA-1 を用いている。(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、196 および 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 };

セキュリティについての考慮事項 English

新しいサイファースイートが、それに相当する以前のものに比べてセキュアでないとは信じられていない。AES は、セキュアであると考えられており、既にさまざまな暗号解析攻撃を受けて 、それに耐えている。

短期的(ephemeral)なDiffie-Hellman サイファースイートは、他の領域のセキュリティを低下させることなく「フォワードシークレシー(forward secrecy)」を提供する。これらのサイファースイートから最大の利益を得るためには:

  1. 短期鍵(ephemeral key)は、一度限り使用するべきである。現在定義されている TLS プロトコルにおいては、短期鍵を再利用しても特に際立った効率の向上はない。
     
  2. 短期鍵は必要とされなくなった際にセキュアに破棄されるべきである。
     
  3. 短期鍵の作成に用いられる乱数生成器は、内部の状態が明かされた場合においても過去の出力を明かすべきではない。

[TLS] は、ADH(匿名 Diffie-Hellman)を非推奨としている。本書において定義される ADH サイファースイートは、非推奨ではない。しかしながら、それらの使用にあたっては 、特に注意が必要である。:

  1. ADH は、守秘性を提供するが認証は提供しない。これは(認証が必要な際には)通信を行う主体が、TLS 以外の手段で、互いに相手を認証する必要があることを意味する。
     
  2. 認証が欠如しているため、ADH は仲介者攻撃(man-in-the-middle 攻撃)に対して脆弱である。主体は、同一の TLS コネクションに関係しているかどうかを判別する手段を必要とする。もし同じ TLS コネクションでないと判断した場合、攻撃を受けているものと推測しコネクションを中断するであろう。

例えば、主体が秘密(secret)を共有している場合、TLS Finished メッセージの MAC を計算可能である。攻撃者は、通信を行う主体ごとに、2つの異なる TLS コネクションを交渉(ネゴシエート)しなければならない。Finished メッセージは、そのときどきにより異なりうるが、これは(とりわけ)主体の公開鍵に依存するためである。この理由により各主体により計算される MAC は異なる。

Finished メッセージを用いない認証テクニックは、この攻撃に対する保護を提供しないことに注意すべきである。例えば、クライアントは、サーバーをパスワードを用いて認証できるが、依然として仲介者攻撃(man-in-the-middle アタック)に関しては脆弱である。 

最近の研究により、[TLS] で定義される CBC モードを使うすべてのサイファースイートに適用可能な選択平文攻撃の存在が明らかになった。WWW において TLS を一般に利用する上で、この弱点は影響しないが、他のアプリケーションで TLS を用いる場合には影響しうる。この攻撃が可能なアプリケーションで TLS が使われた場合、攻撃者は、そのセッションで以前に特定の平文が送信されたかのように偽装できる。鍵とする材料が暴かれることはない。

TLS プロトコルの将来の版では、CBC 構造が変更される可能性がある。 

知的財産権 English

IETF は、実装の特許申請、あるいは、本書に記述された以外の技術の利用、もしくは、そのような権利のもとで利用可能/利用不可なライセンスの程度について主張される可能性があるいかなる知的財産権もしくは他の権利の正当性もしくは範囲について中立である。; また、そのような権利を識別するためのあらゆる努力をしてきたと表現するものではない。スタンダードトラックと標準関連文書における権利に関する IETF の手順についての情報は、BCP-11 にある。入手可能な権利の主張と、あらゆる入手可能なライセンスの証明、もしくは、一般ライセンスを入手する試みの結果、もしくは、この仕様について、そのような財産権を実装者またはユーザが使用する許可についてのコピーは、 IETF 事務局から入手可能である。

IETF は、この標準を施行するために要求される可能性がある技術にあたる可能性があるあらゆる著作権、特許もしくは特許利用、あるいは他の財産権への注目を寄せる、いかなる利益主体も受け付けている。IETF エグゼクティブディレクター宛に情報を寄せていただきたい。

AES の開発過程において、NIST は、知的財産権についての下記の表明を公表している。:

特別な注意事項(知的財産権)

NIST は、すべての利益主体に対して、AES の選択はオープン標準設定活動として実施されていることを注記しておく。具体的には、NIST は、すべての利益主体に対して、NIST に AES の利用のために要求されるあらゆる特許もしくは発明を識別・報告することを要求した。それゆえ、NIST は、将来、この情報要求に対して NIST に開示されていなかった AES のユーザに対する特許権を実行することを求めるあらゆる主体に対して、米国独占禁止法に基づいて賠償を求める可能性があることを告知している。

謝辞 English

本書について有用な示唆を与えてくれた ietf-tls メーリングリストの貢献者に感謝する。

参考文献

[TLS] Dierks, T. and C. Allen,
「TLS プロトコル v1.0(The TLS Protocol Version 1.0)」,
RFC 2246, 1999年 1月.
 
[AES] National Institute of Standards and Technology, U.S. Department of Commerce,
"Specification for the Advanced Encryption Standard (AES)"
FIPS 197. 2001年11月26日.
 
[SHA-1] National Institute of Standards and Technology, U.S. Department of Commerce,
"Secure Hash Standard"
FIPS 180-1, 1995年 4月17日.

著者のアドレス

Pete Chown
Skygate Technology Ltd
8 Lombard Road
London
SW19 3TZ
United Kingdom

電話: +44 20 8542 7856
EMail: pc@skygate.co.uk

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

井上 信吾
情報処理振興事業協会
セキュリティセンター

EMail: s-inoue@@ipa.go.jp

 

著作権表記全文

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 によって提供されています。