Cross-domain video and iot data secure exchange method, system, device and medium

Abstract

This invention provides a method, system, device, and medium for secure cross-domain video and IoT data exchange, relating to the field of data processing technology. The method includes: acquiring a cross-domain exchange request containing an exchange policy; generating a security tag containing data usage constraints based on the request; generating a data key based on the tag; encrypting target data to obtain data ciphertext; encrypting a policy payload containing the security tag and data key using the authorized consumer domain's public key to obtain a policy ciphertext block; and using the data ciphertext hash value as a binding proof, encapsulating the three components to generate a policy binding ciphertext packet and sending it. The authorized consumer domain can only decrypt and use the data after verifying the constraints and binding proof. This invention avoids data overuse through tag constraints, mitigates the risks of theft and key leakage through layered encryption, and ensures tag-data consistency through binding proof, significantly improving the security of cross-domain data exchange.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to a method, system, device, and medium for secure cross-domain video and Internet of Things (IoT) data exchange. Background Technology

[0002] Currently, with the deep integration of IoT technology and video surveillance systems, cross-domain data exchange scenarios are becoming increasingly widespread. For example, the demand for sharing video and IoT data is constantly increasing in fields such as healthcare, security, and industrial control. However, in cross-domain environments, the data sources are complex, the permission boundaries are blurred, and security risks are constantly emerging during data transmission and use, significantly impacting the efficient flow of data.

[0003] Existing cross-domain data exchange methods largely rely on traditional encryption techniques and access control policies, but they have significant drawbacks. The separation of keys from data usage constraints is particularly prominent. In traditional schemes, keys only handle data encryption and decryption, and are stored and transmitted independently of constraints such as data usage scope, timeliness, and purpose. There is a lack of a strong correlation between the two. When keys are leaked, attackers can bypass usage constraints and directly decrypt data, leading to unauthorized data tampering and making it difficult to trace data misuse, posing a significant security risk to cross-domain data exchange. Summary of the Invention

[0004] In view of the shortcomings of the prior art, the present invention provides a method, system, device and medium for secure cross-domain video and Internet of Things data exchange.

[0005] Firstly, the method includes, Obtain a cross-domain exchange request; wherein the cross-domain exchange request contains an exchange strategy for the target data; A security label is generated based on the exchange policy; wherein the security label contains constraints on the use of the target data; A data key is generated based on the security tag, and the target data is encrypted using the data key to obtain the ciphertext. The policy payload is constructed based on the security label and data key, and the policy payload is encrypted using the public key of the authorized consumption domain to obtain the policy ciphertext block; Based on the hash value of the data ciphertext as the binding proof, the policy ciphertext block, data ciphertext, and binding proof are encapsulated to generate a policy binding ciphertext package; The policy binding ciphertext is sent to the authorized consumer domain, which then decrypts the policy ciphertext block using its private key to obtain the security label and data key. After verifying the usage constraints and binding proof in the security label, the data key is used to decrypt the data ciphertext, thus completing the data exchange.

[0006] Furthermore, the generation of security labels based on the exchange policy specifically includes: Parse the cross-domain exchange request to determine the authorized object and exchange context associated with the target data exchange; The usage constraint rules for the target data are determined based on the authorized object and the exchange context; The identifier of the authorized object, the usage constraint rules, and the exchange unique identifier are encapsulated in a predetermined structured format to generate a security label.

[0007] Furthermore, the obtained encrypted data specifically includes: Generate a data key uniquely associated with the security tag; Obtain the type characteristics of the target data; The target data is preprocessed according to the type characteristics to obtain standardized data units; The standardized data unit is encrypted using the data key to generate ciphertext.

[0008] Furthermore, the acquisition strategy ciphertext block specifically includes: The security label and the data key are associated and combined to form the initial policy payload; The initial strategy payload is serialized and encoded to obtain a payload data stream; Using the public key of the authorized consumer domain, the payload data stream is subjected to asymmetric encryption to generate the policy ciphertext block.

[0009] Furthermore, the policy ciphertext block, data ciphertext, and binding proof are encapsulated to generate a policy binding ciphertext package, specifically including: Calculate the hash value of the encrypted data; The hash value is encapsulated into binding verification information; The policy ciphertext block, the data ciphertext, and the binding verification information are assembled according to a preset data structure to generate the policy binding ciphertext package.

[0010] Furthermore, the generation of the policy binding ciphertext package specifically includes: A structured data packet frame is created according to a preset data exchange protocol. The data packet frame includes at least a header field, a payload field, and a signature field. The policy ciphertext block and the data ciphertext are input into the payload field of the packet frame; The binding verification information is input into the verification field specified in the header field of the data packet frame and associated with the identifier of the encrypted data. A digital signature is generated based on the contents of the header and payload fields in the data packet framework; The digital signature is written into the signature field of the data packet frame to form the policy-bound ciphertext packet.

[0011] Furthermore, the step of sending the policy-bound ciphertext packet to the authorized consumer domain, enabling the authorized consumer domain to decrypt the policy ciphertext block using its private key to obtain the security label and data key, specifically includes: The policy binding ciphertext package is sent to the authorized consumer domain, so that the authorized consumer domain can use the private key corresponding to the public key to decrypt the policy ciphertext block to obtain the security label and the data key; Verify whether the current access context meets the requirements based on the usage constraints in the security label; wherein... If so, verify whether the hash value in the policy-bound ciphertext is consistent with the hash value recalculated from the data ciphertext; If so, the ciphertext is decrypted using the data key to obtain the target data.

[0012] Secondly, for running the method described above, the system includes: The acquisition unit is used to acquire cross-domain exchange requests, wherein the cross-domain exchange requests contain the exchange strategy of the target data; The first generation unit is configured to generate a security label according to the exchange strategy, wherein the security label contains usage constraints on the target data; The second generation unit is used to generate a data key based on the security tag, and use the data key to encrypt the target data to obtain ciphertext. The construction unit constructs a policy payload based on the security label and the data key, and encrypts the policy payload using the public key of the authorized consumption domain to obtain a policy ciphertext block; The encapsulation unit is used to encapsulate the policy ciphertext block, the data ciphertext, and the binding proof using the hash value of the data ciphertext as a binding proof to generate a policy binding ciphertext package; The sending unit is configured to send the policy binding ciphertext package to the authorized consumption domain, so that the authorized consumption domain can decrypt the policy ciphertext block based on its private key to obtain the security label and the data key; The decryption unit is used to decrypt the ciphertext of the data using the data key after verifying the use constraints in the security tag and the binding proof has passed, so as to complete the data exchange.

