[要約] RFC 5656は、Secure Shell（SSH）トランスポート層に楕円曲線アルゴリズムを統合するための仕様です。このRFCの目的は、SSHプロトコルのセキュリティを向上させるために、楕円曲線暗号を使用する方法を提案することです。
Network Working Group D. Stebila
Request for Comments: 5656 Queensland University of Technology
Category: Standards Track J. Green
Queen's University
December 2009
Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer
安全なシェル輸送層における楕円曲線アルゴリズムの統合
Abstract
概要
This document describes algorithms based on Elliptic Curve Cryptography (ECC) for use within the Secure Shell (SSH) transport protocol. In particular, it specifies Elliptic Curve Diffie-Hellman (ECDH) key agreement, Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement, and Elliptic Curve Digital Signature Algorithm (ECDSA) for use in the SSH Transport Layer protocol.
このドキュメントは、セキュアシェル（SSH）輸送プロトコル内で使用するための楕円曲線暗号化（ECC）に基づくアルゴリズムについて説明しています。特に、楕円曲線Diffie-Hellman（ECDH）の主要な一致、楕円曲線Menezes-QU-Vanstone（ECMQV）の主要な合意、およびSSH輸送層プロトコルで使用する楕円曲線デジタル署名アルゴリズム（ECDSA）を指定します。
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2009 IETF Trustおよび文書著者として特定された人。全著作権所有。
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.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、BSDライセンスに記載されているように保証なしで提供される簡略化されたBSDライセンステキストを含める必要があります。
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 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.
このドキュメントには、2008年11月10日までに公開または公開されたIETFドキュメントまたはIETFの寄付からの資料が含まれている場合があります。IETF標準プロセスの外。そのような資料の著作権を制御する人から適切なライセンスを取得せずに、このドキュメントはIETF標準プロセスの外側に変更されない場合があり、その派生作業は、ITF標準プロセスの外側で作成されない場合があります。RFCとしての出版またはそれを英語以外の言語に翻訳するため。
Table of Contents
目次
1. Introduction ....................................................3
2. Notation ........................................................4
3. SSH ECC Public Key Algorithm ....................................4
3.1. Key Format .................................................4
3.1.1. Signature Algorithm .................................5
3.1.2. Signature Encoding ..................................5
4. ECDH Key Exchange ...............................................5
5. ECMQV Key Exchange ..............................................8
6. Method Names ...................................................10
6.1. Elliptic Curve Domain Parameter Identifiers ...............10
6.2. ECC Public Key Algorithm (ecdsa-sha2-*) ...................11
6.2.1. Elliptic Curve Digital Signature Algorithm .........11
6.3. ECDH Key Exchange Method Names (ecdh-sha2-*) ..............12
6.4. ECMQV Key Exchange and Verification Method Name
(ecmqv-sha2) ..............................................12
7. Key Exchange Messages ..........................................13
7.1. ECDH Message Numbers ......................................13
7.2. ECMQV Message Numbers .....................................13
8. Manageability Considerations ...................................13
8.1. Control of Function through Configuration and Policy ......13
8.2. Impact on Network Operation ...............................14
9. Security Considerations ........................................14
10. Named Elliptic Curve Domain Parameters ........................16
10.1. Required Curves ..........................................16
10.2. Recommended Curves .......................................17
11. IANA Considerations ...........................................17
12. References ....................................................18
12.1. Normative References .....................................18
12.2. Informative References ...................................19
Appendix A. Acknowledgements .....................................20
This document adds the following elliptic curve cryptography algorithms to the Secure Shell arsenal: Elliptic Curve Diffie-Hellman (ECDH) and Elliptic Curve Digital Signature Algorithm (ECDSA), as well as utilizing the SHA2 family of secure hash algorithms. Additionally, support is provided for Elliptic Curve Menezes-Qu-Vanstone (ECMQV).
このドキュメントでは、次の楕円曲線暗号化アルゴリズムを安全なシェルアーセナルに追加します：楕円曲線diffie-hellman（ecdh）および楕円曲線デジタル署名アルゴリズム（ECDSA）、および安全なハッシュアルゴリズムのSHA2ファミリーを利用します。さらに、楕円曲線Menezes-QU-Vanstone（ECMQV）のサポートが提供されています。
Due to its small key sizes and its inclusion in the National Security Agency's Suite B, Elliptic Curve Cryptography (ECC) is becoming a widely utilized and attractive public-key cryptosystem.
キーサイズが小さく、国家安全保障局のスイートBに含まれるため、楕円曲線暗号化（ECC）は、広く利用され、魅力的な公共鍵の暗号システムになりつつあります。
Compared to cryptosystems such as RSA, the Digital Signature Algorithm (DSA), and Diffie-Hellman (DH) key exchange, ECC variations on these schemes offer equivalent security with smaller key sizes. This is illustrated in the following table, based on Section 5.6.1 of NIST 800-57 [NIST-800-57], which gives approximate comparable key sizes for symmetric- and asymmetric-key cryptosystems based on the best known algorithms for attacking them. L is the field size and N is the sub-field size.
RSAなどの暗号システムと比較して、Digital Signature Algorithm（DSA）、Diffie-Hellman（DH）のキー交換であるこれらのスキームのECCバリエーションは、キーサイズが小さい同等のセキュリティを提供します。これは、NIST 800-57 [NIST-800-57]のセクション5.6.1 [NIST-800-57]に基づいて、次の表に示されています。。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+ |
+-----------+------------------------------+-------+---------+
Implementation of this specification requires familiarity with both SSH [RFC4251] [RFC4253] [RFC4250] and ECC [SEC1] (additional information on ECC available in [HMV04], [ANSI-X9.62], and [ANSI-X9.63]).
この仕様の実装には、SSH [RFC4251] [RFC4253] [RFC4250]とECC [SEC1]の両方に精通する必要があります（[HMV04]、[ANSI-X9.62]、および[ANSI-X9.63]で利用可能なECCに関する追加情報）。
This document is concerned with SSH implementation details; specification of the underlying cryptographic algorithms is left to other standards documents.
このドキュメントは、SSHの実装の詳細に関係しています。基礎となる暗号化アルゴリズムの仕様は、他の標準ドキュメントに任されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
The data types boolean, byte, uint32, uint64, string, and mpint are to be interpreted in this document as described in [RFC4251].
[RFC4251]で説明されているように、このドキュメントでは、boolean、byte、uint32、uint64、string、and mpintのデータ型は解釈されます。
The size of a set of elliptic curve domain parameters on a prime curve is defined as the number of bits in the binary representation of the field order, commonly denoted by p. Size on a characteristic-2 curve is defined as the number of bits in the binary representation of the field, commonly denoted by m. A set of elliptic curve domain parameters defines a group of order n generated by a base point P.
プライム曲線上の楕円曲線ドメインパラメーターのセットのサイズは、一般にpで示されるフィールドオーダーのバイナリ表現のビット数として定義されます。特性2曲線のサイズは、一般にmで示されるフィールドのバイナリ表現のビット数として定義されます。楕円曲線ドメインパラメーターのセットは、ベースポイントPで生成された順序nのグループを定義します。
The SSH ECC public key algorithm is defined by its key format, corresponding signature algorithm ECDSA, signature encoding, and algorithm identifiers.
SSH ECC公開キーアルゴリズムは、そのキー形式、対応する署名アルゴリズムECDSA、署名エンコード、およびアルゴリズム識別子によって定義されます。
This section defines the family of "ecdsa-sha2-*" public key formats and corresponding signature formats. Every compliant SSH ECC implementation MUST implement this public key format.
このセクションでは、「ECDSA-SHA2-*」のファミリを公開キー形式と対応する署名形式を定義します。すべての準拠SSH ECC実装は、この公開キー形式を実装する必要があります。
The "ecdsa-sha2-*" key formats all have the following encoding:
「ECDSA-SHA2-*」のキーフォーマットにはすべて、次のエンコードがあります。
string "ecdsa-sha2-[identifier]" byte[n] ecc_key_blob
string "ecdsa-sha2- [識別子]" byte [n] ecc_key_blob
The ecc_key_blob value has the following specific encoding:
ECC_KEY_BLOB値には、次の特定のエンコードがあります。
string [identifier] string Q
文字列[識別子]文字列Q
The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1. Information on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm can be found in Section 10.
文字列[識別子]は、楕円曲線ドメインパラメーターの識別子です。この文字列の形式は、セクション6.1で指定されています。このアルゴリズムで使用するための楕円曲線ドメインパラメーターの必要なおよび推奨セットに関する情報は、セクション10に記載されています。
Q is the public key encoded from an elliptic curve point into an octet string as defined in Section 2.3.3 of [SEC1]; point compression MAY be used.
Qは、[SEC1]のセクション2.3.3で定義されているように、楕円曲線ポイントからオクテット文字列にエンコードされた公開キーです。ポイント圧縮を使用できます。
The algorithm for ECC key generation can be found in Section 3.2 of [SEC1]. Given some elliptic curve domain parameters, an ECC key pair can be generated containing a private key (an integer d), and a public key (an elliptic curve point Q).
ECCキー生成のアルゴリズムは、[SEC1]のセクション3.2に記載されています。いくつかの楕円曲線ドメインパラメーターを考えると、秘密鍵（整数D）と公開キー（楕円曲線ポイントQ）を含むECCキーペアを生成できます。
Signing and verifying is done using the Elliptic Curve Digital Signature Algorithm (ECDSA). ECDSA is specified in [SEC1]. The message hashing algorithm MUST be from the SHA2 family of hash functions [FIPS-180-3] and is chosen according to the curve size as specified in Section 6.2.1.
署名と検証は、Elliptic Curve Digital Signature Algorithm（ECDSA）を使用して行われます。ECDSAは[SEC1]で指定されています。メッセージハッシュアルゴリズムは、ハッシュ関数のSHA2ファミリー[FIPS-180-3]からのものでなければならず、セクション6.2.1で指定されている曲線サイズに従って選択されます。
Signatures are encoded as follows:
署名は次のようにエンコードされます。
string "ecdsa-sha2-[identifier]" string ecdsa_signature_blob
string "ecdsa-sha2- [識別子]" string ecdsa_signature_blob
The string [identifier] is the identifier of the elliptic curve domain parameters. The format of this string is specified in Section 6.1. Information on the REQUIRED and RECOMMENDED sets of elliptic curve domain parameters for use with this algorithm can be found in Section 10.
文字列[識別子]は、楕円曲線ドメインパラメーターの識別子です。この文字列の形式は、セクション6.1で指定されています。このアルゴリズムで使用するための楕円曲線ドメインパラメーターの必要なおよび推奨セットに関する情報は、セクション10に記載されています。
The ecdsa_signature_blob value has the following specific encoding:
ECDSA_SIGNATURE_BLOB値には、次の特定のエンコードがあります。
mpint r mpint s
mpint r mpint s
The integers r and s are the output of the ECDSA algorithm.
整数RとSは、ECDSAアルゴリズムの出力です。
The width of the integer fields is determined by the curve being used. Note that the integers r and s are integers modulo the order of the cryptographic subgroup, which may be larger than the size of the finite field.
整数フィールドの幅は、使用されている曲線によって決定されます。Integers RとSは、有限フィールドのサイズよりも大きい場合がある暗号化サブグループの順序を整数測定することに注意してください。
The Elliptic Curve Diffie-Hellman (ECDH) key exchange method generates a shared secret from an ephemeral local elliptic curve private key and ephemeral remote elliptic curve public key. This key exchange method provides explicit server authentication as defined in [RFC4253] using a signature on the exchange hash. Every compliant SSH ECC implementation MUST implement ECDH key exchange.
楕円曲線diffie-hellman（ECDH）キー交換方法は、一時的な局所楕円曲線の秘密鍵とはかなか遠隔の楕円曲線公開キーから共有された秘密を生成します。このキーエクスチェンジ方法は、[RFC4253]で定義されているように、Exchange Hashの署名を使用して明示的なサーバー認証を提供します。すべての準拠SSH ECC実装は、ECDHキー交換を実装する必要があります。
The primitive used for shared key generation is ECDH with cofactor multiplication, the full specification of which can be found in Section 3.3.2 of [SEC1]. The algorithm for key pair generation can be found in Section 3.2.1 of [SEC1].
共有キー生成に使用されるプリミティブは、補因子乗算を伴うECDHであり、その完全な仕様は[SEC1]のセクション3.3.2に記載されています。キーペア生成のアルゴリズムは、[SEC1]のセクション3.2.1に記載されています。
The family of key exchange method names defined for use with this key exchange can be found in Section 6.3. Algorithm negotiation chooses the public key algorithm to be used for signing and the method name of the key exchange. The method name of the key exchange chosen determines the elliptic curve domain parameters and hash function to be used in the remainder of this section.
このキーエクスチェンジで使用するために定義されたキーエクスチェンジメソッド名のファミリーは、セクション6.3に記載されています。アルゴリズムのネゴシエーションでは、署名に使用する公開キーアルゴリズムとキーエクスチェンジのメソッド名を選択します。選択したキーエクスチェンジのメソッド名は、このセクションの残りの部分で使用する楕円曲線ドメインパラメーターとハッシュ関数を決定します。
Information on the REQUIRED and RECOMMENDED elliptic curve domain parameters for use with this method can be found in Section 10.
この方法で使用するための必要および推奨される楕円曲線ドメインパラメーターに関する情報は、セクション10に記載されています。
All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail.
すべての楕円曲線パブリックキーは、受信後に検証する必要があります。検証アルゴリズムの例は、[SEC1]のセクション3.2.2に記載されています。キーが検証に失敗した場合、キー交換が失敗する必要があります。
The elliptic curve public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of [SEC1].
送信する必要がある楕円曲線パブリックキー（ポイント）は、送信する前にオクテットの弦にエンコードされます。楕円曲線ポイントとオクテット文字列の間の変換は、[SEC1]のセクション2.3.3および2.3.4で指定されています。ポイント圧縮を使用できます。共有キー生成の出力は、フィールド要素XPです。SSHフレームワークでは、共有キーが整数であることが必要です。フィールド要素と整数の間の変換は、[SEC1]のセクション2.3.9で指定されています。
Specification of the message numbers SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY is found in Section 7.
メッセージ番号の仕様ssh_msg_kex_ecdh_initおよびssh_msg_kex_ecdh_replyはセクション7にあります。
The following is an overview of the key exchange process:
以下は、主要な交換プロセスの概要です。
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECDH_INIT -------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate and sign exchange hash.
<------------- SSH_MSG_KEX_ECDH_REPLY
Verify received key is valid. *Verify host key belongs to server. Compute shared secret. Generate exchange hash. Verify server's signature.
受信キーが有効であることを確認します。*ホストキーがサーバーに属していることを確認します。共有秘密を計算します。Exchange Hashを生成します。サーバーの署名を確認します。
* It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks; see the discussion in Section 4.1 of [RFC4251].
* クライアントは、送信されたホストキーがサーバーのホストキーであることを確認することをお勧めします（たとえば、ローカルデータベースを使用するなど）。クライアントは、検証なしでホストキーを受け入れる場合がありますが、そうすることで、プロトコルがアクティブな攻撃に対して不安定になります。[RFC4251]のセクション4.1の説明を参照してください。
This is implemented using the following messages.
これは、次のメッセージを使用して実装されます。
The client sends:
クライアントが送信します：
byte SSH_MSG_KEX_ECDH_INIT string Q_C, client's ephemeral public key octet string
byte ssh_msg_kex_ecdh_init string q_c、クライアントのはかない公開キーオクテット文字列
The server responds with:
サーバーは次のとおりです。
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
byte ssh_msg_kex_ecdh_reply文字列k_s、サーバーのパブリックホストキー文字
The exchange hash H is computed as the hash of the concatenation of the following.
交換ハッシュ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
文字列v_c、クライアントの識別文字列（crおよびlf除外）文字列v_s、サーバーの識別文字列（crおよびlf除外）文字列i_c、sshg_kexinit文字列i_sのペイロード、サーバーのsshg_msg_kexinit文字列k_sのペイロード、サーバーの公開ホストキー文字列q_c、クライアントのはかない公開キーオクテット文字列Q_S、サーバーのはかない公共キーオクテットストリングMPINT K、共有秘密
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange algorithm generates a shared secret from two local elliptic curve key pairs and two remote public keys. This key exchange method provides implicit server authentication as defined in [RFC4253]. The ECMQV key exchange method is OPTIONAL.
楕円曲線Menezes-QU-Vanstone（ECMQV）キー交換アルゴリズムは、2つのローカル楕円曲線キーペアと2つのリモートパブリックキーから共有秘密を生成します。この重要な交換方法は、[RFC4253]で定義されているように、暗黙のサーバー認証を提供します。ECMQVキー交換方法はオプションです。
The key exchange method name defined for use with this key exchange is "ecmqv-sha2". This method name gives a hashing algorithm that is to be used for the Hashed Message Authentication Code (HMAC) below. Future RFCs may define new method names specifying new hash algorithms for use with ECMQV. More information about the method name and HMAC can be found in Section 6.4.
このキーエクスチェンジで使用するために定義されたキーエクスチェンジメソッド名は「ECMQV-SHA2」です。このメソッド名は、以下のハッシュされたメッセージ認証コード（HMAC）に使用されるハッシュアルゴリズムを示しています。将来のRFCは、ECMQVで使用する新しいハッシュアルゴリズムを指定する新しいメソッド名を定義する場合があります。メソッド名とHMACの詳細については、セクション6.4をご覧ください。
In general, the ECMQV key exchange is performed using the ephemeral and long-term key pair of both the client and server, which is a total of 4 keys. Within the framework of SSH, the client does not have a long-term key pair that needs to be authenticated. Therefore, we generate an ephemeral key and use that as both the clients keys. This is more efficient than using two different ephemeral keys, and it does not adversely affect security (it is analogous to the one-pass protocol in Section 6.1 of [LMQSV98]).
一般に、ECMQVキーエクスチェンジは、クライアントとサーバーの両方の短命と長期キーペアを使用して実行されます。これは合計4つのキーです。SSHのフレームワーク内では、クライアントには認証が必要な長期キーペアがありません。したがって、一時的なキーを生成し、それを両方のクライアントキーとして使用します。これは、2つの異なる一時的なキーを使用するよりも効率的であり、セキュリティに悪影響を与えません（[LMQSV98]のセクション6.1のワンパスプロトコルに類似しています）。
A full description of the ECMQV primitive can be found in Section 3.4 of [SEC1]. The algorithm for key pair generation can be found in Section 3.2.1 of [SEC1].
ECMQVプリミティブの完全な説明は、[SEC1]のセクション3.4に記載されています。キーペア生成のアルゴリズムは、[SEC1]のセクション3.2.1に記載されています。
During algorithm negotiation with the SSH_MSG_KEXINIT messages, the ECMQV key exchange method can only be chosen if a public key algorithm supporting ECC host keys can also be chosen. This is due to the use of implicit server authentication in this key exchange method. This case is handled the same way that key exchange methods requiring encryption/signature capable public key algorithms are handled in Section 7.1 of [RFC4253]. If ECMQV key exchange is chosen, then the public key algorithm supporting ECC host keys MUST also be chosen.
ssh_msg_kexinitメッセージとのアルゴリズムの交渉中に、ECCCホストキーをサポートする公開キーアルゴリズムも選択できる場合にのみ、ECMQVキー交換方法を選択できます。これは、この重要な交換方法での暗黙的なサーバー認証の使用によるものです。このケースは、暗号化/署名可能な公開キーアルゴリズムを必要とするキー交換方法が[RFC4253]のセクション7.1で処理されるのと同じ方法で処理されます。ECMQVキーエクスチェンジが選択されている場合、ECCホストキーをサポートする公開キーアルゴリズムも選択する必要があります。
ECMQV requires that all the keys used to generate a shared secret are generated over the same elliptic curve domain parameters. Since the host key is used in the generation of the shared secret, allowing for implicit server authentication, the domain parameters associated with the host key are used throughout this section.
ECMQVでは、共有秘密を生成するために使用されるすべてのキーが、同じ楕円曲線ドメインパラメーターで生成されることが必要です。ホストキーは共有秘密の生成で使用され、暗黙的なサーバー認証を可能にするため、このセクション全体でホストキーに関連付けられたドメインパラメーターが使用されます。
All elliptic curve public keys MUST be validated after they are received. An example of a validation algorithm can be found in Section 3.2.2 of [SEC1]. If a key fails validation, the key exchange MUST fail.
すべての楕円曲線パブリックキーは、受信後に検証する必要があります。検証アルゴリズムの例は、[SEC1]のセクション3.2.2に記載されています。キーが検証に失敗した場合、キー交換が失敗する必要があります。
The elliptic curve ephemeral public keys (points) that must be transmitted are encoded into octet strings before they are transmitted. The transformation between elliptic curve points and octet strings is specified in Sections 2.3.3 and 2.3.4 of [SEC1]; point compression MAY be used. The output of shared key generation is a field element xp. The SSH framework requires that the shared key be an integer. The conversion between a field element and an integer is specified in Section 2.3.9 of [SEC1].
送信しなければならない楕円曲線の短命のパブリックキー（ポイント）は、送信する前にオクテットの弦にエンコードされます。楕円曲線ポイントとオクテット文字列の間の変換は、[SEC1]のセクション2.3.3および2.3.4で指定されています。ポイント圧縮を使用できます。共有キー生成の出力は、フィールド要素XPです。SSHフレームワークでは、共有キーが整数であることが必要です。フィールド要素と整数の間の変換は、[SEC1]のセクション2.3.9で指定されています。
The following is an overview of the key exchange process:
以下は、主要な交換プロセスの概要です。
Client Server
------ ------
Generate ephemeral key pair.
SSH_MSG_KEX_ECMQV_INIT ------------->
Verify received key is valid.
Generate ephemeral key pair.
Compute shared secret.
Generate exchange hash and compute
HMAC over it using the shared secret.
<------------- SSH_MSG_KEX_ECMQV_REPLY
Verify received keys are valid. *Verify host key belongs to server. Compute shared secret. Verify HMAC.
受信したキーが有効であることを確認します。*ホストキーがサーバーに属していることを確認します。共有秘密を計算します。HMACを確認します。
* It is RECOMMENDED that the client verify that the host key sent is the server's host key (for example, using a local database). The client MAY accept the host key without verification, but doing so will render the protocol insecure against active attacks.
* クライアントは、送信されたホストキーがサーバーのホストキーであることを確認することをお勧めします（たとえば、ローカルデータベースを使用するなど）。クライアントは、検証なしでホストキーを受け入れる場合がありますが、そうすることで、プロトコルがアクティブな攻撃に対して不安定になります。
The specification of the message numbers SSH_MSG_ECMQV_INIT and SSH_MSG_ECMQV_REPLY can be found in Section 7.
メッセージ番号ssh_msg_ecmqv_initおよびssh_msg_ecmqv_replyの指定は、セクション7にあります。
This key exchange algorithm is implemented with the following messages.
このキーエクスチェンジアルゴリズムは、次のメッセージで実装されています。
The client sends:
クライアントが送信します：
byte SSH_MSG_ECMQV_INIT string Q_C, client's ephemeral public key octet string
byte ssh_msg_ecmqv_init string q_c、クライアントのはかない公共鍵オクテット文字列
The server sends:
サーバーが送信します：
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
byte ssh_msg_ecmqv_reply文字列k_s、サーバーのパブリックホストキー文字
The hash H is formed by applying the algorithm HASH on a concatenation of the following:
ハッシュ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
文字列v_c、クライアントの識別文字列（crおよびlf除外）文字列v_s、サーバーの識別文字列（crおよびlf除外）文字列i_c、sshg_kexinit文字列i_sのペイロード、サーバーのsshg_msg_kexinit文字列k_sのペイロード、サーバーの公開ホストキー文字列q_c、クライアントのはかない公開キーオクテット文字列Q_S、サーバーのはかない公共キーオクテットストリングMPINT K、共有秘密
This document defines a new family of key exchange method names, a new key exchange method name, and a new family of public key algorithm names in the SSH name registry.
このドキュメントでは、主要な交換メソッド名の新しいファミリ、新しいキー交換方法名、およびSSH名レジストリの公開キーアルゴリズム名の新しいファミリを定義します。
This section specifies identifiers encoding named elliptic curve domain parameters. These identifiers are used in this document to identify the curve used in the SSH ECC public key format, the ECDSA signature blob, and the ECDH method name.
このセクションでは、楕円曲線ドメインパラメーターという名前の識別子を指定します。これらの識別子は、このドキュメントで使用され、SSH ECC公開キー形式、ECDSA署名BLOB、およびECDHメソッド名で使用される曲線を識別します。
For the REQUIRED elliptic curves nistp256, nistp384, and nistp521, the elliptic curve domain parameter identifiers are the strings "nistp256", "nistp384", and "nistp521".
必要な楕円曲線NISTP256、NISTP384、およびNISTP521の場合、楕円曲線ドメインパラメーター識別子は、文字列「NISTP256」、「NISTP384」、および「NISTP521」です。
For all other elliptic curves, including all other NIST curves and all other RECOMMENDED curves, the elliptic curve domain parameter identifier is the ASCII period-separated decimal representation of the Abstract Syntax Notation One (ASN.1) [ASN1] Object Identifier (OID) of the named curve domain parameters that are associated with the server's ECC host keys. This identifier is defined provided that the concatenation of the public key format identifier and the elliptic curve domain parameter identifier (or the method name and the elliptic curve domain parameter identifier) does not exceed the maximum specified by the SSH protocol architecture [RFC4251], namely 64 characters; otherwise, the identifier for that curve is undefined, and the curve is not supported by this specification.
他のすべてのNIST曲線および他のすべての推奨曲線を含む他のすべての楕円曲線について、楕円曲線ドメインパラメーター識別子は、抽象的構文表記1（ASN.1）[ASN1]オブジェクト識別（OID）のASCII周期分離された小数表現です。サーバーのECCホストキーに関連付けられている名前の曲線ドメインパラメーターの。この識別子は、公開キー形式識別子と楕円曲線ドメインパラメーター識別子（またはメソッド名と楕円曲線ドメインパラメーター識別子）の連結がSSHプロトコルアーキテクチャ[RFC4251]、つまり指定された最大を超えないことを条件に定義されています。64文字;それ以外の場合、その曲線の識別子は未定義であり、この仕様によって曲線はサポートされていません。
A list of the REQUIRED and RECOMMENDED curves and their OIDs can be found in Section 10.
必要な曲線と推奨される曲線のリストとそれらのOIDは、セクション10に記載されています。
Note that implementations MUST use the string identifiers for the three REQUIRED NIST curves, even when an OID exists for that curve.
実装は、その曲線にOIDが存在する場合でも、3つの必要なNIST曲線の文字列識別子を使用する必要があることに注意してください。
The SSH ECC public key algorithm is specified by a family of public key format identifiers. Each identifier is the concatenation of the string "ecdsa-sha2-" with the elliptic curve domain parameter identifier as defined in Section 6.1. A list of the required and recommended curves and their OIDs can be found in Section 10.
SSH ECC公開キーアルゴリズムは、公開キー形式の識別子のファミリーによって指定されています。各識別子は、セクション6.1で定義されているように、楕円曲線ドメインパラメーター識別子との文字列「ecdsa-sha2-」の連結です。必要な曲線と推奨される曲線のリストとそれらのOIDは、セクション10に記載されています。
For example, the method name for ECDH key exchange with ephemeral keys generated on the nistp256 curve is "ecdsa-sha2-nistp256".
たとえば、NISTP256曲線で生成されたECDHキー交換のメソッド名は、「ECDSA-SHA2-NISTP256」です。
The Elliptic Curve Digital Signature Algorithm (ECDSA) is specified for use with the SSH ECC public key algorithm.
楕円曲線デジタル署名アルゴリズム（ECDSA）は、SSH ECC公開キーアルゴリズムで使用するために指定されています。
The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the public key:
メソッド名のこのファミリーによって定義されたハッシュアルゴリズムは、ハッシュアルゴリズムのSHA2ファミリーです[FIPS-180-3]。使用されるSHA2ファミリーのアルゴリズムは、公開鍵で指定された名前の曲線のサイズに基づいて選択されます。
+----------------+----------------+
| Curve Size | Hash Algorithm |
+----------------+----------------+
| b <= 256 | SHA-256 |
| | |
| 256 < b <= 384 | SHA-384 |
| | |
| 384 < b | SHA-512 |
+----------------+----------------+
The Elliptic Curve Diffie-Hellman (ECDH) key exchange is defined by a family of method names. Each method name is the concatenation of the string "ecdh-sha2-" with the elliptic curve domain parameter identifier as defined in Section 6.1. A list of the required and recommended curves and their OIDs can be found in Section 10.
楕円曲線diffie-hellman（ECDH）キー交換は、メソッド名のファミリーによって定義されます。各メソッド名は、セクション6.1で定義されているように、楕円曲線ドメインパラメーター識別子との文字列「ECDH-SHA2-」の連結です。必要な曲線と推奨される曲線のリストとそれらのOIDは、セクション10に記載されています。
For example, the method name for ECDH key exchange with ephemeral keys generated on the sect409k1 curve is "ecdh-sha2-1.3.132.0.36".
たとえば、SECT409K1曲線で生成されたECDHキー交換のメソッド名は、「ECDH-SHA2-1.3.132.0.36」です。
The hashing algorithm defined by this family of method names is the SHA2 family of hashing algorithms [FIPS-180-3]. The hashing algorithm is defined in the method name to allow room for other algorithms to be defined in future documents. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified in the method name according to the table in Section 6.2.1.
メソッド名のこのファミリーによって定義されたハッシュアルゴリズムは、ハッシュアルゴリズムのSHA2ファミリーです[FIPS-180-3]。ハッシュアルゴリズムは、メソッド名で定義されており、他のアルゴリズムが将来のドキュメントで定義されることを可能にします。使用されるSHA2ファミリーのアルゴリズムは、セクション6.2.1の表に従ってメソッド名で指定された名前の曲線のサイズに基づいて選択されます。
The concatenation of any so encoded ASN.1 OID specifying a set of elliptic curve domain parameters with "ecdh-sha2-" is implicitly registered under this specification.
「ECDH-SHA2-」を使用した楕円曲線ドメインパラメーターのセットを指定するそのようにエンコードされたasn.1 oidの連結は、この仕様に暗黙的に登録されています。
The Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key exchange is defined by the method name "ecmqv-sha2". Unlike the ECDH key exchange method, ECMQV relies on a public key algorithm that uses ECC keys: it does not need a family of method names because the curve information can be gained from the public key algorithm.
楕円曲線Menezes-QU-Vanstone（ECMQV）キー交換は、メソッド名「ECMQV-SHA2」で定義されます。ECDHキー交換法とは異なり、ECMQVはECCキーを使用する公開キーアルゴリズムに依存しています。曲線情報を公開キーアルゴリズムから得ることができるため、メソッド名のファミリーは必要ありません。
The hashing and message authentication code algorithms are defined by the method name to allow room for other algorithms to be defined for use with ECMQV in future documents.
ハッシュおよびメッセージ認証コードアルゴリズムは、メソッド名で定義され、他のアルゴリズムが将来のドキュメントでECMQVで使用するためのスペースを定義できるようにします。
The hashing algorithm defined by this method name is the SHA2 family of hashing algorithms [FIPS-180-3]. The algorithm from the SHA2 family that will be used is chosen based on the size of the named curve specified for use with ECMQV by the chosen public key algorithm according to the table in Section 6.2.1.
このメソッド名で定義されたハッシュアルゴリズムは、ハッシュアルゴリズム[FIPS-180-3]のSHA2ファミリーです。使用されるSHA2ファミリーからのアルゴリズムは、セクション6.2.1の表に従って、選択した公開キーアルゴリズムによってECMQVで使用されるように指定された指定された曲線のサイズに基づいて選択されます。
The keyed-hash message authentication code that is used to identify the server and verify communications is based on the hash chosen above. The information on implementing the HMAC based on the chosen hash algorithm can be found in [RFC2104].
サーバーを識別し、通信を確認するために使用されるキー付きHASHメッセージ認証コードは、上記のハッシュに基づいています。選択したハッシュアルゴリズムに基づいてHMACの実装に関する情報は、[RFC2104]に記載されています。
The message numbers 30-49 are key-exchange-specific and in a private namespace defined in [RFC4250] that may be redefined by any key exchange method [RFC4253] without requiring an IANA registration process.
メッセージ番号30-49は、キーエクセンジ固有であり、[RFC4250]で定義されたプライベートネームスペースで、IANA登録プロセスを必要とせずにキー交換方法[RFC4253]によって再定義される場合があります。
The following message numbers have been defined in this document:
次のメッセージ番号は、このドキュメントで定義されています。
#define SSH_MSG_KEX_ECDH_INIT 30
#define SSH_MSG_KEX_ECDH_REPLY 31
#define SSH_MSG_ECMQV_INIT 30
#define SSH_MSG_ECMQV_REPLY 31
As this document only provides new public key algorithms and key exchange methods within the existing Secure Shell protocol architecture, there are few manageability considerations beyond those that apply for existing Secure Shell implementations. Additional manageability considerations are listed below.
このドキュメントは、既存の安全なシェルプロトコルアーキテクチャ内の新しい公開キーアルゴリズムとキー交換方法のみを提供するため、既存のセキュアーシェル実装に適用されるものを超えて管理可能性の考慮事項はほとんどありません。追加の管理可能性の考慮事項を以下に示します。
Section 10 specifies REQUIRED and RECOMMENDED elliptic curve domain parameters to be used with the public key algorithms and key exchange methods defined in this document. Implementers SHOULD allow system administrators to disable some curves, including REQUIRED or RECOMMENDED curves, to meet local security policy.
セクション10では、このドキュメントで定義されている公開キーアルゴリズムとキー交換方法で使用する必要と推奨される楕円曲線ドメインパラメーターを指定します。実装者は、システム管理者がローカルセキュリティポリシーを満たすために、必要または推奨される曲線を含むいくつかの曲線を無効にすることを許可する必要があります。
As this document provides new functionality within the Secure Shell protocol architecture, the only impact on network operations is the impact on existing Secure Shell implementations. The Secure Shell protocol provides negotiation mechanisms for public key algorithms and key exchange methods: any implementations that do not recognize the algorithms and methods defined in this document will ignore them in the negotiation and use the next mutually supported algorithm or method, causing no negative impact on backward compatibility.
このドキュメントは、Secure Shellプロトコルアーキテクチャ内で新しい機能を提供するため、ネットワーク操作に唯一の影響は既存の安全なシェル実装に影響を与えることです。安全なシェルプロトコルは、公開キーアルゴリズムとキー交換方法のネゴシエーションメカニズムを提供します。このドキュメントで定義されているアルゴリズムとメソッドを認識しない実装は、交渉でそれらを無視し、次の相互にサポートされたアルゴリズムまたはメソッドを使用し、負の影響を引き起こしません。後方互換性について。
The use of elliptic curve cryptography should not place a significant computational burden on an implementing server. In fact, due to its smaller key sizes, elliptic curve cryptography can be implemented more efficiently for the same security level than RSA, finite field Diffie-Hellman, or DSA.
楕円曲線暗号化の使用は、実装サーバーに重大な計算負荷をかけるべきではありません。実際、キーサイズが小さいため、楕円曲線暗号化は、RSA、有限のフィールドディフェルマン、またはDSAと同じセキュリティレベルでより効率的に実装できます。
This document provides new public key algorithms and new key agreement methods for the Secure Shell protocol. For the most part, the security considerations involved in using the Secure Shell protocol apply. Additionally, implementers should be aware of security considerations specific to elliptic curve cryptography.
このドキュメントは、安全なシェルプロトコルの新しい公開キーアルゴリズムと新しいキー契約メソッドを提供します。ほとんどの場合、Secure Shellプロトコルの使用に伴うセキュリティ上の考慮事項が適用されます。さらに、実装者は、楕円曲線暗号化に固有のセキュリティ上の考慮事項に注意する必要があります。
For all three classes of functionality added by this document (the public key algorithms involving ECDSA, key exchange involving ECDH, and authenticated key exchange involving ECMQV), the current best known technique for breaking the cryptosystems is by solving the elliptic curve discrete logarithm problem (ECDLP).
このドキュメントによって追加された3つのクラスの機能すべて（ECDSA、ECDHを含む主要な交換、およびECMQVを含む認証されたキー交換）によって追加されたすべての機能について、暗号システムを破るための現在の最もよく知られている手法は、楕円曲線離散対数問題を解決することです。ECDLP）。
The difficulty of breaking the ECDLP depends on the size and quality of the elliptic curve parameters. Certain types of curves can be more susceptible to known attacks than others. For example, curves over finite fields GF(2^m), where m is composite, may be susceptible to an attack based on the Weil descent. All of the RECOMMENDED curves in Section 10 do not have this problem. System administrators should be cautious when enabling curves other than the ones specified in Section 10 and should make a more detailed investigation into the security of the curve in question.
ECDLPを破ることの難しさは、楕円曲線パラメーターのサイズと品質に依存します。特定の種類の曲線は、他の種類よりも既知の攻撃の影響を受けやすい場合があります。たとえば、Mが複合材である有限フィールドGF（2^m）の曲線は、weil降下に基づく攻撃の影響を受けやすい場合があります。セクション10の推奨曲線はすべて、この問題はありません。セクション10で指定されたもの以外の曲線を有効にする場合、システム管理者は慎重になり、問題の曲線のセキュリティをより詳細に調査する必要があります。
It is believed (see, for example, Section B.2.1 of [SEC1]) that when curve parameters are generated at random, the curves will be resistant to special attacks, and must rely on the most general attacks. The REQUIRED curves in Section 10 were all generated verifiably pseudorandomly. The runtime of general attacks depends on the algorithm used. At present, the best known algorithm is the Pollard-rho method. (Shor's algorithm for quantum computers can solve the ECDLP in polynomial time, but at present large-scale quantum computers have not been constructed and significant experimental physics and engineering work needs to be done before large-scale quantum computers can be constructed. There is no solid estimate as to when this may occur, but it is widely believed to be at least 20 years from the present.)
曲線パラメーターがランダムに生成されると、曲線が特別な攻撃に耐性があり、最も一般的な攻撃に依存する必要があると、曲線パラメーターがランダムに生成されると考えられています（たとえば、[SEC1]のセクションB.2.1を参照）。セクション10に必要な曲線はすべて、検証可能に生成されました。一般的な攻撃の実行時間は、使用されるアルゴリズムによって異なります。現在、最もよく知られているアルゴリズムはPollard-RHOメソッドです。（量子コンピューターのShorのアルゴリズムは多項式時間でECDLPを解決できますが、現在は大規模な量子コンピューターが構築されておらず、大規模な量子コンピューターを構築する前に、重要な実験物理学と工学作業を行う必要があります。これがいつ発生する可能性があるかについての確実な推定値は、少なくとも現在から20年以上であると広く信じられています。）
Based on projections of computation power, it is possible to estimate the running time of the best known attacks based on the size of the finite field. The table in Section 1 gives an estimate of the equivalence between elliptic curve field size and symmetric key size. Roughly speaking, an N-bit elliptic curve offers the same security as an N/2-bit symmetric cipher, so a 256-bit elliptic curve (such as the REQUIRED nistp256 curve) is suitable for use with 128-bit AES, for example.
計算能力の投影に基づいて、有限フィールドのサイズに基づいて、最も既知の攻撃の実行時間を推定することができます。セクション1の表は、楕円曲線フィールドサイズと対称キーサイズの等価性の推定値を示しています。大まかに言えば、Nビット楕円曲線はN/2ビット対称暗号と同じセキュリティを提供するため、たとえば、256ビットの楕円曲線（必要なNISTP256曲線など）は128ビットAEでの使用に適しています。。
Many estimates consider that 2^80-2^90 operations are beyond feasible, so that would suggest using elliptic curves of at least 160-180 bits. The REQUIRED curves in this document are 256-, 384-, and 521-bit curves; implementations SHOULD NOT use curves smaller than 160 bits.
多くの推定では、2^80-2^90の操作は実行可能であると考えているため、少なくとも160〜180ビットの楕円曲線を使用することが示唆されます。このドキュメントに必要な曲線は、256-、384、および521ビット曲線です。実装は、160ビット以下の曲線を使用しないでください。
A detailed discussion on the security considerations of elliptic curve domain parameters and the ECDH, ECDSA, and ECMQV algorithms can be found in Appendix B of [SEC1].
楕円曲線ドメインパラメーターとECDH、ECDSA、およびECMQVアルゴリズムのセキュリティに関する考慮事項に関する詳細な議論は、[SEC1]の付録Bに記載されています。
Additionally, the key exchange methods defined in this document rely on the SHA2 family of hash functions, defined in [FIPS-180-3]. The appropriate security considerations of that document apply. Although some weaknesses have been discovered in the predecessor, SHA-1, no weaknesses in the SHA2 family are known at present. The SHA2 family consists of four variants -- SHA-224, SHA-256, SHA-384, and SHA-521 -- named after their digest lengths. In the absence of special purpose attacks exploiting the specific structure of the hash function, the difficulty of finding collisions, preimages, and second preimages for the hash function is related to the digest length. This document specifies in Section 6.2.1 which SHA2 variant should be used with which elliptic curve size based on this guidance.
さらに、このドキュメントで定義されている主要な交換方法は、[FIPS-180-3]で定義されているHash機能のSHA2ファミリーに依存しています。そのドキュメントの適切なセキュリティ上の考慮事項が適用されます。前任者ではいくつかの弱点が発見されていますが、SHA-1は、現在SHA2ファミリーの弱点は知られていません。SHA2ファミリーは、SHA-224、SHA-256、SHA-384、およびSHA-521の4つのバリアントで構成されています。ハッシュ関数の特定の構造を活用する特別な目的攻撃がない場合、ハッシュ関数の衝突、プリイメージ、および2番目のプリイメージを見つけることの難しさは、消化長に関連しています。このドキュメントは、このガイダンスに基づいて楕円曲線サイズのSHA2バリアントを使用する必要があるセクション6.2.1で指定しています。
Since ECDH and ECMQV allow for elliptic curves of arbitrary sizes and thus arbitrary security strength, it is important that the size of elliptic curve be chosen to match the security strength of other elements of the SSH handshake. In particular, host key sizes, hashing algorithms and bulk encryption algorithms must be chosen appropriately. Information regarding estimated equivalence of key sizes is available in [NIST-800-57]; the discussion in [RFC3766] is also relevant. We note in particular that when ECDSA is used as the signature algorithm and ECDH is used as the key exchange method, if curves of different sizes are used, then it is possible that different hash functions from the SHA2 family could be used.
ECDHとECMQVは、任意のサイズの楕円曲線を可能にし、したがって任意のセキュリティ強度を可能にするため、SSHハンドシェイクの他の要素のセキュリティ強度に一致するように楕円曲線のサイズを選択することが重要です。特に、ホストのキーサイズ、ハッシュアルゴリズム、バルク暗号化アルゴリズムを適切に選択する必要があります。キーサイズの推定等価性に関する情報は、[NIST-800-57]で入手できます。[RFC3766]での議論も関連しています。特に、ECDSAが署名アルゴリズムとして使用され、ECDHがキー交換方法として使用される場合、異なるサイズの曲線を使用する場合、SHA2ファミリーからの異なるハッシュ関数を使用できる可能性があることに注意してください。
The REQUIRED and RECOMMENDED curves in this document are at present believed to offer security at the levels indicated in this section and as specified with the table in Section 1.
このドキュメントで必要な曲線と推奨される曲線は、現在、このセクションで示されているレベルでセキュリティを提供し、セクション1の表で指定されていると考えられています。
System administrators and implementers should take careful consideration of the security issues when enabling curves other than the REQUIRED or RECOMMENDED curves in this document. Not all elliptic curves are secure, even if they are over a large field.
システム管理者と実装者は、このドキュメントで必要な曲線または推奨曲線以外の曲線を有効にする際に、セキュリティの問題を慎重に考慮する必要があります。すべての楕円曲線が、たとえ大きなフィールドを超えていても、安全であるわけではありません。
Implementers SHOULD ensure that any ephemeral private keys or random values -- including the value k used in ECDSA signature generation and the ephemeral private key values in ECDH and ECMQV -- are generated from a random number generator or a properly seeded pseudorandom number generator, are protected from leakage, are not reused outside of the context of the protocol in this document, and are erased from memory when no longer needed.
実装者は、ECDSA署名生成で使用される値KやECDHおよびECMQVのはかない秘密鍵値を含む、はかないプライベートキーまたはランダムな値が、乱数ジェネレーターまたは適切にシードされた擬似ランダム数ジェネレーターから生成されることを確認する必要があります。漏れから保護されており、このドキュメントのプロトコルのコンテキストの外で再利用されず、不要になったときにメモリから消去されます。
Implementations MAY support any ASN.1 object identifier (OID) in the ASN.1 object tree that defines a set of elliptic curve domain parameters [ASN1].
実装は、楕円曲線ドメインパラメーターのセットを定義するASN.1オブジェクトツリーのASN.1オブジェクト識別子（OID）をサポートする場合があります[ASN1]。
Every SSH ECC implementation MUST support the named curves below. These curves are defined in [SEC2]; the NIST curves were originally defined in [NIST-CURVES]. These curves SHOULD always be enabled unless specifically disabled by local security policy.
すべてのSSH ECC実装は、以下の名前の曲線をサポートする必要があります。これらの曲線は[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 |
+----------+-----------+---------------------+
* For these three REQUIRED curves, the elliptic curve domain parameter identifier is the string in the first column of the table, the NIST name of the curve. (See Section 6.1.)
* これら3つの必要な曲線の場合、楕円曲線ドメインパラメーター識別子は、テーブルの最初の列、曲線のNIST名の文字列です。（セクション6.1を参照してください。）
It is RECOMMENDED that SSH ECC implementations also support the following curves. These curves are defined in [SEC2].
SSH ECC実装も次の曲線をサポートすることをお勧めします。これらの曲線は[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 |
+----------+-----------+---------------------+
* For these RECOMMENDED curves, the elliptic curve domain parameter identifier is the string in the third column of the table, the ASCII representation of the OID of the curve. (See Section 6.1.)
* これらの推奨曲線では、楕円曲線ドメインパラメーター識別子は、テーブルの3番目の列の文字列であり、曲線のOIDのASCII表現です。（セクション6.1を参照してください。）
Consistent with Section 8 of [RFC4251] and Section 4.6 of [RFC4250], this document makes the following registrations:
[RFC4251]のセクション8および[RFC4250]のセクション4.6と一致して、このドキュメントは次の登録を作成します。
In the Public Key Algorithm Names registry: The family of SSH public key algorithm names beginning with "ecdsa-sha2-" and not containing the at-sign ('@'), to name the public key algorithms defined in Section 3.
公開キーアルゴリズム名レジストリ：「ecdsa-sha2-」から始まり、aT-sign（ '@'）を含んでいないSSH公開キーアルゴリズム名のファミリー。
In the Key Exchange Method Names registry: The family of SSH key exchange method names beginning with "ecdh-sha2-" and not containing the at-sign ('@'), to name the key exchange methods defined in Section 4.
キーエクスチェンジメソッド名レジストリ：「ECDH-SHA2」から始まり、AT-SIGN（ '@'）を含んでいないSSHキーエクスチェンジメソッド名のファミリーは、セクション4で定義されているキー交換メソッドを挙げます。
In the Key Exchange Method Names registry: The SSH key exchange method name "ecmqv-sha2" to name the key exchange method defined in Section 5.
キーエクスチェンジメソッド名レジストリ：SSHキーエクスチェンジメソッド名「ECMQV-SHA2」という名前のセクション5で定義されているキー交換メソッド。
This document creates no new registries.
このドキュメントは、新しいレジストリを作成しません。
[ASN1] International Telecommunications Union, "Abstract Syntax Notation One (ASN.1): Specification of basic notation", X.680, July 2002.
[ASN1] International Telecommunications Union、「Abstract Syntax Notation One（ASN.1）：基本表記の仕様」、X.680、2002年7月。
[FIPS-180-3] National Institute of Standards and Technology, "Secure Hash Standard", FIPS 180-3, October 2008.
[FIPS-180-3]国立標準技術研究所、「Secure Hash Standard」、FIPS 180-3、2008年10月。
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997.
[RFC2104] Krawczyk、H.、Bellare、M。、およびR. CaNetti、「HMAC：メッセージ認証のためのキー付きハッシング」、RFC 2104、1997年2月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC3766] Orman, H. and P. Hoffman, "Determining Strengths For Public Keys Used For Exchanging Symmetric Keys", BCP 86, RFC 3766, April 2004.
[RFC3766] Orman、H。およびP. Hoffman、「対称キーの交換に使用される公共キーの強度の決定」、BCP 86、RFC 3766、2004年4月。
[RFC4250] Lehtinen, S. and C. Lonvick, "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, January 2006.
[RFC4250] Lehtinen、S。およびC. Lonvick、「Secure Shell（SSH）プロトコルが割り当てられた数字」、RFC 4250、2006年1月。
[RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006.
[RFC4251] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）プロトコルアーキテクチャ」、RFC 4251、2006年1月。
[RFC4253] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, January 2006.
[RFC4253] Ylonen、T。およびC. Lonvick、「The Secure Shell（SSH）輸送層プロトコル」、RFC 4253、2006年1月。
[SEC1] Standards for Efficient Cryptography Group, "Elliptic Curve Cryptography", SEC 1, May 2009, <http://www.secg.org/download/aid-780/sec1-v2.pdf>.
[SEC1]効率的な暗号化グループの基準、「Elliptic Curve Cryptography」、Sec 1、2009年5月、<http://www.secg.org/download/aid-780/sec1-v2.pdf>。
[SEC2] Standards for Efficient Cryptography Group, "Recommended Elliptic Curve Domain Parameters", SEC 2, September 2000, <http://www.secg.org/download/aid-386/sec2_final.pdf>.
[SEC2]効率的な暗号化グループの基準、「推奨される楕円曲線ドメインパラメーター」、2000年9月<http://www.secg.org/download/aid-386/sec2_final.pdf>。
[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.62] American National Standards Institute、「金融サービス業界向けの公開鍵暗号：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.
[ANSI-X9.63] American National Standards Institute、「金融サービス業界向けの公開主要な暗号化：楕円曲線暗号化を使用した主要な合意と主要な輸送」、ANSI X9.63、1999年1月。
[HMV04] Hankerson, D., Menezes, A., and S. Vanstone, "Guide to Elliptic Curve Cryptography", Springer ISBN 038795273X, 2004.
[HMV04] Hankerson、D.、Menezes、A。、およびS. Vanstone、「楕円曲線暗号化のガイド」、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, <http:// www.cacr.math.uwaterloo.ca/techreports/1998/ corr98-05.pdf>.
[LMQSV98] Law、L.、Menezes、A.、Qu、M.、Solinas、J。、およびS. Vanstone、「認証された主要契約のための効率的なプロトコル」、Waterloo University of Waterloo Technical Report Corr 98-05、1998年8月、<http：// www.cacr.math.uwaterloo.ca/techreports/1998/ corr98-05.pdf>。
[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-800-57]国立標準技術研究所、「主要な管理の推奨 - パート1：一般（改訂）」、NIST Special Publication 800-57、2007年3月。
[NIST-CURVES] National Institute of Standards and Technology, "Recommended Elliptic Curves for Federal Government Use", July 1999.
[NIST-CURVES]国立標準技術研究所、「連邦政府の使用に推奨される楕円曲線」、1999年7月。
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.
著者は、ジェームズ・ブレイスデル、デビッド・ハリントン、アルフレッド・ホーネス、ラス・ハウスリー、ジェフリー・ハッツェルマン、ケビン・イゴー、ロブ・ランバート、ヤン・ペチャネク、ティム・ポーク、ショーン・ターナー、ニコラス・ウィリアムズ、およびIETF-shsh@netbsd.orgのメンバーからの有益なコメントを認めています。メーリングリスト。
Authors' Addresses
著者のアドレス
Douglas Stebila Queensland University of Technology Information Security Institute Level 7, 126 Margaret St Brisbane, Queensland 4000 Australia
ダグラス・ステビラ・クイーンズランド大学技術情報情報セキュリティ研究所レベル7、126マーガレット・セント・ブリスベン、クイーンズランド4000オーストラリア
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
ジョングリーンクイーンズ大学並列処理研究研究所電気およびコンピューターエンジニアリングルーム614、ウォルターライトホールキングストン、オンタリオK7L 3N6カナダ
EMail: jonathan.green@queensu.ca