A Chinese national cryptographic SSL VPN handshake acceleration method based on dynamic certificate chain compression.

By generating homomorphic ciphertext for certificates in the national cryptographic SSL VPN system and verifying it using zero-knowledge proofs, the problems of certificate chain transmission delay and information leakage in the traditional handshake process are solved. Dynamic compression and synchronous updates of the certificate chain are achieved, improving user experience and system performance.

CN122339652APending Publication Date: 2026-07-03BEIJING CATHAY INTERNET INFORMATION TECH CO LTD +1

Patent Information

Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
BEIJING CATHAY INTERNET INFORMATION TECH CO LTD
Filing Date
2026-04-09
Publication Date
2026-07-03

Smart Images

  • Figure CN122339652A_ABST
    Figure CN122339652A_ABST
Patent Text Reader

Abstract

This invention relates to a method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression, belonging to the field of network security communication technology. It includes extracting key fields from each certificate in the certificate chain. During the initial secure pairing, this invention extracts the key fields of each certificate in the certificate chain and encrypts them separately using a homomorphic public key to generate homomorphic ciphertext, achieving privacy protection encryption of the key certificate fields. All homomorphic ciphertexts are statistically integrated to achieve zero-knowledge proof and ciphertext fusion for extremely compressed transmission. The client performs valid verification of the zero-knowledge proof. After successful verification, the fused ciphertext is decrypted once using a homomorphic private key to obtain the effective analysis results of each certificate in the entire certificate chain. The handshake process is compressed according to trustworthiness to complete the handshake operation and establish a secure channel. When any change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] This invention relates to the field of network security communication technology, and in particular to a method for accelerating the handshake of a Chinese national cryptographic SSL VPN based on dynamic certificate chain compression. Background Technology

[0002] In a Chinese cryptographic SSL VPN system, the client and the gateway need to complete two-way authentication and secure channel establishment through the Chinese cryptographic transport layer security protocol. This process usually relies on a complete SM2 digital certificate chain for authentication, including the terminal entity certificate, intermediate certificates, and root certificate. Since SM2 certificates follow the national standard format and contain a complete structure such as public key, signature algorithm identifier, validity period, issuer information, and extended fields, the size of a single certificate is usually 2-4KB. The entire certificate chain, including the root, intermediate, and entity certificates, can reach 6-12KB in size. Existing certificate compression schemes mainly target international algorithms and compress the entire certificate using general compression algorithms. In traditional implementations, each transport layer security handshake requires transmitting a complete certificate chain over the network, leading to the following problems: The existing national cryptographic SSL VPN handshake process follows the standard TLS protocol. During the handshake process, the client needs to transmit the complete SM2 certificate chain, including the root certificate, intermediate certificates and entity certificates, to the server. The server verifies the certificate signature, checks the certificate validity period and queries the certificate revocation status step by step. As the length of the certificate chain increases, the handshake delay increases linearly, which seriously affects the user experience and system throughput. Sensitive information such as organization name and device identifier contained in the certificate chain may be stolen by man-in-the-middle during transmission, posing a risk of privacy leakage. When the certificate is renewed or revoked, the client needs to retransmit the complete certificate chain, and the server needs to re-perform full verification, resulting in high maintenance costs.

[0003] To address the aforementioned technical shortcomings, a solution is proposed. Summary of the Invention

[0004] This invention adopts the following technical solution: a Chinese cryptographic SSL VPN handshake acceleration method based on dynamic certificate chain compression, comprising the following steps: Step 1: When the client and the SSL VPN gateway are first securely paired, a homomorphic encryption key pair is generated. The key fields of each certificate in the certificate chain are extracted and encrypted separately using the homomorphic public key to generate the certificate homomorphic ciphertext. Step 2: The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified by the preset trust chain. The client statistically integrates all homomorphic ciphertexts of the certificates to generate a fused ciphertext. The client sends the zero-knowledge proof and the fused ciphertext to the server. Step 3: After receiving the zero-knowledge proof and the fused ciphertext, perform a valid verification of the zero-knowledge proof on the client side. After the verification is successful, decrypt the fused ciphertext once using the homomorphic private key to obtain the valid analysis results of each certificate in the entire certificate. Step 4: Based on the effective analysis of each certificate in the entire certificate system, obtain the trustworthiness of the client's identity, compress the handshake process according to the trustworthiness, complete the handshake operation, and establish a secure channel; Step 5: When a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, adds the old proof to the proof revocation list, and the server updates its local cache when it receives the new proof.