[0013] Thirdly, a computer-readable storage medium storing a computer program that, when executed by a processor, implements any of the steps of the cross-domain video and Internet of Things data secure exchange method described above.

[0014] Fourthly, an electronic device includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other via the communication bus. Memory, used to store computer programs; When a processor executes a program stored in memory, it implements any of the steps of the cross-domain video and IoT data secure exchange method described above.

[0015] Compared with the prior art, the present invention has the following advantages: 1. In the method of this invention, the security tag embeds usage constraints of the target data, and the tag is bound to the data key and ciphertext. Authorized consumer domains must first decrypt to obtain the security tag; only after meeting the tag's constraints and passing verification can the data be decrypted and used. Therefore, this method can fundamentally prevent data from being used beyond its scope and permissions in cross-domain scenarios.

[0016] 2. This invention employs a layered encryption architecture. First, it encrypts the target data using a data key to generate ciphertext. Second, it encrypts the policy payload containing the security tag and data key using the public key of the authorized consumer domain. Only the authorized domain holding the corresponding private key can decrypt and obtain the corresponding information, preventing the key and tag from being stolen or tampered with during transmission. This dual encryption can simultaneously resist data theft attacks and key leakage risks, improving the security of cross-domain data exchange.

[0017] 3. In this invention, the hash value of the encrypted data is used as the binding proof, and the policy encrypted block, encrypted data, and binding proof are encapsulated into a policy binding encrypted package. Before decryption, the authorized consumer domain can verify the binding proof to confirm that the encrypted data has not been tampered with and that the policy encrypted block and the encrypted data have a one-to-one correspondence. This effectively ensures the consistency between the tag constraints and the data itself.

[0018] Other features and advantages of the invention will be set forth in the description which follows, and will be apparent in part from the description, or may be learned by practicing the invention. The objects and other advantages of the invention may be realized and obtained by means of the structures pointed out in the description, claims and drawings. Attached Figure Description

[0019] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1This is a schematic diagram of an embodiment of the cross-domain video and IoT data security exchange method based on tag ciphertext binding of the present invention; Figure 2 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 3 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 4 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 5 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 6 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 7 This is a schematic diagram of another embodiment of the cross-domain video and IoT data secure exchange method based on tag ciphertext binding of the present invention; Figure 8 This is a schematic diagram of an embodiment of the cross-domain video and IoT data security exchange device based on tag ciphertext binding of the present invention; Figure 9 This is a schematic diagram of another embodiment of the cross-domain video and IoT data security exchange device based on tag-encrypted binding of the present invention. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0022] like Figure 1 As shown, this invention proposes a method for secure cross-domain video and IoT data exchange based on tag-encrypted binding, the steps of which include: 101. Obtain the cross-domain exchange request, which contains the exchange strategy for the target data; 102. Generate security labels based on the exchange policy. The security labels contain the usage constraints on the target data. 103. Generate a data key based on the security tag, and use the data key to encrypt the target data to obtain the ciphertext; 104. Construct a policy payload based on security tags and data keys, and encrypt the policy payload using the public key of the authorized consumption domain to obtain the policy ciphertext block; 105. Using the hash value of the data ciphertext as the binding proof, encapsulate the policy ciphertext block, data ciphertext, and binding proof to generate a policy binding ciphertext package; 106. Send the policy binding ciphertext package to the authorized consumer domain so that the authorized consumer domain can decrypt the policy ciphertext block based on the private key to obtain the security label and data key. After verifying the usage constraints and binding proof in the security label, use the data key to decrypt the data ciphertext to complete the data exchange.

[0023] In this embodiment, a cross-domain exchange request is first obtained, containing an exchange policy for the target data. Next, a security label is generated based on the exchange policy, containing usage constraints on the target data. Then, a data key is generated based on the security label, and the target data is encrypted using the data key to obtain ciphertext. A policy payload is constructed based on the security label and data key, and encrypted using the public key of the authorized consumer domain to obtain a policy ciphertext block. Then, using the hash value of the ciphertext as a binding proof, the policy ciphertext block, the data ciphertext, and the binding proof are encapsulated to generate a policy binding ciphertext package. This policy binding ciphertext package is then sent to the authorized consumer domain, allowing the authorized consumer domain to decrypt the policy ciphertext block using its private key to obtain the security label and data key. After verifying the usage constraints and binding proof in the security label, the data ciphertext is decrypted using the data key to complete the data exchange. In step 101, a cross-domain exchange request is first obtained, which includes the exchange policy for the target data. This cross-domain exchange request is initiated by the data consumer (i.e., the terminal device, server, or application system corresponding to the authorized consumer domain) to the data provider. The initiation method can be implemented through a pre-defined cross-domain data exchange interface. Interface communication follows an encrypted transmission protocol, such as TLS 1.3, to prevent the request from being tampered with or stolen. The target data can be real-time collected monitoring video, environmental sensor data, device status data, etc., from IoT terminals. The exchange policy is a core parameter pre-negotiated between the data provider and consumer or determined according to system security rules. The exchange policy includes the validity period of the data exchange, authorized usage scenarios, data processing methods, consumer identity identifiers, and permission levels. After receiving the request, the data provider will first perform a preliminary verification of the request initiator's identity. After confirming that it is a registered and legitimate domain entity, the provider will extract and parse the exchange policy from the request, providing basic data for subsequent steps.

[0024] In step 102, after obtaining the exchange policy, a security label is generated based on the exchange policy. The security label contains usage constraints on the target data. As a carrier of data security management, the security label is generated using a structured data format. Its generation process maps various parameters in the exchange policy to ensure that the constraints are consistent with the exchange requirements. Specifically, the usage constraints include at least the data usage validity period, authorized operation permissions, data flow restrictions, integrity verification requirements, and violation handling mechanisms. To ensure the uniqueness and traceability of the security label, information such as the data provider identifier and the unique identifier of the target data are embedded during the generation process. Furthermore, the security label itself undergoes a hash operation to generate a digest for subsequent consistency verification.

[0025] In step 103, after generating the security tag, a data key is generated based on the security tag, and the target data is encrypted using the data key to obtain the ciphertext. The data key is generated using a symmetric encryption algorithm, such as AES-256-GCM. Its generation process is deeply correlated with the security tag. Specifically, it can be achieved by performing a hash operation on the structured data of the security tag, using the resulting hash value as the key seed, and combining it with a random number generator to generate a high-strength data key. This ensures that the data key corresponds one-to-one with the security tag, avoiding security control failures caused by the key and tag becoming disconnected.

