RFC 8998

ShangMi (SM) Cipher Suites for TLS 1.3

📅 published March 2021, from ietf

RFC 8998: ShangMi (SM) Cipher Suites for TLS 1.3 🎀

Okay bestie, here's the vibe check on this doc before we dive in:

  • Number: RFC 8998
  • Title: ShangMi (SM) Cipher Suites for TLS 1.3
  • Author: P. Yang, Ant Group
  • Category: Informational
  • Stream: Independent Submission
  • Date: March 2021
  • ISSN: 2070-1721
  • Obsoletes / Updates: the title block doesn't list anything it obsoletes or updates 🙈

Abstract ✨

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

The IETF doesn't endorse using these algorithms with TLS 1.3, not gonna lie. But the SM algorithms are becoming mandatory in China, so this doc describes how to use them with TLS 1.3 and sets out a profile of TLS 1.3 so implementers can build implementations that actually work together. 🫶

Status of This Memo 📜

This doc is not an Internet Standards Track spec. It's published for informational purposes. 🌸

It's a contribution to the RFC Series, separate from any other RFC stream. The RFC Editor chose to publish it at their discretion and makes no statement about how valuable it is for implementation or deployment. Docs the RFC Editor approves for publication aren't candidates for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details. 💅

For the current status, errata, and how to send feedback, go to https://www.rfc-editor.org/info/rfc8998. 💖

Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved. 🌈

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) as they stood on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc. 🎀

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 💖

This doc describes two new cipher suites, a signature algorithm, and a key exchange mechanism for Transport Layer Security (TLS) protocol version 1.3 (TLS 1.3) ([RFC8446]). They all use several ShangMi (SM) cryptographic algorithms to cover the authentication and confidentiality needs of TLS 1.3. ✨

The new cipher suites are these (see also Section 2):

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

If you want a deeper intro to the SM algorithms, check Section 1.1. These cipher suites follow the TLS 1.3 requirements. Every one of them uses SM4 in either Galois/Counter (GCM) mode or Counter with CBC-MAC (CCM) mode, which gives TLS 1.3 the Authenticated Encryption with Associated Data (AEAD) capable encryption it needs. 🦋

The key exchange uses Elliptic Curve Diffie-Hellman Ephemeral (ECDHE) over the SM2 elliptic curve, and the signature algorithm pairs the SM3 hash function with the SM2 elliptic curve signature scheme. 🔥

For how these mechanisms negotiate shared encryption keys, authenticate the peer(s), and protect the record structure, head to Section 3. 🧚

The cipher suites, signature algorithm, and key exchange mechanism in this doc are not recommended by the IETF. The SM algorithms are becoming mandatory in China, so this doc describes how to use them with TLS 1.3 and sets out a profile of TLS 1.3 so implementers can build interworking implementations. 💅

1.1. The SM Algorithms 🍓

Several different SM cryptographic algorithms plug into TLS 1.3: SM2 for authentication, SM4 for encryption, and SM3 as the hash function. 🌸

SM2 is a family of elliptic curve cryptography algorithms that includes a digital signature, public key encryption, and a key exchange scheme. This doc only involves the SM2 digital signature algorithm and the basic key exchange scheme, 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 is currently being standardized by ISO as ISO/IEC 18033-3:2010 [ISO-SM4]. SM3 is a hash function with a 256-bit output. ISO has accepted SM3 in ISO/IEC 10118-3:2018 [ISO-SM3], and it's also described in [GBT.32905-2016]. 🎀

1.2. Terminology 📖

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

Even though this doc isn't an IETF Standards Track publication, it borrows the conventions for normative language so implementers get clear instructions and so requirement levels are clear for compliant TLS 1.3 implementations. 💜

2. Algorithm Identifiers 🪪

The cipher suites defined here have these identifiers:

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

To finish a TLS 1.3 handshake, a few more objects come along with the cipher suites: 👑

  • The combo of the SM2 signature algorithm and the SM3 hash function, used in the Signature Algorithm extension, is defined in Appendix B.3.1.3 of [RFC8446]:
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]:
NamedGroup curveSM2 = { 41 };

3. Algorithm Definitions 🌈

3.1. TLS Versions 🕰️

The new cipher suites in this doc only apply to TLS 1.3. Implementations of this doc MUST NOT apply these cipher suites to any older versions of TLS. 🙅‍♀️

3.2. Authentication 🔐

3.2.1. SM2 Signature Scheme ✍️

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

