A quantum-resistant certificate chain sparse coding and progressive verification system and method

Abstract

The application discloses an anti-quantum certificate chain sparse coding and progressive verification system and method, and belongs to the network security and anti-quantum cryptography technical field. The application aims at the technical problem that the PQC certificate chain volume explosion leads to the TLS handshake delay being too high in the post-quantum era, and constructs a trinity solution: a certificate chain sparse encoder adopts a three-stage pipeline of differential deduplication coding, LLL lattice base reduction compression and ANS entropy coding, so that the certificate chain volume is losslessly reduced; a progressive certificate verification protocol splits the certificate verification into two stages of digest priority verification and complete post verification, so that the handshake delay and the certificate chain volume are decoupled; and a domain-level Bloom filter pre-caching mechanism realizes cross-device certificate chain sharing, and when the cache hits, the zero round trip time handshake is achieved. The application can greatly reduce the TLS handshake delay in the PQC scenario, the security level is consistent with that of the standard TLS, and is suitable for bandwidth-limited and time-sensitive scenarios such as vehicle networking V2X, industrial IoT, low-orbit satellite communication and the like.

Description

Technical Field

[0001] This invention relates to the fields of network security and quantum-resistant cryptography, and in particular to a quantum-resistant certificate chain sparse coding and progressive verification system and method. Background Technology

[0002] With the rapid development of quantum computing technology, traditional public-key cryptography such as RSA and ECDSA are at risk of being cracked. NIST has released lattice-based quantum-resistant signature standards such as Dilithium and Falcon, and the migration of TLS communication systems to quantum-resistant cryptography has become an inevitable trend.

[0003] The TLS protocol is a core infrastructure for secure internet communication, and the X.509 digital certificate chain is the core carrier of TLS identity authentication. Under classic cryptographic systems, a single ECDSA certificate is only 1.5KB-3KB in size, and the total size of the three-layer certificate chain is less than 10KB. The "complete certificate chain transmission - layer-by-layer signature verification" serial mode adopted by the standard TLS 1.3 can achieve sub-millisecond handshake latency, which can meet the communication needs of most scenarios.

[0004] However, in the era of quantum-resistant cryptography, the size of public keys and signatures in lattice-based algorithms has increased exponentially. A single Dilithium3 certificate can reach 52KB, and the total size of a three-layer certificate chain exceeds 150KB, which is more than ten times that of a classical certificate. In bandwidth-constrained and latency-sensitive scenarios such as V2X (Vehicle-to-Everything), industrial IoT, and low-Earth orbit satellite communications, the transmission of the certificate chain alone can introduce handshake delays of hundreds of milliseconds or even seconds, severely impacting the real-time performance of secure services and becoming a core bottleneck for the large-scale deployment of quantum-resistant cryptography.

[0005] Current mainstream optimization solutions mainly rely on TLS session reuse and general compression algorithms, which have significant limitations. Session reuse only works for repeated connections to the same server and cannot cover the large number of initial connections in the high-frequency switching scenarios of roadside units in the Internet of Vehicles (IoV). General compression algorithms such as Gzip and Brotli cannot exploit the mathematical structural redundancy of lattice data, and the compression rate is only 5%~10%, resulting in very limited optimization effects. At the same time, existing solutions all adhere to the design paradigm of "full verification beforehand," and the handshake delay is strongly coupled with the certificate size, which cannot fundamentally overcome the latency bottleneck caused by large-size certificates.

[0006] Therefore, there is an urgent need for a quantum-resistant certificate chain sparse coding and incremental verification system and method to solve the problems of existing technologies. Summary of the Invention

[0007] The present invention aims to solve at least one of the technical problems existing in the prior art, and proposes a quantum-resistant certificate chain sparse coding and progressive verification system and method.

[0008] In a first aspect, embodiments of the present invention provide a quantum-resistant certificate chain sparse coding and progressive verification system, comprising: a certificate chain sparse encoder, a progressive certificate verification protocol module, a domain-level Bloom filter pre-caching module, and a secure session establishment interface; wherein:

[0009] The certificate chain sparse encoder is used to perform lossless compression encoding of PQC quantum-resistant certificate chains using a three-stage encoding pipeline. Specifically, the first stage is differential deduplication encoding, which extracts the shared fields of adjacent certificates and stores only the differences between certificates; the second stage is lattice basis reduction compression, which compresses the lattice basis public key and signature data in the certificate by performing an equivalent basis transformation based on the LLL lattice basis reduction algorithm; and the third stage is ANS entropy encoding post-processing, which performs statistical entropy compression on the data streams output from the first two stages.

[0010] The progressive certificate verification protocol module is used to split the certificate chain verification process into two stages: the first stage is digest-first verification, which completes identity verification by transmitting a certificate digest carrying a PQC signature. If the verification is successful, a TLS session is immediately established; the second stage is full post-verification, which asynchronously transmits the complete encoded certificate chain and performs full certificate verification after the session is established. If the verification fails, the session is terminated.

[0011] The domain-level Bloom filter pre-caching module is used to maintain the Bloom filter index of commonly used certificate chains in the domain on the domain controller side. Before the client initiates a connection, it pre-queries the cache status and achieves a zero round-trip time handshake when the cache is hit.

[0012] The secure session establishment interface is designed to be compatible with the standard TLS 1.3 protocol and the progressive authentication protocol, supporting adaptive protocol switching and smooth deployment.