[0026] After generating the data key, the target data is encrypted. For large-sized data such as video data, segmented encryption can be used to improve processing efficiency. Data block numbers and timestamps are added during encryption to facilitate complete reassembly after decryption. For small-sized, high-frequency collected data such as IoT sensor data, the entire dataset can be encrypted directly. Encryption algorithm parameters are recorded synchronously during encryption and stored in association with the encrypted data. Through these operations, the target data is transformed into unreadable encrypted data, effectively preventing unauthorized theft and tampering during cross-domain transmission. The binding relationship between the data key and the security tag is also established.

[0027] In step 103, a policy payload is constructed based on the security tag and data key, and then encrypted using the public key of the authorized consumer domain to obtain the policy ciphertext block. Specifically, the policy payload is a data packet combining the security tag and data key. To ensure the structured and parseable nature of the data packet, the security tag and data key are first encapsulated, and a payload generation timestamp and data provider signature are added to verify the payload's legitimacy and timeliness. The public key of the authorized consumer domain must be obtained from a pre-defined cross-domain trust key management center. This key management center is jointly recognized and maintained by all participating domains and is used to store the public key certificates of each domain. After obtaining the public key, the data provider first verifies the validity of the public key certificate. If it is correct, it encrypts the policy payload using an asymmetric encryption algorithm. Since asymmetric encryption algorithms have low processing efficiency, and the policy payload is small, this encryption method can ensure encryption strength while avoiding impacting overall processing efficiency. The encrypted policy ciphertext block can only be decrypted by the corresponding private key of the authorized consumer domain, ensuring that the security tag and data key are only obtained by legitimate consumers and preventing the leakage of core control information.

[0028] In step 105, the hash value of the encrypted data is used as the binding proof to encapsulate the policy ciphertext block, the encrypted data, and the binding proof into a policy binding ciphertext package. The binding proof is generated by performing a cryptographic hash algorithm on the complete encrypted data. Its purpose is to establish a strong binding relationship between the policy ciphertext block and the encrypted data, ensuring that neither is tampered with or replaced during transmission. If the encrypted data is illegally modified, its hash value will change, and the consumer can detect the data anomaly by verifying the binding proof.

[0029] During the encapsulation process, a unified encrypted packet format is used, and the policy encrypted block, data encrypted block and binding proof are stored sequentially. At the same time, the encrypted packet identifier, data provider information, authorized consumer domain identifier, packet generation timestamp and data type identifier are added to the packet header to facilitate the consumer to quickly parse and classify the data after receiving it.

[0030] In step 106, the policy binding ciphertext packet is finally sent to the authorized consumer domain, so that the authorized consumer domain can decrypt the policy ciphertext block based on the private key to obtain the security label and data key. After verifying the use constraints and binding proof in the security label, the data key is used to decrypt the data ciphertext to complete the data exchange.

[0031] In this process, the data provider sends the policy-bound encrypted packet to the authorized consumer domain via a cross-domain data transmission channel. Redundant transmission mechanisms are employed during transmission to ensure the complete delivery of the encrypted packet. If packet loss or errors occur during transmission, the consumer can request a retransmission from the provider. Upon receiving the encrypted packet, the authorized consumer domain first parses the packet header information to confirm that the data source matches its own identifier. Then, it extracts the policy encrypted block and decrypts it using its private key to obtain the security label and data key. Subsequently, the consumer verifies the security label, checking its integrity and timeliness, and verifying that the usage constraints within the security label align with its own usage requirements and permissions. Simultaneously, the consumer re-hashes the encrypted data and compares the result with the binding proof in the encrypted packet to verify that the encrypted data has not been tampered with during transmission. Once both verifications pass, the consumer uses the decrypted data key to decrypt the encrypted data, restoring it to the target data, and then uses the data according to the security label constraints, completing the entire cross-domain data security exchange process. If any verification fails during the process, the consumer will refuse to decrypt the data, record the abnormal information, and report it to the data provider and key management center to ensure data security.

[0032] like Figure 2 As shown, according to some embodiments of the present invention, in step 102, a security label is generated according to the exchange policy. The security label contains usage constraints on the target data, which may include, but are not limited to, the following: 201. Parse cross-domain exchange requests to determine the authorized objects and exchange context associated with the target data exchange; 202. Determine the usage constraints of the target data based on the authorized object and the exchange context; 203. Encapsulate the identifier of the authorized object, usage constraint rules, and exchange unique identifier according to a predetermined structured format to generate a security label.

[0033] In this embodiment of the invention, the cross-domain exchange request is first parsed to determine the authorized object and exchange context associated with the target data exchange. Specifically, the request parsing module of the data providing domain performs deep parsing on the cross-domain exchange request that has passed the initial identity verification, extracting the authorized object identifier and exchange context information hidden in the request. The authorized object is a cross-domain data consumer entity that has been pre-registered and authorized by the data providing domain, and can be specifically divided into types such as individual users, enterprise business systems, and IoT edge nodes. During the parsing process, the unique identity identifier of the authorized object is confirmed by associating it with the authorized list stored on the blockchain. This includes identifiers such as the enterprise's unified social credit code, the device's unique hardware number, and the user's digital identity certificate serial number. At the same time, it verifies whether the authorized object has the basic permissions for this target data exchange, eliminating the risk of unauthorized access by unauthorized objects.

[0034] The exchange context refers to the environment and scenario information related to this data exchange. Specifically, it includes the target data collection scenario, such as IoT monitoring in industrial workshops, video collection for urban security, network environment identifiers for data transmission, triggering scenarios for data exchange, terminal device information used for data, and time windows for data exchange. After parsing, the authorized object identifier will be associated with the exchange context information and stored, and a temporary parsing log will be generated.

[0035] Based on the parsed authorized objects and exchange context, usage constraints on the target data are determined. These usage constraints are the core of the security label and must precisely correspond to the authorized object's permission level, the scenario characteristics of the exchange context, and the exchange strategy to ensure the rules' relevance and feasibility. Specifically, the rule generation module of the data providing domain first retrieves the authorized object's permission profile and determines the basic constraint range based on the authorized object's type. For example, for authorized objects belonging to enterprise business systems, they are allowed to perform batch analysis of IoT data but are prohibited from secondary forwarding; for authorized objects belonging to individual users, they are only allowed to view video data within a specified time period and are prohibited from taking screenshots. Simultaneously, the basic constraint range is refined and adjusted based on the exchange context. If the exchange context is real-time industrial IoT data transmission, constraints on data transmission latency and data processing location are added. If the exchange context is offline video data sharing, constraints on data retention duration and data usage purpose are added.

