SSL VPN security gateway communication method based on post quantum cryptography

Abstract

The invention discloses an SSL VPN security gateway communication method based on a post quantum cryptography technology. The method comprises the following steps: S1, a client and a server respectively configure a pure PQC algorithm digital certificate containing a PQC encryption key pair and a signature key pair; s2, a PQC algorithm password suite using a pure PQC algorithm is newly added in a password suite list of the client, and the priority of the PQC algorithm password suite is forcibly set up; and S3, transforming a message structure in a handshake protocol to replace a digital certificate based on an SM2 cryptographic algorithm with a pure PQC algorithm digital certificate to realize anti-quantum key negotiation. By introducing a pure PQC algorithm digital certificate and transforming a handshake protocol, quantum attack resistant key negotiation and identity authentication can be realized, the communication security is remarkably improved, the existing SSL VPN specification is compatible, only PQC related fields are expanded, and the deployment cost is reduced.

Description

Technical Field

[0001] The present invention relates to the field of network security technology, and in particular to an SSL VPN security gateway communication method based on post-quantum cryptography technology. Background Art

[0002] The handshake protocol in the classic SSL VPN technical specification involves the following process: a) Exchange hello messages to negotiate cipher suites, exchange random numbers, and decide whether to reuse the session; b) Exchange necessary parameters and negotiate the pre-master key; c) Exchange certificates or IBC information to verify the other party; d) Generate the master key using the pre-master key and the exchanged random number; e) Provide security parameters to the record layer; f) Verify the consistency of the security parameters calculated by both parties and the authenticity and integrity of the handshake process.

[0003] like Figure 1 As shown in the figure, 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 terminated. The client hello and server hello messages are used by the client and server to negotiate the SM2-based cryptographic algorithm, determine secure transmission capabilities, including the protocol version, session identifier, and cipher suite attributes, and generate and exchange random numbers. Following the client hello and server hello messages, the authentication and key exchange process begins, including the server certificate and server key exchange, and the client certificate and client key exchange.

[0004] After the server sends its Hello message, it sends its own Certificate message and a Server Key Exchange message. If the server needs to verify the client's identity, it sends a Certificate Request message to the client, followed by a Server Hello Completion message, indicating the end of the Hello message phase and awaiting a response from the client. If the server sends a Certificate Request message, the client responds with 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 and server Hello messages. If the client sends a Certificate message, it also sends a digitally signed Certificate Verification message for the server to verify the client's identity.

[0005] Current SSL VPN systems commonly use public key algorithms such as SM2 and RSA for key negotiation. However, with the development of quantum computing, these algorithms are at risk of being cracked. While theoretical progress has been made in post-quantum cryptography (PQC), its application in practical network equipment like SSL VPNs still faces challenges such as protocol compatibility and performance optimization. Furthermore, existing technologies, such as the national encryption algorithm scheme defined in GM / T 0024, the "SSL VPN Technical Specification," do not yet address the requirements for quantum computing resistance. Summary of the Invention

[0006] 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 to achieve key negotiation and identity authentication that is resistant to quantum attacks, thereby significantly improving communication security.

[0007] In order to solve the above technical problems, the technical solutions adopted by the present invention are as follows.

[0008] A SSL VPN security gateway communication method based on post-quantum cryptography technology, comprising the following steps: S1. The client and server are each configured with a pure PQC algorithm digital certificate containing a PQC encryption key pair and a signature key pair; S2. Add a PQC algorithm cipher suite that uses the pure PQC algorithm to the client's cipher suite list and force it to the top of the priority list. S3. Quantum-resistant key agreement is achieved by modifying the message structure in the handshake protocol to use pure PQC algorithm digital certificates instead of digital certificates based on the SM2 cryptographic algorithm.

[0009] Preferably, the pure PQC algorithm in step S1 includes but is not limited to a key encapsulation algorithm based on a lattice cryptographic mechanism: ML-KEM, and a digital signature algorithm based on a lattice cryptographic mechanism: 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.

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

