RFC8998+BabaSSL---Let the National Secret Drive to the Farther Sea of Stars

01 Introduction-TLS 1.3 protocol and SM algorithm

Speaking of TLS, everyone will not be unfamiliar with it. TLS can be said to be the cornerstone of the entire Internet security, ensuring the security of our communication data. Since the Heartbleed vulnerability was discovered in 2014, network security has attracted more and more attention. Due to the need for more security and speed, the TLS 1.3 protocol has also been proposed, and its corresponding RFC was officially released in 2018. With the increasing attention to network security, the security strategy has gradually risen to the height of the national strategy. At the end of 2010, the State Cryptography Bureau announced the “elliptic curve public key cryptographic algorithm” (SM2 algorithm) independently developed by my country, and subsequently released it successively. The national secret algorithm SM1-SM9 (SM stands for Shangmi Pinyin uppercase). What we are going to share today is related to TLS 1.3 and national secrets.

First, let everyone have a basic concept 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 packages for each algorithm are as follows:

1. Key exchange algorithm: ECC-SM2, ECDHE-SM2 (I will not expand it in detail here, but only briefly introduce it. The key exchange algorithm of the State Secret has designed two special algorithms based on the current elliptic curve algorithm, and the corresponding The 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 also refer to the key exchange algorithm as SM2. Readers should be careful not to confuse it) ；

3. Symmetric encryption algorithm: SM4;

4. Hash algorithm: SM3.

In other words, the State Secret Bureau has issued an autonomous and controllable algorithm for the algorithms required at each stage of the secure handshake.

02 why country secret? why not country secret?

Let me first talk about why the National Secret is used. As the main product of the National Secret Bureau, the National Secret Algorithm must have advantages in many places. First, let's summarize the typical advantages of the National Secret:

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

2. Faster: In the communication process, the 256-bit SM2 algorithm is compared with the 2048-bit RSA algorithm (the national secret algorithm is designed, RSA2048 is the mainstream signature algorithm, so ECDSA and other algorithms are not discussed here), which can transmit more Less data means less transmission time, and in theory, the calculation speed of the SM2 signature algorithm is much faster than that of RSA2048.

3. Independent and controllable: In the current international situation, this is the most critical point!

The national secret sounds like an innovation in Chinese cryptography, but it has not been implemented on a large scale in recent years, indicating that there must be some problems in itself. Here are some small details of the problem, and talk about the big problem of the national secret algorithm. Some thorny problems encountered in the process of scale implementation:

1. The speed is not fast enough (trouble index★★★)

Compared with the mainstream international algorithms, the performance of several algorithms involved in the entire TLS session process of China Secret is relatively weak in most cases. Here are some simple performance comparison tables:

symmetric encryption algorithm performance comparison :

signature algorithm performance comparison :

hash algorithm performance comparison :

From the comparison, we can see that the performance of these national secret algorithms and international algorithms are often not in the same order of magnitude, whether it is symmetric encryption or asymmetric encryption. The ultimate root cause is that the popularity of various general international algorithms is too large, and there are corresponding multi-level optimizations in engineering (hardware calculations and various soft acceleration methods). Take symmetric encryption as an example: National Secret Symmetric Encryption Algorithm SM4's benchmark algorithm is aes-128. From the perspective of its own encryption principle, SM4 will not have such a big gap with aes-128 in theory. However, due to the fact that AES is too universal, typical AES implementations are based on Intel's The SIMD instruction set has been parallelized and accelerated, while SM4 currently only has a pure soft implementation, so there is naturally a big gap in performance. Not only that, the current mainstream symmetric encryption modes are GCM and CCM modes, and the idea behind them is encryption as authentication technology (AEAD), and the national secret algorithm does not yet support this mode, and there are also some weaknesses in security.

2. Dual certificates are required (★★★★)

To clarify the dual certificate, you first need to understand the PKI key agreement mechanism. Typical key agreement algorithms are divided into two types: RSA and ECDHE. The national secret ECC-SM2 key agreement process is similar to RSA. The core nature of the algorithm is that the data encrypted with the public key can be decrypted with the private key. The entire key agreement process is simplified as shown below:

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

Let's talk about dual certificates again. Dual certificates are divided into signature certificates and encryption certificates. The purpose of this system is to meet the country's demand for strong control and control of sensitive data, that is, as long as all data packets can be captured, the regulatory agency can theoretically All the plaintext data was recovered, which gave birth to the encryption certificate. The private key of the encryption certificate needs to be kept in a special organization. Let's look at the key exchange process of RSA. As long as the private key is possessed, the material (random number) generated by the intermediate key can also be derived theoretically. For ECDHE-SM2, the symmetric key derivation 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 cumbersome and will not be expanded here, readers Please refer to the GM/T 0024 standard for detailed details), which means that when the private key is supervised, the symmetric key can be derived theoretically.

