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バージョンのアルゴリズムを参照している。)

サイファースイートは証明書および鍵交換方式の種類により異なる。 プロトコルのこの部分に関して、 ここで定義されるサイファースイートは以下のオプションを用いる。：

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ビットブロックを用いる。

新たなサイファースイートは、以下のように定義される。：

セキュリティについての考慮事項 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メーリングリストの貢献者に感謝する。

参考文献

著者のアドレス

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