A cross-domain transmission security supervision method, system, device and storage medium

Abstract

This application provides a method, system, device, and storage medium for cross-domain file transfer security supervision. The sending end embeds the sender's identity information as a watermark into the original file to obtain a first file to be preserved, calculates its first hash value, and stores it along with sending metadata containing the sender's information as a first evidence record on the blockchain. The first file to be preserved is then sent to the receiving end through a secure transmission channel. Upon receiving the file, the receiving end calculates the received hash value and checks the blockchain to verify if it matches the first hash value. If the verification matches, a second file to be preserved is embedded with the receiver's identity information watermark, calculates its second hash value, and stores it along with the received metadata containing the receiver's information as a second evidence record on the blockchain. During traceability, the supervisory node calculates the current hash value of the target file, retrieves the watermark from the blockchain, and analyzes the file transfer process by combining the identity information and evidence metadata. Using this method, the security, traceability, and accuracy of responsibility determination in cross-domain file transfer can be improved.

Description

Technical Field

[0001] This application relates to the field of data transmission, and more specifically, to a method, system, device, and storage medium for cross-domain transmission security monitoring. Background Technology

[0002] With the deepening development of the digital economy, cross-domain data interaction scenarios are becoming increasingly diverse, covering cross-border trade contract transmission, cross-regional government approval document circulation, and core business data sharing among enterprise branches. The commercial secrets, confidential information, and core business data involved in these interactions place extremely high demands on the security and traceability of the transmission process. It is necessary to prevent the risks of eavesdropping and tampering in the transmission link, and also to ensure that the source can be quickly traced and responsibilities can be defined after a security incident occurs.

[0003] The current mainstream cross-domain file transfer security solution is encrypted channel transmission only. This means that by building a dedicated encrypted tunnel, the file to be transmitted is encapsulated and then transferred across domains within the tunnel. The core of this solution relies on the channel encryption feature to resist external risks such as eavesdropping and interception during the transmission process.

[0004] This solution can only provide basic encryption protection for the transmission link, and cannot establish an effective association between the file and the identities of the sender and receiver. It also lacks means to record the entire file transfer process. Once a file is leaked, it is impossible to determine whether the leak originated from internal management oversights at the sending end, security vulnerabilities in the transmission channel, or improper storage or secondary dissemination at the receiving end. This results in a lack of effective technical support for identifying the responsible party, significantly increasing the difficulty and cost of tracing and handling security incidents. Summary of the Invention

[0005] In view of this, the purpose of this application is to provide a method, system, device and storage medium for cross-domain file transfer security supervision, which can improve the security, traceability and accuracy of responsibility determination of cross-domain file transfer.

[0006] In a first aspect, embodiments of this application provide a cross-domain transmission security monitoring method, applied to a cross-domain secure transmission monitoring system. The cross-domain secure transmission monitoring system includes a sending end, a receiving end, and a monitoring node. The sending end and the receiving end are connected via a secure transmission channel. The method includes:

[0007] The sending end embeds the sender's identity information as a watermark into the original file to obtain the first file to be stored, calculates the first hash value of the first file to be stored, and stores the first hash value and the sending metadata containing the sender's information together as the first storage record in the blockchain.

[0008] The sending end sends the first document to be stored to the receiving end through the secure transmission channel;

[0009] After receiving the first document to be stored, the receiving end calculates the receiving hash value of the first document to be stored, and queries the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record.

[0010] If the verification is consistent, the receiving end will further embed the recipient's identity information as a watermark into the first document to be stored to obtain a second document to be stored, calculate the second hash value of the second document to be stored, and store the second hash value and the receiving metadata containing the recipient's information together as a second evidence record in the blockchain.

[0011] When it is necessary to trace the source of a file in circulation, the monitoring node calculates the current hash value of the target file and queries the blockchain to obtain at least one evidence record that matches the current hash value; at the same time, it performs a watermark extraction operation on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

[0012] Optionally, the step of embedding the sender's identity information as a watermark into the original file to obtain the first document to be stored includes:

[0013] A watermark payload is generated based on the sender's identity information;

[0014] By using frequency domain transformation or spatial domain replacement algorithms, the watermark payload is embedded into a preset feature region of the original file to obtain the first document to be stored.

[0015] Optionally, the step of calculating the first hash value of the first document to be stored, and storing the first hash value together with the sending metadata containing the sender information as the first evidence record in the blockchain, includes:

[0016] The first hash value is calculated using either the SM3 or SHA-256 hash algorithm;

[0017] The first hash value is combined with the sent metadata to construct a structured data packet;

[0018] The structured data packet is used as the first evidence record and submitted to the blockchain network for consensus verification and storage.

[0019] Optionally, sending the first document to be stored to the receiving end through the secure transmission channel includes:

[0020] Negotiate and establish an IPSec VPN tunnel between the sending end and the receiving end;

[0021] Within the IPSec VPN tunnel, the first file to be stored is transmitted in blocks using the SFTP protocol, and a message authentication code is generated for each transmitted data block.

[0022] The integrity of the data block received by the receiving end is verified based on the message authentication code. After the verification is successful, the complete first certificate file is reassembled.

[0023] Optionally, before sending the first document to be authenticated to the receiving end through the secure transmission channel, the method further includes:

[0024] The first file to be stored is encrypted using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file.

[0025] The session key is encrypted using the SM2 public key of the receiving end to obtain an encrypted session key;

[0026] The encrypted file and the encrypted session key are sent together to the receiving end through the secure transmission channel;

[0027] After the receiving end receives the encrypted file and the encryption session key, the method further includes:

[0028] The encrypted session key is decrypted using its own SM2 private key to recover the session key;

[0029] Using the recovered session key, the encrypted file is decrypted using SM4 to obtain the first file to be stored.

[0030] Optionally, the step of combining the extracted identity information with the metadata in the acquired evidence storage records to perform source tracing analysis on the flow process of the target file includes:

[0031] The determination is based on the identity information extracted from the target file: if only the sender's identity information is extracted, the leakage is determined to have occurred after the sender and before the receiver embeds the watermark; if both the sender's and receiver's identity information are extracted, the leakage is determined to have occurred after the receiver embeds the watermark.

[0032] Based on the circulation links corresponding to the above determination, and in conjunction with the sending metadata or receiving metadata of the corresponding links in the evidence storage records, the responsible party for the suspected leakage is determined.

[0033] Based on the timestamp sequence in each evidence record, the complete flow path of the target file from its sending to the leak is reconstructed.

[0034] Optionally, after verifying whether the received hash value matches the first hash value in the first evidence record, the method further includes:

[0035] If the verification fails, the exception handling process will be triggered.

