RFC 8998 - ShangMi (SM) Cipher Suites for TLS 1.3 日本語訳

原文URL : https://www.rfc-editor.org/rfc/rfc8998.html
タイトル : RFC 8998 - TLS 1.3用のShangmi（SM）暗号スイート
翻訳編集 : 自動生成

[要約] RFC 8998はTLS 1.3におけるShangMi (SM) 暗号スイートに関する文書です。この文書の目的は、中国の国家暗号標準をサポートするためにTLS 1.3プロトコルで使用できるSM暗号スイートを定義することです。これらの暗号スイートは、中国国内での安全な通信を必要とする場面や、SM暗号を採用しているシステム間での国際的な通信に利用されます。

Independent Submission                                           P. Yang
Request for Comments: 8998                                     Ant Group
Category: Informational                                       March 2021
ISSN: 2070-1721

ShangMi (SM) Cipher Suites for TLS 1.3

TLS 1.3用のShangmi（SM）暗号スイート

Abstract

概要

This document specifies how to use the ShangMi (SM) cryptographic algorithms with Transport Layer Security (TLS) protocol version 1.3.

このドキュメントは、Shangmi（SM）暗号化アルゴリズムをトランスポート層セキュリティ（TLS）プロトコルバージョン1.3で使用する方法を指定します。

The use of these algorithms with TLS 1.3 is not endorsed by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use the SM algorithms with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations.

TLS 1.3を有するこれらのアルゴリズムを使用することは、IETFによって承認されていない。SMアルゴリズムは中国で必須になっているので、この文書ではTLS 1.3でSMアルゴリズムを使用する方法について説明し、実装者がインターワーキング実装を生成できるようにTLS 1.3のプロファイルを指定します。

Status of This Memo

本文書の位置付け

This document is not an Internet Standards Track specification; it is published for informational purposes.

この文書はインターネット標準のトラック仕様ではありません。情報提供のために公開されています。

This is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not candidates for any level of Internet Standard; see Section 2 of RFC 7841.

これは、他のRFCストリームとは無関係にRFCシリーズへの貢献です。RFCエディタは、この文書を裁量で公開することを選択し、実装または展開のためのその値についてのステートメントを作成しません。RFCエディタによる出版の承認済みの文書は、インターネット規格のレベルレベルの候補者ではありません。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/rfc8998.

この文書の現在のステータス、エラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8998で入手できます。

著作権表示

著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。

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.

この文書は、この文書の公開日に有効なIETF文書（https://truste.ietf.org/License-info）に関するBCP 78とIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。

Table of Contents

   1.  Introduction
     1.1.  The SM Algorithms
     1.2.  Terminology
   2.  Algorithm Identifiers
   3.  Algorithm Definitions
     3.1.  TLS Versions
     3.2.  Authentication
       3.2.1.  SM2 Signature Scheme
     3.3.  Key Exchange
       3.3.1.  Hello Messages
       3.3.2.  CertificateRequest
       3.3.3.  Certificate
       3.3.4.  CertificateVerify
     3.4.  Key Scheduling
     3.5.  Cipher
       3.5.1.  AEAD_SM4_GCM
       3.5.2.  AEAD_SM4_CCM
   4.  IANA Considerations
   5.  Security Considerations
   6.  References
     6.1.  Normative References
     6.2.  Informative References
   Appendix A.  Test Vectors
     A.1.  SM4-GCM Test Vectors
     A.2.  SM4-CCM Test Vectors
   Contributors
   Author's Address

1. Introduction

1. はじめに

This document describes two new cipher suites, a signature algorithm and a key exchange mechanism for the Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3) ([RFC8446]). These all utilize several ShangMi (SM) cryptographic algorithms to fulfill the authentication and confidentiality requirements of TLS 1.3. The new cipher suites are as follows (see also Section 2):

この文書では、トランスポート層セキュリティ（TLS）プロトコルバージョン1.3（[RFC8446]）の2つの新しい暗号スイート、署名アルゴリズム、および鍵交換機構について説明します。これらはすべて、TLS 1.3の認証と機密性の要件を満たすためにいくつかのShangmi（SM）暗号化アルゴリズムを利用しています。新しい暗号スイートは次のとおりです（セクション2も参照）。

      CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
      CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };

For a more detailed introduction to SM cryptographic algorithms, please see Section 1.1. These cipher suites follow the TLS 1.3 requirements. Specifically, all the cipher suites use SM4 in either Galois/Counter (GCM) mode or Counter with CBC-MAC (CCM) mode to meet the needs of TLS 1.3 to have an encryption algorithm that is Authenticated Encryption with Associated Data (AEAD) capable. The key exchange mechanism utilizes Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) over the SM2 elliptic curve, and the signature algorithm combines the SM3 hash function and the SM2 elliptic curve signature scheme.

SM暗号化アルゴリズムのより詳細な紹介については、セクション1.1を参照してください。これらの暗号スイートはTLS 1.3の要件に従います。具体的には、TLS 1.3のニーズを満たすために、すべての暗号スイートはGalois / Counter（GCM）モードまたはCBC-MAC（CCM）モードでCB4（CBC-MAC）モードで使用しています。。鍵交換機構は、SM2楕円曲線を介して楕円曲線Diffie-Hellmanの一時的な（ECDHE）を利用し、署名アルゴリズムはSM3ハッシュ関数とSM2楕円曲線署名方式を組み合わせたものです。

