ShangMi (SM) Cipher Suites for TLS 1.3
Ant Group
No. 77 Xueyuan Road
Hangzhou
310000
China
+86-571-2688-8888
kaishen.yy@antfin.com
Security
TLS
cryptography
encryption
authentication
network security
This document specifies how to use the ShangMi (SM) cryptographic
algorithms with Transport Layer Security (TLS) protocol version 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.
Introduction
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) ().
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 ):
For a more detailed
introduction to SM cryptographic algorithms, please see .
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.
For details about how these mechanisms negotiate shared encryption
keys, authenticate the peer(s), and protect the record structure, please see
.
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.
The SM Algorithms
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.
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 (as well as to ).
SM4 is a block cipher defined in and now is being standardized
by ISO to ISO/IEC 18033-3:2010 . 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 and has also been described by .
Terminology
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
when, and only when, they appear in all capitals, as shown here.
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.
Algorithm Identifiers
The cipher suites defined here have the following identifiers:
To accomplish a TLS 1.3 handshake, additional objects have been introduced along with
the cipher suites as follows:
- The combination of the SM2 signature algorithm and SM3 hash function used in the Signature Algorithm
extension is defined in :
- The SM2 elliptic curve ID used in the Supported Groups extension is defined in :
Algorithm Definitions
TLS Versions
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.
Authentication
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 . The SM2 signature algorithm is
based on elliptic curves. The SM2 signature algorithm uses a fixed elliptic curve
parameter set defined in . This curve is named "curveSM2" and has been assigned the value 41, as shown in . 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 as a reference.
Implementations of the signature scheme and key exchange mechanism defined in this document MUST conform to
what 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:
- curveSM2:
- A prime field of 256 bits.
y2 = x3 + ax + b
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:
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 :
Expressed as octets, this is:
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.
Key Exchange
Hello Messages
The use of the algorithms defined by this document is negotiated during
the TLS handshake with information exchanged in the Hello messages.
ClientHello
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 .
Other requirements of this TLS 1.3 profile on the extensions of
ClientHello message are as follows:
- 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.
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.
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.
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.
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.
Certificate
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.
- 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.
CertificateVerify
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.
Key Scheduling
As described in , 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 . Implementations of this document MUST always conform to
what TLS 1.3 and its successors require regarding the key derivation and
related methods.
Cipher
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 in Counter with CBC-MAC mode, respectively.
The hash function for both cipher suites is SM3 ().
This section defines the AEAD_SM4_GCM and AEAD_SM4_CCM AEAD algorithms in a
style similar to what used to define AEAD ciphers based on the AES cipher.
AEAD_SM4_GCM
The AEAD_SM4_GCM authenticated encryption algorithm works as specified in ,
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 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 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 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 ).
The input and output lengths are as follows:
- The SM4 key length is 16 octets.
- The max plaintext length is 236 - 31 octets.
- The max AAD length is 261 - 1 octets.
- The nonce length is 12 octets.
- The authentication tag length is 16 octets.
- The max ciphertext length is 236 - 15 octets.
A security analysis of GCM is available in .
AEAD_SM4_CCM
The AEAD_SM4_CCM authenticated encryption algorithm works as specified in
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 , and the values of the parameters
identified 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 authentication
tag MUST conform to TLS 1.3 (See ).
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:
- The SM4 key length is 16 octets.
- The max plaintext length is 224 - 1 octets.
- The max AAD length is 264 - 1 octets.
- The max ciphertext length is 224 + 15 octets.
To generate the nonce, implementations of this document MUST conform to
TLS 1.3 (see ).
A security analysis of CCM is available in .
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 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 |
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 |
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 |
Security Considerations
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.
A security analysis of GCM is available in .
A security analysis of CCM is available in .
References
Normative References
IT Security techniques -- Digital signatures with appendix -- Part 3: Discrete logarithm based mechanisms
International Organization for Standardization
IT Security techniques -- Hash-functions -- Part 3: Dedicated hash-functions
International Organization for Standardization
Information technology -- Security techniques -- Encryption algorithms -- Part 3: Block ciphers
International Organization for Standardization
Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC
National Institute of Standards and Technology
Recommendation for Block Cipher Modes of Operation: the CCM Mode for Authentication and Confidentiality
National Institute of Standards and Technology
Informative References
Information security technology -- SM4 block cipher algorithm
Standardization Administration of the People's Republic of China
Information security technology --- SM3 cryptographic hash algorithm
Standardization Administration of China
Information security technology --- Public key cryptographic algorithm SM2 based on elliptic curves --- Part 2: Digital signature algorithm
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
Standardization Administration of the People's Republic of China
SM2 cryptography algorithm application specification
State Cryptography Administration
On the Security of CTR + CBC-MAC
The Security and Performance of the Galois/Counter Mode of Operation
Test Vectors
All values are in hexadecimal and are in network byte order (big endian).
Contributors
Ant Group
zhuolong.lq@antfin.com
Ant Group
kepeng.lkp@antfin.com
Ant Group
william.zk@antfin.com
Ant Group
han.xiao@antfin.com
Peking University
guan@pku.edu.cn