[0036] The exception handling process includes:

[0037] Record abnormal events, interrupt current file processing, or send alarm notifications to the sending end and the monitoring node.

[0038] Secondly, embodiments of this application provide a cross-domain transmission security monitoring system, the apparatus comprising:

[0039] The cross-domain transmission security monitoring system includes a sending end, a receiving end, and a monitoring node, wherein the sending end and the receiving end are connected through a secure transmission channel;

[0040] The sending end is used to embed the sender's identity information as a watermark into the original file to obtain a first file to be stored, calculate the first hash value of the first file to be stored, and store the first hash value and the sending metadata containing the sender's information together as a first storage record in the blockchain.

[0041] The sending end is used to send the first document to be stored to the receiving end through the secure transmission channel;

[0042] The receiving end is used to calculate the receiving hash value of the first document to be stored after receiving the first document to be stored, and query the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record.

[0043] The receiving end is configured to, if the verification is consistent, further embed the recipient's identity information as a watermark into the first document to be stored to obtain a second document to be stored, calculate the second hash value of the second document to be stored, and store the second hash value and the receiving metadata containing the recipient's information together as a second evidence record in the blockchain.

[0044] The monitoring node is used to calculate the current hash value of the target file and query the blockchain when it is necessary to trace the source of the file in circulation, so as to obtain at least one evidence record that matches the current hash value; at the same time, it performs a watermark extraction operation on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

[0045] Optionally, the step of embedding the sender's identity information as a watermark into the original file to obtain the first document to be stored includes:

[0046] A watermark payload is generated based on the sender's identity information;

[0047] By using frequency domain transformation or spatial domain replacement algorithms, the watermark payload is embedded into a preset feature region of the original file to obtain the first document to be stored.

[0048] Optionally, the step of calculating the first hash value of the first document to be stored, and storing the first hash value together with the sending metadata containing the sender information as the first evidence record in the blockchain, includes:

[0049] The first hash value is calculated using either the SM3 or SHA-256 hash algorithm;

[0050] The first hash value is combined with the sent metadata to construct a structured data packet;

[0051] The structured data packet is used as the first evidence record and submitted to the blockchain network for consensus verification and storage.

[0052] Optionally, sending the first document to be stored to the receiving end through the secure transmission channel includes:

[0053] Negotiate and establish an IPSec VPN tunnel between the sending end and the receiving end;

[0054] Within the IPSec VPN tunnel, the first file to be stored is transmitted in blocks using the SFTP protocol, and a message authentication code is generated for each transmitted data block.

[0055] The integrity of the data block received by the receiving end is verified based on the message authentication code. After the verification is successful, the complete first certificate file is reassembled.

[0056] Optionally, before sending the first document to be authenticated to the receiving end through the secure transmission channel, the method further includes:

[0057] The first file to be stored is encrypted using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file.

[0058] The session key is encrypted using the SM2 public key of the receiving end to obtain an encrypted session key;

[0059] The encrypted file and the encrypted session key are sent together to the receiving end through the secure transmission channel;

[0060] After the receiving end receives the encrypted file and the encryption session key, the method further includes:

[0061] The encrypted session key is decrypted using its own SM2 private key to recover the session key;

[0062] Using the recovered session key, the encrypted file is decrypted using SM4 to obtain the first file to be stored.

[0063] Optionally, the step of combining the extracted identity information with the metadata in the acquired evidence storage records to perform source tracing analysis on the flow process of the target file includes:

[0064] The determination is based on the identity information extracted from the target file: if only the sender's identity information is extracted, the leakage is determined to have occurred after the sender and before the receiver embeds the watermark; if both the sender's and receiver's identity information are extracted, the leakage is determined to have occurred after the receiver embeds the watermark.

[0065] Based on the circulation links corresponding to the above determination, and in conjunction with the sending metadata or receiving metadata of the corresponding links in the evidence storage records, the responsible party for the suspected leakage is determined.

[0066] Based on the timestamp sequence in each evidence record, the complete flow path of the target file from its sending to the leak is reconstructed.

[0067] Optionally, the receiving end is configured to trigger an exception handling process if the received hash value is inconsistent with the first hash value in the first evidence record after verifying whether the received hash value is consistent with the first hash value in the first evidence record.

[0068] The exception handling process includes:

[0069] Record abnormal events, interrupt current file processing, or send alarm notifications to the sending end and the monitoring node.

[0070] Thirdly, embodiments of this application provide a computer device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the cross-domain transmission security monitoring method described in any of the optional embodiments of the first aspect are performed.

[0071] Fourthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the cross-domain transmission security monitoring method described in any of the optional embodiments of the first aspect.

[0072] The technical solution provided in this application includes, but is not limited to, the following beneficial effects:

[0073] The sending end embeds the sender's identity information as a watermark into the original file, calculates the hash value, and stores the first evidence record on the blockchain. This achieves a precise binding between the file and the sender's identity. At the same time, by leveraging the characteristics of blockchain, it ensures the reliable evidence storage of the file status, identity information, and transmission metadata during the sending process, providing an initial and tamper-proof technical basis for subsequent file circulation traceability and responsibility definition.

[0074] The sending end sends the first file to be stored through a secure transmission channel. Relying on the secure transmission characteristics of the channel, it effectively resists the risks of eavesdropping, interception, and tampering during the cross-domain transmission of the file. This ensures that the file carrying the sender's watermark and initial storage information can be transmitted to the receiving end completely and securely, laying a secure foundation for the subsequent verification and processing by the receiving end.

[0075] The receiving end calculates the received hash value and queries the blockchain to verify consistency. This enables it to quickly verify whether the received file is consistent with the file sent by the sending end, and promptly detect any abnormalities such as file tampering or data loss that may occur during transmission. This prevents the receiving end from further processing tampered files and ensures the integrity and authenticity of the received files.

[0076] After verification, the receiving end embeds its own watermark and stores a second evidence record on the blockchain, realizing the association between the file and the recipient's identity, forming a two-end identity traceability chain of "sender-recipient". At the same time, the newly added hash value and receiving metadata are uploaded to the blockchain, improving the trusted record of the file circulation process, clarifying the processing responsibility of the receiving end, and further enriching the core data required for traceability.

[0077] By calculating the current hash value of the target file, querying the blockchain, extracting the watermark, and performing source tracing analysis, the regulatory node can accurately reconstruct the entire process of the file from sending to circulation based on the complete evidence record in the blockchain and the dual-end watermark in the file. It can quickly locate the specific link in the file leakage (after the sender, before the receiver, or after the receiver), clearly define the responsible party, and meet the regulatory and source tracing requirements for cross-domain file transmission.

