Encrypted traffic deep packet inspection method, system, and electronic device

Abstract

The application discloses a kind of encrypted traffic deep packet inspection method, system and electronic equipment, it is related to Internet of Things privacy protection technical field, the method includes: gateway generates key set according to security parameter, and plain text detection rule set is converted into encrypted encoding filter table and encrypted rule set;Gateway processes data packet based on key set to generate encrypted token set, and sends encrypted token set to first layer server;First layer server filters encrypted token set according to encrypted encoding filter table, and initiates component request to gateway, generates search trapdoor according to key component group that gateway issues, and sends search trapdoor to second layer server;Second layer server detects encrypted rule set based on search trapdoor, obtains detection result, and returns detection result to gateway, and detection result is the rule identifier set of matching success.This application carries out real-time detection to encrypted traffic deep packet under the premise of ensuring that flow data and detection rule itself are private.

Description

Technical Field

[0001] This application relates to the field of IoT privacy protection technology, and in particular to methods, systems and electronic devices for deep packet inspection of encrypted traffic. Background Technology

[0002] With the widespread adoption of encryption protocols such as Hypertext Transfer Protocol Secure (HTTPS) and Transport Layer Security (TLS), network traffic privacy has been effectively protected. However, this has also made it difficult to directly apply traditional Deep Packet Inspection (DPI) technology. In scenarios such as cloud computing, the Internet of Things (IoT), and 5G, ensuring network security often requires relying on middleware boxes to perform real-time analysis of encrypted traffic to identify threats such as data breaches and malware.

[0003] Currently, some technologies have attempted to perform encrypted traffic inspection while protecting privacy. Although the PrivDPI system reduces complexity, its detection capabilities rely on a fixed set of rules, making it unable to flexibly adapt to new threats. The BlindBox system suffers from high computational and communication overhead and difficulty in supporting large-scale rule sets, which seriously affects the real-time performance of the detection.

[0004] Therefore, how to perform real-time detection of encrypted traffic deep packets while ensuring the privacy of traffic data and detection rules themselves is a problem that urgently needs to be solved. Summary of the Invention

[0005] The main purpose of this application is to provide a method, system, and electronic device for deep packet inspection of encrypted traffic, aiming to solve the technical problem of how to perform real-time detection of deep packets in encrypted traffic while ensuring the privacy of traffic data and the detection rules themselves.

[0006] To achieve the above objectives, this application proposes a method for deep packet inspection of encrypted traffic. This method is applied to a communication system, which includes a gateway, a Layer 1 server, and a Layer 2 server. The method comprises: The gateway generates a key set based on security parameters, and converts the plaintext detection rule set into an encrypted encoding filter table and an encryption rule set based on the key set. The gateway processes data packets based on the key set to generate an encrypted token set, and sends the encrypted token set to the first-layer server; The first-layer server filters the encrypted token set according to the encrypted encoding filter table, initiates a component request to the gateway, assembles a search trapdoor according to the key component issued by the gateway, and sends the search trapdoor to the second-layer server. The second-layer server detects the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway. The detection result is a set of rule identifiers that match successfully.

[0007] In one embodiment, the encryption rule set includes an inverted index and a forward index. The steps of the gateway generating a key set based on security parameters and converting the plaintext detection rule set into an encrypted encoded filter table and an encryption rule set based on the key set include: The gateway generates a key set based on security parameters. The key set includes at least a first key, a second key, a third key, and a fourth key. The first key is used to encrypt the token of the traffic data packet. The second key is used to encrypt the rule identifier in the plaintext detection rule set. The third key is used to generate the key component in the search trapdoor for the second-layer server. The fourth key is used to generate a verification tag for the gateway to verify the detection results returned by the second-layer server. The rule keywords are encrypted based on the pseudo-random function and the first key to generate encrypted rule keywords. The encrypted rule keywords are then mapped to the bit array of the Bloom filter using a hash function to obtain an encrypted encoded filter table. In the locally maintained keyword version table, determine the corresponding version number and update counter for the encryption rule keywords; An encryption key is generated based on the third key, the encryption rule keywords, and the version number. The inverted index is constructed based on the encryption key, and the forward index is constructed based on the second key to generate the encryption rule set. The encrypted encoding filter table is deployed to the first-layer server, and the encryption rule set is deployed to the second-layer server.

[0008] In one embodiment, the key set further includes a fifth key. The steps of the first-layer server filtering the encrypted token set according to the encrypted encoding filter table, initiating a component request to the gateway, assembling a search trapdoor according to the key component issued by the gateway, and sending the search trapdoor to the second-layer server include: The first-layer server filters the encrypted token set according to the Bloom filter in the encrypted encoding filter table to obtain the filtered tokens; Based on the fifth key, the filtered tokens are serialized and pseudo-randomly extended to generate an extended token set; The first-layer server sends a component request to the gateway for the last token in the extended token set; The gateway obtains the current version number and current update counter corresponding to the last token from its locally maintained keyword version table, generates a first key component based on the third key and the current version number, generates a second key component based on the third key and the historical version number, and sends the first key component, the second key component and the current update counter to the first layer server. The first-layer server generates a search trapdoor based on the first key component, the second key component, the current update counter, and the extended token set, and sends the search trapdoor to the second-layer server.

[0009] In one embodiment, the step of the second-layer server detecting the encryption rule set based on the search trapdoor, obtaining a detection result, and returning the detection result to the gateway includes: The second-layer server calculates the inverted index label based on the first key component and the current update counter, and extracts rule identifiers and operators from the inverted index of the encryption rule set in a loop to obtain the first matching result set; Based on the second key component, the local cache is queried to obtain the historical matching result set, and the historical matching result set is merged with the first matching result set to obtain the merged set; Based on the rule identifiers in the merged set, query the forward index to obtain the forward index result set; The inverted index verification proof, the forward index verification proof, the forward index result set, and the extended token set are combined into a result tuple, and the result tuple is returned to the gateway as the detection result.

[0010] In one embodiment, the step of cyclically extracting rule identifiers and operators from the inverted index of the encryption rule set includes: Calculate the current inverted index label based on the current key component and the current update counter; Retrieve the corresponding inverted index data from the inverted index based on the current inverted index label; Generate a hash value based on the current key component; Perform an XOR operation between the inverted index data and the hash value to parse out the rule identifier and the operator; Decrement the current update counter and return to the step of calculating the current inverted index label based on the current key component and the current update counter, until the corresponding inverted index data can no longer be obtained.

[0011] In one embodiment, after the gateway generates a key set based on security parameters and converts the plaintext detection rule set into an encrypted encoded filter table and an encrypted rule set based on the key set, the method further includes: The gateway generates new encryption rule keywords based on the first key according to the newly added rule keywords; Query the keyword version table to obtain the current version number of the new encryption rule keyword, and generate a new encryption key based on the third key and the current version number; A new inverted index entry is generated based on the new encryption key, and the new inverted index entry is sent to the second-layer server to update the encryption rule set; Update the update count corresponding to the new encryption rule keywords in the keyword version table.