[0036] After determining the authorized objects and corresponding usage constraints, the identifiers of the authorized objects, usage constraints, and exchange unique identifiers are encapsulated in a predetermined structured format to generate security labels. The exchange unique identifier is a unique string generated by the identifier generation module of the data providing domain based on the UUID algorithm. It is used to identify this cross-domain data exchange process. This identifier corresponds one-to-one with the cross-domain exchange request and is simultaneously synchronized to the data providing domain's exchange log and blockchain evidence storage system, facilitating traceability and auditing of the entire subsequent data exchange process.

[0037] It should be noted that the pre-defined structured format adopts the scalable and machine-readable JSON format, ensuring that the security label can be quickly recognized and parsed by the parsing module of the authorized consumer domain, while avoiding rule verification failures caused by format confusion. During the encapsulation process, the contents are organized according to the preset field order, specifically including the "Authorized Object Identifier" field, which stores the unique identifier and type information of the parsed authorized object; the "Usage Constraint Rules" field, which converts the various constraint rules determined in step 202 into structured data, with each constraint rule corresponding to an independent sub-field, such as "Purpose Constraint," "Time Constraint," and "Operation Constraint," clarifying the specific content and verification standards of each constraint; the "Exchange Unique Identifier" field, which stores the generated unique exchange identifier; in addition, "Label Generation Timestamp" and "Data Provider Domain Signature" fields are added, where the label generation timestamp is used to determine the effective start time of the security label, and the data provider domain signature is used to digitally sign the label content using the private key of the data provider domain, used to verify the authenticity and integrity of the security label and prevent the label from being tampered with. After encapsulation, the generated security label will be verified for integrity. The hash value of the label content will be calculated using a hash algorithm, and if it matches the signature information in the label, it is a qualified security label.

[0038] like Figure 3 As shown, according to some embodiments of the present invention, in step 103, a data key is generated based on the security tag, and the target data is encrypted using the data key to obtain ciphertext. Specifically, this may include, but is not limited to, the following: 301. Generate a data key that is uniquely associated with the security tag; 302. Obtain the type characteristics of the target data; 303. Preprocess the target data according to its type characteristics to obtain standardized data units; 304. Encrypt the standardized data units according to the data key to generate ciphertext.

[0039] In this embodiment of the invention, after the security tag generation operation is completed, a data key uniquely associated with the security tag is generated. Specifically, this invention uses a key derivation function based on tag content to generate the key. The complete structured data of the security tag, including all fields such as usage constraints, data element information, and digital watermark, is used as the core input factor. A high-strength random number generator generates a random seed, and the HMAC-SHA256 algorithm is used for multiple rounds of iterative computation to ensure that the generated 128-bit symmetric data key and the security tag form a unique one-to-one association. That is, each security tag with different content will generate a unique data key, and there is no situation where different tags correspond to the same key, effectively avoiding the risk of batch data leakage caused by key reuse. The generated data key is temporarily stored in an encrypted key buffer, and the buffer is equipped with an automatic destruction mechanism. The key is immediately cleared after subsequent encryption operations are completed to prevent security risks caused by key retention locally.

[0040] Next, the type characteristics of the target data are obtained. The target data encompasses two main categories: video data and IoT data in cross-domain exchange scenarios. The type characteristics of video data include video encoding format (e.g., H.264, H.265, MP4), resolution parameters (e.g., 1080P, 4K), frame rate, and data storage structure (e.g., the distribution of I-frames, P-frames, and B-frames). The type characteristics of IoT data include data acquisition type (e.g., temperature, humidity, air pressure, equipment operating parameters), data temporal characteristics (e.g., acquisition frequency, timestamp interval), and data structure type (e.g., structured numerical data, semi-structured JSON data). Specifically, the target data is scanned and parsed using a data feature recognition module to extract the aforementioned type characteristic information and organize it into standardized feature description fields.

[0041] After obtaining the type characteristics of the target data, the target data is preprocessed according to the type characteristics to obtain standardized data units. Different preprocessing strategies are adopted for target data with different type characteristics. For video data, if its encoding format is non-standard, it is first converted into a unified H.265 encoding format. At the same time, according to the desensitization constraints in the security label, sensitive information in the video frame, such as faces, device numbers, scene identifiers, etc., is blurred in real time. Then, according to the preset segment size, the complete video stream is cut into video slices of fixed duration, and each slice is used as an independent basic data unit.

[0042] For IoT data, if it is unstructured sensor data, it is first converted into structured data in key-value pair form. If it is time-series data, it is segmented and integrated according to the collection timestamp. At the same time, invalid and abnormal data, such as values ​​that exceed the reasonable range or data with missing timestamps, are filtered out. Then, the processed video slices and IoT data segments are uniformly packaged into standardized data units of the same size. Each data unit contains metadata such as data type identifier, unit sequence number, and length information, which facilitates subsequent batch encryption processing and ensures the efficiency and consistency of encryption operations.

[0043] After acquiring the standardized data units, they are encrypted using the data key to generate ciphertext. This invention employs the AES-256 symmetric encryption algorithm, calling the data key uniquely associated with the security tag generated in step 301 to independently encrypt each standardized data unit. During encryption, an initialization vector is randomly generated for each data unit. This initialization vector is stored along with the encrypted ciphertext for decryption, avoiding ciphertext duplication caused by using the same key for the same plaintext, thus improving the ciphertext's resistance to cracking. For standardized data units segmented from video streams, encryption is performed sequentially according to the unit number, ensuring that the encrypted video ciphertext slices can be reassembled in the original order. For standardized data units of IoT data, encryption is performed according to timestamp order, and a corresponding feature identifier is added to the header of each data unit's ciphertext. After encryption, all encrypted standardized data unit ciphertexts are integrated to form the final complete ciphertext.

[0044] like Figure 4 As shown, according to some embodiments of the present invention, in step 104, a policy payload is constructed based on a security tag and a data key, and the policy payload is encrypted using the public key of the authorized consumption domain to obtain a policy ciphertext block. Specifically, this may include, but is not limited to, the following: 401. Associate and combine the security tag with the data key to form the initial policy payload; 402. Serialize and encode the initial strategy payload to obtain the payload data stream; 403. Using the public key of the authorized consumer domain, perform asymmetric encryption operations on the payload data stream to generate policy ciphertext blocks.