[0078] Each step of this application is progressive and interconnected. Through a coherent design of identity binding, trusted evidence storage, transmission security assurance, integrity verification, and full-link traceability, it not only achieves security protection for cross-domain file transmission but also establishes a trusted recording and accurate traceability mechanism for the entire file flow process. Ultimately, it achieves the core beneficial effects of secure and controllable cross-domain file transmission, traceable flow, and delineable responsibility.

[0079] To make the above-mentioned objectives, features and advantages of this application more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0080] To more clearly illustrate the technical solutions of the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of this application and should not be regarded as a limitation of the scope. For those skilled in the art, other related drawings can be obtained based on these drawings without creative effort.

[0081] Figure 1 A flowchart of a cross-domain transmission security monitoring method provided in Embodiment 1 of this application is shown;

[0082] Figure 2 shows a flowchart of a method for determining a first document to be stored, provided in Embodiment 1 of this application;

[0083] Figure 3 shows a flowchart of a first evidence storage method provided in Embodiment 1 of this application;

[0084] Figure 4 shows a flowchart of a method for sending a first document to be stored, as provided in Embodiment 1 of this application;

[0085] Figure 5 shows a flowchart of an encrypted information transmission method provided in Embodiment 1 of this application;

[0086] Figure 6 shows a flowchart of a method for decrypting a first document to be stored provided in Embodiment 1 of this application;

[0087] Figure 7 This document illustrates a flowchart of a process traceability analysis provided in Embodiment 1 of this application.

[0088] Figure 8 This paper shows a schematic diagram of the core components of a cross-domain secure transmission monitoring system provided in Embodiment 1 of this application;

[0089] Figure 9 This paper illustrates a complete flow diagram and exception handling logic diagram of a cross-domain file from sending to receiving, as provided in Embodiment 1 of this application.

[0090] Figure 10 This paper shows a schematic diagram of the structure of a cross-domain transmission security monitoring system provided in Embodiment 2 of this application;

[0091] Figure 11 A schematic diagram of the structure of a computer device provided in Embodiment 3 of this application is shown. Detailed Implementation

[0092] To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. The components of the embodiments of this application described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this application provided in the accompanying drawings is not intended to limit the scope of the claimed application, but merely represents selected embodiments of this application. All other embodiments obtained by those skilled in the art based on the embodiments of this application without inventive effort are within the scope of protection of this application.

[0093] Example 1

[0094] To facilitate understanding of this application, the following is combined with... Figure 1 The flowchart illustrating a cross-domain transmission security monitoring method provided in Embodiment 1 of this application will be used to describe Embodiment 1 of this application in detail.

[0095] See Figure 1 As shown, Figure 1 This paper presents a flowchart of a cross-domain transmission security monitoring method according to Embodiment 1 of this application. The method is applied to a cross-domain secure transmission monitoring system, which includes a sending end, a receiving end, and a monitoring node. The sending end and the receiving end are connected through a secure transmission channel. The method includes steps S101-S105:

[0096] S101: The sending end embeds the sender's identity information as a watermark into the original file to obtain the first file to be stored, calculates the first hash value of the first file to be stored, and stores the first hash value and the sending metadata containing the sender's information together as the first storage record in the blockchain.

[0097] Specifically, the sender's identity information is a unique combination of identifiers, including the sender's entity ID (such as enterprise registration number, organization code), the operator's user ID (such as employee ID, authorized account), the transmission timestamp accurate to milliseconds, and may also include a unique file number (such as contract number, drawing number). All information is encoded using ASCII (American Standard Code for Information Interchange) to form fixed-length watermark core data.

[0098] The watermark embedding process uses invisible embedding technology, which does not change the format, size, or normal functionality of the original file. It is suitable for various important electronic file types such as contracts (Word, PDF), qualification certificates (scanned copies), audit reports (Excel, PDF), and design drawings (CAD, PNG). The embedding location is selected in the redundant data area of ​​the file or in a visually / logically inconsequential area to avoid accidental deletion by conventional editing tools.

[0099] The first hash value is calculated using the national cryptographic SM3 (SM3 Cryptographic Hash Algorithm). This algorithm performs an irreversible mapping on the file content. Even if only 1 byte of the file is modified, a completely different hash value will be generated, ensuring the accuracy of file integrity verification. In addition to the sender's identity information, the metadata also includes key information such as file name, file size, target receiver identifier, and transmission task number, forming a structured data format (such as JSON (JavaScript Object Notation) format).

[0100] The blockchain storage adopts a consortium blockchain architecture, with nodes including a sending gateway, a receiving gateway, and a designated server for supervision. After the first evidence record is submitted, it must be verified by consensus among at least 3 nodes (such as using a Byzantine fault-tolerant algorithm). After verification, it is distributed and stored to ensure that the record cannot be tampered with or deleted.

[0101] S102: The sending end sends the first certificate to be stored to the receiving end through the secure transmission channel.

[0102] Specifically, the secure transmission channel is built on IPSec VPN (Internet Protocol Security Virtual Private Network) and SFTP (SSH File Transfer Protocol). IPSec VPN uses ESP (Encapsulating Security Payload) protocol for encapsulation and encryption, with AES-256-GCM (Advanced Encryption Standard 256-bit Galois / Counter Mode) as the encryption algorithm. Identity authentication uses a pre-shared key (PSK) + digital certificate dual verification to ensure the link security of cross-domain network transmission and can adapt to the latency and bandwidth fluctuation issues of cross-border network environments such as Hong Kong and Shenzhen.

[0103] The SFTP protocol, as a transport layer protocol, is built on the SSH-2 (Secure Shell Version 2) protocol. It supports file chunked transfer and resume interrupted transfer. For large files (such as design drawings exceeding 1GB), it will automatically split them into 100MB / chunks, with each chunk carrying a checksum to prevent data loss or corruption during transmission.

[0104] S103: After receiving the first document to be stored, the receiving end calculates the receiving hash value of the first document to be stored, and queries the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record.

[0105] Specifically, the algorithm used by the receiving end to calculate the received hash value is exactly the same as that used by the sending end (if the sending end uses SM3, then the receiving end also uses SM3), ensuring the consistency of hash value calculation and avoiding false verification due to differences in algorithms.

[0106] Blockchain queries achieve rapid matching through smart contracts. The receiving end uses the received hash value as a query parameter to call the contract. The contract retrieves the corresponding hash value's stored record in the blockchain distributed ledger. The entire query process takes no more than 3 seconds, making it suitable for rapid verification scenarios of batch files.

