Block chain wallet encrypted traffic transaction behavior identification method based on double auto-encoder enhancement

Abstract

The invention discloses a block chain wallet encrypted traffic transaction behavior identification method and device based on double-auto-encoder enhancement, relates to the technical field of online transaction information security, and provides a block chain wallet encrypted traffic transaction behavior identification method and device based on double-auto-encoder enhancement through a series of technical means such as high-dimensional fine-grained feature design, double-auto-encoder feature compression fusion, TLS handshake feature enhancement and deep learning classifier optimization. The method breaks through the limitation of a traditional encrypted traffic analysis method, and achieves the high-precision and high-robustness recognition of the transaction behavior of the block chain wallet in a highly encrypted communication environment.

Description

Technical Field

[0001] The present invention relates to the field of online transaction information security technology, and in particular to a method for identifying blockchain wallet encrypted traffic transaction behavior based on dual autoencoder enhancement. Background Art

[0002] Blockchain technology is a decentralized distributed ledger technology. It was first used in cryptocurrencies like Bitcoin and has since been widely adopted in various fields, including finance, supply chain management, and smart contracts. Blockchain uses decentralized nodes to jointly maintain a ledger, ensuring the transparency, security, and immutability of transaction records. Blockchain wallets are commonly used to manage and trade digital assets. Most modern blockchain wallets do not interact directly with the blockchain network as decentralized nodes. Instead, they communicate with centralized servers via the https / http2 protocol, sending transaction requests to them. The centralized servers then process and record transactions through interaction with the blockchain network.

[0003] With the widespread adoption of blockchain technology and digital assets, digital asset transactions managed by blockchain wallets are becoming increasingly frequent. These transactions typically interact with remote servers via encrypted protocols such as https / http2. While this blockchain wallet transaction method makes wallet operations more convenient, it also brings many challenges, particularly in terms of transaction monitoring, fund flow analysis, and preventing illegal activities.

[0004] Currently, several blockchain-based data analysis technologies are available on the market, capable of monitoring and identifying transaction behavior. Most focus on extracting information from the blockchain network's own transaction records, analyzing transaction patterns or relationships between wallet addresses. However, traditional deep packet inspection (DPI)-based identification techniques are difficult to directly apply to transaction requests sent to centralized servers using the HTTPS or HTTP2 protocols, as they are encrypted using TLS. Consequently, the encrypted nature of blockchain wallet transaction traffic for HTTPS / HTTP2 protocols reduces identification accuracy, making it difficult for existing technologies to achieve satisfactory results. Therefore, there is an urgent need for an encrypted traffic identification method tailored to blockchain wallet scenarios to improve both accuracy and practicality. Summary of the Invention

[0005] To address these issues, this paper provides a method for identifying encrypted traffic transactions in blockchain wallets based on dual autoencoders. This method extracts information entropy, TLS protocol features, and message length distribution, and uses dual autoencoders and a multi-layer perceptron (MLP) classifier to identify encrypted traffic.

[0006] First, the captured https / http2 encrypted traffic is preprocessed and various statistical features are extracted, including traffic payload entropy, TLS handshake protocol features (such as supported cipher suites and versions), and the length distribution of the first several data packets.

[0007] Then, two independent autoencoder models are constructed to perform unsupervised learning on the feature vectors of normal non-wallet transaction traffic and blockchain wallet transaction traffic, respectively.

[0008] The output encoding vectors of the two autoencoders are then concatenated and input into a multi-layer perceptron (MLP) classifier for training and recognition. This not only achieves high-precision recognition of blockchain wallet https / http2 encrypted traffic wallet transaction behaviors, but also improves the model's generalization ability in diverse encrypted traffic scenarios, overcoming the problem of low recognition accuracy of traditional methods when facing strong encrypted communications.

[0009] This method effectively enhances the ability to extract implicit behavioral features in encrypted communications through TLS protocol feature extraction and autoencoder dimensionality reduction processing, providing efficient and reliable technical support for blockchain asset transaction monitoring and abnormal behavior warning.