[0011] Preferably, the step S3 specifically includes: S31. The client sends a client hello message containing the PQC algorithm cipher suite to the server; S32. The server responds to the client's hello message and selects the PQC algorithm cipher suite. S33 exchange certificate messages containing a clean PQC signature certificate and a clean PQC encryption certificate, and verify the server's identity through a server-side key exchange message signed by the PQC algorithm; the client uses the server-side PQC encryption key to encrypt the pre-master key to generate a client key exchange message; S34. The server uses the client's PQC signature key to authenticate the client as the legitimate holder of the certificate. S35. Verify key exchange and handshake integrity.

[0012] Preferably, the step S33 specifically includes: S331. The server sends a server certificate message to the client. The server certificate message includes a clean PQC signature certificate and a clean PQC encryption certificate on the server. The clean PQC signature certificate comes first, followed by a clean PQC encryption certificate. S332. The server sends a server key exchange message to the client. The server key exchange message adds a new PQC algorithm enumeration type and the corresponding message structure, and signs the random numbers of both parties and the server's pure PQC encryption certificate with the PQC algorithm. S333. The server sends a certificate request message to the client, requesting the client to send its own pure PQC digital certificate; S334. The server sends a server hello completion message to the client, and the client verifies the server certificate and server hello message parameters; 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 a clean PQC signature certificate and a clean PQC encryption certificate, and the structure is the same as the server certificate message structure. S336. The client verifies the public key using the server's PQC signature key obtained from the server's pure PQC signature certificate, and sends a client key exchange message after successful verification. After receiving the client key exchange message, the server decrypts the pre-master key and obtains the plaintext of the pre-master key.

[0013] 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 hello message parameters, it sends a handshake_failure alarm message to the server.

[0014] Preferably, the process of the client using the server's PQC encryption key to encrypt the pre-master key with the public key in step S336 includes: The client first uses the ML-KEM algorithm to generate the shared key Ski and ciphertext Skic; Then use the symmetric algorithm to encrypt the pre-master key PreMasterSecret to obtain the pre-master key ciphertext EncPreMasterSecret; Finally, the pre-master key ciphertext EncPreMasterSecret and the ciphertext Skic are concatenated to obtain the PQC encrypted ciphertext PQCEncryptedPreMasterSecret = EncPreMasterSecret | Skic.

[0015] Preferably, 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 the Skic and EncPreMasterSecret in PQCEncryptedPreMasterSecret; Then use the server-side PQC encryption key to decrypt the private key Skic to obtain Ski; Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

[0016] Due to the adoption of the above technical solution, the technical progress achieved by the present invention is as follows.

[0017] By introducing pure PQC algorithm digital certificates and modifying the handshake protocol, the present invention can achieve quantum attack-resistant key negotiation and identity authentication, significantly improving communication security. At the same time, it is compatible with existing SSL VPN specifications, only expanding PQC-related fields to reduce deployment costs. BRIEF DESCRIPTION OF THE DRAWINGS

[0018] Figure 1 This is the handshake message flow chart in the existing classic SSL VPN technical specifications; Figure 2 This is an architectural diagram of the SSL VPN security gateway system based on post-quantum cryptography technology that applies the present invention. DETAILED DESCRIPTION

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

[0020] A SSL VPN security gateway communication method based on post-quantum cryptography technology, comprising the following steps: S1. The client and server are respectively configured with a pure PQC algorithm digital certificate containing a PQC encryption key pair and a signature key pair.

[0021] The pure PQC algorithm includes but is not limited to the key encapsulation algorithm based on the lattice cryptography mechanism: ML-KEM, and the digital signature algorithm based on the lattice cryptography mechanism: 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.

[0022] Referring to GM / T 0024 "SSL VPN Technical Specifications", the key handshake protocol based on the PQC algorithm uses a pure PQC algorithm digital certificate.