[0107] The verification scenarios include two core situations: if they match, it means that the file has not been tampered with or lost data during transmission, and the subsequent watermark embedding process can proceed; if they do not match, it may be that the file was eavesdropped on and tampered with during transmission, network packet loss caused incomplete data, or the file itself at the sending end is abnormal.

[0108] S104: If the verification is consistent, the receiving end further embeds the recipient's identity information as a watermark into the first document to be stored to obtain a second document to be stored, calculates the second hash value of the second document to be stored, and stores the second hash value and the receiving metadata containing the recipient's information together as a second document storage record in the blockchain.

[0109] Specifically, the recipient's identity information is also a unique combination of identifiers, including the receiving unit ID (such as the receiving enterprise's registration number or organization code), the receiving operation user ID (such as the receiving employee's ID or authorized account), the receiving timestamp (accurate to milliseconds), and the receiving end gateway number. The embedding method is the same as that of the sending end, and it does not conflict with or cover the sending end's watermark, and can be extracted independently.

[0110] The second document to be stored carries a dual-end hidden watermark. The two watermarks are stored in different feature areas of the document. Even if one watermark is maliciously destroyed, the other watermark can still be extracted as a traceability basis, thus improving the watermark's resistance to attacks.

[0111] The second hash value is also calculated using the SM3 algorithm, generated based on the complete content of the file after embedding double watermarks, ensuring complete binding with the current state of the file; the received metadata includes the receiving task number, the receiving end gateway information, the file receiving status (such as "completely received" or "normal decryption"), the signature of the receiving operator, and other information, which are combined with the second hash value to form a structured data packet before being uploaded to the blockchain.

[0112] The process of uploading the second evidence record to the blockchain is the same as that of the first evidence record. After being verified by the consensus of the consortium blockchain nodes, it is distributed and stored to form a complete "send-receive" behavioral evidence chain, providing dual data support for subsequent traceability.

[0113] S105: When it is necessary to trace the source of a file in circulation, the monitoring node calculates the current hash value of the target file and queries the blockchain to obtain at least one evidence record that matches the current hash value; at the same time, a watermark extraction operation is performed on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

[0114] Specifically, the target files include suspected leaked documents and circulating documents that require regulatory verification. The regulatory nodes are deployed by authorized agencies such as the Cyberspace Administration of China and auditing departments, and are equipped with dedicated hash calculation tools and watermark extraction tools to support batch processing of multiple target files.

[0115] When querying hash values, if there is no matching record in the blockchain, it means that the target file has not been transmitted across domains through this system, and its leakage or circulation is unrelated to this system; if there is a matching record, the corresponding evidence record details can be obtained, including full metadata such as sender, receiver, timestamp, and basic file information.

[0116] The watermark extraction tool supports automatic file type identification and is compatible with the extraction of dark watermarks from various file formats. The extraction process does not require modification of the target file; it only reads the watermark data from the file's characteristic areas and then restores the identity information through a decoding algorithm. It can effectively resist attacks from conventional watermark removal tools.

[0117] During source tracing analysis, the regulatory node cross-references the extracted identity information with the metadata in the evidence storage record to confirm the file's sending time, receiving time, and operating entity. It then reconstructs the flow path using the timestamp sequence. In an optional implementation scheme, see Figure 2. Figure 2 shows a flowchart of a method for determining a first document to be stored according to Embodiment 1 of this application. The step of embedding the sender's identity information as a watermark into the original file to obtain the first document to be stored includes steps S201-S202:

[0118] S201: Generate a watermark payload based on the sender's identity information.

[0119] Specifically, the sender's identity information is first encoded using Base64 (Base64 Encoding Scheme), and then combined with a randomly generated 16-bit checksum to form the core watermark data. Next, a Cyclic Redundancy Check (CRC32) algorithm is used to verify the core data, generating check bits. Finally, these are combined into a fixed-length (e.g., 64-byte) watermark payload to ensure the integrity and identifiability of the watermark information.

[0120] The watermark payload also includes an anti-tampering identifier. If the watermark information is maliciously modified, it will fail to decode properly during extraction due to mismatched check bits, thus improving the security of the watermark.

[0121] S202: By using frequency domain transformation or spatial domain replacement algorithms, the watermark payload is embedded into a preset feature region of the original file to obtain the first document to be stored.

[0122] Specifically, the frequency domain transformation algorithm is suitable for visual files such as images and drawings. It uses Discrete Cosine Transform (DCT) to convert the file to the frequency domain and embeds the watermark payload in the mid-frequency coefficient region. This region will not affect the visual effect of the file and can resist conventional processing such as compression and cropping. The spatial domain replacement algorithm is suitable for document files (such as Word and PDF). It embeds the watermark payload in the character encoding redundancy bits or format control fields of the file without affecting the text display and editing functions of the document.

[0123] The preset feature regions are stable regions that have been screened through extensive testing. For document files, redundant fields after the format descriptor are selected; for image and drawing files, regions with low information density but that do not affect the core content are selected to ensure the stability and usability of the file after the watermark is embedded.

[0124] In an optional implementation, referring to Figure 3, which shows a flowchart of a first evidence storage method provided in Embodiment 1 of this application, wherein the step of calculating the first hash value of the first document to be stored, and storing the first hash value together with the sending metadata containing the sender information as the first evidence storage record in the blockchain, includes steps S301 to S303:

[0125] S301: Calculate the first hash value using either SM3 or SHA-256 (Secure Hash Algorithm 256-bit) hash algorithms.

[0126] Specifically, SM3 is an independently developed national cryptographic hash algorithm with a hash value length of 256 bits. It has high security and high collision resistance, and is suitable for cross-border data transmission scenarios in government, finance, and enterprises with high security requirements. SHA-256 is an internationally used hash algorithm with a hash value length of 256 bits. It is suitable for cross-domain transmission scenarios that need to be compatible with international systems. Users can choose according to their actual needs.

[0127] The hash calculation process is performed on the complete binary data of the first file to be certified, including all data such as file content and format information, to ensure that the hash value can uniquely correspond to the current state of the file.

[0128] S302: Combine the first hash value with the sent metadata to construct a structured data packet.

[0129] Specifically, the structured data packet is constructed using JSON format, with fields including "hashValue" (stores the first hash value), "senderInfo" (stores the sender's identity information), "fileBasicInfo" (stores the file name, size, type, and unique number), "transmissionInfo" (stores the transmission task number, target receiver identifier, and transmission timestamp), and "signature" (sender gateway digital signature). The fields are clearly defined and formatted in a standardized manner, facilitating blockchain storage and subsequent querying and parsing.

[0130] The digital signature of the sending gateway uses the SM2 (SM2 Elliptic Curve Cryptographic Algorithm) asymmetric encryption algorithm. The private key of the sending gateway is used to sign the data packet to ensure that the data packet is not tampered with during the transmission to the blockchain node.

[0131] S303: The structured data packet is submitted to the blockchain network as the first evidence record for consensus verification and storage.

[0132] Specifically, the blockchain network is a consortium blockchain, with nodes jointly deployed by the sending institution, the receiving institution, and regulatory agencies. Each node stores a complete distributed ledger to ensure data redundancy and availability. Consensus verification adopts the Practical Byzantine Fault Tolerance (PBFT) algorithm. Consensus is achieved when more than 2 / 3 of the nodes verify the validity of the data packet (including correct hash value format, valid digital signature, and complete metadata).

[0133] The storage adopts a blockchain-style structure, with each block containing multiple evidence records, the hash value of the previous block, and a timestamp. Once a block is generated, it cannot be modified. Subsequent queries can quickly locate the corresponding evidence record through the hash value, ensuring efficient traceability.

[0134] In an optional implementation, referring to Figure 4, Figure 4 shows a flowchart of a method for sending a first document to be stored according to Embodiment 1 of this application, wherein sending the first document to be stored to the receiving end through the secure transmission channel includes steps S401~S403:

[0135] S401: Negotiate and establish an IPSec VPN tunnel between the sending end and the receiving end.

[0136] Specifically, the IPSec VPN tunnel establishment process follows the IKEv2 (Internet Key Exchange Version 2) protocol. The sending gateway and the receiving gateway first authenticate each other (using digital certificates + pre-shared keys for dual verification). After successful authentication, they negotiate security parameters such as encryption algorithms, hash algorithms, and session keys. The session key is dynamically generated by a key exchange algorithm (such as ECDH, Elliptic Curve Diffie-Hellman). A new key is generated each time a tunnel is established to avoid security risks caused by key leakage.

[0137] After the tunnel is established, periodic liveness checks will be performed (e.g., a check packet will be sent every 30 seconds). If a tunnel interruption is detected, it will be automatically re-negotiated to ensure the stability of the transmission channel and adapt to the temporary disconnection issues that may occur in cross-border networks.

[0138] S402: Within the IPSec VPN tunnel, the first document to be stored is transmitted in blocks using the SFTP protocol, and a message authentication code is generated for each transmitted data block.

[0139] Specifically, the block size can be dynamically adjusted according to the network bandwidth. The default block size is 100MB. For cross-border networks with low bandwidth, it can be automatically adjusted to 50MB / block to improve the transmission success rate. The naming rule for each data block is "transmission task number_block sequence number_total number of blocks", which facilitates reassembly at the receiving end.

[0140] The Message Authentication Code (MAC) is generated using the HMAC-SM3 (Hash-based Message Authentication Code with SM3) algorithm. It is calculated based on the data block content and the session key. The MAC of each data block is transmitted together with the data block to ensure that the data block is not tampered with or replaced during transmission.

[0141] S403: Perform integrity verification on the data block received by the receiving end based on the message authentication code, and reassemble it to obtain the complete first certificate file to be stored after successful verification.

[0142] Specifically, after receiving each data block, the receiving end first extracts the corresponding MAC, then uses the same HMAC-SM3 algorithm and session key to recalculate the MAC based on the content of the received data block, and compares whether the two MACs are consistent. If they are consistent, it means that the data block is complete and has not been tampered with; if they are inconsistent, the sending end is required to retransmit the data block.

[0143] After all data blocks have been verified, the receiving end reassembles the data blocks in the order of "block sequence number" to restore the complete first file to be stored. After the reassembly is completed, the overall hash value of the file is verified again (to be consistent with the received hash value) to ensure that no reassembly error has occurred.

[0144] In an optional implementation, referring to Figure 5, which shows a flowchart of an encrypted information transmission method provided in Embodiment 1 of this application, the method further includes steps S501-S503 before sending the first document to be authenticated to the receiving end through the secure transmission channel:

[0145] S501: The first file to be stored is encrypted using the SM4 (SM4 Block Cipher Algorithm) algorithm combined with a dynamically generated session key to obtain an encrypted file.

[0146] Specifically, SM4 is my country's national standard block cipher algorithm, which uses a 128-bit key and a 128-bit block length. The encryption mode is CBC (Cipher Block Chaining). The initialization vector (IV) is randomly generated and transmitted along with the encrypted file to ensure that the ciphertext of the same file is different each time it is encrypted, thus improving encryption security.

[0147] The session key is dynamically generated by the sending gateway using a random number generator. It is 128 bits long and is used only in this transmission. It is automatically destroyed after the transmission ends, thus avoiding the risk of leakage caused by long-term key storage.

[0148] S502: Encrypt the session key using the SM2 public key of the receiving end to obtain an encrypted session key.

[0149] Specifically, SM2 is my country's national standard asymmetric encryption algorithm. The SM2 public key of the receiving end is published to the consortium blockchain node in advance. The sending end obtains the public key through blockchain query, ensuring the authenticity and validity of the public key. During the encryption process, the session key is used as plaintext input. After being encrypted by the SM2 public key, ciphertext is generated. Only the SM2 private key of the receiving end can decrypt it, ensuring that the session key is not stolen during transmission.

[0150] The encryption session key is 256 bits long and is stored separately from the encrypted file. During transmission, the encryption session key is sent first, followed by the encrypted file, so that the receiving end can decrypt the session key first and then decrypt the file.

[0151] S503: The encrypted file and the encrypted session key are sent together to the receiving end through the secure transmission channel.

[0152] Specifically, both the encrypted file and the encrypted session key are transmitted through an IPSec VPN tunnel. The tunnel's encryption protection, combined with the file's own SM4 encryption, forms a double encryption protection. Even if the tunnel is cracked, attackers still need to crack the SM4 encryption to obtain the file content.

[0153] During transmission, the encrypted file and the encrypted session key are packaged together and a file header information (including file type, size, and encryption algorithm identifier) ​​is added to facilitate identification and processing by the receiving end, ensuring the standardization and compatibility of the transmission.

[0154] In an optional implementation, see Figure 6 As shown, Figure 6 The flowchart illustrates a method for decrypting a first document to be preserved, as provided in Embodiment 1 of this application. After the receiving end receives the encrypted file and the encryption session key, the method further includes steps S601-S602:

[0155] S601: Use its own SM2 private key to decrypt the encrypted session key and recover the session key.

[0156] Specifically, the SM2 private key of the receiving end is stored in the hardware security module (HSM, Hardware Security Module). The hardware security module has anti-tampering and anti-theft functions to ensure that the private key will not be illegally obtained. The decryption process is completed within the hardware security module. After the session key is recovered, it is only temporarily stored in memory and is not written to the disk, reducing the risk of key leakage.

[0157] If decryption fails (e.g., private key mismatch, encryption session key tampered with), the receiving end will immediately trigger an alarm, notify the administrator, and interrupt subsequent processes to avoid processing abnormal data.

[0158] S602: Using the recovered session key, the encrypted file is decrypted using SM4 to obtain the first file to be stored.

[0159] Specifically, the decryption process corresponds exactly to the encryption process at the sending end. The receiving end reads the initial vector of the encrypted file, combines it with the recovered session key, and decrypts it using SM4-CBC mode, restoring the file content block by block. After decryption, the complete first file to be stored is obtained.

[0160] After decryption, the file will undergo integrity verification (calculating the file's hash value and comparing it with the hash value received subsequently) to ensure that no data errors occurred during the decryption process and to guarantee the file's availability.

[0161] In an optional implementation, see Figure 7 As shown, Figure 7 The flowchart of a process tracing analysis provided in Embodiment 1 of this application is shown. The step of performing tracing analysis on the process of the target file by combining the extracted identity information with the metadata in the acquired evidence storage records includes steps S701-S703:

[0162] S701: Based on the identity information extracted from the target file, the following determination is made: if only the sender's identity information is extracted, the leakage is determined to have occurred after the sender and before the receiver embeds the watermark; if both the sender's and receiver's identity information are extracted, the leakage is determined to have occurred after the receiver embeds the watermark.

[0163] Specifically, scenarios in which only the sender's identity information can be extracted include: the file is leaked before it is transmitted to the receiver after the sender embeds the watermark; the file is stolen during transmission; and the file is leaked before the receiver embeds its own watermark. These scenarios all belong to the stage "after the sender and before the receiver embeds the watermark".

[0164] Simultaneously, scenarios in which dual-end identity information can be extracted include: after the watermark is embedded on the receiving end, internal personnel illegally disseminate and forward the information, leading to leakage; or the receiving end's storage device is stolen, resulting in file leakage. These scenarios all fall under the stage of "after the receiving end watermark is embedded," and the responsible party clearly points to the receiving end.

[0165] S702: Based on the circulation links corresponding to the above determination, and in conjunction with the sending metadata or receiving metadata of the corresponding links in the evidence storage record, determine the responsible party for the suspected leakage.

[0166] Specifically, if the leak occurs after the sender's ID and before the watermark is embedded at the receiver's end, the specific sender (e.g., a company or employee) can be identified by combining the sender's ID, the user ID, and the transmission timestamp in the sending metadata. At the same time, the transmission logs can be used to investigate whether there was any theft during the transmission process and to pinpoint the responsible party.

[0167] If the leak occurs after the watermark is embedded at the receiving end, the specific receiving entity (such as the receiving company or employee) can be identified by combining the receiving unit ID, receiving user ID, and receiving timestamp in the receiving metadata. Then, by combining the file access logs and transmission logs at the receiving end, the flow path of the file at the receiving end can be investigated to identify the directly responsible person and related responsible persons.

[0168] S703: Based on the timestamp sequence in each evidence record, reconstruct the complete flow path of the target file from its sending to the leak.

[0169] Specifically, the timestamps in the evidence storage record include the sending end's on-chain timestamp and the receiving end's on-chain timestamp. Combined with the network latency data of file transmission, the sending time, transmission duration, and receiving time of the file can be accurately restored, forming a timeline-like flow trajectory.

[0170] If a file is forwarded multiple times (e.g., the receiving end forwards it to other organizations, and the other organizations embed the watermark again and put it on the blockchain), all circulation links can be linked together in the order of timestamps through multiple sets of evidence records on the blockchain, including the operating entity, operation time, and file status of each link, to completely restore the entire lifecycle path of the file from its original transmission to its final leak.

[0171] In an optional implementation, after verifying whether the received hash value matches the first hash value in the first evidence record, the method further includes:

[0172] If the verification fails, the exception handling process will be triggered.

[0173] Specifically, reasons for discrepancies in verification include file tampering during transmission, incomplete data due to network packet loss, errors in the file itself at the sending end, and errors in calculating the hash value at the receiving end. The exception handling process will first automatically check for common causes (such as recalculating the hash value and checking the network connection). If no results are found, the process will proceed to manual handling.

[0174] The exception handling process generates a detailed exception report, including the time of the exception, the receiver identifier, basic file information, hash value comparison results, network status data, etc., providing a complete basis for subsequent troubleshooting.

[0175] The exception handling process includes: recording the exception event, interrupting the current file processing, or sending an alarm notification to the sending end and the monitoring node.

[0176] Specifically, recording abnormal events involves storing the abnormal reports in the log server at the receiving end. The log server uses read-only mode to ensure that the abnormal records are not tampered with and to retain traceability evidence. At the same time, the abnormal events are synchronized to the blockchain to form an immutable abnormal record, which is convenient for subsequent verification by regulatory nodes.

[0177] Interrupting the current file processing will immediately stop subsequent operations such as watermark embedding, hash calculation, and on-chain processing, preventing abnormal files from entering the circulation process and reducing security risks; if the file has been partially processed, temporary files generated during the processing will be automatically deleted to ensure the cleanliness of system storage.

[0178] Alarm notifications are sent through multiple channels, including in-system pop-up alerts, administrator email notifications, and SMS alerts. The alert information includes the abnormal event number, core abnormal information, and handling suggestions, so that the sending end and the monitoring node can be informed in a timely manner and take countermeasures (such as the sending end resending the file or the monitoring node intervening for verification).

[0179] In an optional implementation, see Figure 8 As shown, Figure 8 This diagram illustrates the core components of a cross-domain secure transmission monitoring system provided in Embodiment 1 of this application. The components include a monitoring node, a sending gateway, a receiving gateway, and a blockchain. The interaction relationships between these components are as follows: the monitoring node initiates "data verification" to the blockchain; the sending gateway performs "data upload" to the blockchain; the receiving gateway performs "data verification and upload" to the blockchain; and the sending and receiving gateways interact via a "secure transmission channel." This diagram visually presents the system's basic architecture and information flow path, serving as a visual representation of the cross-domain secure transmission monitoring architecture.

[0180] See Figure 9 As shown, Figure 9This diagram illustrates the complete process and exception handling logic of cross-domain file transmission from sending to receiving, as provided in Embodiment 1 of this application. The sending end's process is: "Original file → Sending watermark at the sending end → Sending to the blockchain → Packaging and encryption," after which the file is transmitted to the receiving end via a "secure transmission channel." The receiving end's process is: "Unpacking and decryption → Receiving end verification → Verification consistency?" If the verification result is "yes," then "Receiving end watermarking → Receiving to the blockchain" is executed, ultimately closing the loop at the "receiving end." If the verification result is "no," then a "sending exception alarm" is triggered. This diagram clearly defines the entire operational chain and exception branches, and clarifies the execution logic of each step.

[0181] Combining these two images, it can be seen that this cross-domain transmission security supervision solution, through the evidence storage interaction architecture of "supervision / sender gateway-blockchain" and the process closed loop of "encrypted transmission + full-link watermarking + blockchain evidence storage + abnormal branch verification," not only relies on the immutability of blockchain to achieve the authenticity and credibility of evidence storage data and the authoritative verifiability of supervision verification, but also strengthens the link isolation and content confidentiality of cross-domain transmission through secure transmission channels and encryption / decryption operations. At the same time, it achieves full-link traceability of file flow by embedding dual-end watermarks and on-chain records, and can quickly identify risks and trigger alarms through abnormal branches verified by the receiving end. Ultimately, it achieves the technical effects of reliable evidence storage, secure isolation, full-link traceability, and timely risk control in cross-domain file transmission.

[0182] Example 2

[0183] See Figure 10 As shown, Figure 10 The diagram shows a cross-domain transmission security monitoring system provided in Embodiment 2 of this application. The cross-domain transmission security monitoring system includes a transmitter 1001, a receiver 1002, and a monitoring node 1003. The transmitter and the receiver are connected through a secure transmission channel.

[0184] The sending end is used to embed the sender's identity information as a watermark into the original file to obtain a first file to be stored, calculate the first hash value of the first file to be stored, and store the first hash value and the sending metadata containing the sender's information together as a first storage record in the blockchain.

[0185] The sending end is used to send the first document to be stored to the receiving end through the secure transmission channel;

[0186] The receiving end is used to calculate the receiving hash value of the first document to be stored after receiving the first document to be stored, and query the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record.

[0187] The receiving end is configured to, if the verification is consistent, further embed the recipient's identity information as a watermark into the first document to be stored to obtain a second document to be stored, calculate the second hash value of the second document to be stored, and store the second hash value and the receiving metadata containing the recipient's information together as a second evidence record in the blockchain.

[0188] The monitoring node is used to calculate the current hash value of the target file and query the blockchain when it is necessary to trace the source of the file in circulation, so as to obtain at least one evidence record that matches the current hash value; at the same time, it performs a watermark extraction operation on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

[0189] In an optional implementation, the step of embedding the sender's identity information as a watermark into the original file to obtain the first document to be stored includes:

[0190] A watermark payload is generated based on the sender's identity information;

[0191] By using frequency domain transformation or spatial domain replacement algorithms, the watermark payload is embedded into a preset feature region of the original file to obtain the first document to be stored.

[0192] In an optional implementation, calculating the first hash value of the first document to be stored, and storing the first hash value together with the sending metadata containing the sender information as a first evidence record in the blockchain, includes:

[0193] The first hash value is calculated using either the SM3 or SHA-256 hash algorithm;

[0194] The first hash value is combined with the sent metadata to construct a structured data packet;

[0195] The structured data packet is used as the first evidence record and submitted to the blockchain network for consensus verification and storage.

[0196] In an optional implementation, sending the first document to be authenticated to the receiving end via the secure transmission channel includes:

[0197] Negotiate and establish an IPSec VPN tunnel between the sending end and the receiving end;

[0198] Within the IPSec VPN tunnel, the first file to be stored is transmitted in blocks using the SFTP protocol, and a message authentication code is generated for each transmitted data block.

[0199] The integrity of the data block received by the receiving end is verified based on the message authentication code. After the verification is successful, the complete first certificate file is reassembled.

[0200] In an optional implementation, before sending the first document to be authenticated to the receiving end via the secure transmission channel, the method further includes:

[0201] The first file to be stored is encrypted using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file.

[0202] The session key is encrypted using the SM2 public key of the receiving end to obtain an encrypted session key;

[0203] The encrypted file and the encrypted session key are sent together to the receiving end through the secure transmission channel;

[0204] After the receiving end receives the encrypted file and the encryption session key, the method further includes:

[0205] The encrypted session key is decrypted using its own SM2 private key to recover the session key;

[0206] Using the recovered session key, the encrypted file is decrypted using SM4 to obtain the first file to be stored.

[0207] In an optional implementation, the step of combining the extracted identity information with the metadata in the acquired evidence storage records to perform source tracing analysis on the flow process of the target file includes:

[0208] The determination is based on the identity information extracted from the target file: if only the sender's identity information is extracted, the leakage is determined to have occurred after the sender and before the receiver embeds the watermark; if both the sender's and receiver's identity information are extracted, the leakage is determined to have occurred after the receiver embeds the watermark.

[0209] Based on the circulation links corresponding to the above determination, and in conjunction with the sending metadata or receiving metadata of the corresponding links in the evidence storage records, the responsible party for the suspected leakage is determined.

[0210] Based on the timestamp sequence in each evidence record, the complete flow path of the target file from its sending to the leak is reconstructed.

[0211] In an optional implementation, the receiving end is configured to trigger an exception handling process if the received hash value is inconsistent with the first hash value in the first evidence record after verifying whether the received hash value is consistent with the first hash value in the first evidence record.

[0212] The exception handling process includes:

[0213] Record abnormal events, interrupt current file processing, or send alarm notifications to the sending end and the monitoring node.

[0214] Example 3

[0215] Based on the same application concept, see [link / reference] Figure 11 As shown, Figure 11 This illustration shows a structural schematic diagram of a computer device provided in Embodiment 3 of this application, wherein, as shown... Figure 11 As shown, the computer device 1100 provided in Embodiment 3 of this application includes:

[0216] The computer device 1100 includes a processor 1101, a memory 1102, and a bus 1103. The memory 1102 stores machine-readable instructions executable by the processor 1101. When the computer device 1100 is running, the processor 1101 and the memory 1102 communicate via the bus 1103. The machine-readable instructions are executed by the processor 1101 to perform the steps of the cross-domain transmission security monitoring method shown in Embodiment 1 above.

[0217] Example 4

[0218] Based on the same concept, embodiments of this application also provide a computer-readable storage medium storing a computer program, which, when executed by a processor, performs the steps of the cross-domain transmission security monitoring method described in any of the above embodiments.

[0219] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the system and apparatus described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0220] The computer program product for cross-domain transmission security monitoring provided in this application includes a computer-readable storage medium storing program code. The instructions included in the program code can be used to execute the methods described in the preceding method embodiments. For specific implementation details, please refer to the method embodiments, which will not be repeated here.

[0221] The cross-domain transmission security monitoring system provided in this application embodiment can be specific hardware on a device or software or firmware installed on the device. The system provided in this application embodiment has the same implementation principle and technical effects as the aforementioned method embodiment. For the sake of brevity, any parts not mentioned in the system embodiment can be referred to the corresponding content in the aforementioned method embodiment. Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working processes of the systems, devices, and units described above can all be referred to the corresponding processes in the above method embodiments, and will not be repeated here.

[0222] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. The system embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Additionally, the coupling or direct coupling or communication connection shown or discussed may be indirect coupling or communication connection through some communication interfaces, devices, or units, and may be electrical, mechanical, or other forms.

[0223] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0224] In addition, the functional units in the embodiments provided in this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0225] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0226] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures. In addition, the terms "first", "second", "third", etc. are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0227] Finally, it should be noted that the above-described embodiments are merely specific implementations of this application, used to illustrate the technical solutions of this application, and not to limit them. The protection scope of this application is not limited thereto. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this application; and these modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application. All should be covered within the protection scope of this application. Therefore, the protection scope of this application should be determined by the protection scope of the claims.