For details about how these mechanisms negotiate shared encryption keys, authenticate the peer(s), and protect the record structure, please see Section 3.

これらのメカニズムが共有暗号化キーのネゴシエーション、ピアを認証し、レコード構造を保護する方法については、セクション3を参照してください。

The cipher suites, signature algorithm, and key exchange mechanism defined in this document are not recommended by the IETF. The SM algorithms are becoming mandatory in China, so this document provides a description of how to use them with TLS 1.3 and specifies a profile of TLS 1.3 so that implementers can produce interworking implementations.

この文書で定義されている暗号スイート、署名アルゴリズム、および鍵交換機構は、IETFによってはお勧めできません。SMアルゴリズムは中国では必須になっているので、この文書はそれらをTLS 1.3で使用する方法について説明し、実装者がインターワーキング実装を生成できるようにTLS 1.3のプロファイルを指定します。

1.1. The SM Algorithms

1.1. SMアルゴリズム

Several different SM cryptographic algorithms are used to integrate with TLS 1.3, including SM2 for authentication, SM4 for encryption, and SM3 as the hash function.

いくつかの異なるSM暗号化アルゴリズムは、認証のためのSM2、暗号化のためのSM4、およびSM3をハッシュ関数として、SM2を含むTLS 1.3と統合するために使用されます。

SM2 is a set of cryptographic algorithms based on elliptic curve cryptography, including a digital signature, public key encryption and key exchange scheme. In this document, only the SM2 digital signature algorithm and basic key exchange scheme are involved, which have already been added to ISO/IEC 14888-3:2018 [ISO-SM2] (as well as to [GBT.32918.2-2016]). SM4 is a block cipher defined in [GBT.32907-2016] and now is being standardized by ISO to ISO/IEC 18033-3:2010 [ISO-SM4]. SM3 is a hash function that produces an output of 256 bits. SM3 has already been accepted by ISO in ISO/IEC 10118-3:2018 [ISO-SM3] and has also been described by [GBT.32905-2016].

SM2は、デジタル署名、公開鍵暗号化および鍵交換方式を含む、楕円曲線暗号化に基づく暗号化アルゴリズムのセットです。この文書では、ISO / IEC 14888-3：2018 [ISO-SM2]（およびGBT.32918.2-2016]にすでに追加されているSM2デジタル署名アルゴリズムと基本鍵交換方式のみが含まれています。。SM4は[GBT.32907-2016]で定義されているブロック暗号であり、現在はISOからISO / IEC 18033-3：2010 [ISO-SM4]に標準化されています。SM3は256ビットの出力を生成するハッシュ関数です。SM3は、ISO / IEC 10118-3：2018 [ISO-SM3]のISOによってすでに受け入れられており、[GBT.32905-2016]によっても記載されています。

1.2. Terminology

1.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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。

Although this document is not an IETF Standards Track publication, it adopts the conventions for normative language to provide clarity of instruction to the implementer and to indicate requirement levels for compliant TLS 1.3 implementations.

この文書はIETF規格のトラック出版物ではありませんが、実装者に命令を明確にし、準拠TLS 1.3実装の要件レベルを示すための規範的言語の規約を採用しています。

2. Algorithm Identifiers

2. アルゴリズム識別子

The cipher suites defined here have the following identifiers:

ここで定義されている暗号スイートには、次の識別子があります。

      CipherSuite TLS_SM4_GCM_SM3 = { 0x00, 0xC6 };
      CipherSuite TLS_SM4_CCM_SM3 = { 0x00, 0xC7 };

To accomplish a TLS 1.3 handshake, additional objects have been introduced along with the cipher suites as follows:

TLS 1.3ハンドシェイクを達成するために、暗号スイートとともに追加のオブジェクトが導入されています。

* The combination of the SM2 signature algorithm and SM3 hash function used in the Signature Algorithm extension is defined in Appendix B.3.1.3 of [RFC8446]:

* 署名アルゴリズム拡張で使用されるSM2シグネチャアルゴリズムとSM3ハッシュ関数の組み合わせは、[RFC8446]の付録B.3.1.3に定義されています。

         SignatureScheme sm2sig_sm3 = { 0x0708 };

* The SM2 elliptic curve ID used in the Supported Groups extension is defined in Appendix B.3.1.4 of [RFC8446]:

* サポートされているグループ拡張機能で使用されるSM2楕円曲線IDは、[RFC8446]の付録B.3.1.4に定義されています。

         NamedGroup curveSM2 = { 41 };

3. Algorithm Definitions

3. アルゴリズム定義

3.1. TLS Versions

3.1. TLSバージョン

The new cipher suites defined in this document are only applicable to TLS 1.3. Implementations of this document MUST NOT apply these cipher suites to any older versions of TLS.

この文書で定義されている新しい暗号スイートはTLS 1.3にのみ適用されます。この文書の実装は、これらの暗号スイートを古いバージョンのTLSに適用してはいけません。

3.2. Authentication

3.2. 認証

3.2.1. SM2 Signature Scheme

3.2.1. SM2シグネチャスキーム