[0023] The two parties involved in the handshake protocol: the client (Initiator) and the server (Responder) need to have a pure PQC digital certificate and the corresponding PQC encryption key pair private key and PQC signature key pair private key. The client's PQC encryption key pair public key is included in the encrypted digital certificate, recorded as EncPubKey I , the private key of the PQC encryption key pair is recorded as EncPriKey I ; The client's PQC signature key pair public key is included in the signature digital certificate, recorded as SignPubKey I , the private key of the PQC signature key pair is recorded as SignPriKey I ; The public key of the server's PQC encryption key pair is included in the encrypted digital certificate, recorded as EncPubKey R , the private key of the PQC encryption key pair is recorded as EncPriKey R ; The server's PQC signature key pair public key is included in the signature digital certificate, recorded as SignPubKey R , the private key of the PQC signature key pair is recorded as SignPriKey R .

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

[0025] The PQC algorithm cipher suite is MLDSA_MLKEM_SM4_SM3, where MLDSA_MLKEM is a key exchange algorithm that combines the ML-DSA algorithm with the ML-KEM algorithm, SM4 is the encryption algorithm, and SM3 is the verification algorithm.

[0026] S3. Quantum-resistant key negotiation is achieved by modifying the message structure in the handshake protocol to use pure PQC algorithm digital certificates instead of digital certificates based on the SM2 cryptographic algorithm. Specifically, this includes: S31. The client sends a client hello message containing the PQC algorithm cipher suite to the server.

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

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

[0029] The client hello message structure is defined as follows: struct{ ProtocolVersion client_version; Random random; SessionID session _id; CipherSuite cipher_suites<2..2^6-1>; CompressionMethod compression_methods<1..2^8-1>; }ClientHello; Among them, 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 first. If the session identifier field is not empty, this field should at least contain the cipher suite used by the session to be reused.

[0030] The cipher suites are defined as follows: uint8 CipherSuite[2]; Each cipher suite consists of a key exchange algorithm, an encryption algorithm, and a verification algorithm. The server will select a matching cipher suite from the cipher suite list. If no matching cipher suite is found, the server will return a handshake failure alarm message, handshake_failure, and close the connection.

[0031] The PQC algorithm cipher suite needs to be added to the cipher suite list as follows: name Key Exchange encryption check value MLDSA_MLKEM_SM4_SM3 MLDSA_MLKEM SM4 SM3 {0xe0,0x61} This document does not describe the unchanged fields in the message structure. Please refer to GM / T 0024 "SSL VPN Technical Specifications".

[0032] S32. The server responds to the client's hello message and selects the PQC algorithm cipher suite.

[0033] ServerHello message: This message is the server hello message.

[0034] If a matching cipher suite is found in the client hello message, the server sends this message as a reply to the client hello message. If no matching cipher suite is found, the server responds with a handshake_failure warning message.

[0035] The server-side hello message structure is defined as follows: struct{ ProtocolVersion server_version; Random random; SessionID session _id; CipherSuite cipher_suite; CompressionMethod compression_method; }ServerHello; Where cipher_suite is a cipher suite selected by the server from the client's hello message. For this method, the selected cipher suite is the PQC algorithm cipher suite. For reused sessions, this field stores the cipher suite used in the reused session.

[0036] S33. Exchange certificate messages containing a clean PQC signature certificate and a clean PQC encryption certificate, and verify the server's identity through a server-side key exchange message signed by the PQC algorithm; the client uses the server's PQC encryption key to encrypt the pre-master key with the public key to generate a client key exchange message. Specifically, this includes: S331. The server sends a server certificate message to the client. The server certificate message includes the server's pure PQC signature certificate and pure PQC encryption certificate, with the pure PQC signature certificate in front and the pure PQC encryption certificate in the back.

[0037] Server Certificate message: This message is the server certificate message.

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