[0045] In this embodiment of the invention, a security label and a data key are associated and combined to form an initial policy payload. Specifically, after the security label is generated and the data key is derived, the system binds the structured security label to the binary format data key. During the association process, a type identifier field is added to both the security label and the data key. The identifier field of the security label indicates that its data format is JSON structured data, and the x identifier field of the data key indicates that it is a 128-bit AES symmetric key. A verification bit is set between the two, which is generated by XORing the digest value of the security label with the lower 16 bits of the data key. This verification bit is used to verify whether the two have been separated or tampered with during subsequent combination. This association method ensures a one-to-one correspondence between the security label and the data key in the initial policy payload, avoiding key-label mismatches. This ensures that after decryption in the authorized consumer domain, the correct security label can be used to constrain the use of the data key. The combined initial policy payload includes three parts: the complete security label data, the binary stream of the data key, and the verification bit, forming a logically related overall data unit.

[0046] Next, the generated initial policy payload is serialized and encoded to obtain the payload data stream. Specifically, since the initial policy payload contains data content in different formats, direct encryption would result in data structure chaos and low encryption efficiency. Therefore, it is necessary to convert it into a unified binary data stream through serialization and encoding. This invention uses the Protocol Buffers serialization protocol for encoding, which enables compact data storage and efficient transmission. During the encoding process, the serialization structure of the payload is first defined, mapping each field of the security label to the corresponding protocol field, mapping the binary stream of the data key to a byte field, and mapping the associated check bit to an integer field. Then, the initial policy payload is encoded field by field according to this structure, removing redundant format characters. At the same time, field length identifiers and version numbers are added to the encoded data stream to facilitate deserialization and parsing by the authorized consumer domain. After serialization and encoding, the resulting payload data stream is a continuous binary byte sequence. Compared with the original initial policy payload, its data volume is smaller and has a unified format standard, which can adapt to the input requirements of asymmetric encryption.

[0047] Subsequently, based on the generated payload data stream, the public key of the authorized consumption domain is used to perform asymmetric encryption on the payload data stream to generate policy ciphertext blocks. Specifically, in actual operation, the system first retrieves the public key of the corresponding authorized consumption domain from the preset authorized public key library. This public key is an asymmetric key generated based on the RSA-2048 algorithm. After obtaining the public key, the encryption module uses the RSA asymmetric encryption algorithm to encrypt the payload data stream. During the encryption process, the payload data stream is divided into blocks according to the block length of the RSA algorithm, and each data block is encrypted sequentially. At the same time, a random padding factor is added during the encryption process to improve the ciphertext's resistance to cracking. Since the computational efficiency of asymmetric encryption algorithms is relatively low, and the payload data stream is small in size after serialization encoding, asymmetric encryption of the payload data stream is chosen to ensure data security without affecting the efficiency of the overall exchange process.

[0048] After encryption is complete, all encrypted data blocks are integrated and ciphertext block header information is added. This header information includes the encryption algorithm identifier, the number of data blocks, and the timestamp of ciphertext block generation, ultimately forming a complete policy ciphertext block. This ciphertext block can only be decrypted by the private key of the corresponding authorized consumer domain, thereby ensuring that the security label and data key can only be obtained by the authorized party.

[0049] like Figure 5 As shown, according to some embodiments of the present invention, in step 105, the hash value of the data ciphertext is used as the binding proof to encapsulate the policy ciphertext block, the data ciphertext, and the binding proof to generate a policy binding ciphertext package. Specifically, this may include, but is not limited to, the following: 501. Calculate the hash value of the encrypted data; 502. Encapsulate the hash value into binding verification information; 503. Assemble the policy ciphertext block, data ciphertext, and binding verification information according to the preset data structure to generate a policy binding ciphertext package.

[0050] In this embodiment of the invention, the hash value of the encrypted data is first calculated. Specifically, after obtaining the complete encrypted data using the data key, the SHA-3-256 hash algorithm is used to perform a full hash calculation on the encrypted data. During the calculation, the encrypted data is divided into several data blocks of fixed byte length, and each data block is iteratively hashed sequentially. An initial hash value and a padding factor are introduced to ensure that encrypted data of different lengths and contents can generate a unique and irreversible hash value. It should be noted that the hash calculation object here is the complete encrypted data generated in step 103, including all content such as the frame structure identifier of the video encrypted data, the time slice identifier of the IoT encrypted data, and the initialization vector added during encryption, rather than a partial fragment of the encrypted data. This ensures that the hash value can fully represent the integrity of the encrypted data. After the calculation is completed, a 256-bit binary hash value is generated, which will serve as the basis for subsequent verification of whether the encrypted data has been tampered with.

[0051] Next, the hash value is encapsulated into binding verification information. Specifically, the obtained 256-bit binary hash value is converted into a hexadecimal string format for storage and transmission. Then, the data structure for the binding verification information is constructed. In addition to the hexadecimal hash value, this information includes a hash algorithm identifier field and a timestamp field. The hash algorithm identifier field records the algorithm type used to generate the hash value; here, it is set to SHA-3-256, allowing the authorized consumer domain to use the corresponding hash algorithm for comparison during verification. The timestamp field records the generation time of the hash value to prevent replay attacks. After filling in all fields, the binding verification information is encapsulated according to a preset TLV format. The type field identifies this information as binding verification information, the length field indicates the total number of bytes in the binding verification information, and the value field contains a combination of the hash algorithm identifier, timestamp, and hexadecimal hash value. After encapsulation, a uniformly structured and formatted binding verification information is generated. This information serves as the binding link between the policy ciphertext block and the data ciphertext, ensuring a one-to-one correspondence between the two.

[0052] The policy ciphertext block, data ciphertext, and binding verification information are then assembled according to a preset data structure to generate a policy binding ciphertext packet. Specifically, the data structure of the policy binding ciphertext packet is preset, which consists of a packet header, a policy ciphertext block storage area, a data ciphertext storage area, a binding verification information storage area, and a packet trailer. The packet header contains the ciphertext packet version number, total length, the identity identifier of the target authorized consumer domain, and the data type identifier. The version number is used to ensure compatibility with different versions of ciphertext packet parsing rules, and the total length is used to verify whether there is data loss during the transmission of the ciphertext packet. The target authorized consumer domain's identity identifier is used to accurately locate the recipient of the encrypted packet, while the data type identifier distinguishes whether the data in the encrypted packet is video data or IoT data. The policy encrypted block storage area is used to store the complete policy encrypted block generated in step 104, and an encrypted block length field is added to facilitate quick location of the policy encrypted block boundary during parsing. The data encrypted storage area is used to store all data encrypted data generated in step 103. For video data encrypted data, auxiliary parsing fields such as frame count and frame interval are added to the header of the storage area. For IoT data encrypted data, fields such as data acquisition device number and data point count are added.