[0005] Furthermore, during the initial secure pairing between the client and the SSL VPN gateway, a homomorphic encryption key pair is generated. The specific generation process is as follows: The client obtains the complete certificate chain after encryption algorithm through device pre-installation and secure import, including the root certificate and the entity certificate. The client uses the root certificate to verify the certificate signature, and then uses the intermediate certificate to verify the entity certificate signature. This confirms that the trust relationship of the entire certificate chain is valid and that all certificates are within their validity period. After successful verification, the certificate chain is stored in the local trusted execution library. During the initial secure pairing between the client and the SSL VPN gateway, both parties negotiate and generate a national standard homomorphic encryption key pair that supports addition homomorphic operations for the pre-configured SM2 certificate through a secure channel. The encryption key pair adopts an encryption scheme that supports addition homomorphism. The key generation process is completed collaboratively by both parties. The encryption key pair consists of a private key and a public key. The private key is securely stored by the client in a trusted execution library, and the public key is sent to the server through a secure channel. The client extracts the public key, subject name, issuer name, and sequence number of each certificate in the certificate chain as key fields, concatenates the extracted fields in order, and encodes them into a plaintext vector of fixed dimensions for homomorphic encryption input.

[0006] Furthermore, the certificate homomorphic ciphertext is generated by encrypting the data using the homomorphic public key. The specific process is as follows: The client reads the verified complete certificate chain from the trusted execution environment, extracts the public key, subject name, issuer name and serial number of each certificate as key fields, concatenates them in order and encodes them into a plaintext vector of fixed dimension; The plaintext vector of each certificate is encrypted using a homomorphic public key, and each certificate uses an independent random number to ensure the uniqueness of the ciphertext, generating a fixed-length homomorphic ciphertext for the certificate. All homomorphic ciphertexts of certificates are associated with and stored in the certificate chain hierarchy to form a local homomorphic ciphertext library. The complete hash value of the certificate chain is calculated as the integrity verification benchmark and stored in the trusted execution library. The homomorphic public key hash value and the certificate chain commitment value are synchronized to the server as the verification benchmark. After the pre-configuration is completed, the subsequent handshake does not require the transmission of the complete certificate chain or the re-execution of the pre-configuration process.

[0007] Furthermore, the client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified through a preset trust chain. The specific content is as follows: The homomorphic ciphertexts of all certificates in the certificate chain are superimposed and merged according to the additive homomorphic rule to obtain the homomorphic fused ciphertext; Based on the certificate chain commitment value and homomorphic fusion ciphertext stored in the pre-set stage, construct a zero-knowledge proof assertion to be proved, including certificate chain consistency assertion, trust chain assertion, validity period judgment and revocation status assertion. Using the certificate chain commitment value from the pre-set stage, the homomorphic fused ciphertext, and the cryptographic proof as auxiliary inputs, a zero-knowledge proof is generated; The generated zero-knowledge proof is serialized into binary data, and an extended field is constructed. The extended field is then appended to the standard certificate chain message, keeping the original certificate chain message structure unchanged. If the server supports the extended field, verification is performed; otherwise, it automatically falls back to the traditional certificate chain transmission mode.

[0008] Furthermore, after receiving the zero-knowledge proof and the fused ciphertext, the client performs a valid verification of the zero-knowledge proof. Upon successful verification, the fused ciphertext is decrypted using a homomorphic private key to obtain the valid analysis results of each certificate within the entire certificate set. The specific steps are as follows: After receiving the zero-knowledge proof and associated auxiliary data sent by the client, the zero-knowledge proof verification algorithm is executed first. The verification process includes verifying the integrity of the proof structure, verifying the consistency assertion of the certificate chain, verifying the trust chain assertion, verifying the validity assertion, and verifying the revocation status assertion. After the zero-knowledge proof verification is successful, the server uses the homomorphic private key obtained in the pre-term negotiation to perform homomorphic decryption on the received fused ciphertext, and obtains the sum of all certificate plaintext vectors. From the superposition obtained by decryption, the effective analysis effect of each certificate is extracted according to the predetermined encoding rules, the complete verification state vector of all certificates is obtained, and the zero-knowledge proof verification result is generated.

