Cross-domain transmission safety supervision method, system and device and storage medium

Abstract

The invention provides a cross-domain transmission security supervision method, system and device, and a storage medium, and the method comprises the steps: enabling a transmitting end to enable the identity information of a transmitting party to serve as a dark watermark to be embedded into an original file, obtaining a first to-be-stored file, calculating a first hash value of the first to-be-stored file, and enabling the first to-be-stored file and transmission metadata containing the information of the transmitting party to serve as a first storage record to be stored in a block chain; and sending the first to-be-stored file to a receiving end through the secure transmission channel. A receiving end calculates a received hash value after receiving the file, and queries the block chain to check whether the received hash value is consistent with the first hash value; and if the verification is consistent, embedding a receiver identity information dark watermark to obtain a second file to be stored, calculating a second hash value, and storing the second hash value and the receiving metadata containing the receiver information in the block chain as a second storage record. And during tracing, the supervision node calculates the current hash value of the target file, checks the block chain and extracts the dark watermark, and analyzes the file circulation process in combination with the identity information and the evidence storage metadata. By adopting the method, the security, the circulation traceability and the responsibility definition accuracy of cross-domain file transmission can be improved.

Description

TECHNICAL FIELD

[0001] The present application relates to the field of data transmission, in particular to a cross-domain transmission security supervision method, system, device and storage medium. BACKGROUND

[0002] With the deep development of digital economy, cross-domain data interaction scenarios are becoming more and more rich, covering cross-border trade contract transmission, cross-regional government approval file circulation, enterprise cross-branch core business data sharing, etc. The commercial secrets, confidential information and core business data involved in these interactions have high requirements for the security and traceability of the transmission process. Not only should the risk of eavesdropping and tampering in the transmission link be prevented, but also the source should be traced quickly and the responsibility should be defined after a security incident occurs.

[0003] The current mainstream cross-domain file transmission security solution is to encrypt only the channel transmission, that is, by building a special encryption tunnel, the file to be transmitted is encapsulated and transmitted across domains in the tunnel. The core relies on the channel encryption feature to resist external risks such as eavesdropping and interception during transmission.

[0004] This solution can only achieve basic encryption protection of the transmission link, and cannot establish an effective association between the file and the identities of the sender and the receiver. It also lacks a recording means for the whole process of file circulation. Once a file is leaked, it is impossible to determine whether the leak is due to internal management oversight at the sending end, security vulnerabilities in the transmission channel, or improper storage or secondary diffusion at the receiving end, resulting in a lack of effective technical support for responsibility subject positioning, greatly increasing the difficulty of tracing and the cost of handling security incidents. SUMMARY

[0005] Therefore, the purpose of the present application is to provide a cross-domain transmission security supervision method, system, device and storage medium, which can improve the security, traceability and responsibility definition accuracy of cross-domain file transmission.

[0006] In a first aspect, the embodiments of the present application provide a cross-domain transmission security supervision method applied to a cross-domain security transmission supervision system, the cross-domain security transmission supervision system comprising a sending end, a receiving end and a supervision node, the sending end and the receiving end being connected through a secure transmission channel, and the method comprising: The sending end embeds the sender identity information as a watermark into the original file to obtain a first to-be-evidenced file, calculates a first hash value of the first to-be-evidenced file, and stores the first hash value and sender metadata containing the sender information as a first evidence record to a blockchain; The sending end sends the first to-be-evidenced file to the receiving end through the secure transmission channel; The receiving end receives the first to-be-stored evidence file, calculates a receiving hash value of the first to-be-stored evidence file, queries the first to-be-stored evidence record stored in the blockchain based on the receiving hash value, and verifies whether the receiving hash value is consistent with a first hash value in the first to-be-stored evidence record; If the verification is consistent, the receiving end further embeds a receiver identity information as a watermark in the first to-be-stored evidence file to obtain a second to-be-stored evidence file, calculates a second hash value of the second to-be-stored evidence file, and stores the second hash value and receiver information-containing receiver metadata as a second to-be-stored evidence record in the blockchain; When it is necessary to trace the file in circulation, the supervision node calculates a current hash value of a target file and queries the blockchain to obtain at least one to-be-stored evidence record matched with the current hash value; at the same time, the supervision node performs a watermark extraction operation on the target file to obtain at least one party identity information contained therein; and the supervision node combines the extracted identity information and the metadata in the obtained to-be-stored evidence record to perform trace analysis on the circulation process of the target file.

[0007] Optionally, the embedding of the sender identity information as a watermark in the original file to obtain the first to-be-stored evidence file comprises: generating a watermark payload according to the sender identity information; embedding the watermark payload into a preset feature region of the original file by a frequency domain transformation or a spatial domain replacement algorithm to obtain the first to-be-stored evidence file.

[0008] Optionally, the calculation of the first hash value of the first to-be-stored evidence file and the storage of the first hash value and sender information-containing sender metadata as a first to-be-stored evidence record in the blockchain comprise: calculating the first hash value by using an SM3 or SHA-256 hash algorithm; combining the first hash value and the sender metadata to construct a structured data packet; submitting the structured data packet as the first to-be-stored evidence record to a blockchain network for consensus verification and storage.

[0009] Optionally, the sending of the first to-be-stored evidence file to the receiving end through the secure transmission channel comprises: negotiating and establishing an IPSec VPN tunnel between the sending end and the receiving end; using an SFTP protocol to perform block transmission on the first to-be-stored evidence file in the IPSec VPN tunnel, and generating a message authentication code for each transmitted data block; Verifying the data block received by the receiving end according to the message authentication code, and recombining the complete first to-be-stored evidence file after verification.

[0010] Optionally, before sending the first to-be-stored evidence file to the receiving end through the secure transmission channel, the method further comprises: Encrypting the first to-be-stored evidence file by using an SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file; Encrypting the session key by using an SM2 public key of the receiving end to obtain an encrypted session key; Sending the encrypted file and the encrypted session key to the receiving end through the secure transmission channel; After the receiving end receives the encrypted file and the encrypted session key, the method further comprises: Decrypting the encrypted session key by using its own SM2 private key to recover the session key; Decrypting the encrypted file by using the recovered session key to obtain the first to-be-stored evidence file.