[0053] The binding verification information storage area stores the binding verification information encapsulated in step 502, and adds an information length field. The packet tail contains the CRC32 checksum of the entire encrypted packet, used to verify whether data tampering has occurred during the assembly and transmission of the encrypted packet. During assembly, the packet header, policy ciphertext block, data ciphertext, binding verification information, and packet tail are sequentially concatenated according to the above preset structure. After concatenation, the concatenated content is converted into a continuous binary data stream using a binary stream conversion tool, ultimately generating a policy binding ciphertext packet. This ciphertext packet has a clear structure and a robust verification mechanism, ensuring security and integrity during cross-domain transmission.

[0054] like Figure 6 As shown, according to some embodiments of the present invention, in step 106, the policy binding ciphertext packet is sent to the authorized consumer domain, so that the authorized consumer domain can decrypt the policy ciphertext block based on its private key to obtain the security label and data key. After verifying the use constraints and binding proof in the security label, the data key is used to decrypt the data ciphertext to complete the data exchange. Specifically, this may include, but is not limited to, the following: 601. Send the policy binding ciphertext package to the authorized consumer domain so that the authorized consumer domain can use the private key corresponding to the public key to decrypt the policy ciphertext block to obtain the security tag and data key; 602. Verify that the current access context meets the requirements based on the usage constraints in the security label; 603. If yes, then verify whether the hash value in the encrypted packet bound by the verification strategy is consistent with the hash value recalculated from the encrypted data. 604. If so, decrypt the ciphertext using the data key to obtain the target data.

[0055] In this embodiment of the invention, after the policy binding ciphertext packet is encapsulated, it is sent to the authorized consumer domain. The authorized consumer domain then uses the private key corresponding to the public key to decrypt the policy ciphertext block and obtain the security tag and data key. Specifically, the data provider domain sends the encapsulated policy binding ciphertext packet as a binary stream to a designated receiving node of the authorized consumer domain based on a preset cross-domain communication protocol, such as a lightweight IoT communication protocol based on MQTT-SN or an RTSP-TLS protocol suitable for video data transmission. This receiving node is pre-configured with a communication link authentication mechanism with the data provider domain, enabling it to verify the legitimacy of the link before receiving data packets, thus preventing data packets from being illegally intercepted or tampered with.

[0056] Upon receiving the policy binding ciphertext packet, the authorized consumer domain first extracts the ciphertext block identifier information from the packet header to locate the storage location of the policy ciphertext block. Then, it calls the private key stored in the local key management module. This private key and the public key used by the data providing domain to encrypt the policy payload in step 104 form an asymmetric key pair, paired through a key negotiation algorithm. The authorized consumer domain uses this private key to perform asymmetric decryption on the policy ciphertext block. Since the policy ciphertext block contains only lightweight data of security tags and data keys, the decryption operation can be completed quickly. After decryption, structured security tag data and a 128-bit symmetric data key can be extracted from the payload. Simultaneously, the extracted content undergoes format verification to confirm the integrity of the JSON structure of the security tag and that the byte length of the data key conforms to preset standards, preventing subsequent steps from failing due to decryption anomalies.

[0057] Based on the acquired security label, the current access context is verified to meet the requirements according to the usage constraints contained in the security label. Specifically, the access verification module for the authorized consumption domain first parses all usage constraints contained in the security label, including core constraints such as data usage purpose restrictions, time validity period, geographical scope, and operation permissions. Simultaneously, it collects the current access context information, which specifically includes the business system identifier that initiated the data access request, the current system time, the physical location information of the consumption domain, and the type of operation to be performed on the target data. Afterwards, the verification module matches and verifies the access context information against the constraints in the security label item by item. For example, if the security label specifies that the data can only be used for model training for industrial equipment fault diagnosis, and the validity period is from July 1, XXXX to July 31, XXXX, with the geographical scope limited to a smart manufacturing park in North China, the verification module will first confirm whether the system initiating the current access request is a pre-registered fault diagnosis model training system, then verify whether the current system time is within the validity period, and confirm whether the physical location of the consumer domain is within the authorized geographical area through the location module. Simultaneously, it will check whether the operation to be performed is a data reading and feature extraction operation related to model training, rather than a data forwarding or storage operation. If all constraints are matched successfully, the current access context is deemed compliant, and subsequent steps are initiated. If any constraint is not matched, such as exceeding the time validity period or the operation type not meeting the requirements, the data exchange process is immediately terminated, and an access exception log is generated and fed back to the data providing domain.

[0058] After successful verification, the system checks whether the hash value in the policy binding ciphertext packet matches the hash value recalculated from the data ciphertext. Specifically, the authorized consumer domain first extracts the binding proof from a designated location in the policy binding ciphertext packet, which is the original data ciphertext hash value generated by the data provider domain in step 105. This hash value is generated based on the SHA-3 algorithm and is irreversible and unique. Then, the complete data ciphertext is extracted from the ciphertext packet, and a new hash value is generated by performing a SHA-3 hash operation on the data ciphertext according to the exact same hash calculation rules as the data provider domain.

[0059] Next, the newly generated hash value is compared byte by byte with the extracted binding proof. If the two hash values ​​are completely identical, it means that the data ciphertext has not been tampered with during cross-domain transmission, and the binding relationship between the policy ciphertext block and the data ciphertext is genuine and valid. If the two hash values ​​are different, it is determined that the data ciphertext may have been illegally tampered with or the data packet was transmitted incorrectly. At this time, a security alarm mechanism will be triggered immediately, the current ciphertext packet will be discarded, and a data verification failure notification will be sent to the data providing domain, requesting the retransmission of the policy binding ciphertext packet.

[0060] After successful verification, the encrypted data is decrypted using the data key to obtain the target data. Specifically, the decryption module of the authorized consumer domain calls the AES-256 decryption algorithm corresponding to the data encryption algorithm in step 103, inputting the data key obtained in step 601 as the decryption key into the algorithm. Simultaneously, it extracts the initialization vector added during encryption to ensure a complete match between the decryption and encryption parameters. For video stream data in the encrypted packet, the decryption module decrypts frame by frame in the order of I-frames, P-frames, and B-frames to reconstruct a continuous video frame sequence. For IoT time-series data, it decrypts in blocks according to the time slices of data acquisition to recover complete sensor data. After decryption, the decryption module verifies the format of the obtained target data, confirming that the encoding format and resolution of the video data meet preset requirements, and that the field integrity and data accuracy of the IoT data are not abnormal. After verification, the target data is transmitted to the business system that initiated the access request for use within the constraints defined by the security label.