[0013] Furthermore, the specific implementation of the differential deduplication encoding is as follows: the three-layer certificate chain is represented as a DER encoded sequence. ,in For root certificate, For intermediate CA certificates, For leaf certificates; define difference sequences ,in For complete root certificate data, The shared() function extracts shared fields between adjacent certificates from DER encoding, including the issuer distinguishable name, certificate policy object identifier, signature algorithm object identifier, and validity period structure field; differential encoding is a lossless and reversible transformation, and the original certificate chain can be completely recovered during decoding using the base certificate and the difference value.

[0014] Furthermore, the specific implementation of the lattice basis reduction compression is as follows: for the public key and signature data of the PQC algorithm, the lattice vector represented by its standard basis is used as input; the LLL algorithm is used to output the LLL reduction basis, and the reduction parameters and maximum number of iterations are set to make the reduction basis vector shorter and more orthogonal; during storage, the LLL reduction basis data and the transformation matrix from the standard basis to the reduction basis are recorded, and during decoding, the standard basis representation is recovered in reverse through the transformation matrix; the lattice basis reduction is a mathematically equivalent transformation, generating the same lattice before and after reduction, without changing the cryptographic security.

[0015] Furthermore, the specific implementation of the progressive certificate verification protocol module is as follows:

[0016] Digest-first verification phase: The client sends a certificate digest request carrying a client-side random number. The server responds with a certificate digest packet, which contains the hash value of the three-layer certificate public key, a timestamp, and the server's PQC signature. After the client verifies that the signature is valid and the timestamp is within the validity period, a TLS session is immediately established and application data transmission is initiated.

[0017] Complete post-verification phase: After the session is established, the server asynchronously transmits the complete certificate chain with sparse encoding in the background; after receiving it, the client decodes it and performs certificate chain path verification, signature verification, and revocation status verification; if the verification is successful, the session is maintained; if the verification fails, a reset message is sent in the next round-trip cycle to terminate the session.

[0018] Furthermore, the specific implementation of the domain-level Bloom filter pre-caching module is as follows:

[0019] The domain controller maintains a global Bloom filter, configuring the bit array size and the number of hash functions;

[0020] When a new certificate is issued, a Bloom filter is automatically inserted and the update is broadcast. When a certificate is revoked, it is recorded through a separate small revocation list. The Bloom filter is rebuilt periodically on a weekly basis to eliminate the cumulative bias of false positives.

[0021] The client is configured with an LRU cache to store the verified encoded certificate chain. Before connecting, it queries the domain-level Bloom filter. If a match is found, it reads the local cache for direct verification, achieving a zero round-trip time handshake.

[0022] Furthermore, when a new certificate is issued, it is automatically inserted into a Bloom filter and broadcast as an update. The specific update method includes: when a new certificate is issued, the domain controller automatically inserts it into a Bloom filter and broadcasts an update notification to all clients in the domain.

[0023] When a certificate is revoked, the Bloom filter does not support deletion operations. Therefore, the domain controller maintains a separate small revocation list that only stores the SPKI hash of the revoked certificate. The Bloom filter performs a full rebuild once a week, regenerating it from the database to eliminate accumulated false positive biases.

[0024] Furthermore, the system supports three deployment modes: TLS library plugin mode, independent certificate proxy service mode, and lightweight SDK mode, which are respectively adapted to general server-side, large domain environment, and resource-constrained IoT devices.

[0025] Furthermore, the specific methods for implementing the secure session establishment interface include: when the client initiates a TLS handshake, it carries a PCVP extended identifier. If the server supports the PCVP protocol, it enters the progressive verification process; if the server does not support it, it automatically falls back to the standard TLS 1.3 full certificate verification process to ensure backward compatibility.

[0026] Secondly, this invention also discloses a quantum-resistant certificate chain sparse coding and asymptotic verification method, comprising:

[0027] Preprocessing of certificate chain encoding: Differential deduplication encoding, LLL lattice basis reduction compression and ANS entropy encoding are performed sequentially on the PQC quantum-resistant certificate chain to generate a compressed encoded certificate chain;

[0028] Handshake with digest first: The client sends a certificate digest request carrying a random number to the server. The server returns a digest packet containing the public key hash, timestamp, and PQC signature. After the client verifies the validity of the digest, it immediately establishes a TLS session and transmits application data.

[0029] Perform full post-verification: After the session is established, the server asynchronously transmits the encoded certificate chain in the background. The client receives the certificate chain, decodes it, and completes full verification of the certificate chain. If the verification fails, the session is terminated.

[0030] Domain-level pre-caching acceleration: The domain controller maintains a Bloom filter index of the certificate chain within the domain. Before the client connects, it pre-queries the cache. When the cache is hit, it directly reads the local cache to complete the verification, achieving a zero round-trip time handshake.

[0031] Thirdly, the present invention also discloses an electronic device, comprising:

[0032] One or more processors;

[0033] Memory, used to store one or more programs;

[0034] When the one or more programs are executed by the one or more processors, the one or more processors implement the method.

[0035] This invention discloses a quantum-resistant certificate chain sparse coding and progressive verification system and method, belonging to the fields of network security and quantum-resistant cryptography. Addressing the technical problem of excessively high TLS handshake latency caused by the explosion of PQC certificate chain size in the post-quantum era, this invention constructs a three-pronged solution: the certificate chain sparse encoder employs a three-stage pipeline of differential deduplication coding, LLL lattice reduction compression, and ANS entropy coding to losslessly reduce the certificate chain size; the progressive certificate verification protocol splits certificate verification into two stages: digest-first verification and full-after verification, decoupling handshake latency from certificate chain size; and a domain-level Bloom filter pre-caching mechanism enables cross-device certificate chain sharing, achieving zero-round-trip time handshakes upon cache hit. This invention can significantly reduce TLS handshake latency in PQC scenarios, achieving a security level consistent with standard TLS, and is suitable for bandwidth-constrained and latency-sensitive scenarios such as V2X for connected vehicles, industrial IoT, and low-Earth orbit satellite communication.