The Chinese government requires the use of the SM2 signature algorithm. This section specifies the use of the SM2 signature algorithm as the authentication method for a TLS 1.3 handshake.

中国政府はSM2署名アルゴリズムの使用を必要とします。このセクションでは、TLS 1.3ハンドシェイクの認証方法としてのSM2署名アルゴリズムの使用を指定します。

The SM2 signature algorithm is defined in [ISO-SM2]. The SM2 signature algorithm is based on elliptic curves. The SM2 signature algorithm uses a fixed elliptic curve parameter set defined in [GBT.32918.5-2017]. This curve is named "curveSM2" and has been assigned the value 41, as shown in Section 2. Unlike other public key algorithms based on elliptic curve cryptography like the Elliptic Curve Digital Signature Algorithm (ECDSA), SM2 MUST NOT select other elliptic curves. But it is acceptable to write test cases that use other elliptic curve parameter sets for SM2; see Annex F.14 of [ISO-SM2] as a reference.

SM2シグネチャアルゴリズムは[ISO-SM2]で定義されています。SM2シグネチャアルゴリズムは楕円曲線に基づいています。SM2シグネチャアルゴリズムは、[GBT.32918.5-2017]で定義されている固定楕円曲線パラメータセットを使用しています。この曲線は「curvsm2」と命名され、楕円曲線デジタル署名アルゴリズム（ECDSA）などの楕円曲線暗号化に基づく他の公開鍵アルゴリズムとは異なり、SM2は他の楕円曲線を選択してはいけません。しかし、SM2の他の楕円曲線パラメータセットを使用するテストケースを書くことは許容されています。参照として[ISO-SM2]の附属書F.14を参照してください。

Implementations of the signature scheme and key exchange mechanism defined in this document MUST conform to what [GBT.32918.5-2017] requires; that is to say, the only valid elliptic curve parameter set for the SM2 signature algorithm (a.k.a. curveSM2) is defined as follows:

この文書で定義されているシグニチャスキームと鍵交換メカニズムの実装は、[GBT.32918.5-2017]が必要なものに準拠している必要があります。つまり、SM2署名アルゴリズム（a.k.a.Curvsm2）に設定された唯一の有効な楕円曲線パラメータは、次のように定義されています。

curveSM2: A prime field of 256 bits.

CurvesM2：256ビットのPrimeフィールド。

   y^(2) = x^(3) + ax + b

p = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFF a = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF FFFFFFFF 00000000 FFFFFFFF FFFFFFFC b = 28E9FA9E 9D9F5E34 4D5A9E4B CF6509A7 F39789F5 15AB8F92 DDBCBD41 4D940E93 n = FFFFFFFE FFFFFFFF FFFFFFFF FFFFFFFF 7203DF6B 21C6052B 53BBF409 39D54123 Gx = 32C4AE2C 1F198119 5F990446 6A39C994 8FE30BBF F2660BE1 715A4589 334C74C7 Gy = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0

P=FFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFFA=FFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF00000000FFFFFFFFFFFFFFFCB=28E9FA9E9D9F5E344D5A9E4BCF6509A7F39789F515AB8F92DDBCBD414D940E93N=FFFFFFFEFFFFFFFFFFFFFFFFFFFFFFFF7203DF6B21C6052B53BBF40939D54123のGx=32C4AE2C1F1981195F9904466A39C9948FE30BBFF2660BE1715A4589334C74C7GY = BC3736A2 F4F6779C 59BDCEE3 6B692153 D0A9877C C62A4740 02DF32E5 2139F0A0

The SM2 signature algorithm requests an identifier value when generating or verifying a signature. In all uses except when a client of a server needs to verify a peer's SM2 certificate in the Certificate message, an implementation of this document MUST use the following ASCII string value as the SM2 identifier when doing a TLS 1.3 key exchange:

SM2署名アルゴリズムは、署名を生成または検証するときに識別子値を要求します。サーバーのクライアントが証明書メッセージ内のピアのSM2証明書を検証する必要がある場合を除き、すべての用途では、このドキュメントの実装は、TLS 1.3キー交換を実行するときにSM2識別子として次のASCII文字列値を使用する必要があります。

      TLSv1.3+GM+Cipher+Suite

If either a client or a server needs to verify the peer's SM2 certificate contained in the Certificate message, then the following ASCII string value MUST be used as the SM2 identifier according to [GMT.0009-2012]:

クライアントまたはサーバーが証明書メッセージに含まれているピアのSM2証明書を確認する必要がある場合は、[GMT.0009-2012]に準拠したSM2 IDとして次のASCII文字列値を使用する必要があります。

1234567812345678

Expressed as octets, this is:

オクテットとして表現されている、これは次のとおりです。

0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38, 0x31, 0x32, 0x33, 0x34, 0x35, 0x36, 0x37, 0x38

0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38,0x31,0x32,0x33,0x34,0x35,0x36,0x37,0x38

In practice, the SM2 identifier used in a certificate signature depends on the certificate authority (CA) who signs that certificate. CAs may choose values other than the ones mentioned above. Implementations of this document SHOULD confirm this information by themselves.

実際には、証明書署名で使用されるSM2 IDは、その証明書に署名する認証局（CA）によって異なります。CASは上記のもの以外の値を選択することができます。この文書の実装は、この情報を自分で確認する必要があります。