[0009] Furthermore, based on the effective analysis of each certificate in the entire certificate system, the trustworthiness of the client's identity is obtained. The handshake process is then compressed based on this trustworthiness, completing the handshake operation and establishing a secure channel. The specific process is as follows: Cross-validate the zero-knowledge proof verification result with the verification state vector obtained by homomorphic decryption; If the zero-knowledge proof verification passes and all certificates are valid, within their validity period, and have not been revoked, then the client's identity is deemed trustworthy. If the analysis of any certificate is invalid, the handshake is rejected and an exception is logged. If the zero-knowledge proof verification fails, the connection will be rejected and an alarm will be triggered. After successful verification, the server skips the sequential process of certificate chain signature verification, revocation list query, and validity period verification in traditional protocols, and directly enters the master key negotiation stage to complete the handshake and establish a secure channel.

[0010] Furthermore, when a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, adds the old proof to the proof revocation list, and the server updates its local cache upon receiving the new proof. The specific process is as follows: Monitor the status of the certificate chain and automatically trigger the certificate chain update process when it is detected that the certificate is about to expire, is revoked, is replaced by the administrator, or the certificate chain structure is adjusted. Based on the scope of certificate changes, key fields are extracted only from the changed certificates and encrypted to generate new homomorphic ciphertexts. The old ciphertexts in the ciphertext library are replaced, the superposition of all ciphertexts is recalculated, a new fused ciphertext is generated, and the certificate chain commitment value is updated. Based on the new certificate chain commitment value and the new fused ciphertext, a zero-knowledge proof is regenerated, and the commitment value corresponding to the old proof is inserted as a leaf node into the proof revocation list to generate a revocation certificate. During the next handshake, a new certificate, a new fused ciphertext, and a revocation credential of the old certificate are sent. After the server verifies that the old certificate has expired, it verifies the new certificate. If the verification is successful, the certificate chain commitment value and trust status in the local cache are updated to complete the update and synchronization.

[0011] In summary, due to the adoption of the above technical solution, the beneficial effects of the present invention are: This national cryptographic SSL VPN handshake acceleration method based on dynamic certificate chain compression generates a homomorphic encryption key pair during the initial secure pairing between the client and the SSL VPN gateway. It extracts key fields from each certificate in the certificate chain and encrypts them separately using a homomorphic public key to generate homomorphic ciphertext, thus achieving privacy protection encryption of key certificate fields. The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified through a preset trust chain. The client statistically integrates all the homomorphic ciphertexts to generate a merged ciphertext. The client sends the zero-knowledge proof and the merged ciphertext to the server, achieving highly compressed transmission through the fusion of the zero-knowledge proof and the ciphertext. Upon receiving the zero-knowledge proof and the merged ciphertext, the client proceeds... The client performs valid zero-knowledge proof verification. After successful verification, the fused ciphertext is decrypted using a homomorphic private key to obtain the valid analysis results of each certificate in the entire certificate. Based on the valid analysis results of each certificate in the entire certificate, the trustworthiness of the client's identity is obtained. The handshake process is compressed based on the trustworthiness, and the handshake operation is completed to establish a secure channel. When any certificate in the certificate chain is detected to have changed, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, and adds the old proof to the proof revocation list. When the server receives the new proof, it updates its local cache to achieve synchronization between dynamic updates of the certificate chain and proof revocation. Attached Figure Description

[0012] Figure 1 A schematic diagram of the overall structure of the method steps of the present invention is shown. Detailed Implementation