[0036] Compared with the prior art, the present invention has the following beneficial effects:

[0037] 1. Significantly reduced handshake latency: By breaking the coupling relationship between handshake latency and certificate chain size through a progressive verification protocol, the PQC-TLS handshake latency in typical scenarios is reduced from 850ms to 2ms, a performance improvement of 425 times, which can meet the stringent latency requirements of less than 100ms for vehicle network security messages.

[0038] 2. Leading Certificate Compression Efficiency: Pioneering a dedicated compression scheme for lattice structures, combining differential deduplication and entropy coding, the three-layer Dilithium certificate chain is compressed from 154KB to 54KB, reducing the total size by 65%, with compression efficiency far exceeding that of general compression algorithms.

[0039] 3. First-time connection also benefits: The domain-level Bloom filter pre-caching mechanism enables certificate information sharing across devices and connections. When the cache is hit on the first connection, a zero round-trip handshake of less than 1ms can be achieved, breaking through the limitation of traditional session reuse that only supports repeated connections to the same server.

[0040] 4. Consistent security level: The security of progressive verification can be strictly reduced to the unforgeability of the underlying PQC signature, and the post-full verification can terminate illegal sessions in a timely manner. The overall security level is equivalent to the standard TLS full verification and does not introduce additional security risks. Attached Figure Description

[0041] Figure 1 A structural block diagram of a quantum-resistant certificate chain sparse coding and progressive verification system provided in an embodiment of the present invention;

[0042] Figure 2 A flowchart illustrating a quantum-resistant certificate chain sparse coding and progressive verification method provided in an embodiment of the present invention;

[0043] Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0044] To enable those skilled in the art to better understand the technical solutions of the present invention, exemplary embodiments of the present invention are described below in conjunction with the accompanying drawings, including various details of the embodiments of the present invention to aid understanding. These should be considered merely exemplary. Therefore, those skilled in the art should recognize that various changes and modifications can be made to the embodiments described herein without departing from the scope and spirit of the present invention. Similarly, for clarity and brevity, descriptions of well-known functions and structures are omitted in the following description.

[0045] Where there is no conflict, the various embodiments of the present invention and the features thereof may be combined with each other.

[0046] As used herein, the term “and / or” includes any and all combinations of one or more related enumerated entries.

[0047] The terminology used herein is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used herein, the singular forms “a” and “the” are intended to include the plural forms as well, unless the context clearly indicates otherwise. It will also be understood that when the terms “comprising” and / or “made of” are used in this specification, the presence of the stated feature, integral, step, operation, element, and / or component is specified, but the presence or addition of one or more other features, integrals, steps, operations, elements, components, and / or groups thereof is not excluded. Terms such as “connected” or “linked” are not limited to physical or mechanical connections but can include electrical connections, whether direct or indirect.

[0048] Unless otherwise specified, all terms used herein (including technical and scientific terms) have the same meaning as commonly understood by one of ordinary skill in the art. It will also be understood that terms such as those defined in commonly used dictionaries should be interpreted as having the meaning consistent with their meaning in the context of the relevant art and the invention, and will not be interpreted as having an idealized or overly formal meaning unless expressly so defined herein.

[0049] In the technical solution of this invention, the collection, storage, use, processing, transmission, provision, and disclosure of user personal information all comply with relevant laws and regulations and do not violate public order and good morals. The use of user data in this technical solution follows relevant national laws and regulations (e.g., the "Information Security Technology - Personal Information Security Specification"). For example: appropriate measures are taken for personal information access control; restrictions are imposed on the display of personal information; the purpose of using personal information does not exceed the scope of direct or reasonable association; and explicit identity targeting is eliminated when using personal information to avoid precisely locating a specific individual.

[0050] The key terms involved in this invention are defined as follows:

[0051] SCCE: Sparse Certificate Chain Encoding, one of the core technologies of this invention;

[0052] PCVP: Progressive Certificate Verification Protocol, an original protocol of this invention;

[0053] BF: Bloom Filter, used for domain-level certificate chain pre-caching services;

[0054] LLL: Lenstra-Lenstra-Lovász lattice basis reduction algorithm, the mathematical core of lattice basis compression in this invention;

[0055] SPKI: Subject Public Key Info, one of the largest single fields in an X.509 certificate;

[0056] Dilithium: A quantum-safe signature algorithm based on the NISTFIPS 204 standard, using lattice signatures based on the MLWE problem (Module Learning With Errors).

[0057] Falcon: NISTFIPS206 quantum-safe signature algorithm, based on short vector signatures using NTRU lattice;

[0058] PQC: Post-Quantum Cryptography;

[0059] TLS: Transport Layer Security.

[0060] DN: Distinguished Name, the subject identifier in an X.509 certificate;

[0061] OID: Object Identifier, used to identify certificate policies, algorithms, etc.

[0062] FPR: False Positive Rate, the probability of false positives in a BF query;

[0063] RTT: Round-Trip Time, a basic performance indicator of network communication;

[0064] V2X: Vehicle-to-Everything, a vehicle-to-everything communication protocol;

[0065] ECU: Electronic Control Unit;

[0066] To address at least one of the technical problems existing in the aforementioned related technologies, the present invention provides a quantum-resistant certificate chain sparse coding and progressive verification system and method.