[0010] Compared with the prior art, the present invention has the following advantages:

[0011] 1) Existing technologies typically use a small number of statistical features (such as packet size, latency, connection duration, etc.) for shallow classification of encrypted traffic, which is difficult to fully characterize the behavioral characteristics of encrypted communications. However, this disclosure designs a comprehensive and fine-grained feature system to extract 302 comprehensive features covering multiple dimensions such as traffic behavior, timing characteristics, length distribution, and TLS handshake information. This achieves a richer and more detailed description of encrypted traffic and significantly improves the ability to identify behavioral characteristics.

[0012] 2) Existing technologies often directly use raw features for classification during feature processing, resulting in poor generalization of the model across different scenarios and applications. This disclosure, however, introduces a dual autoencoder structure that performs unsupervised learning and encoding dimensionality reduction on normal traffic features and blockchain wallet transaction traffic features, effectively extracting abstract features from their respective latent spaces. Feature fusion improves the classifier's ability to distinguish traffic category differences, significantly improving recognition accuracy and robustness across different network environments and application scenarios.

[0013] 3) To address the difficulty of traditional traffic identification methods in parsing content in HTTPS / HTTP2 encrypted environments, this disclosure specifically strengthens the feature extraction of information during the TLS protocol handshake phase, including version number, cipher suite configuration, extended field statistics, and entropy analysis. By leveraging the characteristics of TLS metadata exposed during the handshake phase, the ability to identify blockchain wallet transaction behavior is further enhanced, which is often ignored or superficially addressed in existing technologies.

[0014] Therefore, through a series of innovative technical means such as high-dimensional fine-grained feature design, dual autoencoder feature compression fusion, TLS handshake feature enhancement and deep learning classifier optimization, we have broken through the limitations of traditional encrypted traffic analysis methods and achieved high-precision and high-robustness identification of blockchain wallet transaction behaviors in a strong encrypted communication environment, which has obvious technological advancement and practical value. BRIEF DESCRIPTION OF THE DRAWINGS

[0015] The above and other objects, features and advantages of the present disclosure will become more apparent through a more detailed description of exemplary embodiments of the present disclosure in conjunction with the accompanying drawings, wherein like reference numerals generally represent like components throughout the exemplary embodiments of the present disclosure.

[0016] Figure 1 is an overall flow chart of the method disclosed herein;

[0017] Figure 2 is an overall flow chart of an exemplary embodiment according to the present disclosure;

[0018] Figure 3 Figure 2 is a diagram of the structure of an exemplary MLP classifier. DETAILED DESCRIPTION

[0019] The preferred embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. Although preferred embodiments of the present disclosure are shown in the accompanying drawings, it should be understood that the present disclosure can be implemented in various forms and should not be limited by the embodiments set forth herein. Rather, these embodiments are provided to make the present disclosure more thorough and complete, and to fully convey the scope of the present disclosure to those skilled in the art.

[0020] This disclosure provides a blockchain wallet encrypted traffic transaction behavior recognition method based on dual autoencoder enhancement, as shown in the attached Figure 1 As shown, it mainly includes the following basic steps:

[0021] S1, network traffic collection and preprocessing;

[0022] S2, traffic feature extraction: extract fine-grained statistical features from each normalized traffic after preprocessing;

[0023] S3, Dual Feature Encoding and Dimensionality Reduction: Build and train two independent autoencoder neural networks, including a wallet transaction traffic autoencoder and a wallet other traffic autoencoder, to represent the projection of the input traffic feature vector in the "wallet transaction traffic" feature space and the projection in the "normal traffic" feature space, respectively.

[0024] Specifically, the wallet transaction traffic autoencoder is trained using feature vectors containing only those explicitly labeled as “blockchain wallet transaction traffic.” The wallet other traffic autoencoder is trained using feature vectors containing only those explicitly labeled as “normal business traffic,” i.e., non-blockchain wallet transaction traffic.

[0025] S4, feature fusion: After training the two autoencoders in step S3, use them to encode the new input traffic feature vector separately to obtain a fused feature representation;