[0013] To further illustrate the technical means and effects of the present invention in achieving its intended purpose, the following detailed description of the specific implementation methods, structures, features, and effects of the present invention, in conjunction with the accompanying drawings and preferred embodiments, is provided below.

[0014] Example: like Figure 1 As shown, the Chinese national cryptographic SSL VPN handshake acceleration method based on dynamic certificate chain compression includes the following steps: Step 1: When the client and the SSL VPN gateway are first securely paired, a homomorphic encryption key pair is generated. The key fields of each certificate in the certificate chain are extracted and encrypted separately using the homomorphic public key to generate the certificate homomorphic ciphertext. Step 2: The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified by the preset trust chain. The client statistically integrates all homomorphic ciphertexts of the certificates to generate a fused ciphertext. The client sends the zero-knowledge proof and the fused ciphertext to the server. Step 3: After receiving the zero-knowledge proof and the fused ciphertext, perform a valid verification of the zero-knowledge proof on the client side. After the verification is successful, decrypt the fused ciphertext once using the homomorphic private key to obtain the valid analysis results of each certificate in the entire certificate. Step 4: Based on the effective analysis of each certificate in the entire certificate system, obtain the trustworthiness of the client's identity, compress the handshake process according to the trustworthiness, complete the handshake operation, and establish a secure channel; Step 5: When a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, adds the old proof to the proof revocation list, and the server updates its local cache when it receives the new proof.

[0015] When the client and the SSL VPN gateway are securely paired for the first time, a homomorphic encryption key pair is generated. The specific generation process is as follows: The client obtains the complete certificate chain after encryption algorithm through device pre-installation and secure import, including the root certificate and the entity certificate. The client uses the root certificate to verify the certificate signature, and then uses the intermediate certificate to verify the entity certificate signature. This confirms that the trust relationship of the entire certificate chain is valid and that all certificates are within their validity period. After successful verification, the certificate chain is stored in the local trusted execution library. During the initial secure pairing between the client and the SSL VPN gateway, both parties negotiate and generate a national standard homomorphic encryption key pair that supports addition homomorphic operations for the pre-configured SM2 certificate through a secure channel. The encryption key pair adopts an encryption scheme that supports addition homomorphism. The key generation process is completed collaboratively by both parties. The encryption key pair consists of a private key and a public key. The private key is securely stored by the client in a trusted execution library, and the public key is sent to the server through a secure channel. The client extracts the public key, subject name, issuer name, and sequence number of each certificate in the certificate chain as key fields, concatenates the extracted fields in order, and encodes them into a plaintext vector of fixed dimensions for homomorphic encryption input.

[0016] The certificate homomorphic ciphertext is generated by encrypting each part using a homomorphic public key, as follows: The client reads the verified complete certificate chain from the trusted execution environment, extracts the public key, subject name, issuer name and serial number of each certificate as key fields, concatenates them in order and encodes them into a plaintext vector of fixed dimension; The plaintext vector of each certificate is encrypted using a homomorphic public key, and each certificate uses an independent random number to ensure the uniqueness of the ciphertext, generating a fixed-length homomorphic ciphertext for the certificate. All homomorphic ciphertexts of certificates are associated with and stored in the certificate chain hierarchy to form a local homomorphic ciphertext library. The complete hash value of the certificate chain is calculated as the integrity verification benchmark and stored in the trusted execution library. The homomorphic public key hash value and the certificate chain commitment value are synchronized to the server as the verification benchmark. After the pre-configuration is completed, the subsequent handshake does not require the transmission of the complete certificate chain or the re-execution of the pre-configuration process.

[0017] The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified through a preset trust chain. The specific content is as follows: The homomorphic ciphertexts of all certificates in the certificate chain are superimposed and merged according to the additive homomorphic rule to obtain the homomorphic fused ciphertext; Based on the certificate chain commitment value and homomorphic fusion ciphertext stored in the pre-set stage, construct a zero-knowledge proof assertion to be proved, including certificate chain consistency assertion, trust chain assertion, validity period judgment and revocation status assertion. Using the certificate chain commitment value from the pre-set stage, the homomorphic fused ciphertext, and the cryptographic proof as auxiliary inputs, a zero-knowledge proof is generated; The generated zero-knowledge proof is serialized into binary data, and an extended field is constructed. The extended field is then appended to the standard certificate chain message, keeping the original certificate chain message structure unchanged. If the server supports the extended field, verification is performed; otherwise, it automatically falls back to the traditional certificate chain transmission mode.