[0067] This implementation discloses a quantum-resistant certificate chain sparse coding and asymptotic verification system, such as Figure 1 This includes: a certificate chain sparse encoder, a progressive certificate verification protocol module, a domain-level Bloom filter pre-caching module, and a secure session establishment interface; among which:

[0068] The certificate chain sparse encoder is used to perform lossless compression encoding of PQC quantum-resistant certificate chains using a three-stage encoding pipeline. Specifically, the first stage is differential deduplication encoding, which extracts the shared fields of adjacent certificates and stores only the differences between certificates; the second stage is lattice basis reduction compression, which compresses the lattice basis public key and signature data in the certificate by performing an equivalent basis transformation based on the LLL lattice basis reduction algorithm; and the third stage is ANS entropy encoding post-processing, which performs statistical entropy compression on the data streams output from the first two stages.

[0069] Specifically, the certificate chain sparse encoder is the first core module of the system in this embodiment. The encoder adopts a three-stage pipeline of "differential deduplication → lattice reduction compression → entropy coding post-processing". Unlike existing general compression algorithms that only look for redundancy at the bit level, SCCE utilizes the structural redundancy, lattice mathematical redundancy and statistical redundancy of the certificate chain in a progressive manner.

[0070] In this embodiment, Phase 1 is differential deduplication encoding based on certificate chain semantics. In the standard X.509 certificate chain, there are a large number of shared fields between adjacent certificates. For a typical three-layer certificate chain (RootCA, InterCA, Leaf), the shared fields include: (1) Inheritance relationship - the IssuerDN of the InterCA certificate is exactly the same as the SubjectDN of the RootCA certificate; the IssuerDN of the Leaf certificate is exactly the same as the SubjectDN of the InterCA certificate. (2) Certificate policy OID - the three-layer certificates usually use the same or similar certificate policy extensions. (3) Signature algorithm OID - in the PQC migration scenario, the three-layer certificates uniformly adopt PQC algorithms such as Dilithium or Falcon. (4) Validity structure - the validity period of the child certificate must be completely included within the validity period of the parent certificate.

[0071] Mathematical representation of differential coding: The certificate chain is represented as a sequence C = (c_0, c_1, ..., c_n), where c_i is the DER code of the i-th certificate. Define the differential sequence D = (d_0, d_1, ..., d_n), where: • d_0 = c_0 (the root certificate remains intact); • d_i = c_i The `shared(c_i, c_{i-1})` method stores only the differences between adjacent certificates. The `shared()` function extracts shared fields from the DER encoding. Taking a Dilithium3 three-layer chain as an example: RootCA (52KB) remains intact; InterCA stores only the differences (SubjectDN, SPKI, signature value, sequence number, etc.), approximately 21KB; Leaf stores only the differences from InterCA, approximately 18KB. The deduplication effect is approximately 50%-60% of the original size. Key advantage: Differential encoding is a fully comprehensible lossless compression that does not affect the cryptographic security of the certificate.

[0072] In this embodiment, stage two is lattice basis reduction compression based on the LLL algorithm. This is the most original coding segment in this embodiment. The public key and signature of PQC signature algorithms (Dilithium, Falcon, etc.) are mathematically vectors or matrices in a lattice. Taking Dilithium3 as an example, its public key contains a matrix A∈R_q^{k×l} and a vector t=A·s∈R_q^k, where R_q= q[X] / (X^n+1) is a polynomial ring. These data are represented using a "standard basis"—that is, using polynomial coefficients in the NTT field as basis vectors. However, the same lattice can be represented by different bases, and some bases will be more "compact" than others—this is the core idea of ​​lattice basis reduction.

[0073] The mathematical principle of lattice reduction is as follows: For a given lattice basis B={b_1,b_2,...,b_k}, the LLL algorithm outputs a set of LLL reduced basis B*={b*_1,b*_2,...,b*_k}, satisfying the following conditions: (1)|μ_{i,j}|≤1 / 2, where μ_{i,j} is the Gram-Schmidt coefficient, ensuring that the basis vectors are relatively orthogonal; (2)∥b*_i∥^2≤δ·∥b*_{i+1}∥^2, ensuring that the growth rate of the basis vector length is controlled. Parameter selection: δ=0.75 (standard recommended value), maximum number of iterations max_iter=1000. Key property: The transformation from the standard basis to the LLL reduced basis is comprehensible! The vectors of the LLL reduced basis are shorter and more orthogonal than those of the standard basis, so the same lattice can be represented with fewer bits. During storage, we record the LLL reduced basis representation and the transformation matrix T from the standard basis to the reduced basis (the transformation matrix typically requires only about 150 bytes). During decoding, the standard basis representation is recovered from the reduced basis and T, with negligible computational cost (approximately 20 μs).

[0074] Compression Performance Tests: For a Dilithium3 public key (1952-byte standard basis representation), after LLL reduction, it can be represented as approximately 1340 bytes, a compression rate of -31%; a Dilithium3 signature (3293 bytes) is reduced to approximately 2180 bytes, a compression rate of -34%. For Falcon-512, the public key is compressed from 897 bytes to approximately 640 bytes (-29%), and the signature is compressed from 690 bytes to approximately 490 bytes (-29%). Security Guarantee: Lattice basis reduction is a completely mathematically equivalent transformation—the reducing basis and the standard basis generate the same lattice. The reducing basis itself does not reveal any new cryptographic information because the standard basis can be completely reconstructed from the reducing basis. This is the fundamental difference between this embodiment and general compression—SCCE utilizes the inherent mathematical structure (lattice) of the PQC algorithm for compression, rather than simply performing statistical substitutions at the bit level.