[0026] S5, classification training and identification: Construct a supervised learning classifier based on a multi-layer perceptron and train it using the joint feature vector obtained by feature fusion in step S4 to determine whether the network traffic is a blockchain wallet transaction behavior.

[0027] According to an exemplary embodiment of the present disclosure, the flow chart is as shown in the attached Figure 2 As shown, the specific operations include the following:

[0028] 1. Traffic collection and preprocessing

[0029] (1) Use network traffic capture tools to capture network traffic and perform protocol analysis and traffic segmentation.

[0030] (2) Clean the captured traffic data to remove invalid packets and noise data. For example, filter out retransmitted packets or incorrect checksum packets. This involves the following operations:

[0031] Packet filtering: Use filters to remove specific types of packets. Maintain a list of SNIs for known blockchain wallet services, exchange API domains, or related nodes. Process sessions whose SNIs match this list or have related patterns, retaining only the corresponding https / http2 traffic.

[0032] Abnormal traffic elimination: Identify and eliminate invalid or abnormal session flows, such as sessions where the TLS handshake fails to complete successfully (such as alert errors, certificate verification failures, etc.), sessions where TCP connection establishment fails or is prematurely terminated, and sessions where the payload data is too short or obviously incomplete.

[0033] Packet deduplication: Identify and delete duplicate packets. The packet's five-tuple (source IP, source port, destination IP, destination port, protocol) and sequence number can be used to determine whether the packet is duplicated.

[0034] Packet reassembly: Reassemble the fragmented data packets into complete data packets, which needs to be done based on the fragment offset and identification fields in the IP header of the data packet.

[0035] (3) Converting traffic data into a format suitable for subsequent processing involves the following operations:

[0036] Session reassembly: Serialize the packets belonging to the same TCP session. Five-tuple can be used to identify the packets belonging to the same session.

[0037] Packet sorting: Packets belonging to the same session are sorted based on their timestamps or sequence numbers to maintain their original order.

[0038] Feature vectorization: Extract relevant features from each packet or each session and combine these features into a vector.

[0039] 2. Traffic feature extraction

[0040] This step extracts fine-grained statistical features from each normalized flow after preprocessing, mainly including:

[0041] TLS Protocol Characteristics (Dimension 203): Blockchain wallet software uses its own TLS configuration to select supported cipher suites based on its specific needs and security policies. These configurations may include selecting supported extensions, activating or deactivating specific features, and establishing cipher suite priorities. Therefore, the TLS protocol fingerprint serves as a characteristic for identifying encrypted proxy traffic. Selected TLS protocol characteristics include commonly supported cipher suites, supported groups, supported signature algorithms, and the server-selected cipher suite. Currently, there are over 300 cipher suites. However, most of these cipher suites are rarely used in actual TLS protocol scenarios. To reduce unnecessary memory consumption, this example performs a preliminary analysis of current TLS traffic. The 120 most commonly used cipher suites are selected based on the ranking of client-supported cipher suites. These selected supported cipher suites are encoded as a one-hot vector, with one bit reserved for unknown cipher suites. These 121 bits collectively serve as the TLS client's supported cipher suite characteristics. Similarly, based on the server's selected supported groups, signature algorithms, and cipher suites, the 48 most commonly used groups, 23 signature algorithms, and 8 cipher suites typically preferred by servers are selected in order of ranking. Finally, all the above TLS features are concatenated into a feature vector with a total length of 203, which effectively represents the TLS characteristics of the observed traffic.

[0042] Length feature (30 dimensions): Because the encrypted proxy service re-encapsulates the original traffic packets, it adds protocol information for authentication and traffic management. This process causes the length distribution of traffic packets generated by the encrypted proxy service to differ from that of normal traffic. Therefore, we extract the lengths of the first 30 packets as length features. If the number of packets in a flow is less than 30, the length feature vector is padded with zeros.

[0043] Time series dynamic features (34 dimensions in total): The arrival timing characteristics of data packets, especially the inter-arrival time (IAT), can reveal the interaction rhythm and response patterns within the session and are crucial for identifying transaction behaviors with specific request-response cycles.

