RFC 8731 - Secure Shell (SSH) Key Exchange Method using Curve25519 and Curve448 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8731.html
タイトル : RFC 8731 - Curve25519およびCurve448を使用したセキュアシェル（SSH）鍵交換方式
翻訳編集 : 自動生成＆有志による翻訳・編集

[要約] RFC 8731は、Secure Shell（SSH）プロトコルにおいてCurve25519およびCurve448鍵交換方式を使用するための仕様を記述しています。この文書は、これらの曲線を用いた、より安全で効率的な鍵交換の実現を目指し、Curve25519では約128ビット、Curve448では約224ビットの強力なセキュリティを提供します。

Internet Engineering Task Force (IETF)                   A. Adamantiadis
Request for Comments: 8731                                        libssh
Category: Standards Track                                   S. Josefsson
ISSN: 2070-1721                                                   SJD AB
                                                              M. Baushke
                                                  Juniper Networks, Inc.
                                                           February 2020

Secure Shell (SSH) Key Exchange Method Using Curve25519 and Curve448

Curve25519およびCurve448を使用したセキュアシェル（SSH）鍵交換方式

Abstract

概要

This document describes the specification for using Curve25519 and Curve448 key exchange methods in the Secure Shell (SSH) protocol.

このドキュメントでは、Secure Shell（SSH）プロトコルでCurve25519およびCurve448鍵交換方式を使用するための仕様について説明します。

Status of This Memo

本文書の位置付け

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、IETF（Internet Engineering Task Force）の成果物です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション2をご覧ください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8731.

このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc8731で入手できます。

著作権表示

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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 Simplified BSD License.

この文書は、BCP 78 および本文書発行日時点でのIETFトラストのIETF文書に関する法的規定（https://trustee.ietf.org/license-info）に従います。これらの文書は、本文書に関するあなたの権利と制限を記述しているため、注意深く確認してください。この文書から抽出されたコードコンポーネントには、トラスト法的規定のセクション4.eに記述されている簡易BSDライセンスのテキストが含まれていなければならず、簡易BSDライセンスに記述されている通り無保証で提供されます。

Table of Contents

   1.  Introduction
   2.  Requirements Language
   3.  Key Exchange Methods
     3.1.  Shared Secret Encoding
   4.  Security Considerations
   5.  IANA Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Acknowledgements
   Authors' Addresses

1. Introduction

1. はじめに

Secure Shell (SSH) [RFC4251] is a secure remote login protocol. The key exchange protocol described in [RFC4253] supports an extensible set of methods. [RFC5656] defines how elliptic curves are integrated into this extensible SSH framework, and this document reuses the Elliptic Curve Diffie-Hellman (ECDH) key exchange protocol messages defined in Section 7.1 (ECDH Message Numbers) of [RFC5656]. Other parts of [RFC5656], such as Elliptic Curve Menezes-Qu-Vanstone (ECMQV) key agreement and Elliptic Curve Digital Signature Algorithm (ECDSA), are not considered in this document.

Secure Shell（SSH）[RFC4251]は、安全なリモートログインプロトコルです。[RFC4253]で記述されている鍵交換プロトコルは、拡張可能な方式群をサポートしています。[RFC5656]は、楕円曲線がこの拡張可能なSSHフレームワークにどのように統合されるかを定義しており、本ドキュメントは[RFC5656]のセクション7.1（ECDHメッセージ番号）で定義されている楕円曲線Diffie-Hellman（ECDH）鍵交換プロトコルメッセージを再利用します。[RFC5656]の他の部分、例えば楕円曲線Menezes-Qu-Vanstone（ECMQV）鍵合意や楕円曲線デジタル署名アルゴリズム（ECDSA）などは、本ドキュメントでは考慮されません。

This document describes how to implement key exchange based on Curve25519 and Curve448 [RFC7748] in SSH. For Curve25519 with SHA-256 [RFC6234][SHS], the algorithm described is equivalent to the privately defined algorithm "curve25519-sha256@libssh.org", which at the time of publication was implemented and widely deployed in libssh [libssh] and OpenSSH [OpenSSH]. The Curve448 key exchange method is similar but uses SHA-512 [RFC6234][SHS].

このドキュメントでは、SSHでCurve25519およびCurve448 [RFC7748]に基づく鍵交換を実装する方法について説明します。SHA-256 [RFC6234] [SHS]を使用するCurve25519の場合、記述されているアルゴリズムは、公開時点ではlibssh [libssh]とOpenSSH [OpenSSH]で実装され広く展開されていた、非公開で定義されたアルゴリズム「curve25519-sha256@libssh.org」と同等です。Curve448の鍵交換方式は同様ですが、SHA-512 [RFC6234] [SHS]を使用します。

2. Requirements Language

2. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、本ドキュメントにおいて、ここに示されているようにすべて大文字で出現する場合にのみ、BCP 14 [RFC2119] [RFC8174]で記述されているように解釈されます。

3. Key Exchange Methods

3. 鍵交換方式

The key exchange procedure is similar to the ECDH method described in Section 4 of [RFC5656], though with a different wire encoding used for public values and the final shared secret. Public ephemeral keys are encoded for transmission as standard SSH strings.

鍵交換の手順は[RFC5656]のセクション4で記述されているECDH方式と似ていますが、公開値と最終的な共有秘密に使用されるワイヤエンコーディングが異なります。公開エフェメラル鍵は、送信用に標準のSSH文字列としてエンコードされます。

The protocol flow, the SSH_MSG_KEX_ECDH_INIT and SSH_MSG_KEX_ECDH_REPLY messages, and the structure of the exchange hash are identical to Section 4 of [RFC5656].

プロトコルフロー、SSH_MSG_KEX_ECDH_INITおよびSSH_MSG_KEX_ECDH_REPLYメッセージ、および交換ハッシュの構造は、[RFC5656]のセクション4と同じです。

The method names registered by this document are "curve25519-sha256" and "curve448-sha512".

このドキュメントで登録されている方式名は「curve25519-sha256」と「curve448-sha512」です。

The methods are based on Curve25519 and Curve448 scalar multiplication, as described in [RFC7748]. Private and public keys are generated as described therein. Public keys are defined as strings of 32 bytes for Curve25519 and 56 bytes for Curve448.

[RFC7748]で記述されているように、これらの方式はCurve25519およびCurve448スカラー倍算に基づいています。秘密鍵と公開鍵は同文書で記述されているように生成されます。公開鍵は、Curve25519では32バイト、Curve448では56バイトの文字列として定義されます。

The key-agreement schemes "curve25519-sha256" and "curve448-sha512" perform the Diffie-Hellman protocol using the functions X25519 and X448, respectively. Implementations SHOULD compute these functions using the algorithms described in [RFC7748]. When they do so, implementations MUST check whether the computed Diffie-Hellman shared secret is the all-zero value and abort if so, as described in Section 6 of [RFC7748]. Alternative implementations of these functions SHOULD abort when either the client or the server input forces the shared secret to one of a small set of values, as described in Sections 6 and 7 of [RFC7748]. Clients and servers MUST also abort if the length of the received public keys are not the expected lengths. An abort for these purposes is defined as a disconnect (SSH_MSG_DISCONNECT) of the session and SHOULD use the SSH_DISCONNECT_KEY_EXCHANGE_FAILED reason for the message [IANA-REASON]. No further validation is required beyond what is described in [RFC7748]. The derived shared secret is 32 bytes when "curve25519-sha256" is used and 56 bytes when "curve448-sha512" is used. The encodings of all values are defined in [RFC7748]. The hash used is SHA-256 for "curve25519-sha256" and SHA-512 for "curve448-sha512".

鍵合意方式「curve25519-sha256」と「curve448-sha512」は、それぞれ関数X25519とX448を用いてDiffie-Hellmanプロトコルを実行します。実装は、[RFC7748]で記述されているアルゴリズムを用いてこれらの関数を計算すべきです。その際、[RFC7748]のセクション6に記述されているように、計算されたDiffie-Hellman共有秘密がすべてゼロの値であるかどうかを確認し、そうである場合は中断しなければなりません。これらの関数の代替実装は、[RFC7748]のセクション6および7に記述されているように、クライアントまたはサーバーの入力が共有秘密を少数の値の1つに強制する場合に中断すべきです。受信した公開鍵の長さが期待される長さではない場合、クライアントとサーバーも中断しなければなりません。これらの目的での中断は、セッションの切断（SSH_MSG_DISCONNECT）として定義され、メッセージ[IANA-REASON]にはSSH_DISCONNECT_KEY_EXCHANGE_FAILED理由を使用すべきです。[RFC7748]に記述されている以上の検証は必要ありません。派生した共有秘密は、「curve25519-sha256」が使用される場合は32バイト、「curve448-sha512」が使用される場合は56バイトです。すべての値のエンコーディングは[RFC7748]で定義されています。使用されるハッシュは、「curve25519-sha256」の場合はSHA-256、「curve448-sha512」の場合はSHA-512です。

3.1. Shared Secret Encoding

3.1. 共有秘密エンコーディング

The following step differs from [RFC5656], which uses a different conversion. This is not intended to modify that text generally, but only to be applicable to the scope of the mechanism described in this document.

次のステップは、異なる変換を使用する[RFC5656]とは異なります。これは、一般的にそのテキストを変更することを意図したものではなく、本ドキュメントで記述されているメカニズムの範囲にのみ適用されるものです。

