3.2.1.SM2 Signature Scheme

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.¶

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

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

curveSM2:

A prime field of 256 bits.¶

y² = x³ + 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

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

   TLSv1.3+GM+Cipher+Suite

If either a client or a server needs to verify the peer's SM2 certificatecontained in the Certificate message, then the following ASCII string valueMUST beused as the SM2 identifier according to[GMT.0009-2012]:¶

   1234567812345678

Expressed as octets, this is:¶

   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 thecertificate authority (CA) who signs that certificate. CAs may choose values other than the ones mentionedabove. Implementations of this documentSHOULD confirm this information by themselves.¶

3.3.1.Hello Messages

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

3.3.2.CertificateRequest

If a CertificateRequest message is sent by the server to require the clientto send its certificate for authentication purposes, for conformance to thisprofile, the following isREQUIRED:¶

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

3.3.3.Certificate

When a server sends the Certificate message containing the server certificateto the client side, several new rules are added that will affect the certificateselection:¶

• The public key in the certificateMUST be a valid SM2 public key.¶
• The signature algorithm used by the CA to sign the current certificateMUST be"sm2sig_sm3".¶
• The certificateMUST be capable of signing; e.g., the digitalSignature bitof X.509's Key Usage extension is set.¶

3.3.4.CertificateVerify

In the CertificateVerify message, the signature algorithmMUST be "sm2sig_sm3",indicating that the hash functionMUST be SM3 and the signature algorithmMUST beSM2.¶

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, andassociated data to that mode of operation. An authentication tag conforming tothe requirements of TLS 1.3 as specified inSection 5.2 of [RFC8446]MUST be constructed usingthe details in the TLS record header. The additional data input that forms theauthentication tagMUST be the TLS record header. The AEAD_SM4_GCM ciphertext is formed byappending the authentication tag provided as an output to the GCM encryptionoperation 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 inAppendix A of this document.¶

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

The input and output lengths are as follows:¶

• The SM4 key length is 16 octets.¶
• The max plaintext length is 2³⁶ - 31 octets.¶
• The max AAD length is 2⁶¹ - 1 octets.¶
• The nonce length is 12 octets.¶
• The authentication tag length is 16 octets.¶
• The max ciphertext length is 2³⁶ - 15 octets.¶

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

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_CCMgenerates two outputs: a ciphertext and a message authentication code (also calledan authentication tag). The formatting and counter generation functions are asspecified in Appendix A of[CCM], and the values of the parametersidentified in that appendix are as follows:¶

• The nonce length n is 12.¶
• The tag length t is 16.¶
• The value of q is 3.¶

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

• The SM4 key length is 16 octets.¶
• The max plaintext length is 2²⁴ - 1 octets.¶
• The max AAD length is 2⁶⁴ - 1 octets.¶
• The max ciphertext length is 2²⁴ + 15 octets.¶

To generate the nonce, implementations of this documentMUST conform toTLS 1.3 (see[RFC8446],Section 5.3).¶

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