[0075] In this embodiment, stage three is post-processing based on entropy coding of Asymmetric Numerical Systems (ANS). The data stream after differential deduplication and lattice basis reduction still contains statistical redundancy. This embodiment uses ANS (Asymmetric Numerical Systems) coding as the post-processing stage. ANS is a coding method close to the information entropy limit, with a compression ratio approximately 5%-8% higher than traditional Huffman coding, while its encoding and decoding speed is comparable to Huffman. ANS parameter settings: M=2048 states, adaptive probability update mode (probability table updated every 1KB). Overall compression effect: The total compression ratio of the three stages reaches 60%-70%, meaning the encoded size is 30%-40% of the original size. Specific example: A three-layer Dilithium3 certificate chain (original 154KB) is approximately 54KB after SCCE coding (RootCA: 52KB → 21KB; InterCA: 51KB → 18.5KB; Leaf: 51KB → 14.5KB), with a compression ratio of approximately 65%. The encoding latency is approximately 28ms (including the lattice base, which is reduced by approximately 15ms), and the decoding latency is approximately 22ms, which is perfectly acceptable.

[0076] The progressive certificate verification protocol module is used to split the certificate chain verification process into two stages: the first stage is digest-first verification, which completes identity verification by transmitting a certificate digest carrying a PQC signature. If the verification is successful, a TLS session is immediately established; the second stage is full post-verification, which asynchronously transmits the complete encoded certificate chain and performs full certificate verification after the session is established. If the verification fails, the session is terminated.

[0077] In this embodiment, the progressive certificate verification protocol module is implemented as follows:

[0078] Digest-first verification phase: The client sends a certificate digest request carrying a client-side random number. The server responds with a certificate digest packet, which contains the hash value of the three-layer certificate public key, a timestamp, and the server's PQC signature. After the client verifies that the signature is valid and the timestamp is within the validity period, a TLS session is immediately established and application data transmission is initiated.

[0079] Complete post-verification phase: After the session is established, the server asynchronously transmits the complete certificate chain with sparse encoding in the background; after receiving it, the client decodes it and performs certificate chain path verification, signature verification, and revocation status verification; if the verification is successful, the session is maintained; if the verification fails, a reset message is sent in the next round-trip cycle to terminate the session.

[0080] Specifically, the Progressive Certificate Verification Protocol (PCVP) is the second core module of this embodiment. The core idea of ​​PCVP is to break the traditional assumption that "a complete certificate chain must be verified before a session can be established." By dividing the certificate chain transmission and verification into two phases, "digest first" and "complete after", PCVP achieves decoupling of handshake latency and certificate chain size.