The shared secret, K, is defined in [RFC4253] and [RFC5656] as an integer encoded as a multiple precision integer (mpint). Curve25519/448 outputs a binary string X, which is the 32- or 56-byte point obtained by scalar multiplication of the other side's public key and the local private key scalar. The 32 or 56 bytes of X are converted into K by interpreting the octets as an unsigned fixed-length integer encoded in network byte order.

共有秘密Kは、[RFC4253]と[RFC5656]で、多倍長整数（mpint）としてエンコードされた整数として定義されています。Curve25519/448はバイナリ文字列Xを出力します。これは、相手側の公開鍵とローカルの秘密鍵のスカラー倍算によって得られる32バイトまたは56バイトのポイントです。Xの32バイトまたは56バイトは、オクテットをネットワークバイトオーダーでエンコードされた符号なし固定長整数として解釈することによってKに変換されます。

The mpint K is then encoded using the process described in Section 5 of [RFC4251], and the resulting bytes are fed as described in [RFC4253] to the key exchange method's hash function to generate encryption keys.

次に、mpint Kは[RFC4251]のセクション5で記述されているプロセスを用いてエンコードされ、結果のバイトは[RFC4253]で記述されているように鍵交換方式のハッシュ関数に与えられ、暗号鍵が生成されます。

When performing the X25519 or X448 operations, the integer values there will be encoded into byte strings by doing a fixed-length unsigned little-endian conversion, per [RFC7748]. It is only later when these byte strings are then passed to the ECDH function in SSH that the bytes are reinterpreted as a fixed-length unsigned big-endian integer value K, and then later that K value is encoded as a variable-length signed "mpint" before being fed to the hash algorithm used for key generation. The mpint K is then fed along with other data to the key exchange method's hash function to generate encryption keys.

X25519またはX448操作を実行するとき、[RFC7748]に従って、固定長の符号なしリトルエンディアン変換を行うことにより、整数値はバイト文字列にエンコードされます。これらのバイト文字列がSSHのECDH関数に渡された後で初めて、バイトが固定長の符号なしビッグエンディアン整数値Kとして再解釈され、その後、そのK値が可変長符号付き「mpint」としてエンコードされてから、鍵生成に使用されるハッシュアルゴリズムに与えられます。次に、mpint Kは他のデータと共に鍵交換方式のハッシュ関数に与えられ、暗号鍵が生成されます。

4. Security Considerations

4. セキュリティに関する考慮事項

The security considerations of [RFC4251], [RFC5656], and [RFC7748] are inherited.

[RFC4251]、[RFC5656]、および[RFC7748]のセキュリティに関する考慮事項は継承されます。

Curve25519 with SHA-256 provides strong (~128 bits) security, is efficient on a wide range of architectures, and has characteristics that allow for better implementation properties compared to traditional elliptic curves. Curve448 with SHA-512 provides stronger (~224 bits) security with similar implementation properties; however, it has not received the same cryptographic review as Curve25519. It is also slower (larger key material and larger secure hash algorithm), but it is provided as a hedge to combat unforeseen analytical advances against Curve25519 and SHA-256 due to the larger number of security bits.

SHA-256を使用するCurve25519は、強力な（約128ビット）セキュリティを提供し、幅広いアーキテクチャで効率的であり、従来の楕円曲線と比較してより優れた実装特性を可能にします。SHA-512を使用するCurve448は、同様の実装特性を持つ、より強力な（約224ビット）セキュリティを提供します。ただし、Curve25519と同じ暗号レビューは受けていません。また、鍵データが大きく、よりセキュアなハッシュアルゴリズムを使用するため処理速度は遅くなりますが、より多くのセキュリティビット数があるため、Curve25519およびSHA-256に対する予期せぬ解析の進展に対抗するためのヘッジとして提供されます。

The way the derived mpint binary secret string is encoded before it is hashed (i.e., adding or removing zero bytes for encoding) raises the potential for a side-channel attack, which could determine the length of what is hashed. This would leak the most significant bit of the derived secret and/or allow detection of when the most significant bytes are zero. For backwards-compatibility reasons, it was decided not to address this potential problem.

ハッシュされる前に派生したmpintバイナリ秘密文字列がエンコードされる方法（つまり、エンコードのためにゼロバイトを追加または削除する）は、サイドチャネル攻撃の可能性を高め、ハッシュされるデータの長さを特定する可能性があります。これは、導出された秘密の最上位ビットを漏洩させたり、最上位バイトがゼロである場合の検出を可能にしたりする可能性があります。下位互換性の理由から、この潜在的な問題に対処しないことが決定されました。

This document provides "curve25519-sha256" as the preferred choice but suggests that the "curve448-sha512" be implemented to provide more than 128 bits of security strength should that become a requirement.

このドキュメントでは、「curve25519-sha256」を推奨される選択肢として提供していますが、要件となった場合に128ビットを超えるセキュリティ強度を提供するために、「curve448-sha512」が実装されるべきであると示唆しています。