[0012] In one embodiment, after the step of the second-layer server detecting the encryption rule set based on the search trapdoor, obtaining the detection result, and returning the detection result to the gateway, the method further includes: The gateway receives the detection result and the extended token set, the detection result including the rule identifier set; The gateway recovers the puncture key associated with the rule identifier from the detection results using its local key set; The gateway evaluates each token in the extended token set based on the puncture key. If the evaluation results of all tokens indicate that the puncture has failed, the data packet is determined to be a successful match between the data packet and the rule corresponding to the rule identifier.

[0013] In one embodiment, after the step of the second-layer server detecting the encryption rule set based on the search trapdoor, obtaining the detection result, and returning the detection result to the gateway, the method further includes: The gateway receives the detection result, the inverted index verification proof, and the forward index verification proof; the gateway reconstructs the inverted verification chain and the forward verification chain based on the local key set, the extended token set, and the detection result; The gateway compares the inverted verification chain with the inverted index verification proof to obtain a first comparison result; The gateway compares the forward verification chain with the forward index verification proof to obtain a second comparison result; If the first comparison result and the second comparison result are consistent, then the detection result is deemed to have passed verification.

[0014] In addition, to achieve the above objectives, this application also proposes an encrypted traffic deep packet inspection system, which includes a gateway, a first-layer server, and a second-layer server. The gateway is used to generate a key set based on security parameters, and to convert the plaintext detection rule set into an encrypted encoding filter table and an encryption rule set based on the key set; The gateway is also configured to process data packets based on the key set to generate an encrypted token set, and send the encrypted token set to the first-layer server; The first-layer server is used to filter the encrypted token set according to the encrypted encoding filter table, initiate a component request to the gateway, assemble a search trapdoor according to the key component issued by the gateway, and send the search trapdoor to the second-layer server. The second-layer server is used to detect the encryption rule set based on the search trapdoor, obtain the detection result, and return the detection result to the gateway. The detection result is a set of rule identifiers that are successfully matched.

[0015] In addition, to achieve the above objectives, this application also proposes an electronic device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the encrypted traffic deep packet inspection method as described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: (1) The gateway generates a key set based on security parameters and converts the plaintext detection rule set into an encrypted encoded filter table and an encrypted rule set based on the key set. The gateway processes data packets based on the key set to generate an encrypted token set and sends the encrypted token set to the first-layer server. The first-layer server filters the encrypted token set according to the encrypted encoded filter table and initiates a component request to the gateway. It assembles a search trapdoor based on the key component issued by the gateway and sends the search trapdoor to the second-layer server. The second-layer server detects the encrypted rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway. The detection result is a set of rule identifiers that match successfully. A collaborative detection architecture consisting of a gateway, a first-layer server, and a second-layer server is adopted, and a dual encryption conversion mechanism for rules and data packets based on the key set is introduced, which effectively solves the core problem of security detection without decrypting traffic. Specifically, by converting plaintext rules into an encrypted encoded filter table and an encrypted rule set for separate storage, the risk of privacy leakage of the detection rules themselves is solved. By converting data packets into encrypted tokens and search trapdoors for querying, the confidentiality of traffic data is guaranteed, and the combination of privacy protection and detection function is achieved. Furthermore, by setting up a two-layer processing mechanism, the first-layer server uses an encoded filtering table for rapid coarse screening, reducing the proportion of traffic that the second-layer server performs for encrypted matching calculations. This ensures the privacy of traffic data and the detection rules themselves, while enabling real-time detection of encrypted traffic deep packets, significantly improving the overall system's processing efficiency for encrypted traffic and making it more suitable for large-scale, real-time network environments.

[0017] (2) The gateway generates a key set based on security parameters. The key set includes at least a first key, a second key, a third key, and a fourth key. The first key is used to encrypt the token of the traffic data packet, the second key is used to encrypt the rule identifier in the plaintext detection rule set, the third key is used to generate the key component in the search trapdoor for the second-layer server, and the fourth key is used to generate a verification tag for the gateway to verify the detection results returned by the second-layer server. The rule keywords are encrypted based on a pseudo-random function and the first key to generate encrypted rule keywords. The encrypted rule keywords are then mapped to the bit array of the Bloom filter using a hash function to obtain an encrypted encoded filter table. The corresponding version number and update counter are determined for the encrypted rule keywords in the locally maintained keyword version table. An encryption key is generated based on the third key, the encrypted rule keywords, and the version number. The inverted index is constructed based on the encryption key, and the forward index is constructed based on the second key to generate an encrypted rule set. The encrypted encoded filter table is deployed to the first-layer server, and the encrypted rule set is deployed to the second-layer server. Through the linkage mechanism of dynamic version number and update counter, it is ensured that new rules cannot be associated with historical tokens. Even if intermediate devices store old versions of search tokens, they cannot match the updated rule set, thus completely solving the problem of historical privacy leaks caused by rule updates in traditional solutions. A two-layer index architecture and token expansion mechanism significantly improve detection efficiency and privacy. The collaborative working mechanism of inverted and forward indexes greatly reduces the complexity of rule matching, achieving efficient and accurate matching. The token expansion module performs serialized pseudo-random expansion on unfiltered tokens, obscuring the quantitative characteristics of the original rule keywords, preventing intermediate devices from inferring the rule structure from the token length, while optimizing the retrieval range of single token matching and significantly reducing redundant computation.

[0018] (3) The gateway receives the detection result and the extended token set. The detection result includes a set of rule identifiers. The gateway recovers the puncture key associated with the rule identifier from the detection result using its local key set. The gateway evaluates each token in the extended token set based on the puncture key. If the evaluation results of all tokens indicate that the puncture has failed, the data packet is determined to be successfully matched with the rule corresponding to the rule identifier. In addition, the gateway receives the detection result, the inverted index verification proof, and the forward index verification proof. Based on the local key set, the extended token set, and the detection result, the gateway reconstructs the inverted verification chain and the forward verification chain. The inverted verification chain is compared with the inverted index verification proof to obtain the first comparison result. The forward verification chain is compared with the forward index verification proof to obtain the second comparison result. If both the first comparison result and the second comparison result are consistent, the detection result is determined to be verified. The verification tag dynamically associates the rule version with the identifier through multi-binding technology. After the rule is updated, the historical verification chain automatically becomes invalid to prevent intermediate devices from forging matching results. The forward index verification tag uses key binding hash technology to ensure data integrity. The gateway verifies results through cumulative calculations, completing authenticity checks without interacting with the server, thus significantly reducing communication costs. Attached Figure Description

[0019] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0020] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 This is a flowchart illustrating the first embodiment of the encrypted traffic deep packet inspection method of this application; Figure 2 This is a schematic diagram of the principle modules of the encrypted traffic deep packet inspection system of this application; Figure 3 This is a schematic diagram of the device structure for the hardware operating environment of the electronic device involved in this application.

