01 Introduction -TLS 1.3 protocol and SM algorithm

Speaking of TLS, we are certainly familiar with it. TLS can be said to be the cornerstone of Internet security, ensuring the security of our communication data. Since the Heartbleed bug was discovered in 2014, network security has attracted increasing attention. The TLS 1.3 protocol was proposed to be more secure and faster, and its corresponding RFC was officially released in 2018. With more and more attention to network security, security strategy has gradually risen to the height of the national strategy, the National Cryptography Bureau in 2010 announced China’s independent development of “elliptic curve public key cryptography algorithm” (SM2 algorithm), and then released the state secret algorithm SM1-SM9 (SM represents the pinyin secret capital). Today we are going to share something about TLS 1.3 and state secrets.

To give you a basic idea of the relationship between the two, let’s take a typical TLS 1.2 key suite as an example:

Corresponding to our national secret algorithm, the corresponding suite of each algorithm is as follows:

1, key exchange algorithm: ECC-SM2, ECDHE-SM2 (here is not to expand in detail, just a brief introduction, state secret key exchange algorithm based on the current elliptic curve algorithm designed two special algorithms, and the corresponding curve is SM2 curve);

2, digital signature algorithm: SM2 (SM2 is the name of the signature algorithm, and the corresponding curve name in the elliptic curve algorithm is also called SM2, some blog documents will also be the key exchange algorithm is called SM2, readers please note not to confuse);

3. Symmetric encryption algorithm: SM4;

4. Hash algorithm: SM3.

In other words, the STATE Secret Service has developed an autonomous and controllable algorithm for each stage of a secure handshake.

02 Why national Secrets? Why not?

First, let’s talk about why we use State secrets. As the main product of state Secrets Bureau, state secrets algorithm must have advantages in many places. First, let’s summarize the typical advantages of State secrets:

1. More secure: SM2 as an ECC algorithm (256 bits) is more secure than RSA (2048 bits). At the same time, the digest length of SM3 is 256 bits, and the security strength is higher than the mainstream MD5 algorithm and SHA1 algorithm at that time.

2, faster: In the communication process, the 256-bit SM2 algorithm can transmit less data, which means less transmission time, compared with the 2048-bit RSA algorithm (RSA2048 is the mainstream signature algorithm when the national secret algorithm is designed, so ECDSA and other algorithms will not be discussed here). In addition, in theory, SM2 signature algorithm is much faster than RSA2048.

3, independent and controllable: in the current international situation, this is the most crucial point!

State secret sounds like an innovation of Chinese cryptography, but it has not been widely implemented over the years, indicating that there must be some problems in itself. Here, putting aside some small problems in details, we will talk about some tricky problems encountered in the large-scale implementation of state secret algorithm:

1. Not fast enough

Compared with the mainstream international algorithms, the performance of several algorithms involved in the whole TLS session is relatively weak in most cases. Here are some simple performance comparison tables for some of them:

Performance comparison of symmetric encryption algorithms:

Performance comparison of signature algorithms:

Performance comparison of Hash algorithms:

From the comparison, we can see that the state secret of these algorithms and international algorithm performance is often not the same order of magnitude, whether symmetric encryption or asymmetric encryption part. The ultimate reason is that the popularity of various general international algorithms is too great, and there are corresponding multi-level optimization (hardware computing and various soft acceleration means) in engineering. Take symmetric encryption as an example: The target algorithm of SM4 is AES-128. In terms of its own encryption principle, SM4 will not have such a big gap with AES-128 in theory. However, AES is too universal. Typical AES implementation is based on Intel SIMD instruction set for its parallel acceleration, while SM4 is only a pure soft implementation, there is naturally a large gap in performance. Moreover, the current mainstream symmetric encryption mode is GCM and CCM mode, the idea behind which is encryption authentication technology (AEAD), but the national secret algorithm does not support this mode, there are also some weaknesses in security.

2. Double certificate required (★★★★)

To explain double certificate, you need to understand the PKI key negotiation mechanism. Typical key negotiation algorithms are RSA and ECDHE. The ec-SM2 key negotiation process of state secret is similar to RSA. The core nature of the algorithm lies in that data encrypted with public key can be decrypted with private key. The whole key negotiation process is simplified as follows:

Ecdhe-sm2 is similar to ECDHE algorithm, which is based on DH and ECC algorithms and is easier to understand. The process is simplified as shown below:

We’ll talk about the double certificate, certificate of double divided into signing certificate and encryption certificate, the purpose of this system is to meet national strong control demands for sensitive data, namely as long as can catch all packets, the control organization can restore out all clear data in theory, which spawned encryption certificate on this item, the private key encryption certificate need at special purpose. Let’s look at the RSA key exchange process. As long as you have a private key, the material (random number) generated by the middle key can be exported in theory. For ECDHE-SM2, the symmetric key export process is not only determined by the random number A/C, but also requires the private key corresponding to the encryption certificate to participate in the calculation (the specific process is complicated, and the reader can refer to GM/T 0024 for details), which means that when the private key is supervised, Symmetric keys can be theoretically derived.