[0044] ① Client (uplink) initial IAT sequence (9 dimensions): Capture the 9 IAT values ​​formed by the first 10 packets sent continuously by the client. If the value is insufficient, fill it with zeros.

[0045] ② Server (downlink) initial IAT sequence (9 dimensions): Capture the 9 IAT values ​​formed by the first 10 consecutive data packets responded to / sent by the server. If the value is insufficient, fill it with zeros.

[0046] ③ Upward IAT global statistical moments (5 dimensions): covering the minimum, maximum, arithmetic mean, standard deviation, and median of the upward IAT for the entire session.

[0047] ④ Global statistical moment of downstream IAT (5-dimensional): Same as above, for downstream IAT.

[0048] ⑤ Bidirectional IAT global statistical moment (5 dimensions): Same as above, for the entire session IAT (regardless of direction).

[0049] ⑥TLS handshake phase duration (1 dimension): Accurately measures the time span from the issuance of ClientHello to the completion of TLS handshake negotiation (for example, the exchange of Finished messages between the two parties or the start of transmission of the first application data packet).

[0050] Data transmission burst pattern features (14 dimensions): Network traffic typically occurs in bursts, meaning a series of packets transmitted in a short period of time, interspersed with relatively quiet intervals. Burst pattern analysis can help identify behaviors such as bulk data transfers and intensive API interactions.

[0051] ① Quantification of uplink traffic burst patterns (7 dimensions): includes the total number of uplink bursts, the total number of packets in a burst, the total number of bytes in a burst, the average number of packets per burst, the average number of bytes per burst, the average duration of each burst, and the average inter-burst interval (IAT).

[0052] ② Quantization of downlink traffic burst pattern (7 dimensions): Same as above, for downlink traffic.

[0053] HTTP / 2 protocol layer features (21 dimensions in total, extracted when the ALPN negotiation result is confirmed or heuristically determined to be HTTP / 2): For blockchain wallet communications carried by HTTP / 2, its unique multiplexed stream and frame structure provides a more detailed dimension for behavioral analysis, especially helping to distinguish delicate operations such as API calls.

[0054] HTTP / 2 stream statistics (3D): total number of streams in a session, number of streams initiated by the client, and number of streams initiated by the server (such as PUSH streams).

[0055] ②HTTP / 2 key frame type count (1 dimension each, 7 dimensions in total): Counts the total number of occurrences of major frame types such as HEADERS, DATA, SETTINGS, PING, GOAWAY, WINDOW_UPDATE, and RST_STREAM.

[0056] ③ Initial SETTINGS frame parameters (4 dimensions): Extract the SETTINGS_MAX_CONCURRENT_STREAMS and SETTINGS_INITIAL_WINDOW_SIZE values ​​declared by the client and server in the initial SETTINGS frame.

[0057] ④ Server Push enable status (1st dimension): based on the value of the SETTINGS_ENABLE_PUSH parameter in the server SETTINGS frame.

[0058] ⑤ Total number of DATA frame bytes related to the transmission direction (2-dimensional): uplink and downlink.

[0059] ⑥ Total number of bytes of HEADERS frames related to transmission direction (2-dimensional): uplink and downlink.

[0060] ⑦ Average number of DATA frames per stream (1 dimension).

[0061] ⑧Average number of HEADERS frames per stream (1 dimension).

[0062] Comprehensive features: The three types of features mentioned above are connected to form a feature vector F with a length of 302. This feature vector is used to identify encrypted proxy traffic.

[0063] 3. Dual-feature encoding and dimensionality reduction

[0064] Based on the fused joint feature vector, a multi-layer perceptron (MLP) classifier is constructed for supervised training and behavior recognition. The MLP classifier consists of an input layer, several hidden layers, and an output layer. Nonlinear activation functions (such as ReLU) are used to enhance modeling capabilities. The output layer uses Sigmoid or Softmax activation to achieve binary classification prediction of transaction / non-transaction. To effectively distinguish blockchain wallet transaction traffic from other types of normal HTTPS / HTTP2 traffic in the background and learn their inherent feature representations, this step constructs and trains two independent autoencoder (AE) neural networks:

[0065] Wallet Transaction Autoencoder (AE_Transaction): trained using feature vectors containing only those explicitly labeled as “blockchain wallet transaction flows”.

[0066] Wallet other traffic autoencoder (AE_Normal): trained using feature vectors that only contain data explicitly labeled as “normal business traffic” (non-blockchain wallet transaction traffic).

[0067] Each autoencoder consists of the following two parts:

[0068] Encoder: The encoder is a neural network module whose input is the N-dimensional feature vector extracted and normalized in step 2. The encoder gradually reduces the number of neurons through a series of hidden layers (usually fully connected layers, with activation functions such as ReLU and LeakyReLU), mapping (compressing) the high-dimensional input feature X to a low-dimensional latent space representation Z. For example, the N-dimensional feature can be compressed to M dimensions (such as M = 128, 64, or 32), where M <N。

[0069] Decoder: The decoder is also a neural network module, and its structure is usually symmetrical (or mirrored) with the encoder. The decoder receives the M-dimensional potential representation Z output by the encoder and attempts to reconstruct the original N-dimensional input feature vector through a series of hidden layers (with increasing number of neurons) to obtain the reconstructed feature vector.

[0070] Training process:

[0071] The two autoencoders are trained independently for unsupervised learning. For each autoencoder, the training goal is to minimize the difference between the input feature X and the decoder reconstruction feature The commonly used loss function is Mean Squared Error (MSE):

[0072]

[0073] By adjusting the encoder and decoder weights using backpropagation and optimizers (such as Adam and SGD), the autoencoder learns an effective low-dimensional representation of the corresponding traffic type (normal or transaction), specifically its most important structure and patterns. AE_Normal excels at reconstructing normal traffic, while AE_Transaction excels at reconstructing transaction traffic.

[0074] 4. Feature Fusion

[0075] After training the normal traffic autoencoder (AE_Normal) and transaction traffic autoencoder (AE_Transaction) respectively, they are used to encode the new input traffic feature vector to obtain the fused feature representation.

[0076] For any traffic session to be analyzed, first extract its N-dimensional feature vector X according to step 2.

[0077] Then, the feature vector X is input into two trained encoders respectively:

[0078] a) Input to the encoder of AE_Normal to obtain its potential representation Z Normal (M dimension). Z Normal Characterizes the projection of the input flow X in the “normal flow” feature space.

[0079] b) Input to the encoder of AE_Transaction to obtain its potential representation Z Transaction (M dimension). Z Transaction Characterizes the projection of input flow X in the “wallet transaction flow” feature space.

[0080] Next, these two low-dimensional latent vectors Z obtained from different autoencoders are Normal and Z Transaction n are concatenated to form a unified joint feature vector Z Fused :

[0081] Z Fused =[Z Normal ; Z Transaction ]

[0082] The fused feature vector Z Fused The dimension is 2M.

[0083] 5. Classification training and recognition

[0084] This step uses the joint feature vector Z obtained by fusion in step 4 FusedTo train a supervised learning classifier to ultimately determine whether network traffic is a blockchain wallet transaction. Multilayer Perceptron (MLP) is selected as the main classification model, as shown in the attached Figure 3 shown.

[0085] MLP classifier construction:

[0086] ① Input layer: The number of neurons is equal to the fusion feature vector Z Fused The dimension is 2M.

[0087] Hidden layers: This can include one or more fully connected hidden layers. The number of neurons and layers in each hidden layer are hyperparameters that can be tuned based on dataset complexity and validation set performance (for example, two hidden layers can be used, with P neurons in each layer, such as P = 64, 32). Hidden layers use nonlinear activation functions such as ReLU (Rectified Linear Unit), LeakyReLU, or ELU (Exponential Linear Unit) to enhance the model's nonlinear modeling capabilities.