[0022] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0023] The technical solutions in the embodiments of this application will be clearly and completely described below with reference to the embodiments of this application. Obviously, the described embodiments are only a part of the embodiments of this application, and not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this application.

[0024] This application provides a method for deep packet inspection of encrypted traffic. This method is applied to a communication system, which includes a gateway, a first-layer server, and a second-layer server. Specifically, refer to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the encrypted traffic deep packet inspection method of this application. In this embodiment, the encrypted traffic deep packet inspection method includes steps S10 to S40:

[0025] In step S10, the gateway generates a key set based on security parameters, and converts the plaintext detection rule set into an encrypted encoded filter table and an encrypted rule set based on the key set.

[0026] It's important to note that a gateway is a trusted security entity between an internal network and an external network or network domain to be inspected. It is responsible for system initialization, including generating all keys, converting plaintext rules into encrypted form, and processing network data packets to be inspected. Security parameters are numerical parameters that control the security strength of a cryptographic scheme, determining the key length, randomness, etc., directly affecting the scheme's ability to resist attacks. The key set is a collection of cryptographic keys generated by the gateway based on the security parameters, forming the foundation for the entire scheme's privacy-preserving computations. The plaintext detection rule set is the original set of rules used to identify specific threats, such as malware characteristics and attack commands; it can contain a series of keywords or feature patterns. The encrypted encoding filter table can be understood as a probabilistic data structure generated by the gateway using specific keys from the key set to encrypt and encode keywords in the plaintext detection rule set. For example, a Bloom filter serves as a tool for the first-layer server to quickly and initially filter traffic, removing obviously mismatched traffic, but it does not directly expose the rule content itself. The encryption rule set can be understood as the result of the gateway using a key set to perform deep encryption and structured processing on the complete plaintext detection rule set. All encryption rule information used for the final accurate matching is stored in ciphertext form on the second-layer server.

[0027] For example, during the system startup phase, the Internet Gateway (IGW) acts as a trusted entity and is responsible for generating the system master key set. According to the security policy, the plaintext detection rule set is converted into an encrypted Encoding Filter Table (EFT) and Encryption Rule Set (ERS).

[0028] In step S20, the gateway processes data packets based on the key set to generate an encrypted token set and sends the encrypted token set to the first-layer server.

[0029] It's important to clarify that a data packet can be understood as the basic data unit transmitted in a network, referring to encrypted network traffic data that requires deep packet inspection to determine if it contains threats. An encrypted token set can be understood as a set of ciphertext "tags" or "query fragments" obtained by a gateway after processing the data packet content using a key set. The processing typically involves splitting the data packet into multiple tokens by delimiters; the tokens can be words. Then, cryptographic tools such as pseudo-random functions are used to encrypt each token into a fixed-length ciphertext. This set represents the encrypted query request of the data packet.

[0030] For example, traffic packets can be tokenized using delimiters; then, a pseudo-random function can be used to encode the traffic tokens, with each token... implement: Generate a set of crypto tokens The encrypted token set is sent to the first-level server. Separators include, but are not limited to, commas, periods, pauses, and question marks.

[0031] In step S30, the first-layer server filters the encrypted token set according to the encrypted encoding filter table, initiates a component request to the gateway, assembles the key component according to the key issued by the gateway to generate a search trapdoor, and sends the search trapdoor to the second-layer server.

[0032] It should be noted that the first-layer server can be understood as an intermediate processing node deployed in the method of this embodiment. The filtered tokens refer to the set of tokens remaining after the encrypted token set has been quickly filtered by the first-layer server using an encrypted encoding filter table, and those tokens require further precise matching checks. The search trapdoor can be understood as a secure query credential generated by the first-layer server based on the key component issued by the gateway and the filtered tokens. It authorizes and guides the second-layer server to perform specific search and matching operations within the encrypted rule set, without disclosing the specific content of the tokens and rules to the second-layer server.

[0033] In step S40, the second-layer server detects the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway.

[0034] It should be noted that the detection result is the set of rule identifiers that match successfully. The second-layer server can store the complete set of encryption rules. After receiving the search trapdoor from the first-layer server, it performs a matching operation on the ciphertext rules. The second-layer server uses the search trapdoor to perform a ciphertext matching query on the set of encryption rules to obtain the detection result. The detection result refers to the output generated by the second-layer server after completing the matching query. The set of rule identifiers is the specific content of the detection result, that is, a set of unique encrypted identifiers corresponding to the successfully matched rules.

[0035] This embodiment employs a collaborative detection architecture consisting of a gateway, a first-layer server, and a second-layer server. It introduces a dual encryption conversion mechanism for rules and data packets based on a key set, effectively solving the core challenge of performing security detection without decrypting traffic. Specifically, by converting plaintext rules into encrypted encoded filter tables and storing encrypted rule sets separately, the privacy risk of the detection rules themselves is mitigated. By converting data packets into encrypted tokens and search trapdoors for querying, the confidentiality of traffic data is ensured, achieving a balance between privacy protection and detection functionality. Furthermore, by setting up a two-layer processing mechanism, the first-layer server performs rapid coarse screening using the encoded filter table, reducing the proportion of traffic requiring encrypted matching calculations by the second-layer server. This significantly improves the overall system's processing efficiency for encrypted traffic while ensuring security, making it more suitable for large-scale, real-time network environments.

[0036] Based on the first embodiment described above, in the second embodiment, the encryption rule set includes an inverted index and a forward index, and step S10 includes: Step S101: The gateway generates a key set based on security parameters. The key set includes at least a first key, a second key, a third key, and a fourth key.

[0037] For example, security parameters can be expressed as First key The second key is used to encrypt the tokens in the traffic data packets. The third key is used to encrypt the rule identifiers in the plaintext detection rule set. The fourth key is used to generate the key component for the second-level server in the search trapdoor. Used to generate verification tags for the gateway to verify the detection results returned by the Layer 2 server.

[0038] Step S102: The rule keywords are encrypted based on the pseudo-random function and the first key to generate encrypted rule keywords. The encrypted rule keywords are then mapped to the bit array of the Bloom filter using a hash function to obtain the encrypted encoded filter table.

[0039] It's important to note that a pseudo-random function functions similarly to a random number generator; given the same key and input, the output is deterministic and appears random. Rule keywords refer to the specific features that constitute a detection rule, such as a specific string or byte pattern to be matched. Encryption rule keywords refer to the result of encrypting the rule keywords using the pseudo-random function with the first key; this is used to construct subsequent indexes and filters without revealing the original keyword information. A hash function is a one-way function that maps data of arbitrary length to a fixed hash value; it's used to calculate one or more array index positions for the encryption rule keywords. A Bloom filter is a probabilistic data structure used to quickly determine whether an element is not in a set. Its core is a very long binary vector, i.e., a bit array. In this step, the encryption rule keywords can be mapped to several positions in the bit array using a hash function and set to 1, thus constructing the encoded filter table.