3.3. Key Exchange

3.3. 鍵交換機

3.3.1. Hello Messages

3.3.1. こんにちはメッセージ

The use of the algorithms defined by this document is negotiated during the TLS handshake with information exchanged in the Hello messages.

この文書によって定義されたアルゴリズムの使用は、Helloメッセージで交換された情報を使用してTLSハンドシェイク中にネゴシエートされます。

3.3.1.1. ClientHello

3.3.1.1. クライアントヘロー

To use the cipher suites defined by this document, a TLS 1.3 client includes the new cipher suites in the "cipher_suites" array of the ClientHello structure defined in Section 4.1.2 of [RFC8446].

このドキュメントで定義されている暗号スイートを使用するには、TLS 1.3クライアントには[RFC8446]のセクション4.1.2で定義されているClientHello構造体の「Cipher_Suites」アレイの新しい暗号スイートが含まれています。

Other requirements of this TLS 1.3 profile on the extensions of ClientHello message are as follows:

ClientHelloメッセージの拡張機能に関するこのTLS 1.3のプロファイルのその他の要件は次のとおりです。

* For the supported_groups extension, "curveSM2" MUST be included.

* supported_groups拡張子の場合、 "curvsm2"を含める必要があります。

* For the signature_algorithms extension, "sm2sig_sm3" MUST be included.

* signature_algorithms拡張子の場合、 "SM2SIG_SM3"を含める必要があります。

* For the signature_algorithms_cert extension (if present), "sm2sig_sm3" MUST be included.

* signature_algorithms_cert拡張子（存在する場合）の場合、 "SM2SIG_SM3"を含める必要があります。

* For the key_share extension, a KeyShareEntry for the "curveSM2" group MUST be included.

* key_share拡張機能の場合、 "Curvsm2"グループのKeyshareEntryを含める必要があります。

3.3.1.2. ServerHello

3.3.1.2. ServerHello.

If a TLS 1.3 server receives a ClientHello message containing the algorithms defined in this document, it MAY choose to use them. If so, then the server MUST put one of the new cipher suites defined in this document into its ServerHello's "cipher_suites" array and eventually send it to the client side.

TLS 1.3サーバーがこのドキュメントで定義されているアルゴリズムを含むClientHelloメッセージを受信した場合は、それらを使用することを選択できます。もしそうであれば、この文書にこの文書に定義された新しい暗号スイートのうちの1つをそのServerHelloの「暗号化」アレイにして、最終的にはクライアント側に送信する必要があります。

A TLS 1.3 server's choice of what cipher suite to use depends on the configuration of the server. For instance, a TLS 1.3 server may or not be configured to include the new cipher suites defined in this document. Typical TLS 1.3 server applications also provide a mechanism that configures the cipher suite preference on the server side. If a server is not configured to use the cipher suites defined in this document, it SHOULD choose another cipher suite in the list that the TLS 1.3 client provides; otherwise, the server MUST abort the handshake with an "illegal_parameter" alert.

使用するCipher Suiteがサーバーの構成によって異なります。たとえば、TLS 1.3サーバーは、この文書に定義されている新しい暗号スイートを含めるように設定されているかどうかを示します。一般的なTLS 1.3サーバーアプリケーションは、サーバー側で暗号スイートの設定を設定するメカニズムも提供します。サーバーがこの文書で定義されている暗号スイートを使用するように構成されていない場合は、TLS 1.3クライアントが提供するリスト内の別の暗号スイートを選択してください。それ以外の場合、サーバーはハンドシェイクを「ILLUAL_PARAMETER」アラートで中止する必要があります。

The following extension MUST conform to the new requirements:

次の拡張子は、新しい要件に準拠している必要があります。

* For the key_share extension, a KeyShareEntry with SM2-related values MUST be added if the server wants to conform to this profile.

* key_share拡張機能の場合、サーバーがこのプロファイルに準拠したい場合は、SM2関連の値を持つKEYSHareEntryを追加する必要があります。

3.3.2. CertificateRequest

If a CertificateRequest message is sent by the server to require the client to send its certificate for authentication purposes, for conformance to this profile, the following is REQUIRED:

認証目的で証明書を送信するようにクライアントがサーバーによって送信された場合、このプロファイルへの適合を要求するようにサーバーによって送信された場合は、次のことが必要です。

* The only valid signature algorithm present in "signature_algorithms" extension MUST be "sm2sig_sm3". That is to say, if the server chooses to conform to this profile, the signature algorithm for the client's certificate MUST use the SM2/ SM3 procedure specified by this document.

* 「signature_algorithms」拡張子に存在する唯一の有効なシグネチャアルゴリズムは、 "SM2SIG_SM3"でなければなりません。つまり、サーバーがこのプロファイルに準拠することを選択した場合、クライアントの証明書のシグネチャアルゴリズムはこのドキュメントで指定されたSM2 / SM3プロシージャを使用する必要があります。

3.3.3. Certificate

3.3.3. 証明書

When a server sends the Certificate message containing the server certificate to the client side, several new rules are added that will affect the certificate selection:

サーバーがサーバー証明書を含む証明書メッセージをクライアント側に送信すると、証明書の選択に影響を与えるいくつかの新しいルールが追加されます。

