English

暗号技術における鍵管理についてのガイドライン
(Guidelines for Cryptographic Key Management)

このメモの位置づけ

本書は、 インターネットの「現時点における最善の実践(ベストカレントプラクティス)」を示すものであり、 改善するために議論と示唆を求めるものです。 このメモの配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (2005).

要旨

しばしば、「このセキュリティシステムは、 何らかの形態の自動化された鍵管理を要求するか否か？」あるいは「マニュアル鍵管理で十分であるか否か？」という疑問が提起されます。 このメモは、 このような意思決定についてのガイドラインを提供します。 共通鍵暗号メカニズムが、あるプロトコルに使われているとき、 「一般に、自動化された鍵管理が必要とされるが、 常にではないこと」が想定されます。 マニュアル鍵管理が提案された場合、「自動化された鍵管理は、 要求されない」と書くという重い義務が、提案者に課せられます。

1. はじめに English

しばしば、「このセキュリティシステムは、 何らかの形態の自動化された鍵管理を要求するか否か？」あるいは「マニュアル鍵管理で十分であるか否か？」という疑問が提起されます。

その疑問に対する唯一の答えは、ありません。 状況によって異なります。 一般に、 自動化された鍵管理が使われる必要があります(SHOULD)。 ときどき、マニュアル鍵管理に依拠することが、 合理的であることがあります。 我々は、その判断を行うための、 いくつかのガイドラインを提案します。

一方、マニュアル鍵管理に依拠することには、明白な短所があり、 我々は、自動化された鍵管理の良さの正当性を説明するセキュリティについての関心事を概説します。 しかし、マニュアル鍵管理が許容される状況があります。

1.1. 用語法 English

キーワード MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL は、 本書中に現れるとき、 RFC 2119 [B] に記述されているように解釈されるべきものです。

2. ガイドライン English

このガイドラインは、 「自動化された鍵管理を強制するか否か？」や「マニュアル鍵管理が許容可能であるか否か？」を判断するIETFのWGやプロトコル設計の著者が使うためのものです。 情報に基づいた判断が必要とされます。

「鍵管理」という用語は、暗号アルゴリズムとともに、 プロトコルのセキュリティサービス(特に、インテグリティ、 認証および秘匿性)を提供するために使われる「暗号鍵とする素材」の確立をいいます。 自動化された鍵管理は、ひとつ、もしくは、 複数の短期セッション鍵を導出します。 鍵を導出する機能は、プロセス中に認証を組み込むために、 長期鍵を利用する可能性があります。 この長期鍵がピア宛に配布される作法と、 使われる鍵の種類(事前共有された共通鍵の秘密の値、 RSA公開鍵、DSA公開鍵等)は、本書の範囲外です。 しかし、これは、鍵管理ソリューション全体の一部です。 マニュアル鍵管理は、このような値を配布するために使われます。 マニュアル鍵管理は、 長期セッション鍵を配布するためにも使うことができます。

自動化された鍵管理とマニュアル鍵管理は、 まったく異なる機能を提供します。 特に、自動化された鍵管理テクニックと関連づけられたプロトコルは、 ピアが生きていることを確認し、再生(replay)攻撃から護り、 短期セッション鍵の源泉を認証し、 プロトコル状態情報を短期セッション鍵と関連づけ、 「フレッシュな短期セッション鍵が生成されていること」を確認します。 さらに、自動化された鍵管理プロトコルは、 暗号アルゴリズムについての交渉メカニズムを含めることによって、 相互運用可能性を向上することができます。 これらの可変な機能は、マニュアル鍵管理で達成することが不可能、 もしくは、極めて面倒です。

いくつかの共通鍵暗号アルゴリズムについて、実装は、 各鍵の超過利用を防がなければなりません。 このようなアルゴリズムの実装は、 ほとんど利用限度まで使われたとき、 限度に達する前に置換する鍵を確立し、 セキュアな通信を維持するために、 自動化された鍵管理を利用することができます。

自動化された鍵管理システムの例には、 IPsecのIKEやKerberosが挙げられます。 S/MIMEやTLSも、自動化された鍵管理機能をもちます。

鍵管理スキームをアマチュアが設計しては、いけません。 WGが自身で設計することは、ほぼ確実に不適切であるといえます。 具体的に述べれば、公開文書において最初の鍵管理プロトコル [NS] は、1978年に公表されました。 欠陥と修正版が、1981年に公表され [DS]、 その修正版は1994年に破られました [AN]。 1995年に新しい欠陥が当初の1978年版中の、 1981年／1994年の論点によって影響を受けない箇所に発見されました [L]。 これらの欠陥のすべては、記述されていたのです。 (これまで、誰も記していませんでしたが…。) 「当初のプロトコルは、 (当時は無かった証明書を採用するとしたら)たった3つのメッセージであったこと」に注目してください。

鍵管理ソフトウェアは、常に大きい(あるいは、 膨大である)とは限りません。 IKEv1 [HC] でさえ、 200KB以下のオブジェクトコードで行えますし、 TLS [DA] は、 その半分の大きさで行えます。 「このTLSについての見積もりは、 他の機能も含むこと」に注意してください。