[0011] Optionally, the tracing analysis of the circulation process of the target file combined with the extracted identity information and the metadata in the stored evidence record comprises: Determining based on the identity information extracted from the target file: if only the sender identity information is extracted, it is determined that the leak occurs after the sending end and before the receiving end embeds the dark watermark; if the sender and the receiver identity information are extracted at the same time, it is determined that the leak occurs after the receiving end embeds the dark watermark; According to the circulation link corresponding to the above determination, combined with the sending metadata or the receiving metadata of the corresponding link in the stored evidence record, determining the responsible subject suspected of leaking; According to the timestamp sequence in each stored evidence record, reconstructing the complete circulation path of the target file from sending to leaking.

[0012] Optionally, after verifying whether the receiving hash value is consistent with the first hash value in the first stored evidence record, the method further comprises: If the verification is inconsistent, an abnormal processing procedure is triggered; The abnormal processing procedure comprises: Recording an abnormal event, interrupting the current file processing, or sending an alarm notification to the sending end and the supervision node.

[0013] In a second aspect, the embodiments of the present application provide a cross-domain transmission security supervision system, and the device comprises: The cross-domain transmission security supervision system comprises a sending end, a receiving end and a supervision node, and the sending end is connected with the receiving end through a secure transmission channel; The sending end is configured to embed sender identity information as a watermark into an original file to obtain a first to-be-verified file, calculate a first hash value of the first to-be-verified file, and store the first hash value and sending metadata containing sender information as a first verification record in a blockchain; The sending end is configured to send the first to-be-verified file to the receiving end through the secure transmission channel; The receiving end is configured to, after receiving the first to-be-verified file, calculate a receiving hash value of the first to-be-verified file, query the first verification record stored in the blockchain based on the receiving hash value, and verify whether the receiving hash value is consistent with the first hash value in the first verification record; The receiving end is configured to, if the verification is consistent, further embed receiver identity information as a watermark into the first to-be-verified file to obtain a second to-be-verified file, calculate a second hash value of the second to-be-verified file, and store the second hash value and receiving metadata containing receiver information as a second verification record in the blockchain; The supervision node is configured to, when it is necessary to trace a file in circulation, calculate a current hash value of a target file and query the blockchain to obtain at least one verification record matching the current hash value, and perform a watermark extraction operation on the target file to obtain at least one party's identity information contained therein; the supervision node combines the extracted identity information and the metadata in the obtained verification record to perform trace analysis on the circulation process of the target file.

[0014] Optionally, the embedding of the sender identity information as a watermark into an original file to obtain a first to-be-verified file comprises: generating a watermark payload according to the sender identity information; embedding the watermark payload into a preset feature region of the original file through a frequency domain transformation or a spatial domain replacement algorithm to obtain the first to-be-verified file.

[0015] Optionally, the calculation of the first hash value of the first to-be-verified file and the storage of the first hash value and sending metadata containing sender information as a first verification record in a blockchain comprise: calculating the first hash value by using an SM3 or SHA-256 hash algorithm; combining the first hash value and the sending metadata to construct a structured data packet; submitting the structured data packet as the first verification record to a blockchain network for consensus verification and storage.

[0016] Optionally, the sending the first to-be-stored file to the receiving end through the secure transmission channel comprises: negotiating and establishing an IPSec VPN tunnel between the sending end and the receiving end; using an SFTP protocol to perform block transmission on the first to-be-stored file in the IPSec VPN tunnel, and generating a message authentication code for each transmitted data block; performing integrity verification on the data block received by the receiving end according to the message authentication code, and recombining the complete first to-be-stored file after verification.

[0017] Optionally, before the sending the first to-be-stored file to the receiving end through the secure transmission channel, the method further comprises: encrypting the first to-be-stored file using an SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file; encrypting the session key using an SM2 public key of the receiving end to obtain an encrypted session key; sending the encrypted file and the encrypted session key to the receiving end through the secure transmission channel; after the receiving end receives the encrypted file and the encrypted session key, the method further comprises: decrypting the encrypted session key using its own SM2 private key to recover the session key; decrypting the encrypted file using the recovered session key to obtain the first to-be-stored file.

[0018] Optionally, the tracing the circulation process of the target file by combining the extracted identity information and the metadata in the stored evidence record comprises: determining based on the identity information extracted from the target file: if only the sender identity information is extracted, it is determined that the leak occurs after the sending end and before the receiving end embeds the dark watermark; if the sender and the receiver identity information are extracted at the same time, it is determined that the leak occurs after the receiving end embeds the dark watermark; determining the responsible subject suspected of leaking according to the circulation link corresponding to the above determination, combined with the sending metadata or receiving metadata of the corresponding link in the stored evidence record; reconstructing the complete circulation path of the target file from sending to leaking according to the timestamp sequence in each stored evidence record.

[0019] Optionally, the receiving end is configured to, after verifying whether the received hash value is consistent with the first hash value in the first storage record, trigger an abnormal processing procedure if the verification is inconsistent. The abnormal processing procedure includes: recording an abnormal event, interrupting current file processing, or sending an alarm notification to the sending end and the supervision node.

[0020] In a third aspect, an embodiment of the present application provides 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 and the memory communicate through the bus, and the machine readable instructions are executed by the processor to perform the steps of the cross-domain transmission security supervision method in any one of the optional implementation manners of the first aspect.

[0021] In a fourth aspect, an embodiment of the present application provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is executed by a processor to perform the steps of the cross-domain transmission security supervision method in any one of the optional implementation manners of the first aspect.

[0022] The technical solutions provided by the present application include but are not limited to the following beneficial effects: The sending end embeds the sender identity information as a watermark in the original file and calculates a hash value, and stores a first storage record to a blockchain, thereby realizing accurate binding of the file and the sender identity, and ensuring the credibility of the file state, identity information, and transmission metadata in the sending link by virtue of the characteristics of the blockchain, thereby providing an initial and tamper-proof technical basis for subsequent file circulation traceability and responsibility definition.

[0023] The sending end sends the first file to be stored through a secure transmission channel, effectively resists risks such as eavesdropping, interception, tampering, and the like of the file in the cross-domain transmission process by virtue of the secure transmission characteristics of the channel, and ensures that the file carrying the sender watermark and the initial storage information can be delivered to the receiving end completely and safely, thereby laying a secure foundation for the verification and processing links of the receiving end.

[0024] The receiving end calculates a receiving hash value and queries the blockchain to verify consistency, can quickly verify whether the received file is consistent with the file sent by the sending end, discovers abnormal conditions such as tampering and data loss that may occur in the transmission process in a timely manner, avoids subsequent processing of the tampered file by the receiving end, and ensures the integrity and authenticity of the received file.

