KEM-based anti-quantum TLCP protocol design method and system

Abstract

The invention provides a KEM-based anti-quantum TLCP protocol design method and system, and belongs to the technical field of information security. The method comprises the steps that a server side applies for a server side signature certificate and an encryption certificate from an issuing mechanism, a long-term server side signature public key is stored in the server side signature certificate, and a long-term server side encryption public key is stored in the encryption certificate; and in the TLCP handshake protocol, identity authentication and key exchange between the server and the client are realized based on the long-term server signature public key and the long-term server encryption public key. According to the method, the anti-quantum KEM is used for replacing signature and encrypted primitives to realize key exchange and identity authentication functions of the protocol, identity authentication does not depend on the signature of a message any more, and meanwhile, a client introduces a temporary public key to replace a long-term static public key to participate in a KEM key negotiation process, so that the forward security of the protocol is ensured, and the security of the protocol is improved. Therefore, the efficiency and the security of the TLCP protocol are improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of information security, and in particular to a KEM-based anti-quantum TLCP protocol design method and system. BACKGROUND

[0002] With the acceleration of quantum computing technology from theory to engineering breakthrough, the current widely used communication protocol relies on the classical cryptography system, which is facing an unprecedented survival crisis. Among them, TLCP (Transport Layer Cryptography Protocol) is a transport layer cryptography protocol independently developed by China, which provides confidentiality, data integrity and entity authentication functions for two application programs to achieve secure transport layer communication protection. Since the traditional cryptographic algorithm is used in TLCP, it also does not have the ability to resist quantum attacks. Therefore, how to introduce post-quantum algorithms into the TLCP protocol to realize an anti-quantum secure TLCP protocol is a problem to be solved in the field. At present, the existing TLCP communication method resisting quantum attacks is realized by simple algorithm replacement, such as replacing the SM2 signature algorithm with the CRYSTALS-Dilithium algorithm, and replacing the SM2-based key agreement algorithm with CRYSTALS-Kyber. Compared with traditional algorithms, quantum-safe key agreement has less impact on the protocol, but the volume of anti-quantum signature increases dramatically, and the time-consuming of signature generation and verification increases, which results in high modification cost of anti-quantum signature scheme, making it difficult to be directly deployed in TLCP and other scenarios. SUMMARY

[0003] In view of the problems in the prior art, the purpose of the present application is to provide a KEM (Key Encapsulation Mechanism)-based anti-quantum TLCP protocol design method and system, which modifies the handshake process of the TLCP protocol, uses anti-quantum KEM to replace the signature and encryption primitives to realize the key exchange and identity authentication functions of the protocol, and no longer relies on the signature of the message for identity authentication. At the same time, the client introduces a temporary public key to replace the long-term static public key to participate in the KEM key agreement process, ensuring the forward security of the protocol, thereby improving the efficiency and security of the TLCP protocol.

[0004] In order to achieve the above purpose, the technical scheme of the present application includes the following contents.

[0005] A KEM-based anti-quantum TLCP protocol design method, the method comprising:

[0006] The server end applies to the issuing agency for a server signature certificate and an encryption certificate; wherein the server signature certificate stores a long-term server signature public key, and the encryption certificate stores a long-term server encryption public key;

[0007] In the TLCP handshake protocol, identity authentication and key exchange between the server and the client are implemented based on a long-term server signature public key and a long-term server encryption public key.

[0008] Further, the identity authentication between the server and the client comprises one-way authentication of the server by the client.

[0009] The identity authentication and the key exchange between the server and the client based on the long-term server signature public key and the long-term server encryption public key comprise:

[0010] The client generates a quantum-resistant temporary public-private key pair (sk T , pk T ) using a key generation function KeyGen() and sends a ClientHello message to the server; wherein the ClientHello message comprises a client random number n C , a client protocol version number Version, a session number SID, a list of supported cipher suites negotiation of the client, and a quantum-resistant temporary public key pk T .

[0011] The server determines whether the content in the ClientHello message meets the set requirements, and in the case that the content meets the set requirements, the server generates and returns a ServerHello message, wherein the ServerHello message comprises a server random number n S , a version number Version used in the current handshake, a session number SID, and a cipher suite negotiation, wherein the version number Version used in the current handshake is determined based on the client protocol version number Version, and the cipher suite negotiation is selected from the list of supported cipher suites negotiation of the client.