[0061] Meanwhile, the logging module of the authorized consumption domain will record the entire process of this data exchange, including the time of receiving the encrypted packet, the time of decrypting the private key, the result of the constraint verification, the result of the hash value comparison, and the time of data decryption completion. The log information will be synchronized to the blockchain storage node of the data providing domain, so as to realize the full-process traceability and auditability of cross-domain data exchange.

[0062] like Figure 7 As shown, according to some embodiments of the present invention, in step 503, the policy ciphertext block, data ciphertext, and binding verification information are assembled according to a preset data structure to generate a policy binding ciphertext package, which may include, but is not limited to, the following: 701. Create a structured data packet frame according to the preset data exchange protocol. The data packet frame shall include at least a header field, a payload field, and a signature field. 702. Input the policy ciphertext block and data ciphertext into the payload field of the packet frame; 703. Input the binding verification information into the header field of the data packet frame and associate it with the identifier of the encrypted data. 704. Generate a digital signature based on the content of the header and payload fields in the packet frame; 705. Write the digital signature into the signature field of the packet frame to form a policy-bound ciphertext packet.

[0063] In this embodiment of the invention, a structured data packet framework is first created according to a preset data exchange protocol. The data packet framework includes at least a header field, a payload field, and a signature field. It should be noted that the preset data exchange protocol is a dedicated protocol for cross-domain video and IoT data transmission. It is pre-negotiated and determined by the data provider domain and the authorized consumer domain and incorporated into their secure interaction specifications. This protocol clearly defines core parameters such as the byte length of the data packet, the position offset of each field, and the field encoding format, ensuring that both ends of the device can accurately parse the data packet content during cross-domain transmission. The created structured data packet framework adopts a hybrid structure combining fixed and variable lengths. The header field is designed with a fixed length to store the basic identifier and verification-related information of the data packet, avoiding parsing misalignment caused by variable length. The payload field is designed with a variable length, which can be dynamically expanded according to the actual size of the encrypted data, adapting to the encapsulation requirements of video data at different resolutions and IoT data with different acquisition frequencies. The signature field is designed with a fixed length to store a digital signature value of uniform length, ensuring the efficiency of signature verification.

[0064] Next, based on the created packet frame, the policy ciphertext block and data ciphertext are input into the payload field of the packet frame. Before input, both the policy ciphertext block and data ciphertext are first standardized, converted to binary byte stream format, eliminating format differences between different data types. Then, according to the preset storage rules of the payload field, they are written sequentially in the order of "policy ciphertext block first, data ciphertext last," with the starting position of the policy ciphertext block consistent with the starting offset of the payload field, and the data ciphertext stored immediately after the policy ciphertext block. A separator field is set between the policy ciphertext block and the data ciphertext to quickly distinguish the two data modules during subsequent parsing. After writing, the system automatically calculates the actual number of bytes occupied by the payload field and feeds this value back to the payload length statistics field in the header field, providing a length basis for the receiver's payload field parsing and avoiding data overflow or incomplete reading issues.

[0065] Next, the binding verification information is input into the specified verification field in the header field of the data packet frame and associated with the identifier of the encrypted data. It should be noted that the binding verification information is the binding proof generated in the previous steps, which is the hash value of the encrypted data. A dedicated verification field is pre-defined in the header field, and the length of this field matches the length of the hash value generated by the hash algorithm, ensuring that the binding verification information can be written completely. During the writing process, the system synchronously extracts the unique identifier information of the encrypted data. This identifier information is a globally unique number assigned when the encrypted data is generated, containing characteristic information such as the data acquisition device ID, data generation timestamp, and data type encoding. Through a field mapping mechanism, a one-to-one correspondence is established between the binding verification information in the header field's verification field and the identifier information of the encrypted data in the payload field.

[0066] After filling in the header and payload fields, a digital signature is generated based on the content of the header and payload fields in the data packet frame. Before generating the digital signature, the entire content of the header and payload fields is first integrated and concatenated into a continuous byte stream in the order of "complete header field content + complete payload field content," which serves as the original data for the signature. Then, the private key of the data provider field is called, and a preset asymmetric encryption algorithm is used to perform a signature operation on the concatenated original data. The encryption algorithm used here must be consistent with the signature verification algorithm agreed upon by both parties, such as the SM2 elliptic curve public key cryptography algorithm. This algorithm is suitable for resource-constrained IoT devices and can improve computational efficiency while ensuring signature security. During the signature operation, the original data is hashed to generate a data digest, which is then encrypted using the private key. The final encrypted digest is the digital signature, which can simultaneously verify the integrity of the data packet content and the legitimacy of the data provider field.

[0067] Finally, the digital signature is written to the signature field of the data packet frame to form the encrypted packet bound to the aforementioned policy. Before writing the digital signature, the signature field is first initialized by clearing the reserved placeholders within the field to ensure that there is no redundant data in the signature storage area. Then, the digital signature generated in step 704 is written completely according to the byte order specified in the signature field. After writing, the system performs a consistency check on the header field, payload field, and signature field of the entire data packet frame, checking whether the field length and data format of each field meet the requirements of the preset data exchange protocol.

[0068] For example, the system verifies whether the payload length statistics in the header field match the actual number of bytes occupied by the payload field, and whether the digital signature length in the signature field conforms to the algorithm standard. Once all verification items pass, the content of each field is organically integrated into a complete policy-bound ciphertext package. This ciphertext package possesses the characteristics of standardized structure, complete content, verifiability, and traceability, and can be directly used for cross-domain data transmission, ensuring that the authorized consumer domain can complete decryption and verification operations through the corresponding process after receiving the data.

[0069] like Figure 8 As shown, a second aspect of the present invention provides a cross-domain video and IoT data security exchange device based on tag-encrypted binding, the device comprising: The acquisition unit 801 is used to acquire cross-domain exchange requests, which contain the exchange strategy of the target data. The first generation unit 802 is used to generate a security label according to the exchange strategy. The security label contains usage constraints on the target data. The second generation unit 803 is used to generate a data key based on the security tag and use the data key to encrypt the target data to obtain the data ciphertext. Construction unit 804 constructs a policy payload based on a security tag and a data key, and encrypts the policy payload using the public key of the authorized consumption domain to obtain the policy ciphertext block; Encapsulation unit 805 is used to encapsulate the policy ciphertext block, the data ciphertext, and the binding proof using the hash value of the data ciphertext as the binding proof to generate a policy binding ciphertext package; The sending unit 806 is used to send the policy binding ciphertext packet to the authorized consumer domain, so that the authorized consumer domain can decrypt the policy ciphertext block based on the private key to obtain the security label and data key; The decryption unit 807 is used to decrypt the ciphertext of the data using the data key after the use constraints and binding proof in the verification security tag have passed, so as to complete the data exchange.