[0025] After verification, the receiving end embeds its own dark watermark and stores the second storage record to the blockchain, realizing the association and binding of the file and the identity of the receiving party, forming a "sender-receiver" double-end identity traceability chain. At the same time, the newly added hash value and receiving metadata are chained, perfecting the trusted record of the file transfer process, clarifying the processing responsibility of the receiving end, and further enriching the core data required for traceability.

[0026] The regulatory node can accurately restore the whole process of the file from sending to circulation based on the complete storage record in the blockchain and the double-end dark watermark in the file, quickly locate the specific link of the file leakage (after the sending end, before the receiving end, or after the receiving end), clearly define the responsibility subject, and meet the regulatory traceability needs of cross-domain file transmission.

[0027] The steps of the present application are progressive and interlocking, and through the coherent design of identity binding, trusted storage, transmission security protection, integrity verification, and full-link traceability, the present application not only realizes the security protection of the cross-domain file transmission process, but also establishes a trusted record and accurate traceability mechanism for the whole process of file circulation, and finally achieves the core beneficial effects of controllable security, traceable circulation, and definable responsibility of cross-domain file transmission.

[0028] In order to make the above-mentioned purposes, features and advantages of the present application more obvious and easy to understand, the following preferred embodiments are described in detail below, and the accompanying drawings are described as follows. BRIEF DESCRIPTION OF DRAWINGS

[0029] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the following will briefly introduce the drawings needed to be used in the embodiments. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0030] Figure 1 A flowchart of a cross-domain transmission security regulation method provided by an embodiment of the present application is shown; FIG. 2 shows a flowchart of a first storage file determination method provided by an embodiment of the present application; FIG. 3 shows a flowchart of a first storage record storage method provided by an embodiment of the present application; FIG. 4 shows a flowchart of a first storage file sending method provided by an embodiment of the present application; FIG. 5 shows a flowchart of an encrypted information transmission method provided by an embodiment of the present application; Figure 6 shows a flow chart of a first to-be-stored file decryption method provided by the embodiment one of the present application; Figure 7 Figure 7 shows a flow chart of a flow process traceability analysis provided by the embodiment one of the present application; Figure 8 Figure 8 shows a core component schematic diagram of a cross-domain security transmission supervision system provided by the embodiment one of the present application; Figure 9 Figure 9 shows a complete flow chart and abnormal processing logic diagram of a cross-domain file from sending to receiving provided by the embodiment one of the present application; Figure 10 Figure 10 shows a structural schematic diagram of a cross-domain transmission security supervision system provided by the embodiment two of the present application; Figure 11 Figure 11 shows a structural schematic diagram of a computer device provided by the embodiment three of the present application. DETAILED DESCRIPTION

[0031] In order to make the purpose, technical scheme and advantages of the embodiments of the present application clearer, the technical scheme of the embodiments of the present application will be described clearly and completely below in combination with the drawings in the embodiments of the present application. Obviously, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative work are within the scope of protection of the present application.

[0032] Embodiment one In order to facilitate the understanding of the present application, the following will be combined with the drawings to describe the embodiments of the present application. Figure 1 Figure 1 shows a flow chart of a cross-domain transmission security supervision method provided by the embodiment one of the present application, which is described in detail below.

[0033] Referring to Figure 1, Figure 1 Figure 1 shows a flow chart of a cross-domain transmission security supervision method provided by the embodiment one of the present application, which is described in detail below. Figure 1 Figure 1 shows a flow chart of a cross-domain transmission security supervision method provided by the embodiment one of the present application, which is described in detail below. S101: The sender embeds the sender identity information as a dark watermark into the original file to obtain a first to-be-stored file, calculates a first hash value of the first to-be-stored file, and stores the first hash value and sender metadata containing the sender information together as a first storage record to a block chain.

[0034] Specifically, the sender identity information is a combined identifier with uniqueness, including a sender subject ID (such as an enterprise registration number, an organization code), an operation user ID (such as an employee ID, an authorized account), a transmission timestamp accurate to milliseconds, and a file unique number (such as a contract number, a drawing number) can be additionally attached. All information is encoded by ASCII (American Standard Code for Information Interchange) to form a fixed-length watermark core data.

[0035] The dark watermark embedding process adopts a stealth embedding technology, which does not change the format, size and normal use function of the original file. It is suitable for multiple important electronic file types such as contracts (Word, PDF), qualification certificates (scanned copies), audit reports (Excel, PDF), design drawings (CAD, PNG), and the embedding position is selected in the file redundant data area or the visual / logical non-impact area to avoid being mistakenly deleted by conventional editing tools.

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

[0037] The block chain storage adopts a consortium chain architecture, and the nodes include a sender gateway, a receiver gateway and a designated server of a supervision node. After the first storage record is submitted, it needs to pass the consensus verification (such as a practical Byzantine fault tolerance algorithm) of at least 3 nodes, and after the verification is passed, it is stored in a distributed manner to ensure that the record is tamper-proof and cannot be deleted.

[0038] S102: The sender sends the first to-be-stored file to the receiver through the secure transmission channel.

[0039] Specifically, the secure transmission channel is built based on IPSec VPN (Internet Protocol Security Virtual Private Network) and SFTP (SSH File Transfer Protocol) protocols, wherein the IPSec VPN adopts ESP (Encapsulating Security Payload) protocol for encapsulation and encryption, the encryption algorithm is AES-256-GCM (Advanced Encryption Standard 256-bit Galois / Counter Mode), and the identity authentication adopts pre-shared key (PSK) + digital certificate dual verification, thereby ensuring the link security of cross-domain network transmission and adapting to the delay and bandwidth fluctuation problems of cross-border network environments such as Hong Kong and Shenzhen, China.

[0040] The SFTP protocol, as a transmission layer protocol, is built based on SSH-2 (Secure Shell Version 2) protocol, supports file block transmission and breakpoint resume functions, and for large files (such as design drawings exceeding 1 GB), will be automatically divided into 100 MB / block data packets, each block of data carries a check code, thereby avoiding data loss or disorder in the transmission process.

[0041] S103: After receiving the first to-be-stored evidence file, the receiving end calculates the receiving hash value of the first to-be-stored evidence file, queries the first to-be-stored evidence record stored in the blockchain based on the receiving hash value, and verifies whether the receiving hash value is consistent with the first hash value in the first to-be-stored evidence record.

[0042] Specifically, the algorithm for calculating the receiving hash value of the receiving end is completely consistent with that of the sending end (if the sending end uses SM3, the receiving end also uses SM3), thereby ensuring the consistency of the hash value calculation and avoiding verification misjudgment caused by algorithm difference.