[0012] The server sends a ServerCertificate message to the client, wherein the ServerCertificate message comprises a server signature certificate and an encryption certificate.

[0013] The server encapsulates the quantum-resistant temporary public-private key pk T to generate a quantum-resistant cipher key encapsulation ciphertext c T and a temporary shared key k T , and sends the quantum-resistant cipher key encapsulation ciphertext c T to the client through a ServerKeyExchange message.

[0014] The client obtains a temporary shared key k by decapsulating the anti-quantum password key encapsulation ciphertext c T T The server encapsulates a long-term server signature public key and a long-term server encryption public key to generate signature ciphertext The server shares the signature key The server encrypts the ciphertext and shares the encryption key The server sends the signature ciphertext and the encryption ciphertext to the client through a ClientKeyExchange message.

[0015] The server obtains the shared signature key and the shared encryption key by decapsulating the signature ciphertext and the encryption ciphertext

[0016] After the client and the server respectively calculate a pre-master key pms based on the shared encryption key and the temporary shared key k T , the client and the server generate a master key ms based on the pre-master key pms, the client random number n C and the server random number n S .

[0017] The client sends a ClientFinished message to the server, wherein the ClientFinished message contains first verification information generated based on the shared signature key and the master key ms.

[0018] The server sends a ServerFinished message to the client, wherein the ServerFinished message contains second verification information generated based on the shared signature key and the master key ms.

[0019] In the case that the first verification information and the second verification information are consistent, the authentication of the client to the server is completed.

[0020] Further, the long-term server signature public-private key pair, the long-term server encryption public-private key pair and the anti-quantum temporary public-private key pair (sk T , pk T ) are generated based on a PQC KEM algorithm, wherein the PQC KEM algorithm includes CRYSTALS-Kyber.

[0021] Further, the generation method of the pre-master key pms includes:​ with the temporary shared key k T performing a concatenation operation or an exclusive-OR operation.

[0022] Further, the master secret key ms=pref(pms,"master secret",n c ||n s ); wherein pref() is a key derivation function, and "master secret" represents a first constant string.

[0023] Further, the first verification information wherein "client finished" represents a second constant string, and "log1" represents a hash value of all handshake-related messages from the clientHello message to the first verification information verify_data.

[0024] Further, the method further comprises: based on the master secret key ms, the client random number n C and the server random number n S , generating a working key K.

[0025] Further, in the case that the content does not meet the set requirements, the server generates and returns a RetryRequest message to require the content of the ClientHello message sent by the client to meet the set requirements.

[0026] Further, the identity authentication between the server and the client comprises: bidirectional authentication between the client and the server.

[0027] The identity authentication and key exchange between the server and the client based on the long-term server signature public key and the long-term server encryption public key comprises:

[0028] A client signature certificate applied for by the client to an issuing authority; wherein the client signature certificate comprises a long-term client signature public key;

[0029] The client uses a key generation function KeyGen() to generate a quantum-resistant temporary public-private key pair (sk T , pk T ), and sends a ClientHello message to the server; wherein the ClientHello message comprises: a client random number n C , a client protocol version number Version, a session number SID, a list of cipher suites supported by the client negotiation, a quantum-resistant temporary public key pk T , and a client signature certificate;

[0030] The server judges whether the content in the ClientHello message meets the set requirement, and generates and returns a ServerHello message if the content meets the set requirement; wherein the ServerHello message includes a server random number n S The version number Version used in the handshake, the session number SID, and the cipher suite negotiation are determined based on the client protocol version number Version, and the cipher suite negotiation is selected from the list of cipher suites negotiation supported by the client;

[0031] The server sends a ServerCertificate message to the client, wherein the ServerCertificate message includes a server signature certificate and an encryption certificate;

[0032] The server encapsulates the anti-quantum temporary public and private keys pk T and the long-term client signature public key to generate an anti-quantum cipher key encapsulation ciphertext c T , a temporary shared key k T , a signature ciphertext , and a temporary shared key The server sends the anti-quantum cipher key encapsulation ciphertext c T and the signature ciphertext to the client through a ServerKeyExchange message;