[0081] Phase 1 (Digest Priority Verification): The client sends a CertDigestReq request packet (64 bytes, containing the client's random number Nonce_c). The server responds with a CertDigest packet (64 bytes, containing: • SPKI hash: SHA-256(SPKI_leaf||SPKI_inter||SPKI_root), ensuring complete public key information for the three-layer certificate; • Timestamp: The timestamp is the server's current time, with a precision of 1μs and a lifetime of 1 second; • PQC signature: Dilithium3 signature binding (SPKI_hash||Timestamp||Nonce_c), ensuring unforgeability. After receiving the digest packet, the client verifies the PQC signature. If the signature verification passes and the timestamp is within 1 second, a TLS session is immediately established, and application layer data transmission begins. At this point, the handshake latency is only network RTT + 64B transmission time + a single Dilithium3 signature verification (1.55ms), approximately 2ms.

[0082] Phase Two (Full Chain Post-Verification): After the session is established, the server asynchronously transmits the complete encoded certificate chain (the size of the encoded SCCE is approximately 54KB) in the background. The transmission delay is approximately 44ms (10Mbps link). Upon receiving the certificate chain, the client performs a full verification: (1) Decodes the SCCE data (22ms); (2) Verifies the certificate chain path and signature (52ms); (3) Verifies the revocation status (background OCSP / CRL). If the full verification passes, the session is confirmed secure; if the verification fails, an RST is sent in the next TLSRTT to terminate the session.

[0083] In this embodiment, a security analysis of the Progressive Certificate Verification (PCVP) protocol is also performed. The security of PCVP can be reduced to the unforgeability of the PQC signature. Specifically: • Digest forgery resistance: To forge a CertDigest packet, an attacker must generate a valid Dilithium3 signature for (SPKI_hash, Timestamp, Nonce_c), which is computationally infeasible. • Man-in-the-middle resistance: The signature in the digest packet is bound to the client's Nonce, preventing the attacker from replaying the digest packet. • Downgrade resistance: The digest packet contains the algorithm OID; if the server attempts to downgrade to the classic algorithm, the client can automatically reject it. • Risk window analysis: The interval from successful digest verification to full verification completion is approximately 60ms. Within this window, an attacker can transmit a maximum of 6KB of data (10Mbps link). The computational complexity of forging a valid Dilithium3 signature is 2^128, which is physically infeasible. Therefore, PCVP's ​​security level is the same as standard TLS full verification.

[0084] The domain-level Bloom filter pre-caching module is used to maintain the Bloom filter index of commonly used certificate chains in the domain on the domain controller side. Before the client initiates a connection, it pre-queries the cache status and achieves a zero round-trip time handshake when the cache is hit.

[0085] In this embodiment, the domain-level Bloom filter pre-caching module is implemented as follows:

[0086] The domain controller maintains a global Bloom filter, configuring the bit array size and the number of hash functions;

[0087] When a new certificate is issued, a Bloom filter is automatically inserted and the update is broadcast. When a certificate is revoked, it is recorded through a separate small revocation list. The Bloom filter is rebuilt periodically on a weekly basis to eliminate the cumulative bias of false positives.

[0088] The client is configured with an LRU cache to store the verified encoded certificate chain. Before connecting, it queries the domain-level Bloom filter. If a match is found, it reads the local cache for direct verification, achieving a zero round-trip time handshake.

[0089] When a new certificate is issued, it is automatically inserted into a Bloom filter and broadcast as an update. The specific update method includes: when a new certificate is issued, the domain controller automatically inserts it into a Bloom filter and broadcasts an update notification to all clients in the domain.

[0090] When a certificate is revoked, the Bloom filter does not support deletion operations. Therefore, the domain controller maintains a separate small revocation list that only stores the SPKI hash of the revoked certificate. The Bloom filter performs a full rebuild once a week, regenerating it from the database to eliminate accumulated false positive biases.

[0091] Specifically, the Domain Controller (DC) maintains a global Bloom filter, which inserts certificate chain identifiers commonly used by all devices within the domain. Bloom filter parameters are designed as follows: bit array size m = 8 Mbits (1 MB), number of hash functions k = 7, supports inserting 100K certificate chain records, and the false positive rate (FPR) is controlled below 1%. Insertion operation: BF.insert(h_i(SPKI_hash‖chain_id)) for i ∈ [1, 7], where chain_id = SHA-256 (certificate chain DER encoding).

[0092] The domain-level certificate chain pre-caching mechanism update strategy includes: • When a new certificate is issued, the Domain Controller (DC) automatically inserts a Certificate Framework (BF) and broadcasts an update notification. • When a certificate is revoked, the DC maintains a small revocation list (RL) (<10KB, containing the revoked certificate sequence number), and the BF does not need to be deleted. • The BF is periodically rebuilt (weekly) to eliminate accumulated FPR bias. Client caching: An LRU strategy is used, with a capacity of N=128 entries and total memory <7MB. Before initiating a connection, the client queries the BF: if a match is found, the local LRU cache is checked; if the local cache also matches, full verification can be performed directly, achieving a 0-RTT direct connection; if the local cache does not match, the complete encoded certificate chain is requested. Cache hit rate evaluation: In a typical enterprise environment, the hit rate for repeated connections within the same service is >95%, the hit rate for first connections across services is approximately 40%, and the overall hit rate is approximately 65%. This means that 65% of TLS connections can achieve a handshake latency of <1ms.

[0093] The secure session establishment interface is designed to be compatible with the standard TLS 1.3 protocol and the progressive authentication protocol, supporting adaptive protocol switching and smooth deployment.

[0094] Specifically, the secure session establishment interface is responsible for protocol compatibility and adaptive switching: when the client initiates a TLS handshake, it carries a PCVP extended identifier. If the server supports the PCVP protocol, it enters the progressive verification process; if the server does not support it, it automatically falls back to the standard TLS 1.3 full certificate verification process to ensure backward compatibility.

[0095] This system supports three deployment modes to adapt to different scenarios:

[0096] TLS library plugin mode: Modify the certificate verification callback function of OpenSSL / BoringSSL, embed PCVP logic, which is completely transparent to the upper layer application and requires no modification to the business code;

[0097] Independent Certificate Proxy Service Mode: Deployed on the domain controller, all TLS connections are centrally processed through the proxy, and Bloom filters and caches are managed uniformly, which is suitable for large enterprise domain environments;

[0098] Lightweight SDK mode: Implemented in pure C language, code size <50KB, RAM usage <2MB, can be directly integrated into the firmware of MCU-level IoT devices.

[0099] This embodiment discloses a quantum-resistant certificate chain sparse coding and progressive verification system. Addressing the technical problem of excessively high TLS handshake latency caused by the explosion of PQC certificate chain size in the post-quantum era, this embodiment constructs a three-pronged solution: the certificate chain sparse encoder employs a three-stage pipeline of differential deduplication coding, LLL lattice reduction compression, and ANS entropy coding to losslessly reduce the certificate chain size; the progressive certificate verification protocol splits certificate verification into two stages: digest-first verification and full-after verification, decoupling handshake latency from certificate chain size; and a domain-level Bloom filter pre-caching mechanism enables cross-device certificate chain sharing, achieving zero-round-trip time handshakes upon cache hit. This embodiment can significantly reduce TLS handshake latency in PQC scenarios, achieving a security level consistent with standard TLS, and is suitable for bandwidth-constrained and latency-sensitive scenarios such as V2X for vehicle-to-everything (V2X), industrial IoT, and low-Earth orbit satellite communication.

[0100] Based on the same inventive concept, embodiments of this invention disclose a quantum-resistant certificate chain sparse coding and progressive verification method, such as... Figure 2 ,include:

[0101] S100. Preprocess the certificate chain encoding: Perform differential deduplication encoding, LLL lattice basis reduction compression and ANS entropy encoding on the PQC quantum-resistant certificate chain in sequence to generate the compressed encoded certificate chain;

[0102] S200. Handshake with digest first: The client sends a certificate digest request carrying a random number to the server. The server returns a digest packet containing the public key hash, timestamp, and PQC signature. After verifying the validity of the digest, the client immediately establishes a TLS session and transmits application data.

[0103] S300. Perform post-full verification: After the session is established, the server asynchronously transmits the encoded certificate chain in the background. The client receives the certificate chain, decodes it, and completes full verification of the certificate chain. If the verification fails, the session is terminated.

[0104] S400 accelerates domain-level pre-caching: The domain controller maintains a Bloom filter index for the certificate chain within the domain. Before a client connects, it pre-queries the cache. If the cache is hit, it directly reads the local cache to complete the verification, achieving a zero round-trip time handshake.

[0105] The specific implementation method of a quantum-resistant certificate chain sparse coding and progressive verification method is described in detail in a quantum-resistant certificate chain sparse coding and progressive verification system, and will not be repeated here in this embodiment.

[0106] Based on the same inventive concept, embodiments of the present invention also provide an electronic device. Figure 3 This is a structural block diagram of an electronic device provided in an embodiment of the present invention. Figure 3 As shown, an embodiment of the present invention provides an electronic device including: one or more processors 101, a memory 102, and one or more I / O interfaces 103. The memory 102 stores one or more programs, which, when executed by the one or more processors, cause the one or more processors to implement any of the methods described in the above embodiments; the one or more I / O interfaces 103 are connected between the processor and the memory, configured to enable information interaction between the processor and the memory.

[0107] The processor 101 is a device with data processing capabilities, including but not limited to a central processing unit (CPU); the memory 102 is a device with data storage capabilities, including but not limited to random access memory (RAM, more specifically SDRAM, DDR, etc.), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), and flash memory (FLASH); the I / O interface (read / write interface) 103 is connected between the processor 101 and the memory 102, and can realize information interaction between the processor 101 and the memory 102, including but not limited to a data bus (Bus).