[0043] The blockchain query is realized through a smart contract to achieve fast matching, the receiving end calls the contract by taking the receiving hash value as a query parameter, the contract retrieves the to-be-stored evidence record corresponding to the hash value in the distributed ledger of the blockchain, and the whole query process takes no more than 3 seconds, thereby being suitable for the fast verification scene of batch files.

[0044] The verification scene includes two core cases: if consistent, it means that the file has not been tampered with or data loss during transmission, and can enter the subsequent watermark embedding process; if inconsistent, it may be that the file is tampered with during transmission, network packet loss causes incomplete data, or the sender file itself has abnormalities.

[0045] S104: If the verification is consistent, the receiving end further embeds the receiver identity information into the first to-be-certified file to obtain a second to-be-certified file, calculates a second hash value of the second to-be-certified file, and stores the second hash value and receiving metadata containing the receiver information as a second certification record to the blockchain.

[0046] Specifically, the receiver identity information is also a combined unique identifier, including a receiving unit ID (such as a receiving enterprise registration number, an organization code), a receiving operation user ID (such as a receiving employee ID, an authorized account number), a receiving timestamp (accurate to milliseconds), and a receiving end gateway number. The embedding method is consistent with that of the sender, and the two do not conflict with each other and do not overlap, and can be independently extracted.

[0047] The second to-be-certified file carries double-end dark watermarks, and the two watermarks are stored in different feature areas of the file. Even if one of the watermarks is maliciously destroyed, the other watermark can still be extracted as a trace basis, improving the anti-attack ability of the watermark.

[0048] The second hash value is also calculated using the SM3 algorithm and is generated based on the complete content of the file after embedding the double watermarks, ensuring that it is completely bound to the current state of the file; the receiving metadata includes receiving task number, receiving end gateway information, file receiving status (such as "complete reception" and "normal decryption"), receiving operator signature, and other information, which are combined with the second hash value as a structured data package and uploaded to the chain.

[0049] The second certification record chain process is consistent with the first certification record, and is distributed after consensus verification by the alliance chain node, forming a complete behavior certification chain of "sending-receiving", providing double data support for subsequent traceability.

[0050] S105: When it is necessary to trace the file in circulation, the supervision node calculates the current hash value of the target file and queries the blockchain to obtain at least one certification record matching the current hash value; at the same time, the dark watermark extraction operation is performed on the target file to obtain at least one party's identity information contained therein; the supervision node combines the extracted identity information with the metadata in the obtained certification record to perform traceability analysis on the circulation process of the target file.

[0051] Specifically, the target file includes a suspected leakage file, a file that needs to be monitored and checked, etc. The monitoring node is deployed by an authorized agency such as the Cyberspace Administration of China and the audit department, and is equipped with a special hash calculation tool and a watermark extraction tool, which supports batch processing of multiple target files.

[0052] When the hash value is queried, if there is no matching record in the blockchain, it means that the target file has not been transmitted across domains by the system, and its leakage or circulation is irrelevant to the system. If there is a matching record, the corresponding record details can be obtained, including the sending end, the receiving end, the timestamp, the file basic information, and other full metadata.

[0053] The watermark extraction tool supports automatic identification of file types and extraction of dark watermarks for multiple formats. The extraction process does not need to modify the target file, only reads the watermark data of the characteristic area of the file, and then restores the identity information through a decoding algorithm, which can effectively resist attacks from conventional watermark removal tools.

[0054] In the traceability analysis, the monitoring node cross-comparisons the extracted identity information with the metadata in the record, confirms the sending time, receiving time, and operation subject of the file, and restores the circulation path in combination with the timestamp sequence. In an optional implementation, as shown in FIG. 2, which shows a flowchart of a first file to be stored according to an embodiment of the present application, wherein the sending party identity information is embedded as a dark watermark in the original file to obtain a first file to be stored, including steps S201-S202: S201: Generate a watermark payload according to the sending party identity information.

[0055] Specifically, the sending party identity information is first processed by Base64 (Base64 Encoding Scheme, Base64 encoding scheme) encoding, and then combined with a randomly generated 16-bit check code to form watermark core data; then the core data is checked by a cyclic redundancy check (CRC32, Cyclic Redundancy Check 32-bit, 32-bit cyclic redundancy check) algorithm to generate a check bit, and finally combined into a watermark payload of a fixed length (such as 64 bytes), ensuring the integrity and identifiability of the watermark information.

[0056] The watermark payload also includes an anti-tamper identifier. If the watermark information is maliciously modified, it will not be able to be normally decoded due to the mismatch of the check bit when extracted, improving the security of the watermark.

[0057] S202: Embed the watermark payload into the preset characteristic area of the original file through a frequency domain transformation or spatial domain replacement algorithm to obtain the first file to be stored.

[0058] Specifically, the frequency domain transformation algorithm is suitable for visual files such as pictures and drawings, and uses a discrete cosine transform (DCT) to convert the file to the frequency domain, embeds a watermark load in the medium frequency coefficient area, which neither affects the visual effect of the file nor resists compression, cutting and other conventional processing; the spatial domain replacement algorithm is suitable for document files (such as Word and PDF), and embeds a watermark load in the character encoding redundant bits or format control field of the file, without affecting the text display and editing function of the document.

[0059] The preset feature area is a stable area selected through a large number of tests, and for document files, the redundant field after the format descriptor is selected; for picture and drawing files, the area with low information density but without affecting the core content is selected to ensure the stability and usability of the file after the watermark is embedded.

[0060] In an optional embodiment, referring to FIG. 3, FIG. 3 shows a flowchart of a first evidence storage recording storage method provided by an embodiment of the present application, wherein the first hash value of the first evidence to be stored is calculated, and the first hash value and sending metadata containing sender information are stored as a first evidence storage record to a block chain, including steps S301-S303: S301: The SM3 or SHA-256 (Secure Hash Algorithm 256-bit) hash algorithm is used to calculate the first hash value.

[0061] Specifically, SM3 is a self-developed national encryption hash algorithm, with a hash value length of 256 bits, high security and high collision resistance, and is suitable for government affairs, finance, enterprise cross-border data transmission scenarios with high security requirements; SHA-256 is an international general hash algorithm, with a hash value length of 256 bits, and is suitable for cross-domain transmission scenarios that need to be compatible with international systems, and users can choose according to actual needs.

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

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

[0064] Specifically, the structured data packet is constructed in JSON format, and the fields include "hashValue" (storing the first hash value), "senderInfo" (storing the sender identity information), "fileBasicInfo" (storing the file name, size, type, and unique number), "transmissionInfo" (storing the transmission task number, target receiving end identifier, and transmission timestamp), and "signature" (sender gateway digital signature). The field definition is clear, the format is standard, and it is convenient for blockchain storage and subsequent query analysis.