[0033] The client obtains the temporary shared key k T and the temporary shared key by un-encapsulating the anti-quantum cipher key encapsulation ciphertext c T and the signature ciphertext The server encapsulates the long-term server signature public key and the long-term server encryption public key to generate a signature ciphertext The server shares the signature key The server encrypts the ciphertext and shares the encryption key The server sends the signature ciphertext and the ciphertext to the client through a ClientKeyExchange message;

[0034] The server obtains the shared signature key and the shared encryption key by un-encapsulating the signature ciphertext and the ciphertext

[0035] The client and the server are based on a shared encryption key and a temporary shared key k T After calculating the pre-master key pms, the pre-master key pms, the client random number n C and the server random number n S The master key ms is generated.

[0036] The client sends a ClientFinished message to the server; wherein the ClientFinished message contains first verification information generated based on the shared signature key The temporary shared key and the master key ms.

[0037] The server sends a ServerFinished message to the client; wherein the ServerFinished message contains second verification information generated based on the shared signature key The temporary shared key and the master key ms.

[0038] In the case where the first verification information and the second verification information are consistent, the mutual authentication of the client and the server is completed.

[0039] A KEM-based anti-quantum TLCP protocol design system, the system comprises a server and a client, wherein,

[0040] The server applies to a signing authority for a server signature certificate and an encryption certificate; wherein the server signature certificate stores a long-term server signature public key, and the encryption certificate stores a long-term server encryption public key.

[0041] In the TLCP handshake protocol, identity authentication and key exchange between the server and the client are realized based on the long-term server signature public key and the long-term server encryption public key.

[0042] Compared with the prior art, the present application has the following beneficial effects.

[0043] The application realizes handshake protocol to realize (implicit) identity authentication while completing key exchange by using anti-quantum KEM algorithm on the basis of domestic TLCP, and cleverly uses double certificate information (signature certificate is used for identity authentication, and encryption certificate is used for key exchange). The current mainstream anti-quantum signature scheme has low signature verification efficiency, and since the method does not need to rely on the traditional signature function for identity authentication, and the data packets transmitted in the protocol interaction process are reduced (CertificateRequest, ClientCertificate and CertificateVerify information are not needed), the working efficiency of the protocol can be improved. In addition, the TLCP protocol realized by the application has anti-quantum capability, has forward security, and can support one-way authentication and two-way authentication. BRIEF DESCRIPTION OF DRAWINGS

[0044] Figure 1 The flowchart of the KEM-based anti-quantum TLCP protocol design method.

[0045] Figure 2 The flowchart of the KEM TLCP protocol with one-way authentication and forward security.

[0046] Figure 3 The flowchart of the KEM TLCP protocol with two-way authentication and forward security. DETAILED DESCRIPTION

[0047] The application will be further described in detail below with reference to the drawings, and the examples are only used to explain the application, and not to limit the scope of the application.

[0048] The application realizes identity authentication and key exchange by using the public key information KEM encapsulation mode in double certificates (signature certificate is used for identity authentication, and encryption certificate is used for key exchange). The application includes: using anti-quantum KEM algorithm to realize key exchange in TLCP handshake protocol, completing session key negotiation of the client and the server, and using anti-quantum KEM algorithm to realize (implicit) identity authentication without relying on the traditional signature function for identity authentication.

[0049] Specifically, as Figure 1 described, the KEM-based anti-quantum TLCP protocol design method of the application includes the following steps.

[0050] Step 1: The server end applies to the issuing agency for a server signature certificate and an encryption certificate.

[0051] The server signature certificate stores a long-term server signature public key, and the encryption certificate stores a long-term encryption public key.

[0052] Step 2: In the TLCP handshake protocol, identity authentication and key exchange between the server and the client are realized based on the long-term server signature public key and the long-term server encryption public key.

[0053] In the present application, the identity authentication between the server and the client includes one-way authentication of the client to the server and two-way authentication of the client and the server.

[0054] In one embodiment, the present application realizes one-way authentication (the client authenticates the server) with forward security of the client and the server, as shown in Figure 2 Step 2.1.1 to Step 2.1.9.

[0055] Step 2.1.1: Before the handshake process starts, the server side has already held the server signature certificate and encryption certificate applied for from the signature authority in advance, wherein the long-term signature public key is stored in the signature certificate and the long-term encryption public key is stored in the encryption certificate.