[0039] The certificate message structure is as follows: opaque ASN.1Cert<1..2^24-1>; struct { ASN.1Cert certificate<0..2^24-1>;}Certificate; certificate It should be noted that the server certificate: the pure PQC signature certificate is in front and the pure PQC encryption certificate is in the back.

[0040] S332. The server sends a server key exchange message to the client. The server key exchange message adds the PQC algorithm enumeration type and the corresponding message structure, and signs the random numbers of both parties and the server's pure PQC encryption certificate with the PQC algorithm.

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

[0042] The server-side key exchange message adds the PQC algorithm enumeration type and the corresponding message structure. The server-side key exchange message structure is defined as follows: enum(ECDHE,ECC,IBSDH,IBC,RSA,PQC}KeyExchangeAlgorit; struct{ select (KeyExchangeAlgorithm)( case ECDHE: ServerECDHEParams params; digitally-signed struct { opaque client_random

[32] ; opaque server_random

[32] ; ServerECDHEParams params; }signed_params; case ECC: digitally-signed struct { opaque client_random

[32] ; opaque server_random

[32] ; opaque ASN.1Cert(1..2^24-1); }signed_params; case IBSDH: ServerIBSDHParams params; digitally-signed struct{ opaque client_random

[32] ; opaque server_random

[32] ; ServerIBSDHParams params; }signed_params; case IBC: digitally-signed struct{ opaque client_random

[32] ; opaque server_random

[32] ; opaque ibc_id; }signed_params; case RSA: digitally-signed struet { opaque client_random

[32] ; opaque server_random

[32] ; opaque ASN.1Cert; }signed _params; case PQC: digitally-signed struct { opaque client_random

[32] ; opaque server_random

[32] ; opaque ASN.1Cert(1..2^24-1); }signed_params; } }ServerKeyExchange; When the key exchange method is the pure PQC algorithm, signed_params is the server's signature on both random numbers and the server's encryption certificate. The server's calculation formula is as follows: signed_params=PQC_SecKey_Sign(client_random|server_random|CERT_enc_r_b, SignPriKey R ) Among them, PQC_SecKey_Sign represents the PQC private key signature method; client_random is the random number generated by the client; server_random is the random number generated by the server; CERT_enc_r_b is the derived value of the server-side PQC encryption certificate CERT_enc_r.

[0043] In the subsequent step S336, the client verifies the signature using the public key obtained from the server's signature certificate. The calculation formula is as follows: PQC_SecKey_Verify(signed_params, client_random|server_random| CERT_enc_r_b, SignPubKey R ) After successful client authentication, the client sends a client key exchange message.

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

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

[0046] If the server requires authentication of the client, it should send this message to ask the client to send its own certificate.

[0047] This message follows the server key exchange message.

[0048] The structure of the certificate request message is defined as follows: struct{ ClientCertificateType certificate_types<l..2^8-1> DistinguishedName certificate_authorities<0..2^16-1>; }CertificateRequest; Among them, certificate_types is a list of certificate types required by the client. The newly added pqc_sign type indicates a pure PQC digital certificate.

[0049] enum{ rsa_sign(1),ecdsa_sign(64),ibc_params(80),pqc_sign(96),(255) }ClientCertificateType; S334. The server sends a server hello completion message to the client, and the client verifies the server certificate and server hello message parameters.

[0050] Server Hello Done message: This message is the server hello completion message.

[0051] Indicates that the hello message phase of the handshake process is complete. After sending this message, the server will wait for the client's response message.

[0052] After receiving the server's hello completion message, the client should verify whether the server's certificate is valid and check whether the server's hello message parameters are acceptable. If acceptable, the client continues the handshake process; otherwise, a handshake_failure fatal alarm is sent.

[0053] The server-side hello completion message structure is as follows: struct {} ServerHelloDone; 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 pure PQC signature certificate and pure PQC encryption certificate, and the structure is the same as the server certificate message structure.