[0065] The sender gateway digital signature adopts an SM2 (SM2 Elliptic Curve Cryptographic Algorithm) asymmetric encryption algorithm, uses the private key of the sender gateway to sign the data packet, and ensures that the data packet is not tampered with during transmission to the blockchain node.

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

[0067] Specifically, the blockchain network is a consortium chain, and the nodes are deployed by the sending end belonging to the institution, the receiving end belonging to the institution, and the supervisory authority. Each node stores a complete distributed ledger to ensure data redundancy and availability; the consensus verification adopts a practical Byzantine fault tolerance (PBFT, Practical Byzantine Fault Tolerance) algorithm, and when more than 2 / 3 of the nodes verify that the data packet is valid (including correct hash value format, valid digital signature, and complete metadata), the consensus can be completed.

[0068] When stored, the blockchain structure is adopted, each block contains multiple evidence storage records, the hash value of the previous block, and the timestamp. Once the block is generated, it cannot be modified, and subsequent queries can quickly locate the corresponding evidence storage record through the hash value, ensuring the efficiency of the traceability.

[0069] In an optional embodiment, referring to FIG. 4, FIG. 4 shows a flowchart of a first evidence storage file sending method provided by the embodiment one of the present application, wherein the sending of the first evidence storage file to the receiving end through the secure transmission channel includes steps S401-S403: S401: Establish an IPSec VPN tunnel between the sending end and the receiving end.

[0070] Specifically, the IPSec VPN tunnel establishment process follows the IKEv2 (Internet Key Exchange Version 2) protocol. The sending end gateway and the receiving end gateway first perform identity authentication (using digital certificate + pre-shared key dual verification), and after the authentication is passed, the security parameters such as encryption algorithm, hash algorithm, and session key are negotiated. The session key is dynamically generated by a key exchange algorithm (such as ECDH, Elliptic Curve Diffie-Hellman), and a new key is generated each time the tunnel is established, avoiding the security risks caused by key leakage.

[0071] After the tunnel is established, periodic survival detection (such as sending a detection packet every 30 seconds) is performed. If the tunnel is detected to be interrupted, it will automatically re-negotiate and establish, ensuring the stability of the transmission channel and adapting to the temporary disconnection problem that may occur in cross-border networks.

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

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

[0074] The message authentication code (MAC) is generated using the HMAC-SM3 (Hash-based Message Authentication Code with SM3) algorithm, which 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, ensuring that the data block is not tampered with or replaced during transmission.

[0075] S403: According to the message authentication code, the integrity of the data block received by the receiving end is verified, and after the verification is passed, the complete first to-be-stored file is recombined.

[0076] Specifically, after the receiving end receives each data block, the corresponding MAC is extracted, and the same HMAC-SM3 algorithm and session key are used to recalculate the MAC based on the received data block content. The two MACs are compared to determine whether they are consistent. If they are consistent, the data block is complete and has not been tampered with. If they are not consistent, the sending end is required to retransmit the data block.

[0077] After all the data blocks are verified, the receiving end reorganizes the data blocks in the order of the "block sequence number" to restore the complete first file to be stored as evidence, and checks the overall hash value of the file again after reorganization (consistent with the receiving hash value) to ensure that the file has no reorganization errors.

[0078] In an optional embodiment, referring to FIG. 5, which shows a flowchart of an encrypted information transmission method provided by Embodiment One of the present application, before the first file to be stored as evidence is sent to the receiving end through the secure transmission channel, the method further includes steps S501-S503: S501: The first file to be stored as evidence is encrypted using the SM4 (SM4 Block Cipher Algorithm, SM4 block cipher algorithm) algorithm combined with a dynamically generated session key to obtain an encrypted file.

[0079] Specifically, SM4 is a national block cipher algorithm of China, which uses a 128-bit key and a 128-bit block length, and the encryption mode is the CBC (Cipher Block Chaining, Cipher Block Chaining) mode. The IV (Initialization Vector, Initialization Vector) is randomly generated and transmitted together with the encrypted file to ensure that the ciphertext of the same file is different each time after encryption, thereby improving the security of encryption.

[0080] The session key is dynamically generated by the sending end gateway through a random number generator, has a length of 128 bits, is used only in this transmission after being generated, and is automatically destroyed after the transmission is completed, thereby avoiding the risk of leakage caused by long-term storage of the key.

[0081] S502: The session key is encrypted using the SM2 public key of the receiving end to obtain an encrypted session key.

[0082] Specifically, SM2 is a national asymmetric encryption algorithm of China, and the SM2 public key of the receiving end is published to the alliance chain node in advance by the receiving end. The sending end obtains the public key by querying the blockchain to ensure the authenticity and validity of the public key. In the encryption process, the session key is input as plaintext, and the ciphertext is generated after being encrypted by the SM2 public key. Only the SM2 private key of the receiving end can decrypt it to ensure that the session key is not stolen during transmission.

[0083] The length of the encrypted session key is 256 bits, which is stored separately from the encrypted file. When transmitting, the encrypted session key is sent first, and then the encrypted file is sent, so that the receiving end can first decrypt the session key and then decrypt the file.

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

[0085] 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.

[0086] 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.

[0087] 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: S601: Use its own SM2 private key to decrypt the encrypted session key and recover the session key.

[0088] 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.

[0089] 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.

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

[0091] 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.

[0092] 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.

[0093] In an optional implementation, see Figure 7 As shown, Figure 7A flowchart of a flow conversion process traceability analysis provided by Embodiment One of the present application is shown, wherein the traceability analysis of the flow conversion process of the target file by combining the extracted identity information with the metadata in the obtained storage record comprises steps S701-S703: S701: Based on the identity information extracted from the target file, it is determined that if only the sender identity information is extracted, it is determined that the leak occurs after the sending end and before the receiving end embeds the invisible watermark; if the sender and receiver identity information are extracted at the same time, it is determined that the leak occurs after the receiving end embeds the invisible watermark.

[0094] Specifically, the scenario of only extracting the sender identity information includes: the file is leaked after the sending end embeds the watermark without being transmitted to the receiving end, the file is stolen during transmission, and the file is leaked before the receiving end embeds its own watermark. These scenarios all belong to the link after the sending end and before the receiving end watermark embedding.