* The public key in the certificate MUST be a valid SM2 public key.

* 証明書の公開鍵は有効なSM2公開鍵である必要があります。

* The signature algorithm used by the CA to sign the current certificate MUST be "sm2sig_sm3".

* 現在の証明書に署名するCAが使用するシグネチャアルゴリズムは、 "SM2SIG_SM3"でなければなりません。

* The certificate MUST be capable of signing; e.g., the digitalSignature bit of X.509's Key Usage extension is set.

* 証明書は署名できなければなりません。例えば、X.509の鍵使用量拡張のデジタルシグ様ビットが設定されている。

3.3.4. CertificateVerify

3.3.4. 証明書認証

In the CertificateVerify message, the signature algorithm MUST be "sm2sig_sm3", indicating that the hash function MUST be SM3 and the signature algorithm MUST be SM2.

CertificateVerifyメッセージでは、署名アルゴリズムは「SM2SIG_SM3」でなければならず、ハッシュ関数がSM3でなければならず、シグネチャアルゴリズムはSM2でなければならないことを示します。

3.4. Key Scheduling

3.4. キースケジューリング

As described in Section 1.1, SM2 is actually a set of cryptographic algorithms, including one key exchange protocol that defines methods such as key derivation function, etc. This document does not define an SM2 key exchange protocol, and an SM2 key exchange protocol SHALL NOT be used in the key exchange steps defined in Section 3.3. Implementations of this document MUST always conform to what TLS 1.3 [RFC8446] and its successors require regarding the key derivation and related methods.

セクション1.1で説明されているように、SM2は、実際にはキー導出機能などのメソッドを定義する1つの鍵交換プロトコルを含む一連の暗号化アルゴリズムです。この文書はSM2鍵交換プロトコルを定義し、SM2鍵交換プロトコルはできません。セクション3.3で定義されている鍵交換手順で使用されます。この文書の実装は常にTLS 1.3 [RFC8446]と一致し、その後継者は鍵導出と関連方法に関して必要とされる。

3.5. Cipher

3.5. 暗号化

The new cipher suites introduced in this document add two new AEAD encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM, which stand for SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016] in Counter with CBC-MAC mode, respectively. The hash function for both cipher suites is SM3 ([ISO-SM3]).

この文書で紹介された新しい暗号スイートは、それぞれCBC-MACモードに対抗するGalois / Counter ModeおよびSM4暗号[GBT.32907-2016]のSM4暗号の略2つの新しいAED暗号化アルゴリズム、aead_sm4_ccmを追加します。両方の暗号スイートのハッシュ関数はSM3（[ISO-SM3]）です。

This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD algorithms in a style similar to what [RFC5116] used to define AEAD ciphers based on the AES cipher.

このセクションでは、AES暗号に基づいてAED暗号を定義するために使用されている[RFC5116]と同様のスタイルのAED_SM4_GCMおよびAEAD_SM4_CCM AADアルゴリズムを定義します。

3.5.1. AEAD_SM4_GCM

3.5.1. aead_sm4_gcm

The AEAD_SM4_GCM authenticated encryption algorithm works as specified in [GCM], using SM4 as the block cipher, by providing the key, nonce, plaintext, and associated data to that mode of operation. An authentication tag conforming to the requirements of TLS 1.3 as specified in Section 5.2 of [RFC8446] MUST be constructed using the details in the TLS record header. The additional data input that forms the authentication tag MUST be the TLS record header. The AEAD_SM4_GCM ciphertext is formed by appending the authentication tag provided as an output to the GCM encryption operation to the ciphertext that is output by that operation. AEAD_SM4_GCM has four inputs: an SM4 key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). AEAD_SM4_GCM generates two outputs: a ciphertext and message authentication code (also called an authentication tag). To have a common set of terms for AEAD_SM4_GCM and AEAD_SM4_CCM, the AEAD_SM4_GCM IV is referred to as a nonce in the remainder of this document. A simple test vector of AEAD_SM4_GCM and AEAD_SM4_CCM is given in Appendix A of this document.

AED_SM4_GCM認証された暗号化アルゴリズムは、ブロック暗号としてSM4を使用して、[GCM]で指定されているように機能します。キー、ノン、平文、および関連データをその動作モードに提供します。 [RFC8446]のセクション5.2で指定されているTLS 1.3の要件に準拠した認証タグは、TLSレコードヘッダーの詳細を使用して構築する必要があります。認証タグを形成する追加のデータ入力は、TLSレコードヘッダーである必要があります。 AEAD_SM4_GCM暗号文は、その操作によって出力された暗号文にGCM暗号化操作に出力された認証タグを追加することによって形成される。 aead_sm4_gcmには4つの入力があります.SM4キー、初期化ベクトル（IV）、平文の内容、およびオプションの追加の認証データ（AAD）。 aead_sm4_gcmは2つの出力を生成します。暗号文とメッセージ認証コード（認証タグとも呼ばれます）。 aead_sm4_gcmおよびaead_sm4_ccmの一般的な用語のセットを持つために、AED_SM4_GCM IVはこのドキュメントの残りの部分ではNONCEと呼ばれます。このドキュメントの付録Aには、AED_SM4_GCMとAEAD_SM4_CCMの単純なテストベクトルが付与されています。