[0054] Client Certificate message: This message is the client certificate message.

[0055] If the server requests a client certificate, the client will then send this message. Based on the selected PQC algorithm cipher suite and the pqc_sign certificate type in the server certificate request message, the client sends the corresponding clean PQC signature certificate and clean PQC encryption certificate.

[0056] The structure of the Client Certificate message is the same as that defined for the Server Certificate message.

[0057] S336. The client uses the server's PQC signature key obtained from the server's pure PQC signature certificate to verify the public key, and sends a client key exchange message after the verification is successful; after receiving the client's key exchange message, the server decrypts the pre-master key and obtains the plaintext of the pre-master key.

[0058] ClientKeyExchange message: This message is the client key exchange message.

[0059] If the server requests a client certificate, this message follows the client certificate message. Otherwise, this message is the first message sent by the client after receiving the server's hello completion message.

[0060] If the key exchange algorithm uses the PQC algorithm, this message contains the 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 pre-master key.

[0061] The client key exchange message structure is defined as follows: struct{ select(KeyExchangeAlgorithm)( case ECDHE: Opaque ClientECDHEParams<1..2^16-1>; case IBSDH: Opaque ClientIBSDHParams<1..2^16-1>; case ECC: opaque ECCEncryptedPreMasterSecret<0..2^16-1>; case IBC: Opaque IBCEncryptedPreMasterSecret<0..2^16-1>; case RSA: Opaque RSAEncryptedPreMasterSecret<0..2^16-1>; case PQC: Opaque PQCEncryptedPreMasterSecret<0..2^16-1>; } exchange_keys; }ClientKeyExchange; PQCEncryptedPreMasterSecret: When using the PQC encryption algorithm, the server-side PQC encryption key is used to encrypt the pre-master key with the public key.

[0062] The data structure of the pre-master key is as follows: struct { ProtocolVersion client_version ; opaque random

[46] ; }PreMasterSecret; in: 1) client_version: The version number supported by the client. The server checks whether this value matches the value sent in the client Hello message.

[0063] 2) random: 46 bytes of random number.

[0064] The process of the client using the server's PQC encryption key to encrypt the pre-master secret key with the public key includes: First, use the ML-KEM algorithm to calculate the shared key Ski and the ciphertext Skic. Then use the symmetric algorithm to encrypt the pre-master key PreMasterSecret to obtain the pre-master key ciphertext EncPreMasterSecret. Finally, concatenate the pre-master key ciphertext EncPreMasterSecret and the ciphertext Skic to obtain the PQC encrypted ciphertext PQCEncryptedPreMasterSecret.

[0065] Skic=PQC_PubKey_Enc(Ski, EncPubKey R ) EncPreMasterSecret=Symmetric_Encrypt(PreMasterSecret,Ski) PQCEncryptedPreMasterSecret=EncPreMasterSecret|Skic Symmetric_Encrypt uses the SM4 algorithm.

[0066] The process of obtaining the plaintext pre-master key on the server includes: The server first intercepts the PQC encrypted ciphertext and separates the Skic and EncPreMasterSecret in PQCEncryptedPreMasterSecret; Then use the server-side PQC encryption key to decrypt the private key Skic to obtain Ski; Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

[0067] Ski=PQC_PubKey_Dec(Skic, EncPriKey R ) PreMasterSecret=Symmetric_Decrypt(EncPreMasterSecret,Ski).

[0068] S34. The server uses the client's PQC signature key to the public key to verify whether the client is the legal holder of the certificate.

[0069] CertificateVerify message: This message is a certificate verification message.

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