[0040] For example, for each rule in the original detection rule set containing keywords The internal gateway first uses the first key. and pseudo-random functions Generate its fixed-length encryption code Subsequently, to support fast filtering by the first-layer servers, the gateway utilizes a set of independent hash functions. Encryption encoding Map the bit array to the Bloom filter and set the corresponding position to 1 to construct the encrypted encoded filter table EFT.

[0041] Step S103: Determine the corresponding version number and update counter for the encryption rule keywords in the locally maintained keyword version table.

[0042] It's important to note that the keyword version table can be understood as a query table maintained locally by the gateway, used to record the dynamic status information of each encryption rule keyword. It primarily includes a version number and an update counter. The version number, associated with each encryption rule keyword, is initially 1. It increments whenever a rule associated with a keyword is added or deleted (i.e., the rule set is updated). The version number is the basis for generating version-specific index keys and is the core mechanism for achieving forward privacy. The update counter, also associated with each encryption rule keyword, is initially 0. It records the number of times the encryption keyword is used to build inverted index entries, i.e., how many different rules it is included in. The update counter increments each time a new index entry is created for this keyword, ensuring that even if the same keyword is used multiple times, the generated index label is unique each time.

[0043] For example, for the detection rules to be processed The gateway uses a symmetric encryption key. Its original identifier Transformed into an irreversible rule-based encrypted identifier For each encrypted key in this rule The gateway has a local keyword version table. Query its current version number and update counter If this keyword is appearing for the first time, its state variable is initialized, represented as follows: , .

[0044] Step S104: Generate an encryption key based on the third key, encryption rule keywords, and version number; construct an inverted index based on the encryption key; construct a forward index based on the second key; and generate an encryption rule set.

[0045] It should be noted that the encryption key refers to the inverted index key derived from the third key, encryption rule keywords, and their version numbers using a pseudo-random function. It is the key material for generating specific inverted index entries, ensuring the confidentiality and version binding of the index. The inverted index is an index data structure whose core is establishing a mapping from "keywords" to "a list of rules containing those keywords." Keywords are encryption rule keywords, and the list is a set of encrypted rule identifiers containing those keywords. The second-layer server can quickly retrieve all relevant rule IDs based on the trapdoor. The forward index is another index data structure, complementary to the inverted index. Its core is establishing a mapping from "rule identifiers" to "keyword set keys." A specially processed piercing key is stored for each encrypted rule identifier, used on the gateway side to ultimately verify whether all keywords of a rule have been matched, thereby achieving multi-keyword exact matching and forward checking.

[0046] For example, the gateway utilizes a third key Generate a specific inverted index key for the keyword based on the current version number. Combined with cryptographic hash functions and Gateway calculates inverted index labels With inverted index data .in, The XOR operation masks the rule identifier and operator. such as adding rules Specifically, it is expressed as:

[0047] in, Indicates the inverted index label. and Both are hash functions. For the inverted index key, Update the counter for keywords. Indicates the operation type.

[0048] To support tamper-proof verification of matching results by the second-layer server, the gateway utilizes a fourth key. Calculate inverted index verification tags , represented as: Finally, the inverted index items Store to inverted index table In Location, i.e. And increment the update counter. .

[0049] To support precise matching checks for multiple keywords and forward privacy, the gateway adjusts the settings according to the current rules. Generate a random number And encrypt the set of all keywords contained in the rule. The puncture operation of the puncture-enabled pseudo-random function (t-PPRF) is performed to generate a puncture key specific to this rule. Using forward indexing of the master key The gateway masks the puncture key and calculates the forward index data. Simultaneously, a forward validation label bound to this forward index is generated. , will forward index item Store to forward index table In Location, i.e. .

[0050] Step S105: Deploy the encrypted encoding filter table to the first-layer server and deploy the encryption rule set to the second-layer server.

[0051] For example, after the internal gateway completes the construction of all the above encryption structures, it sends and deploys the Encoded Filter Table (EFT) to the Layer 1 server; and sends the Encryption Rule Set (ERS), which contains all rule features, to the Layer 1 server. and forward index table The system is then sent and deployed to the second-tier server, thus completing the system initialization phase.

[0052] This embodiment further employs a refined key division mechanism, clarifying the dedicated responsibilities of different keys and resolving the functional confusion and ambiguous security boundaries that may arise from a single key. This achieves clearer permission separation and higher system security. By using pseudo-random functions to encrypt rule keywords and constructing a Bloom filter, the privacy protection issue of rules is addressed while providing efficient and fast filtering capabilities for the first-layer server, significantly reducing the pressure of invalid traffic on the second-layer server. By independently maintaining a version number and update counter for each encrypted rule keyword, the forward privacy protection challenge during dynamic rule updates is resolved, ensuring that new rules are not associated with old tokens generated based on historical information. By constructing a two-layer encrypted rule set combining inverted and forward indexes, the inefficiency or insufficient functionality of a single index structure when supporting multi-keyword combination rule matching is resolved. The inverted index enables fast keyword-based retrieval, while the forward index supports the final multi-keyword precise matching verification. Finally, by deploying the coded filter table and the dual indexes of the encrypted rule set on the first-layer and second-layer servers respectively, the problem of centralized computation and storage load is solved, achieving the distribution of computational tasks and further isolation of privacy data.

[0053] In one implementation, after step S10, the method further includes: the gateway generating a new encryption rule keyword based on the first key according to the newly added rule keyword; querying the keyword version table to obtain the current version number of the new encryption rule keyword, and generating a new encryption key based on the third key and the current version number; generating a new inverted index entry based on the new encryption key, and sending the new inverted index entry to the second-layer server to update the encryption rule set; and updating the update count corresponding to the new encryption rule keyword in the keyword version table.

[0054] It should be noted that the Layer 2 server only updates index entries associated with new encryption rule keywords. After network threats evolve or security policies are adjusted, newly added rule keywords, such as new plaintext signatures or patterns, need to be added to the existing detection rule set. A new encryption rule keyword refers to the ciphertext form obtained by encrypting the aforementioned new rule keyword using a pseudo-random function with the first key. The current version number specifically refers to the version number value corresponding to the new encryption rule keyword found in the keyword version table at the time of update, indicating the current state of the keyword in the rule evolution history. The new encryption key specifically refers to the version-bound inverted index key temporarily generated to create an index for the new encryption rule keyword. It is derived from the third key, the new encryption rule keyword, and its current version number using a pseudo-random function, and is used to encrypt and protect the index data associated with this new keyword. A new inverted index entry refers to a complete entry in the inverted index created for a new encryption rule keyword. It contains an index label, encrypted rule identifier data, and a verification label, and will be inserted into or updated in the inverted index table stored on the Layer 2 server. During the dynamic update process, after receiving a new inverted index entry, the second-level server only modifies its local encryption rule set, specifically those data items in the inverted index that are directly related to the newly added keyword, without touching or rebuilding any index parts related to other existing keywords.