セッション鍵は、ペイロードを防護するために使われます。 そのペイロードの性格は、 その共通鍵暗号技術が適用される層に依存します。

一般に、自動化された鍵管理は、 セッション鍵を確立するために使われる必要があります(SHOULD)。 マニュアル鍵管理を利用する提案の「セキュリティについての考慮事項」の章において、 十分な説明が必要とされます。

2.1. 自動化された鍵管理 English

下記のいずれかの状態が保たれる場合、 自動化された鍵管理が行われなければなりません(MUST)。：

• nの数が増える場合、主体は、 n²の鍵を管理する必要がある。 (RC4 [TK]、 AES-CTR [NIST]、 AES-CCM [WHF] のような、あらゆるストリーム暗号が使われます。)
• IV (Initialization Vector)(特に、黙示的なIV)は、 再利用される可能性がある。 (「明示的な乱数、もしくは擬似乱数のIVは、 確率が高くない限り、問題とならないこと」に注意してください。)
• 大量のデータが、短期間に暗号化される必要がある可能性があり、 頻繁な短期セッション鍵の変更をもたらす。
• 長期セッション鍵は、2者以上によって使われる。 (マルチキャストは、避けられない例外ですが、 マルチキャスト鍵管理標準は、将来、 これを避けるために台頭しつつあります。 長期セッション鍵を共有することは、一般に、 止める必要があります。)
• ありがちな運用環境は、 人員(もしくは、デバイス)の交代が頻繁であり、 頻繁な短期セッション鍵の変更をもたらしている環境。

2.2. マニュアル鍵管理 English

マニュアル鍵管理は、下記のすべての状況において、 合理的なアプローチである可能性があります。：

• その環境は、非常に限定された帯域しかもたないか、あるいは、 非常に高いラウンドトリップ回数をもつ。 (公開鍵暗号システムには、 長いメッセージと多くの計算処理を要求する傾向がある。 Kerberosのような共通鍵暗号による代替的システムは、しばしば、 数ラウンドのトリップと、第三者とのやり取りを要求する。)
• 防護される情報には、あまり価値が無い。
• その長期セッション鍵が有効な全期間にわたるトラフィックの総量は、 非常に小さい。
• 各配備の規模が、非常に限定的である。

「このような事項についての宣言は、しばしば、 疑ってみる必要があること」に注意してください。 「マニュアル鍵管理が適切であること」を実証するという重い義務は、 提案者に課せられます。(そして、これは、 かなり高いハードルです。)

マニュアル鍵管理を採用しているシステムは、 鍵交換についての規定を必要とします。 「どの鍵が移行における問題を避けるために使われているか？」を示すための何らかの方法がなければなりません(MUST)。 設計は、新しい鍵を配備し、 侵されている可能性がある古い鍵を置換することについて、 追加可能なメカニズムを描く必要があります(SHOULD)。 うまく行われた場合、このようなメカニズムは、 後で、付加的(add-on)鍵管理スキームによって使えます。

認証に参画している主体についての明確性の欠如は、 鍵管理を避けることについての妥当な理由ではありません。 むしろ、これは、 それが基づいているセキュリティモデルについてのより深い問題を示す傾向があります。

2.3. 鍵長と乱数 English

共通鍵を交換するために使われる公開鍵暗号技術の暗号鍵の長さについてのガイダンスは、 BCP 86 [OH] にあります。

マニュアル鍵管理が使われるとき、長期に「共有される秘密(shared secret)」の値は、 少なくとも128bitである必要があります(SHOULD)。

乱数生成についてのガイダンスは、 BCP 106 [ESC] にあります。

マニュアル鍵管理が行われるとき、 長期の「共有される秘密(shared secret)」は、 「攻撃者が、その値を見つけることについて、 その鍵探査空間の半分を探査した時点で50%未満の期待しかもたない」ような状況を確保する、 予測できない「乱数」でなければなりません(MUST) 。

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

本書は、WGとプロトコル設計者にガイダンスを提供します。 インターネットのセキュリティは、 自動化された鍵管理が採用されたとき、向上します。

自動化された鍵管理を含めることは、 「マニュアル鍵管理についてのインタフェイスが禁止されること」は意味しません。 事実、マニュアル鍵管理は、デバッグする際には、非常に有用です。 それゆえ、たとえ当該プロトコルによって規定されていない場合でも、 実装は、 このような目的のマニュアル鍵管理インタフェイスを提供すべきです。

4. 参考文献 English

この章においては、「規範的参考文献」と「参考情報」を示します。

4.1. 規範的参考文献

4.2. 参考情報

著者のアドレス

Steven M. Bellovin
Department of Computer Science
Columbia University
1214 Amsterdam Avenue, M.C. 0401
New York, NY 10027-7003

電話： +1 212-939-7149
EMail： bellovin＠acm.org

Russell Housley
Vigil Security, LLC
918 Spring Knoll Drive
Herndon, VA 20170

電話： +1 703-435-1775
EMail： housley＠vigilsec.com

翻訳者のアドレス

宮川 寧夫
独立行政法人 情報処理推進機構
セキュリティセンター

EMail： miyakawa＠ipa.go.jp

著作権表記全文

Copyright (C) The Internet Society (2005).

This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

知的財産権

The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights.  Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.

Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.

The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.