The SM2 signature algorithm is defined in [ISO-SM2] and is based on elliptic curves. It uses a fixed elliptic curve parameter set defined in [GBT.32918.5-2017]. That curve is named "curveSM2", has the value 41 as shown in Section 2, and is the one used throughout. Unlike other elliptic-curve public key algorithms such as the Elliptic Curve Digital Signature Algorithm (ECDSA), SM2 MUST NOT select other elliptic curves. You are allowed to write test cases with other elliptic curve parameter sets for SM2, though; see Annex F.14 of [ISO-SM2] for a reference. 🧐

Implementations of the signature scheme and key exchange mechanism defined here MUST conform to what [GBT.32918.5-2017] requires. In other words, the only valid elliptic curve parameter set for the SM2 signature algorithm (a.k.a. curveSM2) is the following:

curveSM2:  A prime field of 256 bits.

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

The SM2 signature algorithm asks for an identifier value when it generates or verifies a signature. Except when a client of a server needs to verify a peer's SM2 certificate in the Certificate message, an implementation of this doc MUST use the following ASCII string as the SM2 identifier when doing a TLS 1.3 key exchange: 🎯

TLSv1.3+GM+Cipher+Suite

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

1234567812345678

Written as octets, that's:

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) that signs the certificate. CAs may pick values other than the ones above. Implementations of this doc SHOULD double-check this info for themselves. 🤓

Heads up: the SM2 identifier can change depending on which CA signed the cert, so don't assume the values above will always match. Check it yourself! 🚨

3.3. Key Exchange 🗝️

3.3.1. Hello Messages 👋

The algorithms defined in this doc are negotiated during the TLS handshake, with the info exchanged in the Hello messages. 💬

3.3.1.1. ClientHello 🧡

To use the cipher suites defined in this doc, 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]. 📨

Other requirements this TLS 1.3 profile puts on the ClientHello extensions are:

  • For the supported_groups extension, "curveSM2" MUST be included.
  • For the signature_algorithms extension, "sm2sig_sm3" MUST be included.
  • For the signature_algorithms_cert extension (if present), "sm2sig_sm3" MUST be included.
  • For the key_share extension, a KeyShareEntry for the "curveSM2" group MUST be included.

3.3.1.2. ServerHello 🥰

If a TLS 1.3 server gets a ClientHello message containing the algorithms defined in this doc, it MAY choose to use them. If it does, the server MUST put one of the new cipher suites from this doc into its ServerHello's cipher_suites array and eventually send that to the client. 🎉

Which cipher suite a TLS 1.3 server picks depends on how the server is configured. For example, a TLS 1.3 server may or may not be set up to include the new cipher suites defined in this doc. Typical TLS 1.3 server apps also offer a mechanism for setting the cipher suite preference on the server side. If a server isn't configured to use the cipher suites defined in this doc, it SHOULD choose another cipher suite from the list the TLS 1.3 client provides. Otherwise, the server MUST abort the handshake with an "illegal_parameter" alert. 🙈

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

3.3.2. CertificateRequest 📜

okay so if the server sends a CertificateRequest message to make the client send its certificate for authentication, then to conform to this profile the following is REQUIRED: 🎀

  • The only valid signature algorithm present in the "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. 💅

3.3.3. Certificate 🎀

when a server sends the Certificate message with the server certificate to the client side, a few new rules kick in that affect which certificate gets picked 👀

  • The public key in the certificate MUST be a valid SM2 public key. 🔑
  • The signature algorithm used by the CA to sign the current certificate MUST be "sm2sig_sm3". 🖊️
  • The certificate MUST be capable of signing; e.g., the digitalSignature bit of X.509's Key Usage extension is set. ✍️

3.3.4. CertificateVerify 🦋

in the CertificateVerify message, the signature algorithm MUST be "sm2sig_sm3", which means the hash function MUST be SM3 and the signature algorithm MUST be SM2. the whole thing is locked in, no wiggle room 🔒✨

3.4. Key Scheduling 🗝️

as we covered in Section 1.1, SM2 is actually a whole set of cryptographic algorithms, and that set includes one key exchange protocol that defines stuff like the 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. the big rule here is that implementations of this document MUST always conform to what TLS 1.3 [RFC8446] and its successors require for key derivation and the related methods. stick to the TLS 1.3 way, bestie 💜

3.5. Cipher 🍓

the new cipher suites in this document add two brand-new AEAD encryption algorithms, AEAD_SM4_GCM and AEAD_SM4_CCM. they stand for SM4 cipher in Galois/Counter mode and SM4 cipher [GBT.32907-2016] in Counter with CBC-MAC mode, respectively. both cipher suites use SM3 ([ISO-SM3]) as their hash function. the vibes are immaculate 😭

this section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD algorithms in a style similar to what [RFC5116] used for the AEAD ciphers based on the AES cipher. same energy, new cast 🌈