[0055] For example, when a new DPI rule is added to the rule set, the gateway updates the encoding filter table and the encryption rule set. Specifically, the encryption encoding can be calculated for the new rule keyword w. , pass A hash function will Mapped to a Bloom filter, the corresponding bit is set to 1 and sent to the first-layer server to generate a rule-based encryption identifier. For each keyword Query the version number and generate the inverted index key. And create the corresponding inverted index entries. Finally, a positive index entry is generated. The inverted index and forward index entries are then sent to the second-level server to complete the rule update.

[0056] This implementation employs a state-aware mechanism based on a keyword version table and continues to use a key system to encrypt and derive keys from newly added rule keywords, solving the technical challenge of securely and seamlessly introducing new detection rules into an encrypted traffic detection system. By querying the version table to obtain the current version number of the keyword and generating a new encryption key and inverted index entry bound to the version, it solves the problem of maintaining cryptographic context consistency and forward privacy protection continuity during dynamic rule updates, ensuring that new rules take effect immediately and that historical tokens cannot be associated with them. By accurately sending the generated new inverted index entry to the second-layer server and updating only the associated index entries, it solves the problem of huge computational and communication overhead caused by the need for global reconstruction of the encrypted index during updates in traditional schemes, achieving fine-grained and efficient incremental updates.

[0057] Based on the second embodiment described above, in the third embodiment, the key set further includes a fifth key, and step S30 includes: In step S301, the first-layer server filters the encrypted token set according to the Bloom filter in the encrypted encoding filter table to obtain the filtered token.

[0058] It should be noted that the Bloom filter in the encrypted encoding filter table refers to a binary bit array filled with encryption rule keyword mappings, constructed by the gateway during initialization. The first-layer server probabilistically and quickly determines whether the encrypted token might match any rule by calculating whether multiple hash positions in this bit array are all "1", thus achieving initial filtering.

[0059] For example, the first-layer server uses a fast filtering table to filter the encoded traffic tokens, for each calculate Number of hash locations: If there exists any Discard the token; otherwise, retain it in the set. .

[0060] Step S302: Based on the fifth key, perform serialization pseudo-random expansion on the filtered tokens to generate an expanded token set.

[0061] Specifically, the first-level server performs a pseudo-random function operation on the filtered tokens based on the fifth key pair in the key set to generate a first number of extended tokens; the first-level server performs a pseudo-random function operation on the filtered tokens and serial numbers based on the fifth key pair in the key set to generate a second number of extended tokens, wherein the sum of the first number and the second number is a fixed value.

[0062] For example, will Expand to Each token is represented as Generate an extended token set .

[0063] Step S303: The first-layer server sends a component request to the gateway for the last token in the extended token set.

[0064] In step S304, the gateway retrieves the current version number and current update counter corresponding to the last token from its locally maintained keyword version table.

[0065] For example, the first-layer server sends the final extended token etokn to the gateway, and the gateway queries the KXVT table locally: ,in, For the final extended token, For the latest extended token version number, Update the counter for the last extended token.

[0066] Step S305: Generate a first key component based on the third key and the current version number, generate a second key component based on the third key and the historical version number, and send the generated first key component, second key component and current update counter to the first-level server.

[0067] It should be noted that the first key component This refers to the inverted index key for the latest version, generated based on the third key and the current version number, used to search the rule index of the current version. Second key component This refers to the inverted index key of the previous version, generated based on a third key and a historical version number. It is used to query historical matching results based on older versions that may exist in the cache, thereby improving efficiency. The historical version number refers to the value preceding the current version number.

[0068] In step S306, the first-layer server generates a search trapdoor based on the first key component, the second key component, the current update counter, and the extended token set, and sends the search trapdoor to the second-layer server.

[0069] For example, the first-layer server receives components from the gateway. The gateway calculates the current and previous version keys using the first key component and the second key component, where the first key component and the second key component are respectively represented as: in, The first key component represents the inverted index key for the current version. The second key component represents the index key of the previous version. This is the third key. After the gateway completes the calculation, it updates the local version table, which is represented as: .

[0070] After the first-layer server receives the component, it generates a trapdoor. , represented as: in, The number of times the last extended token has been updated. To expand the token set.

[0071] In this embodiment, a fifth key is introduced into the key set, and a serialization pseudo-random expansion step is added. This solves the problem of the middle box, i.e., the first-layer server, potentially inferring the number of keywords and structural features contained in the original detection rule by observing the number of filtered tokens. By uniformly expanding the number of tokens to a fixed value, the internal structure of the rule is completely hidden, enhancing rule privacy. By selecting the last token from the expanded token set as the query representative and generating a search trapdoor containing the first and second key components based on its version number, the inefficiency caused by generating multiple trapdoors for a large number of tokens in a single query is solved, significantly reducing the communication and computational overhead with the second-layer server. Simultaneously, incorporating the previous version key into the trapdoor allows the second-layer server to securely and efficiently reuse locally cached historical matching results, further improving overall detection efficiency.

[0072] Based on the third embodiment described above, in the fourth embodiment, step S40 includes: In step S401, the second-layer server calculates the inverted index label based on the first key component and the current update counter, and extracts rule identifiers and operators from the inverted index of the encryption rule set in a loop to obtain the first matching result set.

[0073] The step of iteratively extracting rule identifiers and operators from the inverted index of the encryption rule set includes: calculating the current inverted index label based on the current key component and the current update counter; obtaining the corresponding inverted index data from the inverted index based on the current inverted index label; generating a hash value based on the current key component; performing an XOR operation on the inverted index data and the hash value to parse out the rule identifiers and operators; decrementing the current update counter and returning to the step of calculating the current inverted index label based on the current key component and the current update counter, until the corresponding inverted index data can no longer be obtained.

[0074] It should be noted that the first-layer server will contain a trapdoor. The data is sent to a second-layer server, which performs a matching operation on the trapdoor. This stage utilizes the mathematical properties of the XOR operation to securely extract the rule identifier without decrypting the original key and accumulates verification proofs. For example, the second-layer server first uses the current version key from the trapdoor. With update counter Through hash function Calculate inverted index labels ; Loop through the inverted index table until the query result is empty, that is... The loop terminates when the time is reached. Inside the loop, the following steps are executed sequentially:

[0075] (1) Retrieve the corresponding inverted index data and inverted index verification labels. In order to extract from the mask data Extract rule identifiers AND operator The server uses known parameters through a hash function. Perform XOR decryption. Because the formula for constructing the inverted index during the initialization phase is... Based on the associative law of the XOR operation and the reflexive property that XORing identical values ​​results in zero, the sequential decryption process performed by the server is as follows:

[0076] in, XOR operation, used for data obfuscation and restoration; This is a string concatenation tool used to combine data such as keywords, version numbers, and identifiers.

