A Communication Method for SSL VPN Security Gateway Based on Post-Quantum Cryptography

Abstract

This invention discloses an SSL VPN security gateway communication method based on post-quantum cryptography, comprising the following steps: S1. The client and server are respectively configured with clean PQC algorithm digital certificates containing PQC encryption key pairs and signature key pairs; S2. A PQC algorithm cipher suite using the clean PQC algorithm is added to the client's cipher suite list and its priority is forcibly set to the top; S3. Quantum-resistant key negotiation is achieved by modifying the message structure in the handshake protocol to replace the SM2-based digital certificate with the clean PQC algorithm digital certificate. This invention, by introducing a clean PQC algorithm digital certificate and modifying the handshake protocol, can achieve quantum-resistant key negotiation and authentication, significantly improving communication security. Simultaneously, it is compatible with existing SSL VPN specifications, only extending PQC-related fields, thus reducing deployment costs.

Description

Technical Field

[0001] This invention relates to the field of network security technology, and specifically to an SSL VPN security gateway communication method based on post-quantum cryptography. Background Technology

[0002] The handshake protocol in the classic SSL VPN technical specification involves the following processes:

[0003] a) Exchange hello messages to negotiate cipher suites, exchange random numbers, and decide whether to reuse the session;

[0004] b) Exchange necessary parameters and negotiate the pre-master key;

[0005] c) Exchange certificates or IBC information to verify the other party;

[0006] d) Generate the master key using the pre-master key and the exchanged random numbers;

[0007] e) Provide security parameters to the recording layer;

[0008] f) Verify the consistency of the security parameters calculated by both parties, and the authenticity and completeness of the handshake process.

[0009] like Figure 1 As shown, the client sends a "client hello" message to the server. The server should respond with a "server hello" message; otherwise, a fatal error is generated and the connection is closed. The client and server hello messages are used by the client and server to negotiate SM2-based cryptographic algorithms and determine secure transmission capabilities, including protocol version, session identifier, cipher suite attributes, and to generate and exchange random numbers. Following the client and server hello messages is the authentication and key exchange process, including server certificate and server key exchange, and client certificate and client key exchange.

[0010] After sending the hello message, the server sends its own certificate message, a server-side key exchange message, and if it needs to verify the client's identity, it sends a certificate request message to the client, followed by a server-side hello completion message, indicating that the hello message phase is complete and the server awaits a response from the client. If the server sent a certificate request message, the client should return a certificate message. The client then sends a key exchange message, the content of which depends on the key exchange algorithm negotiated between the client's hello message and the server's hello message. If the client sent a certificate message, it should also send a digitally signed certificate verification message for the server to verify the client's identity.

[0011] Current SSL VPN systems commonly employ public-key algorithms such as SM2 and RSA for key negotiation. However, with the development of quantum computing technology, these algorithms face the risk of being cracked. While post-quantum cryptography (PQC) technology has made theoretical progress, its application in practical network devices such as SSL VPNs still faces challenges such as protocol compatibility and performance optimization. Furthermore, existing technologies, such as the national cryptographic algorithms defined in GM / T 0024 "SSL VPN Technical Specification," have not yet considered the requirements for quantum computing resistance. Summary of the Invention

[0012] The technical problem to be solved by the present invention is to provide an SSL VPN security gateway communication method based on post-quantum cryptography technology, so as to realize key negotiation and identity authentication resistant to quantum attacks and significantly improve communication security.

[0013] To solve the above-mentioned technical problems, the technical solution adopted by the present invention is as follows.

[0014] A communication method for an SSL VPN security gateway based on post-quantum cryptography technology includes the following steps:

[0015] S1. Configure clean PQC algorithm digital certificates containing PQC encryption key pairs and signature key pairs on both the client and server sides.

[0016] S2. Add a PQC algorithm cipher suite that uses the pure PQC algorithm to the client's cipher suite list and force it to be at the top of the priority list;

[0017] S3. Quantum-resistant key negotiation is achieved by modifying the message structure in the handshake protocol to replace the SM2 cryptographic algorithm-based digital certificate with a pure PQC algorithm digital certificate.