[0018] After receiving the zero-knowledge proof and the fused ciphertext, the client performs a valid verification of the zero-knowledge proof. Upon successful verification, the fused ciphertext is decrypted using a homomorphic private key to obtain the valid analysis results of each certificate within the entire certificate set. The specific steps are as follows: After receiving the zero-knowledge proof and associated auxiliary data sent by the client, the zero-knowledge proof verification algorithm is executed first. The verification process includes verifying the integrity of the proof structure, verifying the consistency assertion of the certificate chain, verifying the trust chain assertion, verifying the validity assertion, and verifying the revocation status assertion. After the zero-knowledge proof verification is successful, the server uses the homomorphic private key obtained in the pre-term negotiation to perform homomorphic decryption on the received fused ciphertext, and obtains the sum of all certificate plaintext vectors. From the superposition obtained by decryption, the effective analysis effect of each certificate is extracted according to the predetermined encoding rules, the complete verification state vector of all certificates is obtained, and the zero-knowledge proof verification result is generated.

[0019] Based on the effective analysis of each certificate in the entire certificate system, the trustworthiness of the client's identity is obtained. The handshake process is then compressed based on this trustworthiness, completing the handshake operation and establishing a secure channel. The specific process is as follows: Cross-validate the zero-knowledge proof verification result with the verification state vector obtained by homomorphic decryption; If the zero-knowledge proof verification passes and all certificates are valid, within their validity period, and have not been revoked, then the client's identity is deemed trustworthy. If the analysis of any certificate is invalid, the handshake is rejected and an exception is logged. If the zero-knowledge proof verification fails, the connection will be rejected and an alarm will be triggered. After successful verification, the server skips the sequential process of certificate chain signature verification, revocation list query, and validity period verification in traditional protocols, and directly enters the master key negotiation stage to complete the handshake and establish a secure channel.

[0020] When a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, and adds the old proof to the proof revocation list. The server updates its local cache when it receives the new proof. The specific process is as follows: Monitor the status of the certificate chain and automatically trigger the certificate chain update process when it is detected that the certificate is about to expire, is revoked, is replaced by the administrator, or the certificate chain structure is adjusted. Based on the scope of certificate changes, key fields are extracted only from the changed certificates and encrypted to generate new homomorphic ciphertexts. The old ciphertexts in the ciphertext library are replaced, the superposition of all ciphertexts is recalculated, a new fused ciphertext is generated, and the certificate chain commitment value is updated. Based on the new certificate chain commitment value and the new fused ciphertext, a zero-knowledge proof is regenerated, and the commitment value corresponding to the old proof is inserted as a leaf node into the proof revocation list to generate a revocation certificate. During the next handshake, a new certificate, a new fused ciphertext, and a revocation credential of the old certificate are sent. After the server verifies that the old certificate has expired, it verifies the new certificate. If the verification is successful, the certificate chain commitment value and trust status in the local cache are updated to complete the update and synchronization.

[0021] The size of the interval and threshold is set to facilitate comparison. The size of the threshold depends on the amount of sample data and the number of bases set by those skilled in the art for each set of sample data; as long as it does not affect the ratio between the parameter and the quantized value.

[0022] The above formulas are all dimensionless calculations. The formulas are derived from software simulations based on a large amount of collected data to obtain the most recent real-world results. The preset parameters in the formulas are set by those skilled in the art according to the actual situation. In the two embodiments provided in this application, it should be understood that the disclosed apparatus and system can be implemented in other ways; for example, the apparatus embodiments described above are merely illustrative, and the division of modules is merely a logical functional division. In actual implementation, there may be other division methods, such as multiple modules or components can be combined or integrated into another system, or some features can be ignored or not executed; furthermore, the coupling or direct coupling or communication connection between the shown or discussed mutuals can be through some interfaces, and the indirect coupling or communication connection between the apparatus or modules can be electrical, mechanical or other forms. The above description is merely a preferred embodiment of the present invention and is not intended to limit the present invention in any way. Although the present invention has been disclosed above with reference to preferred embodiments, it is not intended to limit the present invention. Any person skilled in the art can make some modifications or alterations to the above-disclosed technical content to create equivalent embodiments without departing from the scope of the present invention. Any simple modifications, equivalent changes and alterations made to the above embodiments based on the technical essence of the present invention without departing from the scope of the present invention shall still fall within the scope of the present invention.