[0108] In some embodiments, the processor 101, memory 102, and I / O interface 103 are interconnected via bus 104, and thus connected to other components of the computing device.

[0109] In some embodiments, the one or more processors 101 include a field-programmable gate array.

[0110] This invention also provides a computer-readable medium. The computer-readable medium stores a computer program, which, when executed by a processor, implements the steps of any of the methods described in the above embodiments. The computer-readable storage medium may be a volatile or non-volatile computer-readable storage medium.

[0111] This invention also provides a computer program product, including computer-readable code, or a non-volatile computer-readable storage medium carrying computer-readable code, wherein when the computer-readable code is run in the processor of an electronic device, the processor in the electronic device executes the above-described method.

[0112] Those skilled in the art will understand that all or some of the steps, systems, and apparatuses disclosed above, and their functional modules / units, can be implemented as software, firmware, hardware, or suitable combinations thereof. In hardware implementations, the division between functional modules / units mentioned above does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit (ASIC). Such software can be distributed on a computer-readable storage medium, which may include computer storage media (or non-transitory media) and communication media (or transient media).

[0113] As is known to those skilled in the art, the term computer storage medium includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information, such as computer-readable program instructions, data structures, program modules, or other data. Computer storage media includes, but is not limited to, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), static random access memory (SRAM), flash memory or other memory technologies, portable compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, it is known to those skilled in the art that communication media typically contain computer-readable program instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0114] The computer-readable program instructions described herein can be downloaded from computer-readable storage media to various computing / processing devices, or downloaded via a network, such as the Internet, local area network, wide area network, and / or wireless network, to an external computer or external storage device. The network may include copper transmission cables, fiber optic transmission, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards them to the computer-readable storage media in the respective computing / processing device.

[0115] The computer program instructions used to perform the operations of this invention may be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, or source code or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++, etc., and conventional procedural programming languages ​​such as the "C" language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving a remote computer, the remote computer may be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or may be connected to an external computer (e.g., via the Internet using an Internet service provider). In some embodiments, electronic circuitry, such as programmable logic circuitry, field-programmable gate arrays (FPGAs), or programmable logic arrays (PLAs), is personalized by utilizing state information from the computer-readable program instructions. This electronic circuitry can execute the computer-readable program instructions to implement various aspects of the invention.

[0116] The computer program product described herein can be implemented specifically through hardware, software, or a combination thereof. In one alternative embodiment, the computer program product is specifically embodied in a computer storage medium; in another alternative embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0117] Various aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0118] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0119] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions executed on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0120] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the blocks may occur in a different order than those shown in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0121] Example embodiments have been disclosed herein, and while specific terminology has been used, it is for illustrative purposes only and should be construed as such, and is not intended to be limiting. In some instances, it will be apparent to those skilled in the art that features, characteristics, and / or elements described in conjunction with particular embodiments may be used alone, or in combination with features, characteristics, and / or elements described in conjunction with other embodiments, unless otherwise expressly indicated. Therefore, those skilled in the art will understand that various changes in form and detail may be made without departing from the scope of the invention as set forth in the appended claims.

Claims

1. A quantum-resistant certificate chain sparse coding and asymptotic verification system, characterized in that, include: This includes a certificate chain sparse encoder, a progressive certificate verification protocol module, a domain-level Bloom filter pre-caching module, and a secure session establishment interface; among which: The certificate chain sparse encoder is used to perform lossless compression encoding of PQC quantum-resistant certificate chains using a three-stage encoding pipeline. Specifically, the first stage is differential deduplication encoding, which extracts the shared fields of adjacent certificates and stores only the differences between certificates; the second stage is lattice basis reduction compression, which compresses the lattice basis public key and signature data in the certificate by performing an equivalent basis transformation based on the LLL lattice basis reduction algorithm; and the third stage is ANS entropy encoding post-processing, which performs statistical entropy compression on the data streams output from the first two stages. The progressive certificate verification protocol module is used to split the certificate chain verification process into two stages: the first stage is digest-first verification, which completes identity verification by transmitting a certificate digest carrying a PQC signature. If the verification is successful, a TLS session is immediately established; the second stage is full post-verification, which asynchronously transmits the complete encoded certificate chain and performs full certificate verification after the session is established. If the verification fails, the session is terminated. The domain-level Bloom filter pre-caching module is used to maintain the Bloom filter index of commonly used certificate chains in the domain on the domain controller side. Before the client initiates a connection, it pre-queries the cache status and achieves a zero round-trip time handshake when the cache is hit. The secure session establishment interface is designed to be compatible with the standard TLS 1.3 protocol and the progressive authentication protocol, supporting adaptive protocol switching and smooth deployment.