[0018] Preferably, the pure PQC algorithm in step S1 includes, but is not limited to, the key encapsulation algorithm based on lattice cryptography: ML-KEM, and the digital signature algorithm based on lattice cryptography: ML-DSA; the pure PQC algorithm digital certificate is a standard X.509 format certificate, including a pure PQC signature certificate and a pure PQC encryption certificate; the pure PQC algorithm digital certificate uses a new OID to identify the PQC algorithm, the public key value uses the PQC public key value, and the signature value uses the PQC signature value.

[0019] Preferably, in step S2, the PQC algorithm cryptographic suite is MLDSA_MLKEM_SM4_SM3, where MLDSA_MLKEM is a key exchange algorithm combining the ML-DSA algorithm and the ML-KEM algorithm, SM4 is an encryption algorithm, and SM3 is a verification algorithm.

[0020] Preferably, step S3 specifically includes:

[0021] S31. The client sends a client hello message containing a PQC algorithm cipher suite to the server;

[0022] S32. The server responds to the client with a hello message and selects a PQC algorithm cipher suite;

[0023] S33. Exchange certificate messages containing a clean PQC signed certificate and a clean PQC encrypted certificate, and verify the server's identity using a server key exchange message signed with the PQC algorithm; the client uses the server's PQC encrypted key to encrypt the public key into a pre-master key to generate a client key exchange message;

[0024] S34. The server uses the client's PQC signing key to verify whether the client is the legitimate holder of the certificate;

[0025] S35. Verify the integrity of key exchange and handshake.

[0026] Preferably, step S33 specifically includes:

[0027] S331. The server sends a server certificate message to the client. The server certificate message includes the server's clean PQC signing certificate and clean PQC encryption certificate, with the clean PQC signing certificate first and the clean PQC encryption certificate second.

[0028] S332. The server sends a server key exchange message to the client. The server key exchange message adds a PQC algorithm enumeration type and the corresponding message structure, and performs PQC algorithm signature on the random numbers of both parties and the server's clean PQC encryption certificate.

[0029] S333. The server sends a certificate request message to the client, requesting the client to send its own clean PQC digital certificate;

[0030] S334. The server sends a server-side hello completion message to the client, and the client verifies the server certificate and the parameters of the server-side hello message;

[0031] S335. The client sends a client certificate message to the server based on the selected PQC algorithm cipher suite and the certificate type in the server certificate request message. The client certificate message includes the client's clean PQC signing certificate and clean PQC encryption certificate, and the structure is the same as the server certificate message structure.

[0032] S336. The client uses the server-side PQC signing key obtained from the server-side clean PQC signing certificate to verify the public key, and sends a client key exchange message after successful verification; after receiving the client key exchange message, the server decrypts the pre-master key to obtain the plaintext of the pre-master key.

[0033] Preferably, in step S32, if the server cannot select a matching PQC algorithm cipher suite, it returns a handshake failure alarm message (handshake_failure) to the client and closes the connection; in step S334, if the client cannot accept the server's hello message parameter, it sends a handshake_failure alarm message to the server.

[0034] Preferably, the process in step S336 where the client uses the server's PQC encryption key to encrypt the pre-master key using the public key includes:

[0035] The client first uses the ML-KEM algorithm to generate the shared key Ski and the ciphertext Skiic;

[0036] The preMaster key PreMasterSecret is then encrypted using a symmetric algorithm to obtain the preMaster key ciphertext EncPreMasterSecret;

[0037] Finally, the pre-master key ciphertext EncPreMasterSecret is concatenated with the ciphertext Skic to obtain the PQC encrypted ciphertext PQCEncryptedPreMasterSecret=EncPreMasterSecret|Skic.

[0038] Preferably, the process of the server obtaining the plaintext of the pre-master key in step S336 includes:

[0039] The server first intercepts the PQC encrypted ciphertext and separates Skic and EncPreMasterSecret from PQCEncryptedPreMasterSecret;

[0040] Then use the server-side PQC encryption key to decrypt the private key to obtain Ski;

[0041] Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

[0042] Due to the adoption of the above technical solutions, the technical progress achieved by this invention is as follows.

[0043] This invention introduces a pure PQC algorithm digital certificate and modifies the handshake protocol to achieve quantum-resistant key negotiation and identity authentication, significantly improving communication security. At the same time, it is compatible with existing SSL VPN specifications, only extending PQC-related fields and reducing deployment costs. Attached Figure Description