[0071] The data structure of the certificate verification message is as follows: struct { Signature signature; }CertificateVerify; in: The structure of Signature is as follows, with the newly added pqc_sm3 enumeration type and message structure: enum { rsa_shal,rsa_sm3,ecc_sm3,ibs_sm3,pqc_sm3} SignatureAlgorithm; struct { select (SignatureAlgorithm) { case rsa_shal: digitally-signed struct { opaque shal_hash

[20] ; }; case rsa_sm3: digitally-signed struct { opaque sm3_hash

[32] ; }; case ecc_sm3: digitally-signed struct { opaque sm3_hash

[32] ; }; case ibs_sm3: digitally-signed struct { opaque sm3_hash

[32] ; }; case pqc_sm3: digitally-signed struct { opaque sm3_hash

[32] ; }; } }Signature: The SM3 calculation covers all handshake-related messages from the client's hello message up to (but not including) this message (the encryption certificate must be included in the signature calculation), including the handshake message type and length fields. This is consistent with the SSL_VPN technical specification.

[0072] Client calculation process: Signature=PQC_SecKey_Sign(SM3(Handshake),SignPriKey I ) The server verifies the signature using the client's public key.

[0073] S35. Verify key exchange and handshake integrity.

[0074] Finished message: This message is the handshake completion message.

[0075] The server and client each send this message after a CipherSpecChange message to verify the success of the key exchange process and to check the integrity of the handshake process.

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

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

[0078] The handshake end message data structure is as follows: struct { opaque verify_data

[12] ; } Finished; in: verify_data is the verification data, which is generated as follows: PRF(master_secret, finished_label, SM3(handshake_messages)) [o..11].

[0079] In the expression: a) finished_label: For a finished message sent by a client, the tag is the string "client finished". For a server, the tag is the string "server finished".

[0080] b)handshake_messages: Refers to all handshake-related messages from the Client Hello message up to this message (excluding this message and the CipherSpecChange message), including the Type and Length fields of the handshake messages.

[0081] After the handshake protocol is completed, the initiator and responder use the pre-master key to calculate the master key and working key respectively, and the usage method is implemented in accordance with the requirements of the GM / T 0024 standard specification.

[0082] An SSL VPN security gateway system based on post-quantum cryptography technology is implemented based on an SSL VPN security gateway communication method based on post-quantum cryptography technology. It is an upgrade and transformation based on the existing standard SSL VPN security gateway. The upgraded functions include: a handshake protocol based on the PQC algorithm, and import and export functions of PQC digital certificates. The handshake protocol based on the PQC algorithm mainly uses the PQC algorithm to replace the public key algorithm in the existing technical specifications, and uses a pure PQC algorithm digital certificate to replace the digital certificate based on the SM2 cryptographic algorithm. The import and export function of the PQC digital certificate is mainly to import the PQC digital certificate and the corresponding private key into the PQC SSL VPN security gateway, so as to perform key negotiation based on the PQC algorithm. Combined with Figure 2 As shown, it includes a database module, a password module, a device management service, an SSL VPN module and a key negotiation module, wherein the output end of the database module is connected to the input end of the device management service; the output end of the password module is connected to the input ends of the device management service, the SSLVPN module and the key negotiation module respectively; the output end of the key negotiation module is connected to the input end of the SSL VPN module; and the output end of the SSL VPN module is connected to the input end of the device management service.

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

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

[0085] The device management service is a human-computer interaction module used to manage the SSL VPN security gateway's parameters, function enablement, and permissions. It connects to the database module to store data generated during operations. It also connects to the cryptography module to provide both classical and post-quantum cryptographic algorithms for the device management service.

[0086] The SSL VPN module, based on an open-source project, is primarily used to establish secure, encrypted communication tunnels over public networks. Its core functions include remote access (e.g., enabling employees to securely connect to the company intranet) and site-to-site connectivity (e.g., inter-regional network connectivity). It supports both TCP and UDP protocols, with UDP being the default for improved efficiency, and offers reliable traversal through NAT and firewall environments. Data encapsulation is achieved through virtual network adapters (TUN / TAP modes). TUN mode processes IP layer data, while TAP mode supports full Ethernet frame transmission, adapting to diverse scenarios.