[0070] like Figure 9 As shown, the present invention also provides a cross-domain video and IoT data security exchange device based on tag-encrypted binding, the device comprising: Processor 901, memory 902, input / output unit 903, bus 904; The processor 901 is connected to the memory 902, the input / output unit 903, and the bus 904; The memory 902 stores a program, and the processor 901 calls the program to execute any of the methods described above.

[0071] The present invention also relates to a computer-readable storage medium having a program stored thereon, which, when run on a computer, causes the computer to perform any of the methods described above.

[0072] 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 be referred to the corresponding processes in the foregoing method embodiments, and will not be repeated here.

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

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

[0075] Furthermore, the functional units in the various embodiments of the present invention 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. The integrated unit can be implemented in hardware or as a software functional unit.

[0076] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, in essence, or the part that contributes to the prior art, or all or part 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 of the various embodiments of the present invention. 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.

[0077] The foregoing description and accompanying drawings fully illustrate embodiments of the invention to enable those skilled in the art to practice them. Other embodiments may include structural and other changes. The embodiments represent only possible variations. Individual components and functions are optional unless explicitly required, and the order of operation may vary. Some portions and features of some embodiments may be included or substituted for portions and features of other embodiments. Embodiments of the invention are not limited to the structures described above and shown in the accompanying drawings, and various modifications and changes may be made without departing from their scope. The scope of the invention is limited only by the appended claims.

Claims

1. A method for secure cross-domain video and Internet of Things (IoT) data exchange, characterized in that, The method includes: Obtain a cross-domain exchange request; wherein the cross-domain exchange request contains an exchange strategy for the target data; A security label is generated based on the exchange policy; wherein the security label contains constraints on the use of the target data; A data key is generated based on the security tag, and the target data is encrypted using the data key to obtain the ciphertext. The policy payload is constructed based on the security label and data key, and the policy payload is encrypted using the public key of the authorized consumption domain to obtain the policy ciphertext block; Based on the hash value of the data ciphertext as the binding proof, the policy ciphertext block, data ciphertext, and binding proof are encapsulated to generate a policy binding ciphertext package; The policy binding ciphertext is sent to the authorized consumer domain, which then decrypts the policy ciphertext block using its private key to obtain the security label and data key. After verifying the usage constraints and binding proof in the security label, the data key is used to decrypt the data ciphertext, thus completing the data exchange.

2. The method of claim 1, wherein, The generation of security labels according to the exchange policy specifically includes: Parse the cross-domain exchange request to determine the authorized object and exchange context associated with the target data exchange; The usage constraint rules for the target data are determined based on the authorized object and the exchange context; The identifier of the authorized object, the usage constraint rules, and the exchange unique identifier are encapsulated in a predetermined structured format to generate a security label.

3. The method of claim 1, wherein the method further comprises: The obtained encrypted data specifically includes: Generate a data key uniquely associated with the security tag; Obtain the type characteristics of the target data; The target data is preprocessed according to the type characteristics to obtain standardized data units; The standardized data unit is encrypted using the data key to generate ciphertext.

4. The method of claim 1, wherein, The obtained strategy ciphertext block specifically includes: The security label and the data key are associated and combined to form the initial policy payload; The initial strategy payload is serialized and encoded to obtain a payload data stream; Using the public key of the authorized consumer domain, the payload data stream is subjected to asymmetric encryption to generate the policy ciphertext block.

5. The method of claim 1, wherein, The policy ciphertext block, data ciphertext, and binding proof are encapsulated to generate a policy binding ciphertext package, specifically including: Calculate the hash value of the encrypted data; The hash value is encapsulated into binding verification information; The policy ciphertext block, the data ciphertext, and the binding verification information are assembled according to a preset data structure to generate the policy binding ciphertext package.

6. The method of claim 5, wherein, The generation of the policy-bound ciphertext package specifically includes: A structured data packet frame is created according to a preset data exchange protocol. The data packet frame includes at least a header field, a payload field, and a signature field. The policy ciphertext block and the data ciphertext are input into the payload field of the packet frame; The binding verification information is input into the verification field specified in the header field of the data packet frame and associated with the identifier of the encrypted data. A digital signature is generated based on the contents of the header and payload fields in the data packet framework; The digital signature is written into the signature field of the data packet frame to form the policy-bound ciphertext packet.

7. The method of claim 1, wherein the method further comprises: The step of sending the policy-bound ciphertext packet to the authorized consumer domain, enabling the authorized consumer domain to decrypt the policy ciphertext block using its private key to obtain the security label and data key, specifically includes: The policy binding ciphertext package is sent to the authorized consumer domain, so that the authorized consumer domain can use the private key corresponding to the public key to decrypt the policy ciphertext block to obtain the security label and the data key; Verify whether the current access context meets the requirements based on the usage constraints in the security label; wherein... If so, verify whether the hash value in the policy-bound ciphertext is consistent with the hash value recalculated from the data ciphertext; If so, the ciphertext is decrypted using the data key to obtain the target data.

8. A cross-domain video and IoT data secure exchange system, characterized in that, The system for performing the method according to claims 1-7 comprises: The acquisition unit is used to acquire cross-domain exchange requests, wherein the cross-domain exchange requests contain the exchange strategy of the target data; The first generation unit is configured to generate a security label according to the exchange strategy, wherein the security label contains usage constraints on the target data; The second generation unit is used to generate a data key based on the security tag, and use the data key to encrypt the target data to obtain ciphertext. The construction unit constructs a policy payload based on the security tag and the data key, and encrypts the policy payload using the public key of the authorized consumption domain to obtain a policy ciphertext block; The encapsulation unit is used to encapsulate the policy ciphertext block, the data ciphertext, and the binding proof using the hash value of the data ciphertext as a binding proof to generate a policy binding ciphertext package; The sending unit is configured to send the policy binding ciphertext package to the authorized consumption domain, so that the authorized consumption domain can decrypt the policy ciphertext block based on its private key to obtain the security label and the data key; The decryption unit is used to decrypt the ciphertext of the data using the data key after verifying the use constraints in the security tag and the binding proof has passed, so as to complete the data exchange.

9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which, when executed by a processor, implements the steps of the cross-domain video and Internet of Things data security exchange method according to any one of claims 1-7.

10. An electronic device, comprising: It includes a processor, a communication interface, a memory, and a communication bus, wherein the processor, the communication interface, and the memory communicate with each other through the communication bus; Memory, used to store computer programs; When a processor executes a program stored in memory, it implements the steps of the cross-domain video and Internet of Things data security exchange method according to any one of claims 1-7.

Images