[0088] ③ Output layer: For binary classification problems (transaction behavior vs. non-transaction behavior), the output layer usually contains one neuron (using the Sigmoid activation function to output a probability value between 0 and 1, indicating the probability of belonging to "wallet transaction flow") or two neurons (using the Softmax activation function to output the probability distribution of "wallet transaction flow" and "normal flow" respectively).

[0089] 6. Online detection application

[0090] The entire trained model (including the preprocessor, feature extractor, encoder part of the dual autoencoder, and MLP classifier) ​​is deployed in an actual network environment to achieve real-time online detection of blockchain wallet encrypted traffic transaction behavior.

[0091] In this embodiment, by designing a 302-dimensional comprehensive feature vector, combining the feature compression and feature fusion technology of the dual autoencoder, and strengthening the feature extraction in the TLS handshake stage, the accuracy and robustness of identifying transaction behaviors under blockchain wallet encrypted traffic are effectively improved.

[0092] Compared with the existing technology, the present invention can extract richer and more discriminative traffic features under the conditions of high encryption level and subtle traffic differences, overcoming the problems of traditional methods relying on shallow statistical features and insufficient recognition accuracy, and realizing high-precision detection of blockchain transaction behavior, with stronger adaptability, real-time performance and engineering application value.

[0093] The above technical solutions are only exemplary embodiments of the present invention. For those skilled in the art, it is easy to make various types of improvements or modifications based on the application methods and principles disclosed in the present invention, and are not limited to the methods described in the above specific embodiments of the present invention. Therefore, the methods described above are only preferred and do not have a restrictive meaning.

Claims

1. A blockchain wallet encrypted traffic transaction behavior recognition method based on dual autoencoder enhancement, characterized by: The following steps are involved: S1, network traffic collection and preprocessing; S2, traffic feature extraction: extract fine-grained statistical features from each normalized traffic after preprocessing; S3, Dual Feature Encoding and Dimensionality Reduction: Build and train two independent autoencoder neural networks, including a wallet transaction flow autoencoder and a wallet other flow autoencoder, to represent the projection of the input flow feature vector in the "wallet transaction flow" feature space and the projection in the "normal flow" feature space, respectively. The wallet transaction traffic autoencoder is trained using feature vectors containing only those explicitly labeled "blockchain wallet transaction traffic." The wallet other traffic autoencoder is trained using feature vectors containing only those explicitly labeled "normal business traffic," i.e., non-blockchain wallet transaction traffic. S4, feature fusion: After training the two autoencoders in step S3, use them to encode the new input traffic feature vector separately to obtain a fused feature representation; S5, classification training and identification: Construct a supervised learning classifier based on a multi-layer perceptron and train it using the joint feature vector obtained by feature fusion in step S4 to determine whether the network traffic is a blockchain wallet transaction behavior.

2. The method according to claim 1, characterized in that The step S1 specifically includes: S11, use network traffic capture tools to capture network traffic, and perform protocol analysis and traffic segmentation; S12, cleaning the captured traffic data to remove invalid data packets and noise data; S13, converting the traffic data into a format suitable for subsequent processing.