5. IANA Considerations

5. IANAに関する考慮事項

IANA has added "curve25519-sha256" and "curve448-sha512" to the "Key Exchange Method Names" registry for SSH [IANA-KEX] that was created in Section 4.10 of [RFC4250].

IANAは、[RFC4250]のセクション4.10で作成されたSSH [IANA-KEX]の「鍵交換方式名」レジストリに「curve25519-sha256」と「curve448-sha512」を追加しました。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2119] Bradner, S., "要件レベルを示すためにRFCで使用するキーワード", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Assigned Numbers", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.

[RFC4250] Lehtinen, S. and C. Lonvick, Ed., "Secure Shell (SSH)プロトコル割り当て番号", RFC 4250, DOI 10.17487/RFC4250, January 2006, <https://www.rfc-editor.org/info/rfc4250>.

[RFC4251] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Protocol Architecture", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4251] Ylonen, T. and C. Lonvick, Ed., "Secure Shell (SSH)プロトコルアーキテクチャ", RFC 4251, DOI 10.17487/RFC4251, January 2006, <https://www.rfc-editor.org/info/rfc4251>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., "The Secure Shell (SSH) Transport Layer Protocol", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC4253] Ylonen, T. and C. Lonvick, Ed., "Secure Shell (SSH)トランスポート層プロトコル", RFC 4253, DOI 10.17487/RFC4253, January 2006, <https://www.rfc-editor.org/info/rfc4253>.

[RFC5656] Stebila, D. and J. Green, "Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.

[RFC5656] Stebila, D. and J. Green, "Secure Shellトランスポート層における楕円曲線アルゴリズムの統合", RFC 5656, DOI 10.17487/RFC5656, December 2009, <https://www.rfc-editor.org/info/rfc5656>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8174] Leiba, B., "RFC 2119キーワードの大文字と小文字の曖昧さ", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[SHS] National Institute of Standards and Technology, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/ NIST.FIPS.180-4.pdf>.

[SHS]米国国立標準技術研究所, "Secure Hash Standard (SHS)", FIPS PUB 180-4, DOI 10.6028/NIST.FIPS.180-4, August 2015, <https://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.180-4.pdf>.

6.2. Informative References

6.2. 参考引用

[IANA-KEX] IANA, "Secure Shell (SSH) Protocol Parameters: Key Exchange Method Names", <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-KEX] IANA, "Secure Shell (SSH)プロトコルパラメータ: 鍵交換方式名", <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-REASON] IANA, "Secure Shell (SSH) Protocol Parameters: Disconnection Messages Reason Codes and Descriptions", <https://www.iana.org/assignments/ssh-parameters/>.

[IANA-REASON] IANA, "Secure Shell (SSH)プロトコルパラメータ: 切断メッセージ理由コードと説明", <https://www.iana.org/assignments/ssh-parameters/>.

[libssh] libssh, "The SSH Library", <https://www.libssh.org/>.

[OpenSSH] OpenBSD group of OpenSSH, "The OpenSSH Project", <https://www.openssh.com/>.

[OpenSSH] OpenBSDのOpenSSHグループ, "The OpenSSH Project", <https://www.openssh.com/>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHAおよびSHAベースのHMACとHKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, "Elliptic Curves for Security", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.

[RFC7748] Langley, A., Hamburg, M., and S. Turner, "セキュリティのための楕円曲線", RFC 7748, DOI 10.17487/RFC7748, January 2016, <https://www.rfc-editor.org/info/rfc7748>.

Acknowledgements

謝辞

The "curve25519-sha256" key exchange method is identical to the "curve25519-sha256@libssh.org" key exchange method created by Aris Adamantiadis and implemented in libssh and OpenSSH.

「curve25519-sha256」鍵交換方式は、Aris Adamantiadisによって作成され、libsshおよびOpenSSHに実装された「curve25519-sha256@libssh.org」鍵交換方式と同一です。

Thanks to the following people for review and comments: Denis Bider, Damien Miller, Niels Moeller, Matt Johnston, Eric Rescorla, Ron Frederick, and Stefan Buehler.

レビューとコメントをくださった以下の方々に感謝いたします: Denis Bider、Damien Miller、Niels Moeller、Matt Johnston、Eric Rescorla、Ron Frederick、Stefan Buehler。

Authors' Addresses

著者の連絡先

Aris Adamantiadis libssh

アリス・アダマンティアディス (libssh)

   Email: aris@badcode.be

Simon Josefsson SJD AB

シモン・ヨーゼフソン (SJD AB)

   Email: simon@josefsson.org

Mark D. Baushke Juniper Networks, Inc.

マーク・D・バウシュケ (Juniper Networks, Inc.)

   Email: mdb@juniper.net