Claims

1. A method for accelerating the handshake of a Chinese cryptographic SSL VPN based on dynamic certificate chain compression, characterized in that, Includes the following steps: Step 1: When the client and the SSL VPN gateway are first securely paired, a homomorphic encryption key pair is generated. The key fields of each certificate in the certificate chain are extracted and encrypted separately using the homomorphic public key to generate the certificate homomorphic ciphertext. Step 2: The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified by the preset trust chain. The client statistically integrates all homomorphic ciphertexts of the certificates to generate a fused ciphertext. The client sends the zero-knowledge proof and the fused ciphertext to the server. Step 3: After receiving the zero-knowledge proof and the fused ciphertext, perform a valid verification of the zero-knowledge proof on the client side. After the verification is successful, decrypt the fused ciphertext once using the homomorphic private key to obtain the valid analysis results of each certificate in the entire certificate. Step 4: Based on the effective analysis of each certificate in the entire certificate system, obtain the trustworthiness of the client's identity, compress the handshake process according to the trustworthiness, complete the handshake operation, and establish a secure channel; Step 5: When a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, adds the old proof to the proof revocation list, and the server updates its local cache when it receives the new proof.

2. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, When the client and the SSL VPN gateway are securely paired for the first time, a homomorphic encryption key pair is generated. The specific generation process is as follows: The client obtains the complete certificate chain after encryption algorithm through device pre-installation and secure import, including the root certificate and the entity certificate. The client uses the root certificate to verify the certificate signature, and then uses the intermediate certificate to verify the entity certificate signature. This confirms that the trust relationship of the entire certificate chain is valid and that all certificates are within their validity period. After successful verification, the certificate chain is stored in the local trusted execution library. During the initial secure pairing between the client and the SSL VPN gateway, both parties negotiate and generate a national standard homomorphic encryption key pair that supports addition homomorphic operations for the pre-configured SM2 certificate through a secure channel. The encryption key pair adopts an encryption scheme that supports addition homomorphism. The key generation process is completed collaboratively by both parties. The encryption key pair consists of a private key and a public key. The private key is securely stored by the client in a trusted execution library, and the public key is sent to the server through a secure channel. The client extracts the public key, subject name, issuer name, and sequence number of each certificate in the certificate chain as key fields, concatenates the extracted fields in order, and encodes them into a plaintext vector of fixed dimensions for homomorphic encryption input.

3. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, The certificate homomorphic ciphertext is generated by encrypting each part using a homomorphic public key, as follows: The client reads the verified complete certificate chain from the trusted execution environment, extracts the public key, subject name, issuer name and serial number of each certificate as key fields, concatenates them in order and encodes them into a plaintext vector of fixed dimension; The plaintext vector of each certificate is encrypted using a homomorphic public key, and each certificate uses an independent random number to ensure the uniqueness of the ciphertext, generating a fixed-length homomorphic ciphertext for the certificate. All homomorphic ciphertexts of certificates are associated with and stored in the certificate chain hierarchy to form a local homomorphic ciphertext library. The complete hash value of the certificate chain is calculated as the integrity verification benchmark and stored in the trusted execution library. The homomorphic public key hash value and the certificate chain commitment value are synchronized to the server as the verification benchmark. After the pre-configuration is completed, the subsequent handshake does not require the transmission of the complete certificate chain or the re-execution of the pre-configuration process.

4. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, The client generates a zero-knowledge proof in the certificate chain message to prove to the server that it holds a valid certificate chain that can be verified through a preset trust chain. The specific content is as follows: The homomorphic ciphertexts of all certificates in the certificate chain are superimposed and merged according to the additive homomorphic rule to obtain the homomorphic fused ciphertext; Based on the certificate chain commitment value and homomorphic fusion ciphertext stored in the pre-set stage, construct a zero-knowledge proof assertion to be proved, including certificate chain consistency assertion, trust chain assertion, validity period judgment and revocation status assertion. Using the certificate chain commitment value from the pre-set stage, the homomorphic fused ciphertext, and the cryptographic proof as auxiliary inputs, a zero-knowledge proof is generated; The generated zero-knowledge proof is serialized into binary data, and an extended field is constructed. The extended field is then appended to the standard certificate chain message, keeping the original certificate chain message structure unchanged. If the server supports the extended field, verification is performed; otherwise, it automatically falls back to the traditional certificate chain transmission mode.

5. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, After receiving the zero-knowledge proof and the fused ciphertext, the client performs a valid verification of the zero-knowledge proof. Upon successful verification, the fused ciphertext is decrypted using a homomorphic private key to obtain the valid analysis results of each certificate within the entire certificate set. The specific steps are as follows: After receiving the zero-knowledge proof and associated auxiliary data sent by the client, the zero-knowledge proof verification algorithm is executed first. The verification process includes verifying the integrity of the proof structure, verifying the consistency assertion of the certificate chain, verifying the trust chain assertion, verifying the validity assertion, and verifying the revocation status assertion. After the zero-knowledge proof verification is successful, the server uses the homomorphic private key obtained in the pre-term negotiation to perform homomorphic decryption on the received fused ciphertext, and obtains the sum of all certificate plaintext vectors. From the superposition obtained by decryption, the effective analysis effect of each certificate is extracted according to the predetermined encoding rules, the complete verification state vector of all certificates is obtained, and the zero-knowledge proof verification result is generated.

6. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, Based on the effective analysis of each certificate in the entire certificate system, the trustworthiness of the client's identity is obtained. The handshake process is then compressed based on this trustworthiness, completing the handshake operation and establishing a secure channel. The specific process is as follows: Cross-validate the zero-knowledge proof verification result with the verification state vector obtained by homomorphic decryption; If the zero-knowledge proof verification passes and all certificates are valid, within their validity period, and have not been revoked, then the client's identity is deemed trustworthy. If the analysis of any certificate is invalid, the handshake is rejected and an exception is logged. If the zero-knowledge proof verification fails, the connection will be rejected and an alarm will be triggered. After successful verification, the server skips the sequential process of certificate chain signature verification, revocation list query, and validity period verification in traditional protocols, and directly enters the master key negotiation stage to complete the handshake and establish a secure channel.

7. The method for accelerating the handshake of a national cryptographic SSL VPN based on dynamic certificate chain compression according to claim 1, characterized in that, When a change is detected in any certificate in the certificate chain, the client regenerates a new certificate chain and the corresponding zero-knowledge proof, updates the homomorphic ciphertext library, and adds the old proof to the proof revocation list. The server updates its local cache when it receives the new proof. The specific process is as follows: Monitor the status of the certificate chain and automatically trigger the certificate chain update process when it is detected that the certificate is about to expire, is revoked, is replaced by the administrator, or the certificate chain structure is adjusted. Based on the scope of certificate changes, key fields are extracted only from the changed certificates and encrypted to generate new homomorphic ciphertexts. The old ciphertexts in the ciphertext library are replaced, the superposition of all ciphertexts is recalculated, a new fused ciphertext is generated, and the certificate chain commitment value is updated. Based on the new certificate chain commitment value and the new fused ciphertext, a zero-knowledge proof is regenerated, and the commitment value corresponding to the old proof is inserted as a leaf node into the proof revocation list to generate a revocation certificate. During the next handshake, a new certificate, a new fused ciphertext, and a revocation credential of the old certificate are sent. After the server verifies that the old certificate has expired, it verifies the new certificate. If the verification is successful, the certificate chain commitment value and trust status in the local cache are updated to complete the update and synchronization.