[0077] Through the aforementioned continuous operations, the second-layer server securely separated the key without obtaining any plaintext key. At the same time, the extracted verification tags Verification is achieved by accumulating the XOR operation into the inverted index. middle:

[0078] in, This serves as proof for verifying the inverted index. These are validation labels for inverted indexes, used to verify the integrity of the inverted index results.

[0079] (2) Based on the parsed operators ,Will and Rule identifier Add to the new collection respectively and delete collection After extraction is complete, the update counter will be decremented. ), and recalculate To continue the next round of extraction.

[0080] Step S402: Based on the second key component, query the local cache to obtain the historical matching result set, and merge the historical matching result set with the first matching result set to obtain the merged set.

[0081] It's important to note that the local cache refers to a temporary storage area maintained by the second-layer server itself, used to store the matching results of historical queries. Its key is typically based on the previous version key, and the value is the corresponding set of historical matching results and verification proof, designed to accelerate repeated queries for the same or similar keywords. The historical matching result set refers to the matching results retrieved from the local cache based on the second key component, from the previous or a specific historical query. It contains the set of rule identifiers matched for the same keyword in previous versions. The merged set refers to the temporary set obtained by performing a union operation between the first matching result set and the historical matching result set.

[0082] For example, after the loop ends, in order to support forward privacy of dynamic rules and improve efficiency, the previous version key in the trapdoor is used. Search the local cache for a previous matching result. If it exists, calculate and retrieve the historical result set. Historical verification proves , represented as:

[0083] The historical results are then merged into the current matching set, represented as: in, For newly added rule sets, this indicates the rule identifier for the storage operation type "add". The set, For a set of caching rules, To reconstruct the inverted index verification chain, it is the inverted index verification proof reconstructed by the gateway, used in conjunction with... Comparison.

[0084] Step S403: Query the forward index based on the rule identifier in the merged set to obtain the forward index result set.

[0085] It should be noted that the forward index result set refers to the result set obtained by the second-level server by querying the forward index table in the encryption rule set based on each rule identifier in the valid rule set.

[0086] For example, the final matching result of the inverted index can be calculated. This means removing deleted rules from the set of newly added rules, expressed as: in, For the set of deletion rules, the identifier represents the rule whose storage operation type is "delete (del)". A set of.

[0087] The latest matching result is retained in the cache for reuse in subsequent queries, as shown below: Step S404: Combine the inverted index verification proof, forward index verification proof, forward index result set, and extended token set into a result tuple, and return the result tuple as the detection result to the gateway.

[0088] It should be noted that the result tuple refers to the final detection result data structure assembled and returned to the gateway by the second-layer server after completing all matching operations. For example, this applies to inverted index matching results. Each rule identifier in Query the forward index table Retrieve the corresponding positive index data and verification tags. Calculate the forward index result, and... Add to forward index result set In the middle, we get:

[0089] Cumulative forward verification proof is represented as in, For positive index data, Verify the label for the positive index. Finally, the second-level server will return the complete result tuple. The result is returned to the internal gateway for subsequent forward checks and result verification.

[0090] In this embodiment, a cyclic extraction mechanism based on the first key component and the current update counter is employed to achieve the decryption and collection of batch rule identifiers. By querying the local cache based on the second key component to obtain and merge the historical matching result set, the computational redundancy problem when repeatedly querying the same or similar keywords is solved, and the matching efficiency is significantly improved by utilizing the caching mechanism. By integrating the forward index query and the generation process of result verification tags, and finally combining the verification proof, the forward index result set, and the original extended token set into a unified result tuple for return, the completeness of the matching logic and the verifiability of the results are ensured.

[0091] In one implementation, after step S40, the method further includes: the gateway receiving a detection result and an extended token set, the detection result including the rule identifier set; the gateway recovering the puncture key associated with the rule identifier from the detection result using a local key set; the gateway evaluating each token in the extended token set based on the puncture key, and if the evaluation results of all tokens indicate that the puncture has failed, then the data packet is determined to have successfully matched the rule corresponding to the rule identifier.

[0092] The step of the gateway recovering the puncture key associated with the rule identifier from the detection result using its local key set includes: the gateway generating a first mask value based on its local forward index master key and the rule identifier; and the gateway performing an XOR operation between the forward index data in the detection result and the first mask value to recover the puncture key.

[0093] It should be noted that the internal gateway receives the positive indexing results returned by the Layer 2 server. Subsequently, a forward check needs to be performed using a puncturable pseudo-random function (t-PPRF) to verify the unfiltered token set. Are all tokens strictly rule identifiers? The corresponding set of keywords.

[0094] For example, for the forward index result set Each element in The gateway needs to recover its corresponding specific puncture key. Because during the initialization phase, the formula for constructing the forward index data mask is: The gateway uses its own forward index master key. Perform the following continuous derivation and decryption process:

[0095] Through the above continuous derivation, the gateway securely and losslessly restored the rules for the current situation. puncture key According to the mathematical definition of a puncturable pseudorandom function, when using a puncture key... Evaluate the input elements When the output follows the characteristics of a piecewise function: in, This is a puncture-compatible PRF assessment algorithm. This indicates that the function cannot output a valid pseudo-random value at the puncture failure point. The random number is the encryption rule xid.

[0096] Internal gateway utilizes the recovered For extended token sets Each token in The evaluation is performed one by one. The gateway determines that the packet fully matches the rules. The necessary and sufficient condition is that all tokens trigger the puncture failure. Its mathematical logic formula is:

[0097] If the above logical AND operation results in a true match, then a complete match is confirmed, and the gateway decryption rule identifier is determined. And execute the action according to the corresponding rule; if there exists any The evaluation result is not If the result is not found, it is considered a mismatch.

[0098] In this implementation, after the gateway receives the detection result, it employs a process of recovering the puncture key based on the local key and performing evaluation and verification. The puncture key is recovered by performing an XOR operation on the returned encrypted forward index data using the locally stored forward index master key. This process does not require the involvement of an intermediate box, enhancing security. The recovered puncture key is then used to evaluate each token in the extended token set of the result tuple using a puncturable pseudo-random function. By setting the evaluation result of all tokens to indicate puncture failure as the sole criterion for successful matching, the false alarm problem that may be caused by ambiguous matching conditions is solved. This ensures that only data packets that fully conform to all keyword features of the rules are ultimately determined to be a hit, achieving extremely high detection accuracy.

[0099] In one implementation, after step S40, the method further includes: the gateway receiving the detection result, the inverted index verification proof, and the forward index verification proof; the gateway reconstructing the inverted verification chain and the forward verification chain based on its local key set, extended token set, and the detection result; the gateway comparing the inverted verification chain with the inverted index verification proof to obtain a first comparison result; the gateway comparing the forward verification chain with the forward index verification proof to obtain a second comparison result; if both the first comparison result and the second comparison result are consistent, the detection result is determined to be verified successfully.