[0044] Figure 1A flowchart of the handshake message in the existing classic SSL VPN technical specification;

[0045] Figure 2 This is an architecture diagram of an SSL VPN security gateway system based on post-quantum cryptography technology that applies the present invention. Detailed Implementation

[0046] The present invention will now be described in further detail with reference to the accompanying drawings and specific embodiments.

[0047] A communication method for an SSL VPN security gateway based on post-quantum cryptography technology includes the following steps:

[0048] S1. Configure clean PQC algorithm digital certificates containing PQC encryption key pairs and signature key pairs on both the client and server sides.

[0049] The pure PQC algorithm includes, but is not limited to, the ML-KEM key encapsulation algorithm based on lattice cryptography, and the ML-DSA digital signature algorithm based on lattice cryptography. The pure PQC algorithm digital certificate is a standard X.509 format certificate, including a pure PQC signature certificate and a pure PQC encryption certificate. The pure PQC algorithm digital certificate uses a new OID to identify the PQC algorithm, uses the PQC public key value, and uses the PQC signature value.

[0050] According to GM / T 0024 "SSL VPN Technical Specification", the key handshake protocol based on the PQC algorithm uses a clean PQC algorithm digital certificate.

[0051] The two parties involved in the handshake protocol, the client (Initiator) and the server (Responder), each need a clean PQC digital certificate and the corresponding PQC encryption key pair (private key) and PQC signing key pair (private key), respectively. The client's PQC encryption key pair public key is contained in the encryption digital certificate and is denoted as EncPubKey. I The private key of the PQC encryption key pair is denoted as EncPriKey. I The client's PQC signing key pair public key is contained in the signing digital certificate, denoted as SignPubKey. I The PQC signature key pair private key is denoted as SignPriKey. I The server-side PQC encryption key pair public key is contained in the encryption digital certificate, denoted as EncPubKey. R The private key of the PQC encryption key pair is denoted as EncPriKey. R The server-side PQC signing key pair public key is contained in the signing digital certificate, denoted as SignPubKey. RThe PQC signature key pair private key is denoted as SignPriKey. R .

[0052] S2. Add a PQC algorithm cipher suite that uses the pure PQC algorithm to the client's cipher suite list and force it to be at the top of the priority list.

[0053] The PQC algorithm cryptographic suite is MLDSA_MLKEM_SM4_SM3, where MLDSA_MLKEM is a key exchange algorithm combining the ML-DSA and ML-KEM algorithms, SM4 is the encryption algorithm, and SM3 is the verification algorithm.

[0054] S3. Achieve quantum-resistant key negotiation by modifying the message structure in the handshake protocol to replace the SM2-based cryptographic algorithm digital certificate with a pure PQC algorithm digital certificate. Specifically, this includes:

[0055] S31. The client sends a "Client Hello" message containing a PQC algorithm cipher suite to the server.

[0056] ClientHello message: This message is the client hello message, which is the first message in the handshake protocol.

[0057] After sending a client-side hello message, the client waits for the server to respond with a server-side hello message.

[0058] The client-side hello message structure is defined as follows:

[0059] struct{

[0060] ProtocolVersion client_version;

[0061] Random random;

[0062] SessionID (session _id);

[0063] CipherSuite cipher_suites<2..2^6-1>;

[0064] CompressionMethod compression_methods<1..2^8-1>;

[0065] ClientHello;

[0066] Here, cipher_suites is a list of cipher suites supported by the client. The client should arrange the cipher suites in order of priority, with the highest priority cipher suite listed first. If the session identifier field is not empty, this field should at least include the cipher suites used by the sessions that will be reused.

[0067] The cipher suite is defined as follows:

[0068] uint8 CipherSuite[2];

[0069] Each cipher suite includes a key exchange algorithm, an encryption algorithm, and a verification algorithm. The server will select a matching cipher suite from the list. If no matching cipher suite is found, it should return a handshake failure alert message (handshake_failure) and close the connection.

[0070] The list of cipher suites needs to include PQC algorithm cipher suites, as follows:

[0071] name Key exchange encryption check value MLDSA_MLKEM_SM4_SM3 MLDSA_MLKEM SM4 SM3 {0xe0,0x61}

[0072] For fields in the message structure that have not been modified, this document will not elaborate further; please refer to GM / T 0024 "SSL VPN Technical Specification".

[0073] S32. The server responds to the client with a hello message and selects a PQC algorithm cipher suite.

[0074] ServerHello message: This message is the server-side hello message.

[0075] If a matching cipher suite can be found in the client's hello message, the server sends this message as a response to the client's hello message. If no matching cipher suite is found, the server will respond with a handshake_failure alert message.

[0076] The server-side hello message structure is defined as follows:

[0077] struct{

[0078] ProtocolVersion server_version;

[0079] Random random;

[0080] SessionID (session _id);

[0081] CipherSuite cipher_suite;

[0082] CompressionMethod compression_method;

[0083] ServerHello;

[0084] Here, `cipher_suite` is a cipher suite selected by the server from the client's hello message, and for this method, the selected cipher suite is a PQC algorithm cipher suite. For reused sessions, this field stores the cipher suite used in the reused session.

[0085] S33. Exchange certificate messages containing a clean PQC signed certificate and a clean PQC encrypted certificate, and verify the server's identity using a server-side key exchange message signed with the PQC algorithm; the client uses the server's PQC encryption key to encrypt the public key into a pre-master key to generate a client-side key exchange message. Specifically, this includes:

[0086] S331. The server sends a server certificate message to the client. The server certificate message includes a clean PQC signing certificate and a clean PQC encryption certificate, with the clean PQC signing certificate first and the clean PQC encryption certificate second.

[0087] Server Certificate message: This message is a server certificate message.

[0088] The server should send a server certificate message to the client, which always follows the server's hello message. When the selected cipher suite uses the clean PQC algorithm, this message contains the server's clean PQC signing certificate and clean PQC encryption certificate, and the digital certificate is in standard X.509 format, using the new OID to identify the PQC algorithm.

[0089] The certificate message structure is as follows:

[0090] opaque ASN.1Cert<1..2^24-1>;

[0091] struct {

[0092] ASN.1Cert certificate<0..2^24-1>;}Certificate;

[0093] certificate

[0094] It is important to note that for server-side certificates: the clean PQC signing certificate comes first, followed by the clean PQC encryption certificate.

[0095] S332. The server sends a server key exchange message to the client. The server key exchange message adds a PQC algorithm enumeration type and the corresponding message structure, and performs PQC algorithm signatures on the random numbers of both parties and the server's clean PQC encryption certificate.

[0096] ServerKeyExchange message: This message is a server-side key exchange message. The information conveyed in this message is used by the client to calculate and generate a 48-byte pre-master key.

[0097] The server-side key exchange message now includes a new PQC algorithm enumeration type and its corresponding message structure. The server-side key exchange message structure is defined as follows:

[0098] enum(ECDHE,ECC,IBSDH,IBC,RSA,PQC}KeyExchangeAlgorit;

[0099] struct{

[0100] select (KeyExchangeAlgorithm)(

[0101] case ECDHE:

[0102] ServerECDHEParams params;

[0103] digitally-signed struct {

[0104] opaque client_random

[32] ;

[0105] opaque server_random

[32] ;

[0106] ServerECDHEParams params;

[0107] }signed_params;

[0108] case ECC:

[0109] digitally-signed struct {

[0110] opaque client_random

[32] ;

[0111] opaque server_random

[32] ;

[0112] opaque ASN.1Cert(1..2^24-1);

[0113] }signed_params;

[0114] case IBSDH:

[0115] ServerIBSDHParams params;

[0116] digitally-signed struct{

[0117] opaque client_random

[32] ;

[0118] opaque server_random

[32] ;

[0119] ServerIBSDHParams params;

[0120] }signed_params;

[0121] case IBC:

[0122] digitally-signed struct{

[0123] opaque client_random

[32] ;

[0124] opaque server_random

[32] ;

[0125] opaque ibc_id;

[0126] }signed_params;

[0127] case RSA:

[0128] digitally-signed struet {

[0129] opaque client_random

[32] ;

[0130] opaque server_random

[32] ;

[0131] opaque ASN.1Cert;

[0132] }signed _params;

[0133] case PQC:

[0134] digitally-signed struct {

[0135] opaque client_random

[32] ;

[0136] opaque server_random

[32] ;

[0137] opaque ASN.1Cert(1..2^24-1);

[0138] }signed_params;

[0139] }

[0140] ServerKeyExchange;

[0141] When the key exchange method is the pure PQC algorithm, signed_params is the server's signature of the random numbers from both parties and the server's encryption certificate. The server's calculation formula is as follows:

[0142] signed_params=PQC_SecKey_Sign(client_random|server_random|CERT_enc_r_b, SignPriKey R )

[0143] Wherein, PQC_SecKey_Sign represents the PQC private key signing method; client_random is a random number generated by the client; server_random is a random number generated by the server; and CERT_enc_r_b is a derived value of the server's PQC encryption certificate CERT_enc_r.

[0144] In the subsequent step S336, the client uses the signing public key obtained from the server's signing certificate to verify the signature, calculated as follows:

[0145] PQC_SecKey_Verify(signed_params, client_random|server_random|

[0146] CERT_enc_r_b, SignPubKey R )

[0147] After successful client verification, a client key exchange message is sent.

[0148] S333. The server sends a certificate request message to the client, requesting the client to send its own clean PQC digital certificate.

[0149] CertificateRequest message: This message is a certificate request message.

[0150] If the server requires client authentication, this message should be sent, requesting the client to send its own certificate.

[0151] This message follows immediately after the server-side key exchange message.

[0152] The structure of the certificate request message is defined as follows:

[0153] struct{

[0154] ClientCertificateType certificate_types<l..2^8-1>

[0155] DistinguishedName certificate_authorities<0..2^16-1>;

[0156] CertificateRequest;

[0157] Among them, certificate_types is a list of certificate types that the client is required to provide. A new type, pqc_sign, has been added to represent a clean PQC digital certificate.

[0158] enum{

[0159] rsa_sign(1),ecdsa_sign(64),ibc_params(80),pqc_sign(96),(255)

[0160] ClientCertificateType;

[0161] S334. The server sends a "Server Hello" completion message to the client, and the client verifies the server certificate and the parameters of the "Server Hello" message.

[0162] Server Hello Done message: This message indicates that the server has completed the hello process.

[0163] This indicates that the hello message phase of the handshake process is complete. After sending this message, the server will wait for a response from the client.

[0164] After receiving the hello completion message from the server, the client should verify the validity of the server's certificate and check if the parameters of the server's hello message are acceptable. If acceptable, the client continues the handshake process; otherwise, it sends a handshake_failure fatal alarm.

[0165] The server-side hello completion message structure is as follows:

[0166] struct {} ServerHelloDone;

[0167] S335. The client sends a client certificate message to the server based on the selected PQC algorithm cipher suite and the certificate type in the server certificate request message. The client certificate message includes the client's clean PQC signing certificate and clean PQC encryption certificate, and its structure is the same as that of the server certificate message.

[0168] Client Certificate Message: This message is a client certificate message.

[0169] If the server requests a certificate from the client, the client should subsequently send this message. Based on the selected PQC algorithm cipher suite and the pqc_sign certificate type in the server's certificate request message, the client sends the corresponding clean PQC signing certificate and clean PQC encryption certificate.

[0170] The structure of the client certificate message is the same as the structure defined for the server certificate message.

[0171] S336. The client uses the server-side PQC signing key obtained from the server's clean PQC signing certificate to verify the public key, and sends a client key exchange message after successful verification; after receiving the client key exchange message, the server decrypts the pre-master key to obtain the plaintext of the pre-master key.

[0172] ClientKeyExchange message: This message is a client key exchange message.

[0173] If the server requests a certificate from the client, this message follows immediately after the client certificate message; otherwise, this message is the first message sent by the client after receiving the server's "hello completion" message.

[0174] If the key exchange algorithm uses the PQC algorithm, this message contains a pre-master key, which is generated by the client and encrypted using the server's public key. When the server receives the encrypted pre-master key, it decrypts it using the corresponding private key to obtain the plaintext of the pre-master key.

[0175] The client key exchange message structure is defined as follows:

[0176] struct{

[0177] select(KeyExchangeAlgorithm)(

[0178] case ECDHE:

[0179] Opaque ClientECDHEParams<1..2^16-1>;

[0180] case IBSDH:

[0181] Opaque ClientIBSDHParams<1..2^16-1>;

[0182] case ECC:

[0183] opaque ECCEncryptedPreMasterSecret<0..2^16-1>;

[0184] case IBC:

[0185] Opaque IBCEncryptedPreMasterSecret<0..2^16-1>;

[0186] case RSA:

[0187] Opaque RSAEncryptedPreMasterSecret<0..2^16-1>;

[0188] case PQC:

[0189] Opaque PQCEncryptedPreMasterSecret<0..2^16-1>;

[0190] } exchange_keys;

[0191] ClientKeyExchange;

[0192] PQCEncryptedPreMasterSecret:

[0193] When using the PQC encryption algorithm, the public key is encrypted with the server-side PQC encryption key to create a pre-master key.

[0194] The data structure of the pre-master key is as follows:

[0195] struct {

[0196] ProtocolVersion client_version ;

[0197] opaque random

[46] ;

[0198] PreMasterSecret;

[0199] in:

[0200] 1) client_version:

[0201] The version number supported by the client. The server needs to check if this value matches the value sent in the client's Hello message.

[0202] 2) random:

[0203] A 46-byte random number.

[0204] The process by which the client uses the server's PQC encryption key to encrypt the pre-master key using the public key includes:

[0205] First, the shared key Ski and ciphertext Skic are calculated using the ML-KEM algorithm; then, the pre-master key PreMasterSecret is encrypted using a symmetric algorithm to obtain the pre-master key ciphertext EncPreMasterSecret; finally, the pre-master key ciphertext EncPreMasterSecret is concatenated with the ciphertext Skic to obtain the PQC encrypted ciphertext PQCEncryptedPreMasterSecret.

[0206] Skic=PQC_PubKey_Enc(Ski, EncPubKey R )

[0207] EncPreMasterSecret=Symmetric_Encrypt(PreMasterSecret,Ski)

[0208] PQCEncryptedPreMasterSecret=EncPreMasterSecret|Skic

[0209] Symmetric_Encrypt is the SM4 algorithm.

[0210] The process by which the server obtains the plaintext of the pre-master key includes:

[0211] The server first intercepts the PQC encrypted ciphertext and separates Skic and EncPreMasterSecret from PQCEncryptedPreMasterSecret;

[0212] Then use the server-side PQC encryption key to decrypt the private key to obtain Ski;

[0213] Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

[0214] Ski=PQC_PubKey_Dec(Skic, EncPriKey R )

[0215] PreMasterSecret=Symmetric_Decrypt(EncPreMasterSecret,Ski).

[0216] S34. The server uses the client's PQC signing key to verify whether the client is the legitimate holder of the certificate.

[0217] CertificateVerify message: This message is for certificate verification.

[0218] This message is used to verify whether the client is the legitimate holder of the certificate. It is sent only when the ClientCertificate message is sent, immediately following the client key exchange message.

[0219] The data structure of the certificate verification message is as follows:

[0220] struct {

[0221] Signature signature;

[0222] CertificateVerify;

[0223] in:

[0224] The structure of the Signature is as follows, with the addition of the pqc_sm3 enumeration type and message structure:

[0225] enum { rsa_shal,rsa_sm3,ecc_sm3,ibs_sm3,pqc_sm3} SignatureAlgorithm;

[0226] struct {

[0227] select (SignatureAlgorithm){

[0228] case rsa_shal:

[0229] digitally-signed struct {

[0230] opaque shal_hash

[20] ;

[0231] };

[0232] case rsa_sm3:

[0233] digitally-signed struct {

[0234] opaque sm3_hash

[32] ;

[0235] };

[0236] case ecc_sm3:

[0237] digitally-signed struct {

[0238] opaque sm3_hash

[32] ;

[0239] };

[0240] case ibs_sm3:

[0241] digitally-signed struct {

[0242] opaque sm3_hash

[32] ;

[0243] };

[0244] case pqc_sm3:

[0245] digitally-signed struct {

[0246] opaque sm3_hash

[32] ;

[0247] };

[0248] }

[0249] Signature:

[0250] The SM3 calculation covers all handshake-related messages from the client's hello message up to this message (excluding this message itself), including the type and length fields of the handshake messages. This is in accordance with the SSL / VPN technical specification.

[0251] Client-side calculation process:

[0252] Signature=PQC_SecKey_Sign(SM3(Handshake),SignPriKey I )

[0253] The server uses the client's signature public key to verify the signature.

[0254] S35. Verify the integrity of key exchange and handshake.

[0255] Finished message: This message marks the end of the handshake.

[0256] Both the server and the client send this message after the password specification change message to verify whether the key exchange process was successful and to check the integrity of the handshake process.

[0257] This message is protected using the algorithm and key negotiated during this handshake process.

[0258] The recipient of this message must verify the integrity of its content. Once one party sends a handshake end message and receives and verifies the other party's handshake end message, the connection can be used for secure data transmission.

[0259] The handshake end message data structure is as follows:

[0260] struct {

[0261] opaque verify_data

[12] ;

[0262] Finished;

[0263] in:

[0264] `verify_data` is the verification data, which is generated as follows:

[0265] PRF(master_secret, finished_label, SM3(handshake_messages)) [o..11].

[0266] In the expression:

[0267] a) finished_label:

[0268] For a client-sent end message, the label is the string "client finished". For a server-sent end message, the label is the string "server finished".

[0269] b) Handshake_messages:

[0270] This refers to all handshake-related messages from the client's Hello message up to this message (excluding this message and password specification change messages), including the type and length fields of the handshake messages.

[0271] After the handshake protocol ends, the initiator and the responder respectively use the pre-master key to calculate the master key and working key, and the usage method shall be performed in accordance with the requirements of the GM / T 0024 standard specification.

[0272] An SSL VPN security gateway system based on post-quantum cryptography technology is disclosed. This system utilizes a communication method based on post-quantum cryptography and represents an upgrade of existing standard SSL VPN security gateways. The upgraded functions include: a PQC-based handshake protocol and PQC digital certificate import / export functionality. The PQC-based handshake protocol primarily replaces the public-key algorithm in existing technical specifications with the PQC algorithm and replaces the SM2-based digital certificate with a clean PQC digital certificate. The PQC digital certificate import / export function imports the PQC digital certificate and its associated private key into the PQC SSL VPN security gateway for PQC-based key negotiation. Figure 2 As shown, it includes a database module, a cryptographic module, a device management service, an SSL VPN module, and a key negotiation module. The output of the database module is connected to the input of the device management service; the output of the cryptographic module is connected to the inputs of the device management service, the SSL VPN module, and the key negotiation module, respectively; the output of the key negotiation module is connected to the input of the SSL VPN module; and the output of the SSL VPN module is connected to the input of the device management service.

[0273] The database module is a data storage module used to store data generated by the management system.

[0274] The cryptographic module includes classical cryptographic algorithms and post-quantum cryptographic algorithms. The classical cryptographic algorithms are used for classical static key management and the logical implementation of classical cryptographic algorithms. The post-quantum cryptographic algorithms are used to implement post-quantum cryptographic algorithms, and for the storage and use of post-quantum keys.

[0275] The device management module is a human-machine interface module used to manage the SSL VPN security gateway's parameters, enabled functions, and access roles. It connects to the database module, storing data generated during operations. It also connects to the cryptography module, providing both classical and post-quantum cryptographic algorithms for the device management functionality.

[0276] The SSL VPN module is an upgrade based on an open-source project, primarily used to establish secure encrypted communication tunnels over public networks. Its core functions include remote access (such as secure employee connections to the company intranet) and site-to-site interconnection (such as cross-regional network communication). It supports TCP / UDP protocols, using UDP by default for improved efficiency, and can stably penetrate NAT and firewall environments. Data encapsulation is achieved through virtual network interface cards (TUN / TAP modes). TUN mode handles IP layer data, while TAP mode supports full Ethernet frame transmission, adapting to different scenario requirements.

[0277] The key negotiation module implements the handshake protocol, completing key negotiation and certificate verification. Compared to standard SSL VPNs, it replaces the original SM2 national cryptographic algorithm with the PQC algorithm, which improves the security of the SSL VPN key negotiation process while maintaining compatibility with SSL VPN protocol specifications, and also possesses quantum resistance.

Claims

1. A SSL VPN security gateway communication method based on post-quantum cryptography technology, characterized in that: Includes the following steps: S1. Configure clean PQC algorithm digital certificates containing PQC encryption key pairs and signature key pairs on both the client and server sides. S2. Add a PQC algorithm cipher suite that uses the pure PQC algorithm to the client's cipher suite list and force it to be at the top of the priority list; S3. Quantum-resistant key negotiation is achieved by modifying the message structure in the handshake protocol to replace the SM2 cryptographic algorithm-based digital certificate with a pure PQC algorithm digital certificate. Step S3 specifically includes: S31. The client sends a client hello message containing a PQC algorithm cipher suite to the server; S32. The server responds to the client with a hello message and selects a PQC algorithm cipher suite; S33. Exchange certificate messages containing a clean PQC signed certificate and a clean PQC encrypted certificate, and verify the server's identity using a server key exchange message signed with the PQC algorithm; the client uses the server's PQC encrypted key to encrypt the public key into a pre-master key to generate a client key exchange message; Step S33 specifically includes: S331. The server sends a server certificate message to the client. The server certificate message includes the server's clean PQC signing certificate and clean PQC encryption certificate, with the clean PQC signing certificate first and the clean PQC encryption certificate second. S332. The server sends a server key exchange message to the client. The server key exchange message adds a PQC algorithm enumeration type and the corresponding message structure, and performs PQC algorithm signature on the random numbers of both parties and the server's clean PQC encryption certificate. S333. The server sends a certificate request message to the client, requesting the client to send its own clean PQC digital certificate; S334. The server sends a server-side hello completion message to the client, and the client verifies the server certificate and the parameters of the server-side hello message; S335. The client sends a client certificate message to the server based on the selected PQC algorithm cipher suite and the certificate type in the server certificate request message. The client certificate message includes the client's clean PQC signing certificate and clean PQC encryption certificate, and the structure is the same as the server certificate message structure. S336. The client uses the server-side PQC signing key obtained from the server-side clean PQC signing certificate to verify the public key, and sends a client key exchange message after successful verification; after receiving the client key exchange message, the server decrypts the pre-master key to obtain the plaintext of the pre-master key. S34. The server uses the client's PQC signing key to verify whether the client is the legitimate holder of the certificate; S35. Verify the integrity of key exchange and handshake.

2. The SSL VPN security gateway communication method based on post-quantum cryptography according to claim 1, characterized in that: The pure PQC algorithm in step S1 includes, but is not limited to, the key encapsulation algorithm based on lattice cryptography: ML-KEM, and the digital signature algorithm based on lattice cryptography: ML-DSA; the pure PQC algorithm digital certificate is a standard X.509 format certificate, including a pure PQC signature certificate and a pure PQC encryption certificate; the pure PQC algorithm digital certificate uses a new OID to identify the PQC algorithm, the public key value uses the PQC public key value, and the signature value uses the PQC signature value.

3. The SSL VPN security gateway communication method based on post-quantum cryptography according to claim 2, characterized in that: In step S2, the PQC algorithm cryptographic suite is MLDSA_MLKEM_SM4_SM3, where MLDSA_MLKEM is a key exchange algorithm combining the ML-DSA algorithm and the ML-KEM algorithm, SM4 is an encryption algorithm, and SM3 is a verification algorithm.

4. The SSL VPN security gateway communication method based on post-quantum cryptography according to claim 1, characterized in that: In step S32, if the server cannot select a matching PQC algorithm cipher suite, it returns a handshake failure alarm message (handshake_failure) to the client and closes the connection. In step S334, if the client cannot accept the server's hello message parameter, it sends a handshake_failure alarm message to the server.

5. The SSL VPN security gateway communication method based on post-quantum cryptography according to claim 1, characterized in that: The process in step S336 where the client uses the server's PQC encryption key to encrypt the pre-master key using the public key includes: The client first uses the ML-KEM algorithm to generate the shared key Ski and the ciphertext Skiic; The preMaster key PreMasterSecret is then encrypted using a symmetric algorithm to obtain the preMaster key ciphertext EncPreMasterSecret; Finally, the pre-master key ciphertext EncPreMasterSecret is concatenated with the ciphertext Skic to obtain the PQC encrypted ciphertext PQCEncryptedPreMasterSecret=EncPreMasterSecret|Skic.

6. The SSL VPN security gateway communication method based on post-quantum cryptography according to claim 5, characterized in that: The process of the server obtaining the plaintext of the pre-master key in step S336 includes: The server first intercepts the PQC encrypted ciphertext and separates Skic and EncPreMasterSecret from PQCEncryptedPreMasterSecret; Then use the server-side PQC encryption key to decrypt the private key to obtain Ski; Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

Images