[0095] The scenario of extracting both end identity information includes: internal personnel illegally disseminate after the receiving end embeds the watermark, secondary forwarding leads to leakage, or the receiving end storage device is stolen leading to file leakage. These scenarios all belong to the link after the receiving end watermark embedding, and the responsibility subject is clearly pointed to the receiving end.

[0096] S702: According to the flow conversion link corresponding to the above determination, the sending metadata or receiving metadata of the corresponding link in the storage record is combined to determine the suspected leak responsibility subject.

[0097] Specifically, if the leak occurs after the sending end and before the receiving end watermark embedding, the sender ID, operation user ID, and transmission timestamp in the sending metadata can be combined to determine the specific sending operation subject (such as a certain enterprise or employee), and the transmission log can be combined to determine whether there is a stealing behavior during transmission to lock the responsibility subject.

[0098] If the leak occurs after the receiving end watermark embedding, the receiving unit ID, receiving user ID, and receiving timestamp in the receiving metadata can be combined to determine the specific receiving operation subject (such as a receiving enterprise or receiving employee), and the file access log and transmission log of the receiving end can be combined to determine the direct and related responsibility persons by investigating the flow conversion path of the file in the receiving end.

[0099] S703: According to the timestamp sequence in each storage record, the complete flow conversion path of the target file from sending to leakage is reconstructed.

[0100] Specifically, the timestamps in the storage record include the sending end on-chain timestamp and the receiving end on-chain timestamp, which can be combined with the network delay data of file transmission to accurately restore the sending time, transmission duration, and receiving time of the file, forming a time axis type flow conversion track.

[0101] If the file exists multiple forwarding (such as the receiving end forwarding to other agencies, and other agencies embedding watermarks again and uploading), all the circulation links can be connected in time sequence by multiple groups of evidence records on the block chain, including the operation subject, operation time and file status of each link, to completely restore the whole life cycle path of the file from the original sending to the final leakage.

[0102] In an optional embodiment, after verifying whether the receiving hash value is consistent with the first hash value in the first evidence record, the method further comprises: If the verification is inconsistent, an abnormal processing procedure is triggered.

[0103] Specifically, the reasons for inconsistency include tampering during file transmission, incomplete data due to network packet loss, errors in the sending end file itself, errors in the receiving end hash value calculation, and the abnormal processing procedure will automatically investigate common reasons (such as recalculating the hash value and checking the network connection) first. If the investigation is unsuccessful, the manual processing procedure is entered.

[0104] The abnormal processing procedure generates a detailed abnormal report, including the abnormal occurrence time, the receiving end identifier, the file basic information, the hash value comparison result, the network state data, etc., which provides a complete basis for subsequent problem investigation.

[0105] The abnormal processing procedure includes recording abnormal events, interrupting the current file processing, or sending alarm notifications to the sending end and the supervision node.

[0106] Specifically, recording abnormal events will store the abnormal report in the log server of the receiving end, and the log server uses a read-only mode for storage to ensure that the abnormal record is not tampered with and to retain the traceability basis; at the same time, the abnormal event is synchronized to the block chain to form an unalterable abnormal record, which is convenient for the supervision node to check later.

[0107] Interrupting the current file processing will immediately stop subsequent operations such as watermark embedding, hash calculation, and uploading, to avoid abnormal files entering the circulation link and reduce security risks; if the file has been partially processed, the temporary files generated during the processing process will be automatically deleted to ensure the cleanliness of system storage.

[0108] Sending alarm notifications uses a multi-channel notification method, including system pop-up window alarm, administrator email notification, and mobile phone SMS alarm. The alarm information includes abnormal event number, core abnormal information, and processing suggestions, which are convenient for the sending end and the supervision node to know and take measures (such as the sending end resending the file and the supervision node intervening in the verification) in time.

[0109] In an optional embodiment, referring to Figure 8 As shown in Figure 8A core component schematic diagram of a cross-domain security transmission supervision system provided by Embodiment One of the present application is shown, wherein the components contained in the diagram are a supervision node, a sending end gateway, a receiving end gateway, and a blockchain, and the interaction relationship of each component is that the supervision node initiates "data verification" to the blockchain; the sending end gateway performs "data on-chain" to the blockchain; the receiving end gateway performs "data verification and on-chain" to the blockchain; and meanwhile, the sending end gateway and the receiving end gateway realize data interaction through a "security transmission channel". The diagram directly presents the basic framework and information flow path of the system, and is an architecture visualization carrier of cross-domain transmission security supervision.

[0110] Referring to Figure 9 as shown, Figure 9 A complete flow and abnormal processing logic diagram of a cross-domain file from sending to receiving provided by Embodiment One of the present application is shown, wherein the flow on the sending end side is "original file → sending end watermarking → blockchain sending and on-chain → packaging and encryption", and then the file is transmitted to the receiving end through a "security transmission channel"; the flow on the receiving end side is "unpacking and decryption → receiving end verification → whether the verification is consistent?", if the verification result is "yes", then "receiving end watermarking → receiving end on-chain" is performed, and the final flow is closed to the "receiving end"; if the verification result is "no", then "sending exception alarm" is triggered. The diagram clearly defines the whole-link operation link and abnormal branch, and clearly defines the execution logic of each step.

[0111] It can be known from the two diagrams that, through the evidence storage interaction architecture of "supervision / receiving and sending end gateway-blockchain" and the flow closed loop of "encrypted transmission + whole-link watermarking + blockchain evidence storage + abnormal branch verification", the cross-domain transmission security supervision scheme not only realizes the real trust of evidence storage data and the authoritative check of supervision verification relying on the non-tamperable characteristics of the blockchain, but also strengthens the link isolation and content security of cross-domain transmission through the secure transmission channel and encryption and decryption operations, simultaneously achieves the whole-link traceability of file flow through the double-end watermark embedding and on-chain recording, and can also quickly identify risks and trigger alarms through the abnormal branch of receiving end verification, and finally realizes the technical effects of trusted evidence storage, safe isolation, whole-link traceability, and timely risk control of cross-domain file transmission.