3.5.1. AEAD_SM4_GCM 🌸

the AEAD_SM4_GCM authenticated encryption algorithm works the way [GCM] specifies, using SM4 as the block cipher. you hand it the key, nonce, plaintext, and associated data, and it does the mode of operation for you. an authentication tag that meets the TLS 1.3 requirements in Section 5.2 of [RFC8446] MUST be built from 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 made by sticking the authentication tag (the output of the GCM encryption operation) onto the end of the ciphertext that operation spits out. 🧁

AEAD_SM4_GCM takes four inputs: an SM4 key, an initialization vector (IV), a plaintext content, and optional additional authenticated data (AAD). it gives back two outputs: a ciphertext and a message authentication code (also called an authentication tag). so that AEAD_SM4_GCM and AEAD_SM4_CCM can share the same vocabulary, the AEAD_SM4_GCM IV is called a nonce for the rest of this document. there's a simple test vector for both AEAD_SM4_GCM and AEAD_SM4_CCM in Appendix A of this document, so you can check your work 🫶

the nonce is generated by the party doing the authenticated encryption operation. within the scope of any authenticated encryption key, the nonce value MUST be unique. in other words, the set of nonce values used with any given key MUST NOT contain any duplicates. reusing the same nonce for two different messages encrypted with the same key destroys the security properties of GCM mode, so this is a big deal 🚨😱 to generate the nonce, implementations of this document MUST conform to TLS 1.3 (see [RFC8446], Section 5.3).

here are the input and output lengths:

  • The SM4 key length is 16 octets.
  • The max plaintext length is 2^(36) - 31 octets.
  • The max AAD length is 2^(61) - 1 octets.
  • The nonce length is 12 octets.
  • The authentication tag length is 16 octets.
  • The max ciphertext length is 2^(36) - 15 octets.

a security analysis of GCM is available in [MV04]. go read it if you're curious, it's the good stuff 🧠

3.5.2. AEAD_SM4_CCM 🦢

the AEAD_SM4_CCM authenticated encryption algorithm works the way [CCM] specifies, using SM4 as the block cipher. AEAD_SM4_CCM takes four inputs: an SM4 key, a nonce, a plaintext, and optional additional authenticated data (AAD). it 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 parameter values from that appendix are:

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

an authentication tag is used in AEAD_SM4_CCM too. generating that tag MUST conform to TLS 1.3 (See [RFC8446], Section 5.2). the AEAD_SM4_CCM ciphertext is formed by appending the authentication tag (the output of the CCM encryption operation) to the ciphertext that operation outputs. ✨ here are the input and output lengths:

  • The SM4 key length is 16 octets.
  • The max plaintext length is 2^(24) - 1 octets.
  • The max AAD length is 2^(64) - 1 octets.
  • The max ciphertext length is 2^(24) + 15 octets.

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

a security analysis of CCM is available in [J02]. 🔍

4. IANA Considerations 🦋

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 the reference:

    +===========+=================+=========+=============+===========+
    | 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

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

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

                                 Table 2

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

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

                                  Table 3

5. Security Considerations 💀

at the time of writing, there are no known weak keys for the SM cryptographic algorithms SM2, SM3 and SM4, and no security issues have been found for these algorithms. no weak keys, no known issues, that's the tea ☕

a security analysis of GCM is available in [MV04]. 🔐

a security analysis of CCM is available in [J02]. 🔐

6. References 📚

6.1. Normative References

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

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

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

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

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

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

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

6.2. Informative References 📚✨

Okay bestie, these are the "for your reading pleasure" sources 🤓💅. Nothing here is required to get the basics, but if you want to go deep, these are the receipts.

Appendix A. Test Vectors 🧪🔥

All values are in hexadecimal and are in network byte order (big endian). Read these carefully, because these are the exact numbers your implementation should spit out if it's doing things right 💖.

A.1. SM4-GCM Test Vectors 🌸

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 🦋

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
    • Email: kepeng.lkp@antfin.com
  • Ke Zeng
    • Ant Group
    • Email: william.zk@antfin.com
  • Han Xiao
    • Ant Group
    • Email: han.xiao@antfin.com
  • Zhi Guan
    • Peking University
    • Email: guan@pku.edu.cn

Author's Address 🎀

  • Paul Yang
    • Ant Group
    • No. 77 Xueyuan Road
    • Hangzhou
    • 310000
    • China
    • Phone: +86-571-2688-8888
    • Email: kaishen.yy@antfin.com

That's the whole spec, bestie! 🌈✨ You made it through all three parts, and you're officially a SM2/SM3/SM4 TLS girlie 👑😭

📦 where this page comes from