Claims

1. A method for cross-domain transmission security supervision, characterized in that, An application is made in a cross-domain secure transmission monitoring system, the system comprising a sender, a receiver, and a monitoring node, wherein the sender and the receiver are connected via a secure transmission channel, and the method includes: The sending end embeds the sender's identity information as a watermark into the original file to obtain the first file to be stored, calculates the first hash value of the first file to be stored, and stores the first hash value and the sending metadata containing the sender's information together as the first storage record in the blockchain. The sending end sends the first document to be stored to the receiving end through the secure transmission channel; After receiving the first document to be stored, the receiving end calculates the receiving hash value of the first document to be stored, and queries the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record. If the verification is consistent, the receiving end will further embed the recipient's identity information as a watermark into the first document to be stored to obtain a second document to be stored, calculate the second hash value of the second document to be stored, and store the second hash value and the receiving metadata containing the recipient's information together as a second evidence record in the blockchain. When it is necessary to trace the source of a file in circulation, the monitoring node calculates the current hash value of the target file and queries the blockchain to obtain at least one evidence record that matches the current hash value; at the same time, it performs a watermark extraction operation on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

2. The method according to claim 1, characterized in that, The step of embedding the sender's identity information as a watermark into the original file to obtain the first file to be stored includes: A watermark payload is generated based on the sender's identity information; By using frequency domain transformation or spatial domain replacement algorithms, the watermark payload is embedded into a preset feature region of the original file to obtain the first document to be stored.