The nonce is generated by the party performing the authenticated encryption operation. Within the scope of any authenticated encryption key, the nonce value MUST be unique. That is, the set of nonce values used with any given key MUST NOT contain any duplicates. Using the same nonce for two different messages encrypted with the same key destroys the security properties of GCM mode. To generate the nonce, implementations of this document MUST conform to TLS 1.3 (see [RFC8446], Section 5.3).

認証された暗号化操作を実行するパーティによってNonceが生成されます。認証された暗号化キーの範囲内で、NONCE値は一意である必要があります。つまり、特定のキーで使用される非CCE値のセットには、重複を含めないでください。同じキーで暗号化された2つの異なるメッセージに対して同じNonceを使用すると、GCMモードのセキュリティプロパティが破棄されます。NONCEを生成するには、この文書の実装はTLS 1.3に準拠している必要があります（[RFC8446]、5.3項参照）。

The input and output lengths are as follows:

入力および出力の長さは次のとおりです。

The SM4 key length is 16 octets.

SM4キーの長さは16オクテットです。

The max plaintext length is 2^(36) - 31 octets.

最大平文の長さは2 ^（36） - 31オクテットです。

The max AAD length is 2^(61) - 1 octets.

最大AADの長さは2 ^（61） - 1オクテットです。

The nonce length is 12 octets.

ノンスの長さは12オクテットです。

The authentication tag length is 16 octets.

認証タグの長さは16オクテットです。

The max ciphertext length is 2^(36) - 15 octets.

最大暗号文の長さは2 ^（36） - 15オクテットです。

A security analysis of GCM is available in [MV04].

GCMのセキュリティ分析は[MV04]で入手可能です。

3.5.2. AEAD_SM4_CCM

3.5.2. aead_sm4_ccm

The AEAD_SM4_CCM authenticated encryption algorithm works as specified in [CCM] using SM4 as the block cipher. AEAD_SM4_CCM has four inputs: an SM4 key, a nonce, a plaintext, and optional additional authenticated data (AAD). AEAD_SM4_CCM generates two outputs: a ciphertext and a message authentication code (also called an authentication tag). The formatting and counter generation functions are as specified in Appendix A of [CCM], and the values of the parameters identified in that appendix are as follows:

AEAD_SM4_CCM認証済み暗号化アルゴリズムは、SM4を使用してSM4をブロック暗号として使用して指定されています。aead_sm4_ccmには4つの入力があります.SM4キー、NONCE、平文、およびオプションの追加の認証データ（AAD）。aead_sm4_ccmは2つの出力を生成します.CipherTextとメッセージ認証コード（認証タグとも呼ばれます）。フォーマットとカウンタ生成機能は[CCM]の付録Aで指定されているとおり、その付録で識別されたパラメータの値は次のとおりです。

The nonce length n is 12.

NONCE長Nは12です。

The tag length t is 16.

タグ長Tは16である。

The value of q is 3.

Qの値は3です。

An authentication tag is also used in AEAD_SM4_CCM. The generation of the authentication tag MUST conform to TLS 1.3 (See [RFC8446], Section 5.2). The AEAD_SM4_CCM ciphertext is formed by appending the authentication tag provided as an output to the CCM encryption operation to the ciphertext that is output by that operation. The input and output lengths are as follows:

認証タグはaead_sm4_ccmでも使用されます。認証タグの生成はTLS 1.3に準拠している必要があります（[RFC8446]、セクション5.2を参照）。AEAD_SM4_CCM暗号文は、その操作によって出力される暗号文に出力として提供された認証タグをCCHM暗号化操作に追加することによって形成される。入力および出力の長さは次のとおりです。

The SM4 key length is 16 octets.

SM4キーの長さは16オクテットです。

The max plaintext length is 2^(24) - 1 octets.

最大平文の長さは2 ^（24） - 1オクテットです。

The max AAD length is 2^(64) - 1 octets.

最大AADの長さは2 ^（64） - 1オクテットです。

The max ciphertext length is 2^(24) + 15 octets.

最大暗号文の長さは2 ^（24）15オクテットです。

To generate the nonce, implementations of this document MUST conform to TLS 1.3 (see [RFC8446], Section 5.3).

NONCEを生成するには、この文書の実装はTLS 1.3に準拠している必要があります（[RFC8446]、5.3項参照）。

A security analysis of CCM is available in [J02].

CCMのセキュリティ分析は[J02]で入手可能です。

4. IANA Considerations

4. IANAの考慮事項

IANA has assigned the values {0x00,0xC6} and {0x00,0xC7} with the names "TLS_SM4_GCM_SM3" and "TLS_SM4_CCM_SM3" to the "TLS Cipher Suites" registry with this document as reference:

IANAは、この文書を参照として、「TLS_SM4_GCM_SM3」と「TLS_SM4_CCM_SM3」と「TLS暗号スイート」の名前に値{0x00,0xC6}と{0x00,0xc7}を割り当てました。

    +===========+=================+=========+=============+===========+
    | Value     | Description     | DTLS-OK | Recommended | Reference |
    +===========+=================+=========+=============+===========+
    | 0x00,0xC6 | TLS_SM4_GCM_SM3 | No      | No          | RFC 8998  |
    +-----------+-----------------+---------+-------------+-----------+
    | 0x00,0xC7 | TLS_SM4_CCM_SM3 | No      | No          | RFC 8998  |
    +-----------+-----------------+---------+-------------+-----------+