[0100] It should be noted that the internal gateway can process the result tuples returned by the Layer 2 server. Perform non-interactive result verification to ensure that the server honestly executes the matching algorithm and does not tamper with or omit the results.

[0101] For example, the gateway first reconstructs the final extended token using local data. Its formula is: in, This represents the total number of tokens after expansion. The gateway then queries the keyword version table. Get the current update count of this extended token:

[0102] The gateway reconstructs the inverted verification chain locally. The gateway is based on the number of historical updates and the current... Using the verification key Initialize and accumulate the head and tail tags of the verification chain:

[0103] For the forward result set returned by the server Each of them The gateway assigns its rule identifier The corresponding verification tags have accumulated to middle: at this time, It fully simulates the ideal XOR cumulative result when a match is found on the server side. If the server executes honestly, the update verification tag of its intermediate version will inevitably be completely zeroed due to the cancellation property of XOR.

[0104] Furthermore, the gateway initializes the forward verification chain. and for each Iteratively calculate and accumulate forward validation labels: The gateway rigorously compares and verifies the locally reconstructed verification chain with the proof returned by the server. The determination formula is as follows: in, To create a reverse-order verification chain, It is a positive verification chain. To verify the inverted index, This serves as proof for verifying the positive index.

[0105] If the above logical equation holds true, the verification passes, confirming that the result returned by the intermediate box is complete and reliable; if they are not equal, it is determined that the server has engaged in deception or tampering, and the matching result is rejected.

[0106] In this implementation, after receiving the detection result, the gateway employs a non-interactive comparison mechanism based on cryptographic cumulative verification tags to ensure the integrity and authenticity of the returned result. Specifically, by requiring the server to dynamically generate and return inverted index verification proofs and forward index verification proofs during the matching process, the auditability issue of the result is resolved, providing cryptographic evidence from the executor for verification. By independently reconstructing the inverted and forward verification chains based on the local key, the original query token, and the returned result, the gateway independently verifies the validity of the evidence without reproducing the entire high-overhead matching process. By directly comparing the locally reconstructed verification chain with the proof returned by the server, and setting double consistency as a strict condition for verification success, the system is endowed with strong result verifiability without increasing additional communication overhead, ensuring the credibility of the final result of the entire privacy protection detection process, thus forming a reliable security closed loop.

[0107] Based on the same inventive concept, such as Figure 2 As shown, this application also provides an encrypted traffic deep packet inspection system, wherein solid arrows are used for transmitting parameters and data streams, and dashed arrows are used for transmitting cross-entity parameters and data streams. The encrypted traffic deep packet inspection system includes a gateway 10, a first-layer server 20, and a second-layer server 30. Gateway 10 is used to generate a key set based on security parameters, and to convert the plaintext detection rule set into an encrypted encoded filter table and an encrypted rule set based on the key set; Gateway 10 is also used to process data packets based on the key set to generate a set of encrypted tokens and send the set of encrypted tokens to the first-level server; The first-layer server 20 is used to filter the encrypted token set according to the encrypted encoding filter table, and initiate a component request to the gateway. It assembles the key component according to the key issued by the gateway to generate a search trapdoor, and sends the search trapdoor to the second-layer server. The second-layer server 30 is used to detect the set of encryption rules based on the search trapdoor, obtain the detection results, and return the detection results to the gateway. The detection results are the set of rule identifiers that match successfully.

[0108] It should be noted that the encrypted traffic deep packet inspection system and the encrypted traffic deep packet inspection method provided in this application are based on the same application concept. Therefore, the specific implementation of this embodiment can refer to the implementation of the aforementioned encrypted traffic deep packet inspection method, and the repeated parts will not be described again.

[0109] In some embodiments, this application provides an electronic device 2000, which includes: at least one processor 2001; and a memory 2003 communicatively connected to the at least one processor 2001; wherein the memory 2003 stores instructions executable by the at least one processor 2001, which are executed by the at least one processor 2001 to enable the at least one processor 2001 to perform the encrypted traffic deep packet inspection method in the above embodiments.

[0110] The following is for reference. Figure 3 This diagram illustrates a structural schematic of an electronic device 2000 suitable for implementing embodiments of this application. The electronic device 2000 in this application embodiment may include a processor 2001 and a memory 2003. The processor 2001 and the memory 2003 are connected, for example, via a bus 2002. Optionally, the electronic device 2000 may also include a transceiver 2004. It should be noted that in practical applications, the transceiver 2004 is not limited to one, and the structure of this electronic device 2000 does not constitute a limitation on the embodiments of this application.

[0111] Processor 2001 may be a CPU, a general-purpose processor, a DSP, an ASIC, an FPGA, or other programmable logic device, transistor logic device, hardware component, or any combination thereof. It may implement or execute the various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 2001 may also be a combination that implements computational functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0112] Bus 2002 may include a pathway for transmitting information between the aforementioned components. Bus 2002 may be a PCI bus or an EISA bus, etc. Bus 2002 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 3 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0113] The memory 2003 may be ROM or other type of static storage device capable of storing static information and instructions, RAM or other type of dynamic storage device capable of storing information and instructions, or EEPROM, CD-ROM or other optical disc storage, optical disc storage (including compressed optical discs, laser discs, optical discs, digital universal optical discs, Blu-ray discs, etc.), magnetic disk storage media or other magnetic storage devices, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but not limited thereto.

[0114] The memory 2003 stores the application code that executes the scheme of this application, and its execution is controlled by the processor 2001. The processor 2001 executes the application code stored in the memory 2003 to implement... Figure 2 The operation of the encrypted traffic deep packet inspection system provided in the illustrated embodiment.

[0115] This application also provides a non-transitory storage medium storing a computer program that, when executed by a processor, implements the aforementioned encrypted traffic deep packet inspection method. This storage medium may be included in the device / apparatus / system described in the above embodiments; or it may exist independently and not be assembled into that device / apparatus / system. The aforementioned non-transitory storage medium carries one or more programs, which, when executed, implement the method as described in the embodiments or implementations of this application.

[0116] According to embodiments of this application, a non-transitory storage medium can be a computer-readable signal medium or a computer-readable storage medium, or any combination thereof. A computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of a computer-readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this application, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in connection with an instruction execution system, apparatus, or device. A computer-readable signal medium can also be any storage medium other than a computer-readable storage medium that can transmit, propagate, or transfer a program for use by or in connection with an instruction execution system, apparatus, or device. The program code contained on the storage medium can be transmitted using any suitable medium, including but not limited to: wireless, wired, optical fiber, radio frequency signals, etc., or any suitable combination thereof.

[0117] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties, and the collection, use and processing of the relevant data must comply with relevant regulations.