3. The method according to claim 1, characterized in that, The step of calculating the first hash value of the first document to be stored, and storing the first hash value together with the sending metadata containing the sender information as the first evidence storage record in the blockchain, includes: The first hash value is calculated using either the SM3 or SHA-256 hash algorithm; The first hash value is combined with the sent metadata to construct a structured data packet; The structured data packet is used as the first evidence record and submitted to the blockchain network for consensus verification and storage.

4. The method according to claim 1, characterized in that, Sending the first document to be stored to the receiving end through the secure transmission channel includes: Negotiate and establish an IPSec VPN tunnel between the sending end and the receiving end; Within the IPSec VPN tunnel, the first file to be stored is transmitted in blocks using the SFTP protocol, and a message authentication code is generated for each transmitted data block. The integrity of the data block received by the receiving end is verified based on the message authentication code. After the verification is successful, the complete first certificate file is reassembled.

5. The method according to claim 1, characterized in that, Before sending the first document to be stored to the receiving end through the secure transmission channel, the method further includes: The first file to be stored is encrypted using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file. The session key is encrypted using the SM2 public key of the receiving end to obtain an encrypted session key; The encrypted file and the encrypted session key are sent together to the receiving end through the secure transmission channel; After the receiving end receives the encrypted file and the encryption session key, the method further includes: The encrypted session key is decrypted using its own SM2 private key to recover the session key; Using the recovered session key, the encrypted file is decrypted using SM4 to obtain the first file to be stored.