[0087] The key negotiation module implements the handshake protocol, completing key negotiation and certificate verification. Compared to standard SSL VPN, the original SM2 national encryption algorithm is replaced with the PQC algorithm. This improves the security of the SSLVPN key negotiation process while maintaining compatibility with SSL VPN protocol specifications, and also provides quantum-resistant features.

Claims

1. A SSL VPN security gateway communication method based on post-quantum cryptography technology, characterized by: The following steps are involved: S1. The client and server are each configured with a pure PQC algorithm digital certificate containing a PQC encryption key pair and a signature key pair; S2. Add a PQC algorithm cipher suite that uses the pure PQC algorithm to the client's cipher suite list and force it to the top of the priority list. S3. Quantum-resistant key agreement is achieved by modifying the message structure in the handshake protocol to use pure PQC algorithm digital certificates instead of digital certificates based on the SM2 cryptographic algorithm.

2. The SSL VPN security gateway communication method based on post-quantum cryptography technology according to claim 1, characterized in that: The pure PQC algorithm in step S1 includes but is not limited to a key encapsulation algorithm based on a lattice cryptographic mechanism: ML-KEM, and a digital signature algorithm based on a lattice cryptographic mechanism: 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 technology according to claim 2, characterized in that: In step S2, the PQC algorithm cipher suite is MLDSA_MLKEM_SM4_SM3, where MLDSA_MLKEM is a key exchange algorithm that combines the ML-DSA algorithm with 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 technology according to claim 3, characterized in that: The step S3 specifically includes: S31. The client sends a client hello message containing the PQC algorithm cipher suite to the server; S32. The server responds to the client's hello message and selects the PQC algorithm cipher suite. S33 exchange certificate messages containing a clean PQC signature certificate and a clean PQC encryption certificate, and verify the server's identity through a server-side key exchange message signed by the PQC algorithm; the client uses the server-side PQC encryption key to encrypt the pre-master key to generate a client key exchange message; S34. The server uses the client's PQC signature key to authenticate the client as the legitimate holder of the certificate. S35. Verify key exchange and handshake integrity.

5. The SSL VPN security gateway communication method based on post-quantum cryptography technology according to claim 4, characterized in that: The step S33 specifically includes: S331. The server sends a server certificate message to the client. The server certificate message includes a clean PQC signature certificate and a clean PQC encryption certificate on the server. The clean PQC signature certificate comes first, followed by a clean PQC encryption certificate. S332. The server sends a server key exchange message to the client. The server key exchange message adds a new PQC algorithm enumeration type and the corresponding message structure, and signs the random numbers of both parties and the server's pure PQC encryption certificate with the PQC algorithm. S333. The server sends a certificate request message to the client, requesting the client to send its own pure PQC digital certificate; S334. The server sends a server hello completion message to the client, and the client verifies the server certificate and server hello message parameters; 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 a clean PQC signature certificate and a clean PQC encryption certificate, and the structure is the same as the server certificate message structure. S336. The client verifies the public key using the server's PQC signature key obtained from the server's pure PQC signature certificate, and sends a client key exchange message after successful verification. After receiving the client key exchange message, the server decrypts the pre-master key and obtains the plaintext of the pre-master key.

6. The SSL VPN security gateway communication method based on post-quantum cryptography technology according to claim 5, characterized in that: If the server cannot select a matching PQC algorithm cipher suite in step S32, it returns a handshake failure alarm message handshake_failure to the client and closes the connection; if the client cannot accept the server hello message parameters in step S334, it sends a handshake_failure alarm message to the server.

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

8. The SSL VPN security gateway communication method based on post-quantum cryptography technology according to claim 7, 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 the Skic and EncPreMasterSecret in PQCEncryptedPreMasterSecret; Then use the server-side PQC encryption key to decrypt the private key Skic to obtain Ski; Finally, use Ski to decrypt EncPreMasterSecret to obtain the pre-master key PreMasterSecret.

Images