2. The system according to claim 1, characterized in that, The specific implementation of the differential deduplication encoding is as follows: the three-layer certificate chain is represented as a DER encoded sequence. ,in For root certificate, For intermediate CA certificates, For leaf certificates; define difference sequences ,in For complete root certificate data, The shared() function extracts shared fields between adjacent certificates from DER encoding, including the issuer distinguishable name, certificate policy object identifier, signature algorithm object identifier, and validity period structure field; differential encoding is a lossless and reversible transformation, and the original certificate chain can be completely recovered during decoding using the base certificate and the difference value.

3. The system according to claim 1, characterized in that, The specific implementation of the lattice basis reduction compression is as follows: For the public key and signature data of the PQC algorithm, the lattice vector represented by its standard basis is used as input; the LLL algorithm is used to output the LLL reduction basis, and the reduction parameters and maximum number of iterations are set to make the reduction basis vector shorter and more orthogonal; during storage, the LLL reduction basis data and the transformation matrix from the standard basis to the reduction basis are recorded, and during decoding, the standard basis representation is recovered in reverse through the transformation matrix; the lattice basis reduction is a mathematically equivalent transformation, and the same lattice is generated before and after the reduction, without changing the cryptographic security.

4. The system according to claim 1, characterized in that, The specific implementation method of the progressive certificate verification protocol module is as follows: Digest-first verification phase: The client sends a certificate digest request carrying a client-side random number. The server responds with a certificate digest packet, which contains the hash value of the three-layer certificate public key, a timestamp, and the server's PQC signature. After the client verifies that the signature is valid and the timestamp is within the validity period, a TLS session is immediately established and application data transmission is initiated. Complete post-verification phase: After the session is established, the server asynchronously transmits the complete certificate chain with sparse encoding in the background; after receiving it, the client decodes it and performs certificate chain path verification, signature verification, and revocation status verification; if the verification is successful, the session is maintained; if the verification fails, a reset message is sent in the next round-trip cycle to terminate the session.

5. The system according to claim 1, characterized in that, The specific implementation of the domain-level Bloom filter pre-caching module is as follows: The domain controller maintains a global Bloom filter, configuring the bit array size and the number of hash functions; When a new certificate is issued, a Bloom filter is automatically inserted and the update is broadcast. When a certificate is revoked, it is recorded through a separate small revocation list. The Bloom filter is rebuilt periodically on a weekly basis to eliminate the cumulative bias of false positives. The client is configured with an LRU cache to store the verified encoded certificate chain. Before connecting, it queries the domain-level Bloom filter. If a match is found, it reads the local cache for direct verification, achieving a zero round-trip time handshake.

6. The system according to claim 5, characterized in that, When a new certificate is issued, it is automatically inserted into the Bloom filter and the update is broadcast. The specific update method includes: when a new certificate is issued, the domain controller automatically inserts it into the Bloom filter and broadcasts the update notification to all clients in the domain. When a certificate is revoked, the Bloom filter does not support deletion operations. Therefore, the domain controller maintains a separate small revocation list that only stores the SPKI hash of the revoked certificate. The Bloom filter performs a full rebuild once a week, regenerating it from the database to eliminate accumulated false positive biases.

7. The system according to claim 1, characterized in that, The system supports three deployment modes: TLS library plugin mode, independent certificate proxy service mode, and lightweight SDK mode, which are respectively adapted to general server, large domain environment, and resource-constrained IoT devices.

8. The system according to claim 1, characterized in that, The specific methods for implementing the secure session establishment interface include: when the client initiates a TLS handshake, it carries the PCVP extended identifier. If the server supports the PCVP protocol, it enters the progressive verification process; if the server does not support it, it automatically falls back to the standard TLS 1.3 full certificate verification process to ensure backward compatibility.

9. A quantum-resistant certificate chain sparse coding and asymptotic verification method, characterized in that, include: Preprocessing of certificate chain encoding: Differential deduplication encoding, LLL lattice basis reduction compression and ANS entropy encoding are performed sequentially on the PQC quantum-resistant certificate chain to generate a compressed encoded certificate chain; Handshake with digest first: The client sends a certificate digest request carrying a random number to the server. The server returns a digest packet containing the public key hash, timestamp, and PQC signature. After the client verifies the validity of the digest, it immediately establishes a TLS session and transmits application data. Perform full post-verification: After the session is established, the server asynchronously transmits the encoded certificate chain in the background. The client receives the certificate chain, decodes it, and completes full verification of the certificate chain. If the verification fails, the session is terminated. Domain-level pre-caching acceleration: The domain controller maintains a Bloom filter index of the certificate chain within the domain. Before the client connects, it pre-queries the cache. When the cache is hit, it directly reads the local cache to complete the verification, achieving a zero round-trip time handshake.

10. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs; When the one or more programs are executed by the one or more processors, the one or more processors implement the method as described in claim 9.

Images