This system is very powerful, but the difficulty is that all the mainstream cryptography libraries such as OpenSSL and BoringSSL do not support it. This means that if we want to promote the popularization of this system, we should develop based on the mainstream cryptography libraries and promote the acceptance of the open source community, and then gradually infiltrate into the domestic users and use this system. Either develop a new password library that is as compatible with the current system as possible and force domestic users to replace it, each of which presents considerable difficulties.

3. The client must also have a certificate (★★★★★ ★)

In GM/T 0024 standard, State Secret defines the key exchange process based on ECDHE-SM2 algorithm, but the algorithm has very strict requirements, requiring clients to hold certificates. Indeed, this improves security to a certain degree, but the trouble also follows. Alipay’s Client does not have certificates at present. If the certificate is added, the App will be heavier and the data of handshake interaction will be more, which will greatly reduce the user experience. These problems are not fatal enough, how to manage a large number of on-end certificates, is the real headache trouble.

You may ask: it would be better not to use ECDHE, but from the perspective of the evolution trend of technology, efficiency/security is our tireless pursuit, and rSA-like handshake process from the root of the state secret ECC key exchange process can not evolve to 1-RTT handshake, 0-RTT information transmission. Not only that, ECHDE also has much better security and performance. In the 1RTT standard handshake flow of TLS 1.3, the RSA handshake is explicitly abolished and only ECDHE is supported. If you want to use TLS 1.3-> requires ECDHE-> requires the Client to have a certificate -> does not have a certificate and does not want to use a certificate -> No solution.

TLS 1.3+ national secret algorithm suite

In view of these pain points during the implementation of state secrets, in August 2019, ant students took the lead to write a TLS 1.3+ State secrets algorithm draft, which eventually became an IETF standard document:

The core idea of the whole standard design is to integrate the advantages of the current state secret algorithm, fully fit the international security technology ideas, temporarily remove the things that are not good to use, enhance the influence of the state secret algorithm at home and abroad, so as to let more organizations and individuals participate in the use and construction of the state secret algorithm. Based on this idea, we jointly launched relevant standards with 360 and other companies after communicating with the State Administration of State Secrets for many times. In the whole process, we have eliminated the requirement of Client certificate on ECDHE algorithm, and temporarily relaxed the requirement of double certificate, thus introduced two complete sets of state secret algorithm, and determined the signature algorithm and the standard number of curve. At the same time, we defined GCM mode and CCM mode of SM4 based on AEAD requirements of TLS 1.3, and implemented them.

The whole draft defines the following standards (at present, these standards have been obtained the corresponding standard number) : The standard number of SM2 curve: CurveSM2 (41), this standard number allows the Client and server to use curveSM2 as the contract curve during TLS 1.3 handshake. This makes ECDHE_SM2 an international standard in TLS 1.3 (there is no need for clients to have certificates).

Signature algorithm based on SM2 and SM3 Sm2sig_sm3 (0x0708), the function of this standard number is that in the TLS 1.3 process, if the server has a state secret certificate, sm2SIG_SM3 can be used as the signature algorithm by default, and its significance is that the state secret certificate has become the standard.

Key suite based on TLS 1.3 and SM2,SM3,SM4 algorithm:

TLS_SM4_GCM_SM3 (0x00,0xC6) and TLS_SM4_CCM_SM3 (0x00,0xC7), which means that from now on you can use TLS 1.3’s 1RTT handshake + state secret algorithm according to the standard, which not only meets the requirements of the national standard, but also can be fast and convenient. At the same time, SM4 algorithm also uses more secure GCM/CCM mode.

Of course, standards also need engineering implementation, and often engineering implementation is the absolute determinant of whether an algorithm is good or not. In view of the poor performance of SM2/3/4, we designed and implemented many solutions to optimize, such as: asynchronous SM2 hardware acceleration process; SM4 soft optimization based on SIMD. Based on these technologies, the state secret is really available in production, and the cost is controllable.

04 summary

That day long tassel in hand, today eventually bound dragon. Looking back, it took about two years for the agreement to become an official IETF standard document from a draft. During this period, the IETF working group conducted several rounds of discussions and the draft also went through several rounds of revision. Finally, it was not easy to achieve the final result. With TLS 1.3+ officially becoming a nationally/internationally recognized standard (RFC8998), we are also officially supporting and open-source capabilities in BabaSSL and building the BabaSSL community.

The so-called Pengbeihai, with the sun rising, and the vast road with books and swords, the initial intention of BabaSSL construction is to create a unified/easy-to-use national secret database for the economy, but the implementation and implementation of only a national secret standard will not be the end of BabaSSL, BabaSSL will always strive for a further sea of stars. We’re doing quantum random numbers, MPK, Delegated Crendential, and that’s another story.

Recommended Reading of the Week

  • The secret ecology of AnolisOS is all you need to read

  • MOSN sub-project Layotto: Open a new chapter of service grid + application runtime

  • Open a new chapter in cloud native MOSN – Fusion Envoy and GoLang ecology

  • MOSN multi-protocol extension development practice

More articles please scan code to pay attention to “financial level distributed architecture” public number