[0112] Embodiment Two Referring to Figure 10 as shown, Figure 10 A structure schematic diagram of a cross-domain transmission security supervision system provided by Embodiment Two of the present application is shown, wherein the cross-domain transmission security supervision system comprises a sending end 1001, a receiving end 1002, and a supervision node 1003, and the sending end and the receiving end are connected through a security transmission channel; The sending end is configured to embed sender identity information as a watermark into an original file to obtain a first to-be-stored evidence file, calculate a first hash value of the first to-be-stored evidence file, and store the first hash value and sending metadata containing the sender information together as a first evidence record to a blockchain; The sending end is configured to send the first to-be-stored evidence file to the receiving end through the secure transmission channel. The receiving end is configured to, after receiving the first to-be-stored evidence file, calculate a receiving hash value of the first to-be-stored evidence file, query the first evidence record stored in the blockchain based on the receiving hash value, and verify whether the receiving hash value is consistent with the first hash value in the first evidence record. The receiving end is configured to, if the verification is consistent, further embed receiver identity information as a watermark into the first to-be-stored evidence file to obtain a second to-be-stored evidence file, calculate a second hash value of the second to-be-stored evidence file, and store the second hash value and receiving metadata containing the receiver information together as a second evidence record to the blockchain. The supervision node is configured to, when it is necessary to trace a file in circulation, calculate a current hash value of a target file and query the blockchain to obtain at least one evidence record matching the current hash value, and perform a watermark extraction operation on the target file to obtain at least one party identity information contained therein; the supervision node combines the extracted identity information and the metadata in the obtained evidence record to perform trace analysis on the circulation process of the target file.

[0113] In an optional embodiment, the embedding of the sender identity information as a watermark into the original file to obtain the first to-be-stored evidence file comprises: generating a watermark payload according to the sender identity information; embedding the watermark payload into a preset feature region of the original file through a frequency domain transformation or a spatial domain replacement algorithm to obtain the first to-be-stored evidence file.

[0114] In an optional embodiment, the calculation of the first hash value of the first to-be-stored evidence file and the storage of the first hash value and the sending metadata containing the sender information together as a first evidence record to a blockchain comprise: calculating the first hash value by using an SM3 or SHA-256 hash algorithm; combining the first hash value and the sending metadata to construct a structured data packet; submitting the structured data packet as the first evidence record to a blockchain network for consensus verification and storage.

[0115] In an alternative embodiment, the sending of the first to-be-stored file to the receiving end through the secure transmission channel comprises: negotiating and establishing an IPSec VPN tunnel between the sending end and the receiving end; performing block transmission of the first to-be-stored file using the SFTP protocol within the IPSec VPN tunnel, and generating a message authentication code for each transmitted data block; performing integrity verification on the data blocks received by the receiving end according to the message authentication code, and recombining the complete first to-be-stored file after verification.

[0116] In an alternative embodiment, before the sending of the first to-be-stored file to the receiving end through the secure transmission channel, the method further comprises: encrypting the first to-be-stored file using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file; encrypting the session key using the SM2 public key of the receiving end to obtain an encrypted session key; sending the encrypted file and the encrypted session key to the receiving end through the secure transmission channel; after the receiving end receives the encrypted file and the encrypted session key, the method further comprises: decrypting the encrypted session key using its own SM2 private key to recover the session key; decrypting the encrypted file using the recovered session key to obtain the first to-be-stored file.

[0117] In an alternative embodiment, the tracing analysis of the flow process of the target file combined with the extracted identity information and the metadata in the obtained storage record comprises: determining based on the identity information extracted from the target file: if only the sender identity information is extracted, it is determined that the leak occurred after the sending end and before the receiving end embedded the dark watermark; if both the sender and the receiving end identity information are extracted, it is determined that the leak occurred after the receiving end embedded the dark watermark; determining the responsible subject suspected of leaking according to the corresponding flow link of the above determination combined with the sending metadata or receiving metadata of the corresponding link in the storage record; reconstructing the complete flow path of the target file from sending to leaking according to the timestamp sequence in each storage record.

[0118] In an optional embodiment, the receiving end is configured to, after verifying whether the received hash value is consistent with the first hash value in the first storage record, trigger an exception handling procedure if the verification is inconsistent. The exception handling procedure includes: recording an exception event, interrupting current file processing, or sending an alarm notification to the sending end and the supervision node.

[0119] Embodiment Three Based on the same application concept, refer to Figure 11 as shown, Figure 11 a structural schematic diagram of a computer device provided by Embodiment Three of the present application is shown, wherein, as shown, Figure 11 a computer device 1100 provided by Embodiment Three of the present application 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 through the bus 1103, and the machine readable instructions executed by the processor 1101 perform the steps of the cross-domain transmission security supervision method shown in Embodiment One described above.

[0120] Embodiment Four Based on the same application concept, the present application further provides a computer readable storage medium, the computer readable storage medium stores a computer program, and the computer program is run by a processor to perform the steps of the cross-domain transmission security supervision method described in any one of the above embodiments.

[0121] Those skilled in the art can clearly understand that, for the convenience and brevity of description, the specific working process of the system and device described above can refer to the corresponding process in the foregoing method embodiments, which will not be repeated here.

[0122] The computer program product for cross-domain transmission security supervision provided by the embodiments of the present application includes a computer readable storage medium storing program codes, the program codes include instructions for executing the method described in the foregoing method embodiments, and the specific implementation can be referred to the method embodiments, which will not be repeated here.

[0123] The cross-domain transmission security supervision system provided in the embodiments of the present application can be specific hardware on a device or software or firmware installed on the device, and the like. The system provided in the embodiments of the present application has the same implementation principles and technical effects as the foregoing method embodiments, and for brevity of description, the system embodiments are not described in detail in parts not mentioned in the foregoing method embodiments, and the corresponding content in the foregoing method embodiments can be referred to.

[0124] In the embodiments provided in the present application, it should be understood that the disclosed system and method can be implemented in other manners. The system embodiments described above are only schematic. For example, the division of the units is only a logical function division. There can be another division manner for the actual implementation, for example, a plurality of units or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the displayed or discussed mutual couplings or direct couplings or communication connections between the units can be indirect couplings or communication connections through some interfaces, devices or units, and can be electrical, mechanical or in other forms.

[0125] The units described as separated components can or can not be physically separated, and the components displayed as units can or can not be physical units, i.e., can be located in one place, or can be distributed on a plurality of network units. In actual implementation, some or all of the units can be selected according to the actual needs to achieve the purposes of the embodiments of the present application.

[0126] In addition, each functional unit in the embodiments of the present application can be integrated in one processing unit, or each unit can exist physically, or two or more units can be integrated in one unit.

[0127] If the functions are implemented in the form of software function units and sold or used as independent products, the software function units can be stored in a computer readable storage medium. Based on such understanding, the technical solutions of the present application can be embodied in the form of a software product, and the computer software product is stored in a storage medium, and includes several instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present application. The foregoing storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0128] It should be noted that like reference numerals and letters refer to like elements throughout the several views of the drawings, and that, unless otherwise indicated, like reference numerals and letters are used consistently throughout the drawings and the description and have meanings ascribed to them even when doing so incurs redundancy. Furthermore, the terms "first", "second", "third", etc. are used merely as identifiers, and are not intended to signify or imply relative importance.