3. The method according to claim 1, characterized in that The features extracted in step S2 and the specific extraction method include: S21, TLS protocol features: Based on the ranking of the client's supported cipher suites, the 120 most commonly used cipher suites are selected. These selected supported cipher suites are encoded as a one-hot vector, with one bit reserved for unknown cipher suites. These 121 bits together serve as the TLS client's supported cipher suite features. Similarly, based on the server's selected supported groups, signature algorithms, and cipher suites, the 48 most commonly used groups, 23 signature algorithms, and 8 cipher suites typically preferred by the server are selected according to their ranking. Finally, all the above TLS features are concatenated into a feature vector with a total length of 203. S22, length feature: extract the length of the first 30 packets as the length feature. When the number of packets in the flow is less than 30, fill the length feature vector with zeros; S23, time series dynamic characteristics: the arrival timing characteristics of data packets, especially the inter-arrival time (IAT), specifically including: Client initial IAT sequence: captures the 9 IAT values ​​formed by the first 10 packets sent continuously by the client, and fills them with zeros if they are insufficient; Server initial IAT sequence: captures the 9 IAT values ​​formed by the first 10 packets continuously responded to / sent by the server, and fills them with zeros if they are insufficient; Uplink IAT global statistical moments: covers the minimum, maximum, arithmetic mean, standard deviation, and median of the uplink IAT for the entire session; Downstream IAT global statistical moment: Same as above, for downstream IAT; Bidirectional IAT global statistical moment: Same as above, for the whole session IAT, without distinguishing between directions; TLS handshake phase duration: accurately measures the time span from the sending of ClientHello to the completion of TLS handshake negotiation; S24, data transmission burst pattern characteristics: This refers to the data packets in the network traffic appearing in "bursts", with a series of data packets transmitted in a short period of time, interspersed with relatively silent intervals. Specifically, it includes: a) Quantitative characteristics of the uplink traffic burst pattern, including one or more of the following: the total number of uplink bursts, the total number of data packets in a burst, the total number of bytes in a burst, the average number of packets per burst, the average number of bytes per burst, the average duration of each burst, and the average silence period between bursts; b) Quantitative characteristics of the downlink traffic burst pattern: Same as above, for downlink traffic; S25, HTTP / 2 protocol layer features, is extracted when the ALPN negotiation result is confirmed or heuristically determined to be HTTP / 2. Specifically, it includes: a) HTTP / 2 stream statistics: total number of streams in the session, number of client-initiated streams, and number of server-initiated streams; b) HTTP / 2 key frame type count: counts the total number of occurrences of the main frame types; c) Initial SETTINGS frame parameters; d) Server push enablement status; e) The total number of DATA frame bytes related to the transmission direction; f) The total number of bytes in the HEADERS frames related to the transmission direction; g) Average number of DATA frames per stream; h) Average number of HEADERS frames per stream; The above four types of features are connected to form a feature vector F with a length of 302 dimensions, which is used to identify encrypted proxy traffic.

4. The method according to claim 1, wherein In step S3, each autoencoder includes two parts: an encoder and a decoder; The two autoencoders are trained independently for unsupervised learning, where the training objective for each autoencoder is to minimize the difference between the input feature X and the decoder reconstruction feature the differences between; The weight parameters of the encoder and decoder are adjusted through the back-propagation algorithm and optimizer, so that the autoencoder can learn an effective low-dimensional representation of the corresponding category of traffic. The transaction traffic autoencoder is used to reconstruct transaction traffic, and the other traffic autoencoders are used to reconstruct normal traffic.

5. The method according to claim 1, wherein The step S4 specifically includes: For any traffic session to be analyzed, first extract its N-dimensional feature vector X according to step S2. Then, input the feature vector X into two trained encoders respectively: Input to other traffic autoencoders to obtain its potential representation Z Normal , Z Normal It is M-dimensional, representing the projection of the input flow X in the "normal flow" feature space; Input into the transaction flow autoencoder to obtain its potential representation Z Transaction , Z Transaction It is M-dimensional, representing the projection of the input flow X in the "wallet transaction flow" feature space; Then the low-dimensional latent vector Z obtained from different autoencoders Normal and Z Transaction Splice to form the fused joint feature vector Z Fused : WITH Fused =[Z Normal ;WITH Transaction ] The fused feature vector Z Fused The dimension is 2M.

6. The method according to claim 1, characterized in that The following steps are also included: The entire trained model is deployed in the actual network environment to conduct real-time online detection of blockchain wallet encrypted traffic transaction behavior.

7. A blockchain wallet encrypted traffic transaction behavior identification device based on dual autoencoder enhancement using the method described in any one of claims 1 to 6, characterized in that: include: Network traffic collection and preprocessing module; Traffic feature extraction module, used to extract fine-grained statistical features from each standardized traffic after preprocessing; A dual-feature encoding module, including the wallet transaction flow autoencoder and the wallet other flow autoencoder; The feature fusion module is used to fuse the output vectors of two independent autoencoders to obtain a joint feature vector; The MLP classifier module is used to determine whether the network traffic is a blockchain wallet transaction behavior based on the joint feature vector.

Images