This system is very powerful, but the difficulty is that all mainstream cryptographic libraries such as openssl and boringssl do not support it, so this means that if you want to promote the universality of this system, you must either develop based on mainstream cryptographic libraries and promote open source. Accepted by the community, and then slowly penetrated into domestic users to use this system, or to develop a new password library and force domestic users to replace it with the current password system as compatible as possible. Each method has a lot of problems. Difficulty.

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

The National Secret in the GM/T 0024 standard defines a key exchange process based on the ECDHE-SM2 algorithm, but this algorithm is very demanding, and the client must also be required to hold a certificate. It does improve security to a certain extent, but it is also troublesome. As a result, the Alipay client does not currently have a certificate. If the certificate is added, the App will be heavier and the handshake interaction will be more data, greatly reducing the user experience. These problems are not fatal enough. How to manage the massive amount of end-to-end certificates is the real headache.

You may ask: It’s better not to use ECDHE, but from the perspective of technological evolution, efficiency/security is our tireless pursuit, and the RSA-like handshake process restricts the national secret ECC key exchange process from the root. Unable to evolve to 1-RTT handshake, 0-RTT information transmission. Not only that, but the safety and performance of ECHDE are much better. In the 1RTT standard handshake process of TLS 1.3, it is clearly defined that the RSA handshake is abolished and only ECDHE is supported. The current situation has caused a deadlock. I want to use TLS 1.3 -> ECDHE is required -> Client has a certificate -> No certificate and I don't want to use a certificate -> The problem is unsolvable.

03 Heavy launch, TLS 1.3+ national encryption algorithm suite

In response to these pain points during the implementation of the national secret, in August 2019, a classmate of Ant took the lead to write a draft of the TLS 1.3+ national secret algorithm, which eventually became an IETF standard document:

The core idea of the entire standard design is: Integrate the advantages of the current national secret algorithm, fully conform to the international security technology ideas, temporarily remove the unusable things, and enhance the national and international influence of the national secret algorithm, thereby Let more organizations and individuals participate in the use and construction of the national secret algorithm. Based on this idea, we united 360 and other companies, and after many communications with the State Secret Bureau, we formally launched the relevant standards. In the entire process, we canceled the client certificate requirement on the ECDHE algorithm, and temporarily relaxed the dual certificate requirement, and thus launched two complete national secret algorithm suites, and determined the signature algorithm and the standard number of the curve. At the same time, we defined the GCM mode and CCM mode of SM4 based on the AEAD requirements of TLS 1.3, and implemented this.

The entire draft defines the following standards (currently these standards have obtained the corresponding standard numbers):
The standard number of the national secret SM2 curve: curveSM2 (41). The role of this standard number allows the client and server to use curveSM2 as the agreed curve during the TLS 1.3 handshake, which is equivalent to making ECDHE_SM2 an international standard in TLS 1.3 (of course, here The client does not need to hold a certificate).

The signature algorithm standard number based on SM2 and SM3: sm2sig_sm3 (0x0708). The function of this standard number is that in the future TLS 1.3 process, if the server holds a national secret certificate, it can use sm2sig_sm3 as the signature algorithm by default. The significance is that the national secret certificate has since become a standard.

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

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

Of course, standards also require engineering implementation, and often engineering implementation is the absolute factor that really determines whether an algorithm is easy to use. In response to the poor performance of SM2/3/4, we designed and implemented many solutions to optimize, such as: asynchronous SM2 hardware acceleration process; SIMD-based SM4 soft optimization implementation, etc. Based on these technologies, it is truly possible to make the National Secret Company available in production and the cost is controllable.

04 Summary

Chang Ying was in hand that day, and now the dragon is bound to be finally bound. Looking back, it took almost two years for the agreement to go from a draft to a formal IETF standard document. During this period, we had many rounds and discussions with the IETF working group. The draft also went through multiple rounds of revisions, and finally it could be revised. Positive results are not easy. As TLS 1.3+ National Secret has officially become a national/international standard (RFC8998), we have also officially supported related capabilities in BabaSSL and open sourced them, and built the BabaSSL community.

The so-called Peng Beihai, Feng Chaoyang, and the boundless road with books and swords, the original intention of BabaSSL construction is to create a unified/easy-to-use national secret cryptographic library for the economy, but the implementation and realization of only a national secret standard will never be BabaSSL At the end of the year, BabaSSL will always strive for the farther sea of stars. We are actively implementing quantum random number, MPK, Delegated Crendential and other cutting-edge technologies. Of course, that is another story.

Recommended reading this week

• AnolisOS national secret ecology, it is enough to understand this one
• MOSN sub-project Layotto: opening a new chapter in service grid + application runtime
• Opens a new chapter in cloud-native MOSN-Integrating Envoy and GoLang ecology
• MOSN multi-protocol extension development practice

For more articles, please scan the QR code to follow the "Financial-level Distributed Architecture" public account