[0056] Step 2.1.2: The client uses the key generation function KeyGen() to generate a temporary KEM public-private key pair (sk T ,pk T ), and sends the ClientHello message to the server, wherein the ClientHello message includes the client random number n C , the version number Version, the session number SID (the value of which is determined by the server and is Null for the first connection), the cipher suite negotiation list supported by the client, and the temporary public key pk T .

[0057] Step 2.1.3: After receiving the ClientHello message, the server sends the ServerHello message to the client, wherein the ServerHello message includes the server random number n S , the version number Version used in this handshake, the session number SID, the cipher suite negotiation, etc.; wherein the protocol version number Version used in the handshake of the client and the server is consistent, and only then will the subsequent handshake connection be performed, the session number SID is generated by the server and sent to the client to declare the establishment of a new session, and the cipher suite negotiation is a cipher suite selected by the server from the suite list in the ClientHello message of the client.

[0058] Step 2.1.4: The server sends the ServerCertificate message to the client, wherein the ServerCertificate includes the server's own signature certificate (the certificate includes the server long-term signature public key) and encryption certificate (the certificate includes the server long-term encryption public key).

[0059] Step 2.1.5: The server encapsulates the client's temporary public key and sends it to the client via a ServerKeyExchange message, utilizing the client's quantum-resistant temporary public key for PK. T Perform quantum-resistant cryptographic key encapsulation to generate quantum-resistant cryptographic key encapsulated ciphertext c. T With shared key k T , (k T ,c T =Encaps(pk T The `Encaps()` method specifies the public-key encapsulation algorithm, such as CRYSTALS-Kyber. The `ServerKeyExchange` message includes the quantum-resistant cryptographic key encapsulated ciphertext `c`. T .

[0060] Step 2.1.6: The client receives the ServerKeyExchange message and uses the quantum-resistant temporary private key sk T Perform quantum-resistant cryptographic key decapsulation, k T =Decaps(sk T ,c T ), where Decaps() is the public key decapsulation algorithm.

[0061] The client encapsulates the server's signing public key and encryption public key, and sends them to the server via a ClientKeyExchange message, utilizing the server's quantum-resistant signature public key. (Long-term signature public key), encryption public key (Long-term encryption public key) is encapsulated with a quantum-resistant cryptographic key to generate quantum-resistant cryptographic key-encapsulated ciphertext. With shared keys The ClientKeyExchange message includes quantum-resistant cryptographic key-encapsulated ciphertext.

[0062] Step 2.1.7: The server receives the ClientKeyExchange message and uses the quantum-resistant signature private key. Quantum-resistant cryptographic private key Perform quantum-resistant cryptographic key decapsulation.

[0063] The client and server calculate the premaster key separately. Here, || represents a join operation, meaning the pre-master key is shared with the encryption key on the server side. Temporary shared key k with the client TThe pref() is a key derivation function, and the pref() function is used to generate the master secret ms and the working key K, and the calculation method is consistent with the original TLCP protocol.

[0064] ms = pref(pms, "master secret", n c || n s )

[0065] K = pref(ms, "key expansion", n c || n s )

[0066] The master secret represents the first constant string, and the key expansion represents the third constant string.

[0067] Step 2.1.8: The client sends a ClientFinished message to the server, representing the end of the handshake. The Finished message contains the verification information verify_data, The calculation method of the verification information is different from that of the original TLCP protocol, in that the input of the pref function is additionally increased by the server signature shared key The client finished represents the second constant string, and the log1 represents the hash value of all handshake related messages from the clientHello message to the first verification information verify_data. The server performs the verification calculation to determine whether the generated verification information is consistent with the verify_data sent by the client. The server needs to use the signature private key to calculate Since the private key can only be owned by itself, the server proves its identity by proving that it knows a secret (signature private key). Therefore, this step verifies the integrity of the handshake process and completes the implicit authentication of the client to the server.

[0068] Step 2.1.9: The server sends a ServerFinished message to the client, representing the end of the handshake. The Finished message contains the verification information verify_data, This step verifies the integrity of the handshake process.

[0069] In another embodiment, the present application realizes the mutual authentication with forward security between the client and the server, as shown in Figure 3 The following steps 2.2.1 to 2.2.9 are included.

[0070] Step 2.2.1: Before the handshake process, the client has a client signature certificate (including the client long-term signature public key) pre-applied to the issuing authority, and the server has a server signature certificate (including the long-term server signature public key) and an encryption certificate (including the long-term encryption public key) pre-applied to the issuing authority.

[0071] Step 2.2.2: The client uses the key generation function KeyGen() to generate a temporary KEM public-private key pair (sk T ,pk T ), and sends a ClientHello message to the server, which includes the client random number n C , the version number Version, the session number SID (whose value is determined by the server, and is Null for the first connection), the client-supported cipher suite negotiation list, and the temporary public key pk T and the client signature certificate.

[0072] Step 2.2.3: After receiving the ClientHello message, if the content sent by the client does not meet the requirements (such as the server requires mutual authentication, but the client does not send a signature certificate), the server returns a RetryRequest message, requiring the client to resend the required information; if the requirements are met, the server sends a ServerHello message to the client, which includes the server random number n S , the version number Version used in this handshake, the session number SID, and the cipher suite negotiation; among them, the protocol version number Version used in the client and server handshake is consistent, then the subsequent handshake connection will be performed, the session number SID is generated by the server and sent to the client to declare the establishment of a new session, and the cipher suite negotiation is a cipher suite selected by the server from the suite list in the client ClientHello message.

[0073] Step 2.2.4: The server sends a ServerCertificate message to the client, which includes the server's own signature certificate (including the server long-term signature public key) and encryption certificate (including the server long-term encryption public key).

[0074] Step 2.2.5: The server encapsulates the client's temporary public key and signature public key and sends them to the client through the ServerKeyExchange message, which uses the client's quantum-resistant temporary public key pk T and signature public key Anti-quantum password key encapsulation is performed to generate anti-quantum password key encapsulation ciphertext c T 、 With the shared key (k T ,c T )=Encaps(pk T ), Where Encaps() is a public key encapsulation algorithm, such as CRYSTALS-Kyber. The anti-quantum password key encapsulation ciphertext c is included in the ServerKeyExchange message T 、

[0075] Step 2.2.6: The client receives the ServerKeyExchange message, and performs anti-quantum password key decapsulation through the anti-quantum temporary private key sk T , signature private key k T =Decaps(sk T ,c T ), Where Decaps() is a public key decapsulation algorithm.

[0076] The client encapsulates the server signature public key and encryption public key, and sends it to the server through the ClientKeyExchange message, and uses the server anti-quantum signature public key Encryption public key Anti-quantum password key encapsulation is performed to generate anti-quantum password key encapsulation ciphertext With the shared key The anti-quantum password key encapsulation ciphertext is included in the ClientKeyExchange message

[0077] Step 2.2.7: The server receives the ClientKeyExchange message, and performs anti-quantum password key decapsulation through the anti-quantum signature private key Anti-quantum encryption private key

[0078] The client and the server respectively calculate the pre-master key Where || represents the concatenation operation, that is, the pre-master key is generated by the server shared encryption key and the client temporary shared key k T ​The spliced connection is obtained; the pre-master key is used as key material for derivation of other keys of the client and the server, and the master key ms and the working key K are generated, and the calculation manner is consistent with the original TLCP protocol, wherein pred() is a key derivation function;

[0079] ms=pref(pms,"master secret",n c ||n s )

[0080] K=pref(ms,"key expansion",n c ||n s )

[0081] Step 2.2.8: The client sends a ClientFinished message to the server, which represents the end of the handshake. The Finished message contains verification information The calculation manner of the verification information is different from that of the original TLCP protocol, and the input of the pref function is additionally spliced with the server and the client signature shared key The server performs verification calculation to determine whether the generated verification information is consistent with the verify_data sent by the client, and the client needs to use the signature private key in step 2.2.6 The calculation result is obtained The server needs to use the signature private key in step 2.2.7 The calculation result is obtained Since the private key can only be owned by itself, the client and the server can prove their identities by proving that they know a secret (signature private key), so this step verifies the integrity of the handshake process and completes the implicit authentication of the client and the server.

[0082] Step 2.2.9: The server sends a ServerFinished message to the client, which represents the end of the handshake. The Finished message contains verification information verify_data, Similarly, this step verifies the integrity of the handshake process.

[0083] In summary, the client of the application can use a temporary KEM public key to replace the KEM long-term public key stored in the encryption certificate to participate in the key exchange process, and the temporary key is only used in a single session, so that the forward security of the communication process can be ensured.

[0084] The identity authentication process of the present application comprises: the server generates a client shared signature key through an anti-quantum KEM encapsulation algorithm, the client end obtains the client shared signature key through decapsulation, the client generates a server shared signature key through an anti-quantum KEM encapsulation algorithm, the server obtains the server shared signature key through decapsulation, in the Finished message of the handshake end of the TLCP protocol, the shared signature key information is additionally added, only the communication parties can check through the Finished message of the same shared signature key, since the shared signature key is obtained through decapsulation processing, the decapsulation process needs the participation of the private key itself, the client / server proves its identity by proving that it knows a secret (signature private key), thereby realizing implicit identity authentication.

[0085] The identity authentication process of the present application supports one-way authentication and two-way authentication. The authentication process realizes the identity authentication of the server to the client through the client being able to obtain the client shared signature key, realizes the identity authentication of the client to the server through the server being able to obtain the server shared signature key. When both the identity authentication processes are executed, two-way authentication of the client and the server is realized.

[0086] Although the specific embodiments of the present application are disclosed for the purpose of illustration, it is intended to help understand the content of the present application and to implement the same, those skilled in the art can understand that various substitutions, changes and modifications are possible without departing from the spirit and scope of the present application and the appended claims. Therefore, the present application should not be limited to the disclosed content of the best mode, the scope of the present application claimed is the scope defined by the claims.

Claims

1. A KEM-based quantum-resistant TLCP protocol design method, characterized in that, The method comprises: The server end applies to the issuing agency for a server signature certificate and an encryption certificate; the server signature certificate stores a long-term server signature public key, and the encryption certificate stores a long-term server encryption public key; In the TLCP handshake protocol, identity authentication and key exchange between the server and the client are realized based on the long-term server signature public key and the long-term server encryption public key.

2. The method of claim 1, wherein, The identity authentication between the server and the client comprises one-way authentication of the server by the client. The identity authentication and the key exchange between the server and the client based on the long-term server signature public key and the long-term server encryption public key comprise: A client generates a quantum-resistant ephemeral public-private key pair (sk T , pk T ) using a key generation function KeyGen() and sends a ClientHello message to a server; wherein the ClientHello message comprises a client nonce n C , a client protocol version number Version, a session number SID, a list of cipher suites negotiation supported by the client, and a quantum-resistant ephemeral public key pk T ; The server judges whether the content in the ClientHello message meets the set requirement, and in the case that the content meets the set requirement, the server generates and returns a ServerHello message, wherein the ServerHello message comprises: a server random number n S The version number Version used in the handshake is determined based on the client protocol version number Version, and the cipher suite negotiation is selected from the list of cipher suites negotiation supported by the client. The server sends a ServerCertificate message to the client, and the ServerCertificate message comprises the server signature certificate and the encryption certificate; Server encapsulates quantum-resistant ephemeral public-private pk T to generate quantum-resistant key encapsulation ciphertext c T and ephemeral shared key k T and sends quantum-resistant key encapsulation ciphertext c T to the client using a ServerKeyExchange message; The client obtains the temporary shared key k by decapsulating the anti-quantum cipher key encapsulation ciphertext c T T The server generates the signature ciphertext by encapsulating the long-term server signature public key and the long-term server encryption public key The server shares the signature key The server encrypts the ciphertext and shares the encryption key The server sends the signature ciphertext and the encryption ciphertext to the client using the ClientKeyExchange message.​ The server side decapsulates the signed ciphertext and the encrypted ciphertext to obtain the shared signed key and the shared encrypted key The client and the server are based on a shared encryption key and a temporary shared key k T After calculating the pre-master key pms, the master key ms is generated based on the pre-master key pms, the client random number n C and the server random number n S ​ The client sends a ClientFinished message to the server; wherein the ClientFinished message contains first verification information generated based on the shared signing key and the master key ms. The server sends a ServerFinished message to the client; wherein the ServerFinished message contains second verification information generated based on the shared signing key and the master key ms. In the case that the first check information and the second check information are consistent, the authentication of the server by the client is completed.

3. The method of claim 2, wherein, generating the long-term server signature public-private key pair, the long-term server encryption public-private key pair, and the quantum-resistant ephemeral public-private key pair (sk T , pk T ) based on a PQC KEM algorithm; wherein the PQC KEM algorithm comprises CRYSTALS-Kyber.

4. The method of claim 2, wherein, The method for generating the pre-master key pms includes performing a splicing operation or an exclusive or operation on the shared encryption key with the temporary shared key k T performs a splicing operation or an exclusive or operation.

5. The method of claim 2, wherein, The master key ms = pref(pms, "master secret", n c ||n s ); wherein pref() is a key derivation function, and master secret represents a first constant string.

6. The method of claim 2, wherein, The first check information wherein the client finished indicates a second constant string, and logl indicates a hash value of all handshake-related messages from the clientHello message to the first check information verify_data.

7. The method of claim 2, wherein, The method further comprises: based on a master secret key ms, the client nonce n C and the server nonce n S to generate a working key K.

8. The method of claim 2, wherein, In the case that the content does not meet the set requirement, the server generates and returns a RetryRequest message to require the content of the ClientHello message re-sent by the client to meet the set requirement.

9. The method of claim 1, wherein, The identity authentication between the server and the client comprises two-way authentication of the server by the client. The identity authentication and the key exchange between the server and the client based on the long-term server signature public key and the long-term server encryption public key comprise: The client signature certificate applied for by the client to the issuing agency comprises a long-term client signature public key; The client generates a quantum-resistant temporary public-private key pair (sk T ,pk T ) using a key generation function KeyGen() and sends a ClientHello message to the server; wherein the ClientHello message comprises: a client random number n C , a client protocol version number Version, a session number SID, a list of cipher suites negotiation supported by the client, a quantum-resistant temporary public key pk T , and a client signature certificate; The server judges whether the content in the ClientHello message meets the set requirement, and generates and returns a ServerHello message if the content meets the set requirement; wherein the ServerHello message comprises: a server random number n S The version number Version used in the handshake, the session number SID, and the cipher suite negotiation are determined based on the client protocol version number Version, the cipher suite negotiation is selected from the list of cipher suites supported by the client, and the session number SID is selected from the list of session numbers supported by the server. The server sends a ServerCertificate message to the client, and the ServerCertificate message comprises the server signature certificate and the encryption certificate; Server encapsulates anti-quantum temporary public-private pk T and long-term client signature public key to generate anti-quantum cryptographic key encapsulation ciphertext c T , temporary shared key k T , signature ciphertext and temporary shared key and sends anti-quantum cryptographic key encapsulation ciphertext c T and signature ciphertext to the client using the ServerKeyExchange message; The client obtains a temporary shared key k by decrypting the anti-quantum cryptography key-encapsulated ciphertext c T and the signature ciphertext to obtain a temporary shared key k T with the temporary shared key encapsulating the long-term server signature public key and the long-term server encryption public key to generate the signature ciphertext sharing the signature key encrypting the ciphertext and sharing the encryption key and sending the signature ciphertext and the encryption ciphertext to the server using a ClientKeyExchange message; The server side decapsulates the signed ciphertext and the encrypted ciphertext to obtain the shared signed key and the shared encrypted key The client and the server are based on a shared encryption key and a temporary shared key k T After calculating the pre-master key pms, a master key ms is generated based on the pre-master key pms, the client random number n C and the server random number n S ​ The client sends a ClientFinished message to the server; wherein the ClientFinished message contains a first verification information generated based on the shared signing key The temporary shared key and the master key ms The server sends a ServerFinished message to the client; wherein the ServerFinished message contains second verification information generated by the master key ms based on the shared signing key The temporary shared key and the second verification information generated by the master key ms In the case that the first check information and the second check information are consistent, the two-way authentication of the server by the client is completed.

10. A KEM-based quantum-resistant TLCP protocol design system, characterized in that, The system comprises a server end and a client, wherein, The server end applies to the issuing agency for a server signature certificate and an encryption certificate; the server signature certificate stores a long-term server signature public key, and the encryption certificate stores a long-term server encryption public key; In the TLCP handshake protocol, identity authentication and key exchange between the server and the client are realized based on the long-term server signature public key and the long-term server encryption public key.

Images