[0129] Finally, it should be noted that the above-described embodiments are merely exemplary of the application, which is not limited to them, but can be practiced with modification and alteration within the scope of the appended claims. Accordingly, the specification, including the examples, is to be regarded in an illustrative manner and not a restrictive one.

Claims

1. A method for cross-domain transfer security supervision, characterized in that, The application is applied to a cross-domain secure transmission supervision system, the cross-domain secure transmission supervision system comprises a sending end, a receiving end and a supervision node, the sending end is connected with the receiving end through a secure transmission channel, and the method comprises the following steps: The sending end embeds sender identity information into an original file as a watermark to obtain a first to-be-evidenced file, calculates a first hash value of the first to-be-evidenced file, and stores the first hash value and sending metadata containing sender information together as a first evidence record in a block chain; The sending end sends the first to-be-evidenced file to the receiving end through the secure transmission channel; After receiving the first to-be-evidenced file, the receiving end calculates a receiving hash value of the first to-be-evidenced file, queries the first evidence record stored in the block chain based on the receiving hash value, and verifies whether the receiving hash value is consistent with the first hash value in the first evidence record; If the verification is consistent, the receiving end further embeds receiver identity information into the first to-be-evidenced file as a watermark to obtain a second to-be-evidenced file, calculates a second hash value of the second to-be-evidenced file, and stores the second hash value and receiving metadata containing receiver information together as a second evidence record in the block chain; When it is necessary to trace the file in circulation, the supervision node calculates a current hash value of a target file and queries the block chain to obtain at least one evidence record matched with the current hash value; meanwhile, the supervision node performs a watermark extraction operation on the target file to obtain at least one party identity information contained in the target file; and the supervision node combines the extracted identity information and the metadata in the obtained evidence record to perform trace analysis on the circulation process of the target file.

2. The method of claim 1, wherein, The sending end embeds sender identity information into an original file as a watermark to obtain a first to-be-evidenced file, which comprises the following steps: Generating a watermark payload according to the sender identity information; Embedding the watermark payload into a preset feature area of the original file through a frequency domain transformation or a spatial domain replacement algorithm to obtain the first to-be-evidenced file.

3. The method of claim 1, wherein, The sending end calculates a first hash value of the first to-be-evidenced file, and stores the first hash value and sending metadata containing sender information together as a first evidence record in a block chain, which comprises the following steps: Calculating the first hash value by using an SM3 or SHA-256 hash algorithm; Combining the first hash value and the sending metadata to construct a structured data packet; Submitting the structured data packet as the first evidence record to a block chain network for consensus verification and storage.

4. The method of claim 1, wherein, The sending end sends the first to-be-evidenced file to the receiving end through the secure transmission channel, which comprises the following steps: Negotiating to establish an IPSec VPN tunnel between the sending end and the receiving end; Using an SFTP protocol to perform block transmission on the first to-be-evidenced file in the IPSec VPN tunnel, and generating a message authentication code for each transmitted data block; Performing integrity verification on the data blocks received by the receiving end according to the message authentication code, and recombining the complete first to-be-evidenced file after verification.

5. The method of claim 1, wherein, Before sending the first to-be-verified file to the receiving end through the secure transmission channel, the method further comprises: encrypting the first to-be-verified file using the SM4 algorithm combined with a dynamically generated session key to obtain an encrypted file; encrypting the session key using the SM2 public key of the receiving end to obtain an encrypted session key; sending the encrypted file and the encrypted session key to the receiving end through the secure transmission channel; After the receiving end receives the encrypted file and the encrypted session key, the method further comprises: decrypting the encrypted session key using its own SM2 private key to recover the session key; decrypting the encrypted file using the recovered session key to obtain the first to-be-verified file.

6. The method of claim 1, wherein, The combination of the extracted identity information and the obtained metadata in the verification record is used to trace the flow process of the target file, including: Based on the identity information extracted from the target file, it is determined that if only the sender's identity information is extracted, the leak occurs after the sending end and before the receiving end embeds the invisible watermark; if the sender's and receiver's identity information are extracted at the same time, the leak occurs after the receiving end embeds the invisible watermark; According to the flow link corresponding to the above determination, combined with the sending metadata or receiving metadata of the corresponding link in the verification record, the responsible subject suspected of leaking is determined; According to the timestamp sequence in each verification record, the complete flow path of the target file from sending to leaking is reconstructed.

7. The method of claim 1, wherein, After verifying whether the received hash value is consistent with the first hash value in the first verification record, the method further comprises: If the verification is inconsistent, the receiving end triggers an exception handling process; The exception handling process includes: Recording an exception event, interrupting the current file processing, or sending an alarm notification to the sending end and the supervision node.

8. A cross-domain transfer security governance system, comprising: The cross-domain transmission security supervision system comprises a sending end, a receiving end, and a supervision node, and the sending end and the receiving end are connected through a secure transmission channel; The sending end is configured to embed the sender's identity information as an invisible watermark into an original file to obtain a first to-be-verified file, calculate a first hash value of the first to-be-verified file, and store the first hash value and sending metadata containing the sender's information as a first verification record to a blockchain; The sending end is configured to send the first to-be-verified file to the receiving end through the secure transmission channel; The receiving end is configured to calculate a receiving hash value of the first to-be-verified file after receiving the first to-be-verified file, query the first verification record stored in the blockchain based on the receiving hash value, and verify whether the receiving hash value is consistent with the first hash value in the first verification record; The receiving end is configured to, if the verification is consistent, further embed the receiver identity information into the first to-be-stored file as a watermark to obtain a second to-be-stored file, calculate a second hash value of the second to-be-stored file, and store the second hash value and receiver metadata containing the receiver information together as a second storage record in the blockchain. The supervision node is configured to, when it is necessary to trace the file in circulation, calculate a current hash value of a target file and query the blockchain to obtain at least one storage record matched with the current hash value, and perform a watermark extraction operation on the target file to obtain at least one party identity information contained in the target file; the supervision node combines the extracted identity information with the metadata in the obtained storage record to perform trace analysis on the circulation process of the target file.

9. A computer device, comprising: The computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the steps of the cross-domain transmission security supervision method according to any one of claims 1 to 7. The computer readable storage medium stores a computer program, and the computer program is executed by the processor to perform the steps of the cross-domain transmission security supervision method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, ​

Images