Table 1

表1

IANA has assigned the value 0x0708 with the name "sm2sig_sm3" to the "TLS SignatureScheme" registry:

IANAは、 "SM2SIG_SM3"という名前の "TLS SignatureScheme"レジストリに値0x0708を割り当てました。

            +========+=============+=============+===========+
            |  Value | Description | Recommended | Reference |
            +========+=============+=============+===========+
            | 0x0708 | sm2sig_sm3  | No          | RFC 8998  |
            +--------+-------------+-------------+-----------+

Table 2

表2.

IANA has assigned the value 41 with the name "curveSM2" to the "TLS Supported Groups" registry:

IANAには、「CURVSM2」という名前の値41が "TLSサポートされているグループ"レジストリに割り当てました：

        +=======+=============+=========+=============+===========+
        | Value | Description | DTLS-OK | Recommended | Reference |
        +=======+=============+=========+=============+===========+
        |    41 | curveSM2    | No      | No          | RFC 8998  |
        +-------+-------------+---------+-------------+-----------+

Table 3

表3.

5. Security Considerations

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

At the time of writing, there are no known weak keys for SM cryptographic algorithms SM2, SM3 and SM4, and no security issues have been found for these algorithms.

書き込み時には、SM暗号化アルゴリズムSM2、SM3、およびSM4のための既知の弱キーはありません。これらのアルゴリズムについてはセキュリティ問題は見つかりませんでした。

A security analysis of GCM is available in [MV04].

GCMのセキュリティ分析は[MV04]で入手可能です。

A security analysis of CCM is available in [J02].

CCMのセキュリティ分析は[J02]で入手可能です。

6. References

6. 参考文献

6.1. Normative References

6.1. 引用文献

[CCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality", Special Publication 800-38C, DOI 10.6028/NIST.SP.800-38C, May 2004, <http://csrc.nist.gov/publications/nistpubs/800-38C/ SP800-38C.pdf>.

[CCM] DWORIN、M.、「ブロック暗号化モードの推奨事項：認証および機密性のためのCCMモード」、特別発表800-38C、DOI 10.6028 / NIST.SP.800-38C、<http：//csrc.nist.gov/publications/nistpubs/800-38c/SP800-38C.pdf>。

[GCM] Dworkin, M., "Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC", Special Publication 800-38D, DOI 10.6028/NIST.SP.800-38D, November 2007, <http://csrc.nist.gov/publications/nistpubs/800-38D/ SP-800-38D.pdf>.

[GCM] DWORIN、M。、「ブロック暗号化モードの推奨事項：ガロア/カウンタモード（GCM）およびGMAC」、特別出版物800-38D、DOI 10.6028 / NIST.SP.800-38D、2007年11月、<HTTP：//csrc.nist.gov/publications/nistpubs/800-38d / sp-800-38d.pdf>。

[ISO-SM2] International Organization for Standardization, "IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms", ISO/ IEC 14888-3:2018, November 2018, <https://www.iso.org/standard/76382.html>.

[ISO-SM2]標準化のための国際機関、「付録付きデジタル署名 - パート3：離散対数ベースのメカニズム」、ISO / IEC 14888-3：2018、2018年11月、<https：// www。iso.org/standard/76382.html>。

[ISO-SM3] International Organization for Standardization, "IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions", ISO/IEC 10118-3:2018, October 2018, <https://www.iso.org/standard/67116.html>.

[ISO-SM3]標準化のための国際機関、「ITセキュリティ技術 - ハッシュ関数 - 第3部：専用ハッシュ関数」、ISO / IEC 10118-3：2018、2018年10月、<https：//www.iso.org /標準/ 67116.html>。

[ISO-SM4] International Organization for Standardization, "Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers", ISO/ IEC 18033-3:2010, December 2010, <https://www.iso.org/standard/54531.html>.

[ISO-SM4]標準化のための国際機関、「情報技術 - セキュリティ技術 - 暗号化アルゴリズム - 第3部：ブロック暗号」、ISO / IEC 18033-3：2010、2010年12月、<https：//www.iso.org /標準/ 54531.html>。

[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、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, <https://www.rfc-editor.org/info/rfc5116>.

[RFC5116] MCGREW、D。、「認証済み暗号化のためのインタフェースとアルゴリズム」、RFC 5116、DOI 10.17487 / RFC5116、2008年1月、<https：//www.rfc-editor.org/info/rfc5116>。

[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、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。

[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8446] RESCORLA、E.、「トランスポート層セキュリティ（TLS）プロトコルバージョン1.3」、RFC 8446、DOI 10.17487 / RFC8446、2018年8月、<https：//www.rfc-editor.org/info/rfc8446>。

6.2. Informative References

6.2. 参考引用

   [GBT.32905-2016]
              Standardization Administration of China, "Information
              security technology --- SM3 cryptographic hash algorithm",
              GB/T 32905-2016, March 2017, <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401392982079739.pdf>.

[GBT.32907-2016] Standardization Administration of the People's Republic of China, "Information security technology -- SM4 block cipher algorithm", GB/T 32907-2016, March 2017, <http://www.gmbz.org.cn/ upload/2018-04-04/1522788048733065051.pdf>.

[GBT.32907-2016]中華人民共和国の標準化管理、「情報セキュリティ技術 - SM4ブロック暗号アルゴリズム」、GB / T 32907-2016、2017年3月、<http://www.gmbz.org.cn/ Upload / 2018-04-04 / 152278804-04/1522788048733065051.pdf>。

   [GBT.32918.2-2016]
              Standardization Administration of the People's Republic of
              China, "Information security technology --- Public key
              cryptographic algorithm SM2 based on elliptic curves ---
              Part 2: Digital signature algorithm", GB/T 32918.2-2016,
              March 2017, <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401673138056311.pdf>.

   [GBT.32918.5-2017]
              Standardization Administration of the People's Republic of
              China, "Information security technology --- Public key
              cryptographic algorithm SM2 based on elliptic curves ---
              Part 5: Parameter definition", GB/T 32918.5-2017, December
              2017, <http://www.gmbz.org.cn/
              upload/2018-07-24/1532401863206085511.pdf>.

[GMT.0009-2012] State Cryptography Administration, "SM2 cryptography algorithm application specification", GM/T 0009-2012, November 2012, <http://www.gmbz.org.cn/main/ viewfile/2018011001400692565.html>.

[GMT.0009-2012]状態暗号化管理、「SM2暗号化アルゴリズムアプリケーション仕様」、GM / T0009-2012、2012年11月、<http://www.gmbz.org.cn/main/ ViewFile / 2018011001400692565.html>。

[J02] Jonsson, J., "On the Security of CTR + CBC-MAC", DOI 10.1007/3-540-36492-7_7, February 2003, <https://link.springer.com/ chapter/10.1007%2F3-540-36492-7_7>.

[J02] Jonsson、J.、「CTR CBC-MACのセキュリティについて」、DOI 10.1007 / 3-540-36492-7_7、2003年2月、<https：//link.springer.com/章/ 10.1007％2F3-540-36492-7_7>。

[MV04] McGrew, D. and J. Viega, "The Security and Performance of the Galois/Counter Mode of Operation", DOI 10.1007/978-3-540-30556-9_27, December 2004, <http://eprint.iacr.org/2004/193>.

[MV04] MCGREW、D.およびJ.Viega、「Galois / Counter Operationモードのセキュリティとパフォーマンス」、DOI 10.1007 / 978-3-540-30556-9_27、2004年12月、<http：// eprint。iacr.org/2004/193>。

Appendix A. Test Vectors

付録A.テストベクトル

All values are in hexadecimal and are in network byte order (big endian).

すべての値は16進数で、ネットワークバイトオーダー（ビッグエンディアン）にあります。

A.1. SM4-GCM Test Vectors

A.1. SM4-GCMテストベクトル

   Initialization Vector:   00001234567800000000ABCD
   Key:                     0123456789ABCDEFFEDCBA9876543210
   Plaintext:               AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
                            CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
                            EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
                            EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
   Associated Data:         FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
   CipherText:              17F399F08C67D5EE19D0DC9969C4BB7D
                            5FD46FD3756489069157B282BB200735
                            D82710CA5C22F0CCFA7CBF93D496AC15
                            A56834CBCF98C397B4024A2691233B8D
   Authentication Tag:      83DE3541E4C2B58177E065A9BF7B62EC

A.2. SM4-CCM Test Vectors

A.2. SM4-CCMテストベクトル

   Initialization Vector:   00001234567800000000ABCD
   Key:                     0123456789ABCDEFFEDCBA9876543210
   Plaintext:               AAAAAAAAAAAAAAAABBBBBBBBBBBBBBBB
                            CCCCCCCCCCCCCCCCDDDDDDDDDDDDDDDD
                            EEEEEEEEEEEEEEEEFFFFFFFFFFFFFFFF
                            EEEEEEEEEEEEEEEEAAAAAAAAAAAAAAAA
   Associated Data:         FEEDFACEDEADBEEFFEEDFACEDEADBEEFABADDAD2
   CipherText:              48AF93501FA62ADBCD414CCE6034D895
                            DDA1BF8F132F042098661572E7483094
                            FD12E518CE062C98ACEE28D95DF4416B
                            ED31A2F04476C18BB40C84A74B97DC5B
   Authentication Tag:      16842D4FA186F56AB33256971FA110F4

Contributors

貢献者

Qin Long Ant Group

   Email: zhuolong.lq@antfin.com

Kepeng Li Ant Group

ケペンLI ANTグループ

   Email: kepeng.lkp@antfin.com

Ke Zeng Ant Group

KE Zeng Ant Group

   Email: william.zk@antfin.com

Han Xiao Ant Group

Han Xiao Ant Group.

   Email: han.xiao@antfin.com

Zhi Guan Peking University

Zhi Guan Peking大学

   Email: guan@pku.edu.cn

Author's Address

著者の住所

Paul Yang Ant Group No. 77 Xueyuan Road Hangzhou 310000 China

Paul Yang Ant Group No. 77 Xueyuan Road杭州310000中国

   Phone: +86-571-2688-8888
   Email: kaishen.yy@antfin.com