[0118] Those skilled in the art will understand that the features described in the various embodiments of this application can be combined and / or combined in various ways, even if such combinations or combinations are not explicitly described in this application. In particular, the features described in the various embodiments of this application can be combined and / or combined in various ways without departing from the spirit and teachings of this application. All such combinations and / or combinations fall within the scope of this application. Therefore, the scope of this application should not be limited to the above embodiments. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for deep packet inspection of encrypted traffic, characterized in that, The encrypted traffic deep packet inspection method is applied to a communication system, which includes a gateway, a first-layer server, and a second-layer server. The encrypted traffic deep packet inspection method includes: The gateway generates a key set based on security parameters, and converts the plaintext detection rule set into an encrypted encoding filter table and an encryption rule set based on the key set. The gateway processes data packets based on the key set to generate an encrypted token set, and sends the encrypted token set to the first-layer server; The first-layer server filters the encrypted token set according to the encrypted encoding filter table, initiates a component request to the gateway, assembles a search trapdoor according to the key component issued by the gateway, and sends the search trapdoor to the second-layer server. The second-layer server detects the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway. The detection result is a set of rule identifiers that match successfully.

2. The method as described in claim 1, characterized in that, The encryption rule set includes an inverted index and a forward index. The gateway generates a key set based on security parameters and converts the plaintext detection rule set into an encrypted encoded filter table and an encryption rule set based on the key set, including the following steps: The gateway generates a key set based on security parameters. The key set includes at least a first key, a second key, a third key, and a fourth key. The first key is used to encrypt the token of the traffic data packet. The second key is used to encrypt the rule identifier in the plaintext detection rule set. The third key is used to generate the key component in the search trapdoor for the second-layer server. The fourth key is used to generate a verification tag for the gateway to verify the detection results returned by the second-layer server. The rule keywords are encrypted based on the pseudo-random function and the first key to generate encrypted rule keywords. The encrypted rule keywords are then mapped to the bit array of the Bloom filter using a hash function to obtain an encrypted encoded filter table. In the locally maintained keyword version table, determine the corresponding version number and update counter for the encryption rule keywords; An encryption key is generated based on the third key, the encryption rule keywords, and the version number. The inverted index is constructed based on the encryption key, and the forward index is constructed based on the second key to generate the encryption rule set. The encrypted encoding filter table is deployed to the first-layer server, and the encryption rule set is deployed to the second-layer server.

3. The method as described in claim 2, characterized in that, The key set also includes a fifth key. The steps of the first-layer server filtering the encrypted token set according to the encrypted encoding filter table, initiating a component request to the gateway, assembling a search trapdoor according to the key component issued by the gateway, and sending the search trapdoor to the second-layer server include: The first-layer server filters the encrypted token set according to the Bloom filter in the encrypted encoding filter table to obtain the filtered tokens; Based on the fifth key, the filtered tokens are serialized and pseudo-randomly extended to generate an extended token set; The first-layer server sends a component request to the gateway for the last token in the extended token set; The gateway obtains the current version number and current update counter corresponding to the last token from its locally maintained keyword version table, generates a first key component based on the third key and the current version number, generates a second key component based on the third key and the historical version number, and sends the first key component, the second key component and the current update counter to the first layer server. The first-layer server generates a search trapdoor based on the first key component, the second key component, the current update counter, and the extended token set, and sends the search trapdoor to the second-layer server.

4. The method as described in claim 3, characterized in that, The second-layer server performs detection on the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway, including: The second-layer server calculates the inverted index label based on the first key component and the current update counter, and extracts rule identifiers and operators from the inverted index of the encryption rule set in a loop to obtain the first matching result set; Based on the second key component, the local cache is queried to obtain the historical matching result set, and the historical matching result set is merged with the first matching result set to obtain the merged set; Based on the rule identifiers in the merged set, query the forward index to obtain the forward index result set; The inverted index verification proof, the forward index verification proof, the forward index result set, and the extended token set are combined into a result tuple, and the result tuple is returned to the gateway as the detection result.

5. The method as described in claim 4, characterized in that, The step of cyclically extracting rule identifiers and operators from the inverted index of the encryption rule set includes: Calculate the current inverted index label based on the current key component and the current update counter; Retrieve the corresponding inverted index data from the inverted index based on the current inverted index label; Generate a hash value based on the current key component; Perform an XOR operation between the inverted index data and the hash value to parse out the rule identifier and the operator; Decrement the current update counter and return to the step of calculating the current inverted index label based on the current key component and the current update counter, until the corresponding inverted index data can no longer be obtained.

6. The method as described in claim 2, characterized in that, After the gateway generates a key set based on security parameters and converts the plaintext detection rule set into an encrypted encoded filter table and an encrypted rule set based on the key set, the method further includes: The gateway generates new encryption rule keywords based on the first key according to the newly added rule keywords; Query the keyword version table to obtain the current version number of the new encryption rule keyword, and generate a new encryption key based on the third key and the current version number; A new inverted index entry is generated based on the new encryption key, and the new inverted index entry is sent to the second-layer server to update the encryption rule set; Update the update count corresponding to the new encryption rule keywords in the keyword version table.

7. The method as described in claim 1, characterized in that, After the second-layer server detects the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway, the method further includes: The gateway receives the detection result and the extended token set, the detection result including the rule identifier set; The gateway recovers the puncture key associated with the rule identifier from the detection results using its local key set; The gateway evaluates each token in the extended token set based on the puncture key. If the evaluation results of all tokens indicate that the puncture has failed, the data packet is determined to be a successful match between the data packet and the rule corresponding to the rule identifier.

8. The method as described in claim 1, characterized in that, After the second-layer server detects the encryption rule set based on the search trapdoor, obtains the detection result, and returns the detection result to the gateway, the method further includes: The gateway receives the detection result, the inverted index verification proof, and the forward index verification proof; the gateway reconstructs the inverted verification chain and the forward verification chain based on the local key set, the extended token set, and the detection result; The gateway compares the inverted verification chain with the inverted index verification proof to obtain a first comparison result; The gateway compares the forward verification chain with the forward index verification proof to obtain a second comparison result; If the first comparison result and the second comparison result are consistent, then the detection result is deemed to have passed verification.

9. A deep packet inspection system for encrypted traffic, characterized in that, The encrypted traffic deep packet inspection system includes a gateway, a first-layer server, and a second-layer server. The gateway is used to generate a key set based on security parameters, and to convert the plaintext detection rule set into an encrypted encoding filter table and an encryption rule set based on the key set; The gateway is also configured to process data packets based on the key set to generate an encrypted token set, and send the encrypted token set to the first-layer server; The first-layer server is used to filter the encrypted token set according to the encrypted encoding filter table, initiate a component request to the gateway, assemble a search trapdoor according to the key component issued by the gateway, and send the search trapdoor to the second-layer server. The second-layer server is used to detect the encryption rule set based on the search trapdoor, obtain the detection result, and return the detection result to the gateway. The detection result is a set of rule identifiers that are successfully matched.

10. An electronic device, characterized in that, The electronic device includes: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the encrypted traffic deep packet inspection method as described in any one of claims 1 to 8.

Images