6. The method according to claim 1, characterized in that, The step of combining the extracted identity information with the metadata in the acquired evidence storage records to perform source tracing analysis on the flow process of the target file includes: The determination is based on the identity information extracted from the target file: if only the sender's identity information is extracted, the leakage is determined to have occurred after the sender and before the receiver embeds the watermark; if both the sender's and receiver's identity information are extracted, the leakage is determined to have occurred after the receiver embeds the watermark. Based on the circulation links corresponding to the above determination, and in conjunction with the sending metadata or receiving metadata of the corresponding links in the evidence storage records, the responsible party for the suspected leakage is determined. Based on the timestamp sequence in each evidence record, the complete flow path of the target file from its sending to the leak is reconstructed.

7. The method according to claim 1, characterized in that, After verifying whether the received hash value matches the first hash value in the first evidence record, the method further includes: If the verification fails, the receiving end will trigger an exception handling process. The exception handling process includes: Record abnormal events, interrupt current file processing, or send alarm notifications to the sending end and the monitoring node.

8. A cross-domain transmission security monitoring system, characterized in that, The cross-domain transmission security monitoring system includes a sending end, a receiving end, and a monitoring node, wherein the sending end and the receiving end are connected through a secure transmission channel; The sending end is used to embed the sender's identity information as a watermark into the original file to obtain a first file to be stored, calculate the first hash value of the first file to be stored, and store the first hash value and the sending metadata containing the sender's information together as a first storage record in the blockchain. The sending end is used to send the first document to be stored to the receiving end through the secure transmission channel; The receiving end is used to calculate the receiving hash value of the first document to be stored after receiving the first document to be stored, and query the first storage record stored in the blockchain based on the receiving hash value to verify whether the receiving hash value is consistent with the first hash value in the first storage record. The receiving end is configured to, if the verification is consistent, further embed the recipient's identity information as a dark watermark into the first document to be stored to obtain a second document to be stored, calculate the second hash value of the second document to be stored, and store the second hash value and the receiving metadata containing the recipient's information together as a second evidence record in the blockchain. The monitoring node is used to calculate the current hash value of the target file and query the blockchain when it is necessary to trace the source of the file in circulation, so as to obtain at least one evidence record that matches the current hash value; at the same time, it performs a watermark extraction operation on the target file to obtain the identity information of at least one party contained therein; the monitoring node combines the extracted identity information with the metadata in the obtained evidence record to perform source tracing analysis on the circulation process of the target file.

9. A computer device, characterized in that, include: The computer device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the computer device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the cross-domain transmission security monitoring method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the cross-domain transport security monitoring method as described in any one of claims 1 to 7.

Images