Network Working Group D. Stebila Request for Comments: 5656 Queensland University of Technology Category: Standards Track J. Green Queen's University December 2009 SSH トランスポート層での楕円曲線アルゴリズムの統合 概要 この文章は, セキュアシェル(SSH) トランスポートプロトコルの中で利用する 楕円曲線暗号(ECC)ベースのアルゴリズムを記述する. 特に, 楕円曲線 Diffie-Hellman (ECDH) 鍵交換(鍵同意) と 楕円曲線 Menezes-Qu-Vanstone (ECMQV) 鍵交換(鍵同意), 楕円曲線 Digital Signature Algorithm (ECDSA) を SSHトランスポート層プロトコルで利用するために仕様を定める. このメモの位置づけ この文書は, インターネットコミュニティに対するインターネットの標準トラックプロトコルを定義している. また, 改善のための議論と示唆を求めている. このプロトコルの標準化の状態と状況は "Internet Official Protocol Standards" (STD 1) の現在の版を参照してほしい. このメモの配布は制限しない. 著作権情報 Copyright (c) 2009 IETF Trust and the persons identified as the document authors. 訳者: 春山征吾 All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified Stebila & Green Standards Track [Page 1] RFC 5656 SSH ECC Algorithm Integration December 2009 outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. 目次 1イントロダクション ...............................................3 2. 表記法 ........................................................4 3. SSH 楕円曲線暗号公開鍵アルゴリズム .....................................4 3.1. 鍵のフォーマット .................................................4 3.1.1. 署名アルゴリズム .................................5 3.1.2. 署名のエンコーディング ..................................5 4. ECDH 鍵交換 ...............................................5 5. ECMQV 鍵交換 ..............................................8 6. 方法の名前 ...................................................10 6.1. 楕円曲線ドメインパラメータ識別子 ...............10 6.2. 楕円曲線暗号公開鍵アルゴリズム (ecdsa-sha2-*) ...................11 6.2.1. 楕円曲線 Digital Signature Algorithm .........11 6.3. ECDH 鍵公開法の名前 (ecdh-sha2-*) ..............12 6.4. ECMQV 鍵交換/検証法の名前 (ecmqv-sha2) ..............................................12 7. 鍵交換のメッセージ ..........................................13 7.1. ECDH メッセージ番号 ......................................13 7.2. ECMQV メッセージ番号 .....................................13 8. 管理の上での考慮 ...................................13 8.1. 設定とポリシーによる機能の管理 ......13 8.2. ネットワーク操作への影響 ...............................14 9. セキュリティの考慮 ........................................14 10. 指定された楕円曲線ドメインパラメータ ........................16 10.1. 必須の曲線 ..........................................16 10.2. 推奨される曲線 .......................................17 11. IANAの考慮 ...........................................17 12. References ....................................................18 12.1. Normative References .....................................18 12.2. Informative References ...................................19 Appendix A. Acknowledgements .....................................20 Stebila & Green Standards Track [Page 2] RFC 5656 SSH ECC Algorithm Integration December 2009 1イントロダクション この文書は, 次の楕円曲線アルゴリズムを セキュアシェルの機能に加える: 楕円曲線 Diffie-Hellman (ECDH) , 楕円曲線 Digital Signature Algorithm (ECDSA). また, 安全なハッシュアルゴリズムのSHA2ファミリの利用も加える. さらに, 楕円曲線 Menezes-Qu-Vanstone (ECMQV) のサポートを提供する. 鍵サイズが小さいことと National Security Agencyの Suite B に含まれていることから, 楕円曲線暗号 (ECC) は広く利用され魅力的な公開鍵暗号システムとなってきている. RSAや Digital Signature Algorithm (DSA), Diffie-Hellman (DH) 鍵交換のような暗号システムに比べて, これらの方式のECCでのバリエーションは, より小さい鍵サイズで同等のセキュリティを提供する. これは, NIST 800-57 [NIST-800-57] の Section 5.6.1 に基づく次のテーブルに示されている. この表は, アルゴリズムを攻撃するときのもっとも良く知られたアルゴリズムに基づいた 対称/非対称鍵の暗号システムのおおよそ同等の鍵サイズを示している. L はフィールドサイズで, Nは サブフィールドのサイズだ. +-----------+------------------------------+-------+---------+ | Symmetric | Discrete Log (e.g., DSA, DH) | RSA | ECC | +-----------+------------------------------+-------+---------+ | 80 | L = 1024, N = 160 | 1024 | 160-223 | | | | | | | 112 | L = 2048, N = 256 | 2048 | 224-255 | | | | | | | 128 | L = 3072, N = 256 | 3072 | 256-383 | | | | | | | 192 | L = 7680, N = 384 | 7680 | 384-511 | | | | | | | 256 | L = 15360, N = 512 | 15360 | 512+ | +-----------+------------------------------+-------+---------+ この仕様の実装は, SSH [RFC4251] [RFC4253] [RFC4250] と ECC [SEC1] ([HMV04]と [ANSI-X9.62], [ANSI-X9.63] で利用可能なECCの追加の情報) の両方に精通している必要がある. この文書は, SSHの実装の詳細に関係している. 基底の暗号アルゴリズムの仕様は, 他の標準文書に任されている. Stebila & Green Standards Track [Page 3] RFC 5656 SSH ECC Algorithm Integration December 2009 2. Notation この文書でのキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" は, [RFC-2119] で記述されているように解釈される. データ型 boolean, byte, uint32, uint64, string, mpint は, [RFC4251] で記述されているように解釈される. prime curve上の楕円曲線ドメインパラメータの集合のサイズは, フィールドオーダーの2進表現のビット数で定義される. 通常 p で示される. characteristic-2 曲線のサイズは, フィールドの2進表現のビット数で定義される. 通常 m で示される. 楕円曲線ドメインパラメータの集合は, ベースポイント(基底点) P から生成される オーダ(位数)の群 n で定義される. 3. SSH 楕円曲線暗号公開鍵アルゴリズム SSH ECC 公開鍵アルゴリズムは, その鍵のフォーマットや対応する署名アルゴリズム ECDSA, 署名のエンコーディング, アルゴリズムの識別子で定義される. この節では, "ecdsa-sha2-*" ファミリーの公開鍵フォーマットと対応する署名フォーマットを定義する. すべての準拠する SSH ECC 実装は, この公開鍵フォーマットを実装しなければならない. 3.1. 鍵のフォーマット "ecdsa-sha2-*" 鍵フォーマットは, すべて次のようなエンコーディングを持つ: string "ecdsa-sha2-[identifier]" byte[n] ecc_key_blob ecc_key_blob の値は, 次のエンコーディングを持つ: string [identifier] string Q 文字列 [identifier] は, 楕円曲線のドメインパラメータの識別子だ. この文字列のフォーマットは, 6.1節で指定する. このアルゴリズムと共に用いる楕円曲線ドメインパラメータの要求されている集合と推奨される集合の情報は, 10節で示す. Q は, [SEC1] の 2.3.3節で定義されているように, 楕円曲線上の点をオクテット文字列にエンコードした公開鍵だ; ポイント圧縮が利用されてもよい. Stebila & Green Standards Track [Page 4] RFC 5656 SSH ECC Algorithm Integration December 2009 ECC 鍵生成のアルゴリズムは, [SEC1]の 3.2節にある. いくつかの楕円曲線ドメインパラメータより, 秘密鍵(整数 d) と公開鍵(楕円曲線上の点 Q)を含む ECC鍵ペアが生成される. 3.1.1. 署名アルゴリズム 楕円曲線デジタル署名アルゴリズム (ECDSA) を用いて署名と検証が行なわれる. ECDSA は [SEC1] で指定されている. メッセージハッシュアルゴリズムは, SHA2 ファミリーのハッシュ関数 [FIPS-180-3] のものでなければならない. 6.2.1節で指定される曲線のサイズに応じて, ハッシュアルゴリズムは選ばれる. 3.1.2. 署名のエンコーディング 署名は次のようにエンコードされる: string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob 文字列 [identifier] は, 楕円曲線のドメインパラメータの識別子だ. この文字列のフォーマットは, 6.1節で指定する. このアルゴリズムと共に用いる楕円曲線ドメインパラメータの要求されている集合と推奨される集合の情報は, 10節で示す. ecdsa_signature_blob の値は, 次のエンコーディングを持つ: mpint r mpint s 整数 r と s は ECDSA アルゴリズムの出力だ. 整数のフィールドの大きさは, 利用する曲線によって決定される. 整数 r と s は, 暗号学的なサブグループのオーダーを法とする整数で, 有限体のサイズよりも大きいかもしれないことに注意. 4. ECDH 鍵交換 楕円曲線 Diffie-Hellman (ECDH) 鍵交換法は, 一時的でローカルな楕円曲線秘密鍵と一時的でリモートの楕円曲線公開鍵から共有の秘密(shared secret)を生成する. この鍵交換法は, 交換ハッシュ(exchange hash) の署名を用いる [RFC4253] で定義された明示的なサーバ認証を提供する. すべての準拠する SSH ECC実装は, ECDH 鍵交換を実装しなければならない. Stebila & Green Standards Track [Page 5] RFC 5656 SSH ECC Algorithm Integration December 2009 共有鍵の生成に使われる primitive は, 余因子の乗算(cofactor multiplication)を用いる ECDHだ. 完全な仕様は, [SEC1}の 3.3.2 節にある. 鍵ペアの生成のアルゴリズムは, [SEC1]の 3.2.1節にある. この鍵交換の利用のために定義された名前のファミリーは 6.3 節にある. アルゴリズムのネゴシエーションでは, 署名に用いる公開鍵アルゴリズムと鍵交換の方法名を選ぶ. 選ばれた鍵交換の方法名は, この節の残りで用いる楕円曲線ドメインパラメータとハッシュ関数を決定する. この方法で利用する必須および推奨の楕円曲線ドメインパラメータに関する情報は、 10節にある. すべての楕円曲線公開鍵は, 受信後に検証されなければならない. 検証アルゴリズムの例は, [SEC1]の 3.2.1節にある. 鍵が検証に失敗したら, 鍵交換は失敗しなければならない. 転送される楕円曲線公開鍵(点)は, 転送前に8bit文字列にエンコードする必要がある. 楕円曲線の点と8bit文字列との変換は, [SEC1]の2.3.3と2.3.4節で指定されている; 点の圧縮が利用されるかもしれない. 共有鍵の生成の出力は, フィールド要素 xp だ. SSHのフレームワークでは, 共有鍵が整数でなければならない. フィールド要素と整数との変換は, [SEC1]の2.3.9節で指定されている. SSH_MSG_KEX_ECDH_INIT と SSH_MSG_KEX_ECDH_REPLY のメッセージ番号の定義は, 7節にある. Stebila & Green Standards Track [Page 6] RFC 5656 SSH ECC Algorithm Integration December 2009 鍵交換プロセスの概要を次に示す. クライアント サーバ ------ ------ 一時鍵ペアの生成 SSH_MSG_KEX_ECDH_INIT --------------> 受信した鍵の検証が成功 一時鍵ペアの生成 共有の秘密の計算 交換ハッシュの生成と署名 <------------- SSH_MSG_KEX_ECDH_REPLY 受信した鍵の検証が成功 *ホスト鍵がサーバのものか検証 共有の秘密の計算 交換ハッシュの生成 サーバの署名の検証 * クライアントが(たとえばローカルなデータベースを用いて)送られたホスト鍵がサーバのホスト鍵かどうか検証するのを推奨する. クライアントは, 検証なしにホスト鍵を受けいれてもよい. しかし, これはプロトコルヲを能動的な攻撃に対して安全でなくしてしまう; [RFC4251] の 4.1節の議論を見よ. これは, 次のメッセージ群を用いて実装される. クライアントは次を送る: byte SSH_MSG_KEX_ECDH_INIT string Q_C, client's ephemeral public key octet string サーバは以下で応答する. byte SSH_MSG_KEX_ECDH_REPLY string K_S, server's public host key string Q_S, server's ephemeral public key octet string string the signature on the exchange hash Stebila & Green Standards Track [Page 7] RFC 5656 SSH ECC Algorithm Integration December 2009 交換ハッシュ H は, 次の連結のハッシュで計算される. string V_C, client's identification string (CR and LF excluded) string V_S, server's identification string (CR and LF excluded) string I_C, payload of the client's SSH_MSG_KEXINIT string I_S, payload of the server's SSH_MSG_KEXINIT string K_S, server's public host key string Q_C, client's ephemeral public key octet string string Q_S, server's ephemeral public key octet string mpint K, shared secret 5. ECMQV 鍵交換 楕円曲線 Menezes-Qu-Vanstone (ECMQV) 鍵交換アルゴリズムは, 2つのローカルな楕円曲線鍵ペアと2つのリモートの公開鍵から 共有の秘密を生成する. この鍵交換法は, [RFC4253]で定義された暗黙的なサーバ認証を提供する. ECMQV 鍵交換法は選択できる. この鍵交換法を利用するために定義された名前は, "ecmqv-sha2" だ. この名前は, 次のHMACで用いられるハッシュアルゴリズムを与える. 将来のRFCが, ECMQVと共に用いる新しいハッシュアルゴリズムを指定する新しい認証法の名前が定義するかもしれない. 認証法の名前とHMACについてのさらなる情報は, 6.4節にある. 一般に, ECMQV 鍵交換はクライアントとサーバ両方で一時的な鍵と長期間の鍵を用いて行なわれる. すなわち 全部で4つの鍵を用いる. SSHのフレームワークの中では, クライアントは認証に必要な長期間の鍵ペアを持たない. したがって, 1つの一時的鍵を生成し, それをあたかも2つのクライアント鍵のように利用する. これは2つの一時的鍵を用いるより効率的で, セキュリティに不利に作用しない(これは, [LMQSV98] の 6.1節の one-passプロトコルに類似している.) ECMQV プリミティブの完全な説明は, [SEC1] の 3.4 節にある. 鍵ペア生成のアルゴリズムは, [SEC1]の 3.2.1 節にある. SSH_MSG_KEXINIT メッセージを用いる アルゴリズムネゴシエーションにおいて, ECCホスト鍵をサポートする公開鍵アルゴリズムが選ばれた場合のみECMQV 鍵交換法は選択されうる. これは, この鍵交換法で暗黙的なサーバ認証を利用するためだ. [RFC4253]の 7.1 節での 暗号化/署名可能な公開鍵アルゴリズムを必要とする鍵交換法が扱われるのと同じように, この場合も扱われる. Stebila & Green Standards Track [Page 8] RFC 5656 SSH ECC Algorithm Integration December 2009 handled in Section 7.1 of [RFC4253]. ECMQV 鍵交換が選ばれる場合は, ECC ホスト鍵をサポートする公開鍵アルゴリズムが選ばれなければならない. ECMQV は, 共有の秘密を生成するのに使われるすべての鍵が同じ楕円曲線ドメインパラメータで生成されていることを要求する. ホスト鍵が共有の秘密の生成に用いられるため, 暗黙的なサーバの認証を考慮すると, ホスト鍵に関連するドメインパラメータはこの節の間中用いられる. すべての楕円曲線公開鍵は, 受信後に検証されなければならない. 検証アルゴリズムの例は, [SEC1]の 3.2.1節にある. 鍵が検証に失敗したら, 鍵交換は失敗しなければならない. 転送される楕円曲線一時的公開鍵(点)は, 転送前に8bit文字列にエンコードする必要がある. 楕円曲線の点と8bit文字列との変換は, [SEC1]の2.3.3と2.3.4節で指定されている; 点の圧縮が利用されるかもしれない. 共有鍵の生成の出力は, フィールド要素 xp だ. SSHのフレームワークでは, 共有鍵が整数でなければならない. フィールド要素と整数との変換は, [SEC1]の2.3.9節で指定されている. 鍵交換プロセスの概要を次に示す. クライアント サーバ ------ ------ 一時鍵ペアの生成 SSH_MSG_KEX_ECMQV_INIT -------------> 受信した鍵の検証が成功 一時鍵ペアの生成 共有の秘密の計算 交換ハッシュの生成と, 共有の秘密を用いた交換ハッシュのHMACの計算. <------------- SSH_MSG_KEX_ECMQV_REPLY Verify received keys are valid. *ホスト鍵がサーバのものか検証 共有の秘密の計算 HMACの検証. * クライアントが(たとえばローカルなデータベースを用いて)送られたホスト鍵がサーバのホスト鍵かどうか検証するのを推奨する. クライアントは, 検証なしにホスト鍵を受けいれてもよい. しかし, これはプロトコルヲを能動的な攻撃に対して安全でなくしてしまう. Stebila & Green Standards Track [Page 9] RFC 5656 SSH ECC Algorithm Integration December 2009 SSH_MSG_ECMQV_INIT と SSH_MSG_ECMQV_REPLY のメッセージ番号の定義は, 7節にある. この鍵交換アルゴリズムは, 次のメッセージ群で実装される. クライアントは次を送る: byte SSH_MSG_ECMQV_INIT string Q_C, client's ephemeral public key octet string サーバは以下を送る: byte SSH_MSG_ECMQV_REPLY string K_S, server's public host key string Q_S, server's ephemeral public key octet string string HMAC tag computed on H using the shared secret ハッシュ H は, 次の連結に対して HASH アルゴリズムを適用した結果だ: string V_C, client's identification string (CR and LF excluded) string V_S, server's identification string (CR and LF excluded) string I_C, payload of the client's SSH_MSG_KEXINIT string I_S, payload of the server's SSH_MSG_KEXINIT string K_S, server's public host key string Q_C, client's ephemeral public key octet string string Q_S, server's ephemeral public key octet string mpint K, shared secret 6. 方法の名前 この文章は, 鍵交換の方法名の新しいファミリや新しい鍵交換法の名前, 公開鍵アルゴリズムの新しいファミリを SSHの名前レジストリに定義する. 6.1. 楕円曲線ドメインパラメータ識別子 この節では, 指定された楕円曲線ドメインパラメータをエンコードする識別子を指定する. これらの識別子は, この文書で以下を識別するために用いられている: SSH 楕円曲線公開鍵フォーマットや, ECDSA署名blob, ECDHの方法名だ. 必須の楕円曲線として, nistp256 と nistp384, nistp521 がある. 楕円曲線ドメインパラメータの識別子は, 文字列 "nistp256" と "nistp384", "nistp521" だ. Stebila & Green Standards Track [Page 10] RFC 5656 SSH ECC Algorithm Integration December 2009 他のすべてのNISTの曲線と他のすべての推奨される曲線を含む他のすべての楕円曲線のために, 楕円曲線ドメインパラメータ識別子は, サーバの楕円曲線ホスト鍵に関連付いて指定された曲線ドメインパラメータのASN.1[ASN1]オブジェクト識別子(OID)のASCIIでピリオドで分割された10進表現で表現される. 公開鍵識別子と楕円曲線ドメインパラメータ識別子(もしくは方法の名前と楕円曲線ドメインパラメータ識別子)の連結でこの識別子は定義され提供される. このとき, この識別子はSSH プロトコルアーキテクチャ [RFC4251]で指定された最大長, すなわち 64文字を越えない. そうでなければ, 曲線の識別子が定義されず, この曲線はこの仕様ではサポートされない. 必須/推奨の曲線とそのOIDのリストは, 10節にある. 実装は, 3つの必須のNISTの曲線については, これらの曲線のOIDがあったとしても, 文字列の識別子を用いなければならないことに注意. 6.2. 楕円曲線公開鍵アルゴリズム (ecdsa-sha2-*) SSH楕円曲線公開鍵アルゴリズムは, 公開鍵フォーマット識別子のファミリで指定される. それぞれの識別子は, 文字列 "ecdsa-sha2-" と 6.1節で定義した楕円曲線ドメインパラメータ識別子の連結だ. 必須/推奨の曲線とそのOIDのリストは, 10節にある. たとえば, nistp256 曲線から生成された一時鍵を用いるECDHの方法の名前は, "ecdsa-sha2-nistp256" だ. 6.2.1. 楕円曲線 Digital Signature Algorithm 楕円曲線 Digital Signature Algorithm (ECDSA) は, SSHの楕円曲線公開鍵アルゴリズムの共に利用するために指定される. このファミリで定義されるハッシュアルゴリズムは, SHA2ファミリのハッシュアルゴリズム [FIPS-180-3] だ. SHA2ファミリからどのアルゴリズムが選ばれるかは, 公開鍵に指定された曲線のサイズを元に決められる. Stebila & Green Standards Track [Page 11] RFC 5656 SSH ECC Algorithm Integration December 2009 +----------------+----------------+ | Curve Size | Hash Algorithm | +----------------+----------------+ | b <= 256 | SHA-256 | | | | | 256 < b <= 384 | SHA-384 | | | | | 384 < b | SHA-512 | +----------------+----------------+ 6.3. ECDH 鍵交換法の名前 (ecdh-sha2-*) 楕円曲線 Diffie-Hellman (ECDH) 鍵交換は, 方法の名前のファミリで定義される. それぞれの方法の名前は, 文字列 "ecdh-sha2-" と 6.1節で定義した楕円曲線ドメインパラメータ識別子の連結だ. 必須/推奨の曲線とそのOIDのリストは, 10節にある. たとえば, sect409k1 曲線から生成された一時鍵を用いるECDHの方法の名前は "ecdh-sha2-1.3.132.0.36" だ. このファミリで定義されるハッシュアルゴリズムは, SHA2ファミリのハッシュアルゴリズム [FIPS-180-3] だ. ハッシュアルゴリズムは, 方法の名前で定義される. その他のアルゴリズムを許可する余地があるかどうかは, 将来の文書で定義される. SHA2ファミリからどのアルゴリズムが選ばれるかは, 6.2.1節の表に基づいて方法の名前で指定された曲線のサイズを元に決められる. "ecdh-sha2-" と連結される 楕円曲線ドメインパラメータの集合を指定する ASN.1 OID は, この仕様の元で暗黙的に登録される. 6.4. ECMQV 鍵交換/検証法の名前 (ecmqv-sha2) 楕円曲線 Menezes-Qu-Vanstone (ECMQV) 鍵交換は名前 "ecmqv-sha2" で定義される. ECDH 鍵交換とは異なり, ECMQV は楕円曲線鍵を用いる公開鍵アルゴリズムに依存している: 方法の名前のファミリは必要ない. 曲線の情報は公開鍵アルゴリズムから入手できる. ハッシュとメッセージ認証コードのアルゴリズムは, 方法の名前で定義される. その他のアルゴリズムをECMQVで許可する余地があるかどうかは, 将来の文書で定義される. Stebila & Green Standards Track [Page 12] RFC 5656 SSH ECC Algorithm Integration December 2009 この名前で定義されるハッシュアルゴリズムは, SHA2ファミリのハッシュアルゴリズム [FIPS-180-3] だ. SHA2ファミリからどのアルゴリズムが選ばれるかは, 6.2.1節の表に基づいて, ECMQVと共に用いられる公開鍵アルゴリズムで指定された曲線のサイズを元に決められる. サーバの同定と通信の検証に用いられる鍵付きハッシュのメッセージ認証コードは, 上で選ばれたハッシュを元にする. 選ばれたハッシュアルゴリズムに基づくHMACを実装するための情報は [RFC2104]にある. 7. 鍵交換のメッセージ [RFC4250] でメッセージ番号は鍵交換特有なプライベートな名前空間と定義されている. この空間は, [RFC4253]で IANAの登録手続きを必要とせずに, 任意の鍵交換法で再定義してよいとされている. 次のメッセージ番号を, この文書で定義する. 7.1. ECDH メッセージ番号 #define SSH_MSG_KEX_ECDH_INIT 30 #define SSH_MSG_KEX_ECDH_REPLY 31 7.2. ECMQV メッセージ番号 #define SSH_MSG_ECMQV_INIT 30 #define SSH_MSG_ECMQV_REPLY 31 8. 管理の上での考慮 この文書は, 既存のセキュアシェルプロトコルアーキテクチャに新しい公開鍵アルゴリズムと鍵交換法を提供しているだけで, 既存のセキュアシェル実装への適用されている管理の上での考慮を越えるものはほとんどない. 追加の管理の上での考慮を次に挙げる. 8.1. 設定とポリシーによる機能の管理 10節で, この文書で定義された公開鍵アルゴリズムと鍵交換法と共に用いられる必須と推奨の楕円曲線ドメインパラメータを定義している. 実装者は, 必須や推奨の曲線を含むいくつかの曲線をシステム管理者がローカルなセキュリティポリシーを充たすために無効にするのを許可する必要がある. Stebila & Green Standards Track [Page 13] RFC 5656 SSH ECC Algorithm Integration December 2009 8.2. ネットワーク操作への影響 この文書はセキュアシェルプロトコルアーキテクチャに新しい機能を追加しているので, ネットワーク操作への影響は, 既存のセキュアシェル実装の影響と同一だ. セキュアシェルプロトコルは, 公開鍵アルゴリズムと鍵交換法のネゴシエーションメカニズムを提供している: この文書で定義されているアルゴリズムや方法を認識しない実装はどれも, ネゴシエージョンでこれらを無視し相互にサポートしているアルゴリズムか方法を用いる. 後方互換性で問題となる影響は発生しない. 楕円曲線暗号の利用は, 実装したサーバに重大な計算の負担を発生されるものではないはずだ. 実際, 楕円曲線暗号は, RSAや有限体 Diffie-Hellman, DSA より小さな鍵サイズを持つので, 同じセキュリティレベルをより効率的に実装できる. 9. セキュリティの考察 この文書はセキュアシェルプロトコルに新しい公開鍵アルゴリズムと新しい同意方法を提供する. セキュアシェルプロトコル利用上のセキュリティの考察が大部分適用される. さらに, 実装者は楕円曲線暗号に特有のセキュリティの考察に注意する必要がある. この文書で追加された3つのクラス(ECDSAに関連する公開鍵アルゴリズムと, ECDHに関連する鍵交換, ECMQVに関連する認証付き鍵交換)のすべてについて, 暗号系を破る現在もっともよく知られた技術は, 楕円曲線離散対数問題(ECDLP)を解くことだ. ECDLPを破る難易度は, 楕円曲線パラメータのサイズと品質に依存する. 特定の種類の曲線は, 他のものよりも既知の攻撃に対して弱い可能性がある. たとえば, 有限体 GR(2^m) 上の曲線(mは合成数)は, Weil descent に基づく攻撃に対して弱いかもしれない. 10節でのすべての推奨の曲線には, この問題はない. システム管理者は, 10節で指定されたもの以外の曲線を有効にするときに注意する必要がある.. また, 問題の曲線のセキュリティについてよく詳しい調査する必要がある. 曲線パラメータをランダムに生成すると, 曲線は特有の攻撃に耐性を持ちもっとも一般的な攻撃だけが有効になると信じられている.(たとえば, [SEC1] のB.2.1節を参照). 10節の必須の曲線は, すべて検証できる疑似乱数で生成されている. 一般的な攻撃のランタイムは, 利用されるアルゴリズムに依存する. 現在, もっとも良く知られているアルゴリズムは, Pollard-rho 素因数分解法だ. Stebila & Green Standards Track [Page 14] RFC 5656 SSH ECC Algorithm Integration December 2009 (量子計算機での Shorのアルゴリズムは多項式時間で ECDLP を解ける. しかし, 現在大規模な量子計算機は構築されておらず, その構築には, 非常の実験的な物理やエンジニアリングの作業がなされなければならない. いつ達成されるかのしっかりした見積りはないが, 現在より少なくとも20年はかかると広く信じられている.) 計算能力の予測に基づいて, 有限体のサイズに基づくもっとも良い既知の方法の時間を見積もれる. 1 節の表は, 楕円曲線フィールドサイズと対称鍵サイズの等しさの見積りだ. おおざっぱにいって, N-ビットの楕円曲線は, N/2-bitの対称暗号と同じセキュリティを提供する. たとえば, (必須の nistp256 曲線のような) 256-bitの楕円曲線は, 128-bitのAECと共に利用するのに適している. example. 多くの見積りが2^80-2^90の操作が実行可能な線を越えているとみなしている. これは少なくとも160-180 ビットの楕円曲線の利用を示唆している. この文書の必須の曲線は, 256や384, 512 ビットの曲線だ. 実装は160ビットよりも小さい曲線を使わないほうがよい. 楕円曲線ドメインパラメータとECDHやECDSA, ECMQVアルゴリズムのセキュリティの考察についてより詳しい議論は, [SEC1] の付録Bにある. また, この文書で定義された鍵交換法は, [FIPS-180-3] で定義されたハッシュ関数 SHA2ファミリに依存している. この文書の適切なセキュリティの考察が適用される. 先祖であるSHA-1にはいくつかの弱点が見つかっているが, SHA2ファミリには現在弱点は知られていない. SHA2 ファミリは4つのバリエーションで構成されている. SHA-224 と SHA-256, SHA-384, SHA-521 だ. そのダイジェストの長さによって命名された. ハッシュ関数特有の構造を攻撃する特別な攻撃がなければ, そのハッシュ関数の衝突や原像, 第2原像の発見の難しさはダイジェストの長さに依存する. この文書では, このガイダンスに基づく楕円曲線のサイズと共に利用する必要のある SHA2のバリエーションを 6.2.1節で指定している. ECDHとECMQVは, 任意の楕円曲線サイズ, つまり任意のセキュリティ強度を許すので, SSHハンドシェイクの他の要素のセキュリティ強度に一致する楕円曲線のサイズを選ぶことが重要だ. 特に ホスト鍵のサイズとハッシュアルゴリズムとバルク(任意長)暗号化アルゴリズムは, 適切に選択しなければならない. 鍵サイズの同等性の見積りについての情報は, [NIST-800-57] にある. [RFC3766]の議論も関連している. We note in particular that when ECDSA is used as the Stebila & Green Standards Track [Page 15] RFC 5656 SSH ECC Algorithm Integration December 2009 特に, ECDSAを署名アルゴリズムとしてかつECDHを鍵交換法として利用する際, 異なるサイズの曲線を利用していると, SHA2ファミリの異なるハッシュ関数が利用される可能性があることに注意. この文書での必須/推奨の曲線は, この節で示しまた1節の表で指定されたレベルのセキュリティを提供すると現時点では考えられている. システムの管理者と実装者は, この文書での必須や推奨でない曲線を有効にする際にセキュリティ問題について注意深く考察する必要がある. すべての楕円曲線は安全ではない. たとえ大きなフィールド上のものだったとしてもだ. すべての一時秘密鍵や乱数値 -- ECDSA署名生成での値 k や ECDHやECMQVの一時秘密鍵の値を含む -- が乱数生成器か適切にシードされ(漏洩から保護され)た疑似乱数生成器から生成され, この文書でのプロトコルの文脈の外側で再利用されず, 必要なくなった際にメモリから削除されるように 実装者は保証する必要がある. 10. 指定された楕円曲線ドメインパラメータ 実装は, 楕円曲線ドメインパラメータの集合を定義する ASN.1 オブジェクトツリーのすべての ASN.1 オブジェクト識別子(OID)をサポートしてもよい.[ASN1]. 10.1. 必須の曲線 すべての SSH 楕円曲線暗号実装は, 次の指定された曲線をサポートしなければならない. これらの曲線は [SEC2]で定義されている; NISTの曲線はもともと [NIST-CURVES]で定義されている. これらの曲線は, ローカルなセキュリティポリシーで明示的に無効にされていない限り, 常に有効である必要がある. +----------+-----------+---------------------+ | NIST* | SEC | OID | +----------+-----------+---------------------+ | nistp256 | secp256r1 | 1.2.840.10045.3.1.7 | | | | | | nistp384 | secp384r1 | 1.3.132.0.34 | | | | | | nistp521 | secp521r1 | 1.3.132.0.35 | +----------+-----------+---------------------+ * これらの3つの必須の曲線では, 楕円曲線ドメインパラメータ識別子は, この表の最初のカラムの文字列, 曲線のNIST名だ. (6.1節参照) Stebila & Green Standards Track [Page 16] RFC 5656 SSH ECC Algorithm Integration December 2009 10.2. 推奨される曲線 SSH楕円曲線暗号実装は次の曲線もサポートすることが推奨される. これらの曲線は [SEC2] で定義されている. +----------+-----------+---------------------+ | NIST | SEC | OID* | +----------+-----------+---------------------+ | nistk163 | sect163k1 | 1.3.132.0.1 | | | | | | nistp192 | secp192r1 | 1.2.840.10045.3.1.1 | | | | | | nistp224 | secp224r1 | 1.3.132.0.33 | | | | | | nistk233 | sect233k1 | 1.3.132.0.26 | | | | | | nistb233 | sect233r1 | 1.3.132.0.27 | | | | | | nistk283 | sect283k1 | 1.3.132.0.16 | | | | | | nistk409 | sect409k1 | 1.3.132.0.36 | | | | | | nistb409 | sect409r1 | 1.3.132.0.37 | | | | | | nistt571 | sect571k1 | 1.3.132.0.38 | +----------+-----------+---------------------+ * これらの推奨の曲線では, 楕円曲線ドメインパラメータ識別子は, この表の3番目のカラムの文字列, 曲線のOIDのASCII表現だ. (6.1節参照) 11. IANA の考慮 [RFC4251] の 8節と [RFC4250] の4.6節と整合するため, この文書は次の登録を行なう. 公開鍵アルゴリズム名レジストリに: "ecdsa-sha2-" で始まり アットマーク('@')を含まない SSH公開鍵アルゴリズム名のファミリを, 3節で定義した公開鍵アルゴリズムを指定するために登録. 鍵交換法名レジストリに: "ecdh-sha2-" で始まり アットマーク('@')を含まないSSH鍵交換法名を 4節で定義した鍵交換法を指定するために登録. Stebila & Green Standards Track [Page 17] RFC 5656 SSH ECC Algorithm Integration December 2009 鍵交換法名レジストリに: SSH鍵交換法名 "ecmqv-sha2" を 5節で定義した鍵交換法を指定するために登録. この文書は新しいレジストリは作成しない. 12. References 12.1. Normative References [ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002. [FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008. [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004. [RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006. [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. [RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006. [SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, May 2009, . [SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000, . Stebila & Green Standards Track [Page 18] RFC 5656 SSH ECC Algorithm Integration December 2009 12.2. Informative References [ANSI-X9.62] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: The Elliptic Curve Digital Signature Algorithm (ECDSA)", ANSI X9.62, 1998. [ANSI-X9.63] American National Standards Institute, "Public Key Cryptography For The Financial Services Industry: Key Agreement and Key Transport Using Elliptic Curve Cryptography", ANSI X9.63, January 1999. [HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to Elliptic Curve Cryptography", Springer ISBN 038795273X, 2004. [LMQSV98] Law, L., Menezes, A., Qu, M., Solinas, J., and S. Vanstone, "An Efficient Protocol for Authenticated Key Agreement", University of Waterloo Technical Report CORR 98-05, August 1998, . [NIST-800-57] National Institute of Standards and Technology, "Recommendation for Key Management - Part 1: General (Revised)", NIST Special Publication 800-57, March 2007. [NIST-CURVES] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", July 1999. Stebila & Green Standards Track [Page 19] RFC 5656 SSH ECC Algorithm Integration December 2009 Appendix A. Acknowledgements The authors acknowledge helpful comments from James Blaisdell, David Harrington, Alfred Hoenes, Russ Housley, Jeffrey Hutzelman, Kevin Igoe, Rob Lambert, Jan Pechanek, Tim Polk, Sean Turner, Nicolas Williams, and members of the ietf-ssh@netbsd.org mailing list. Authors' Addresses Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia EMail: douglas@stebila.ca Jon Green Queen's University Parallel Processing Research Laboratory Department of Electrical and Computer Engineering Room 614, Walter Light Hall Kingston, Ontario K7L 3N6 Canada EMail: jonathan.green@queensu.ca Stebila & Green Standards Track [Page 20]