Data security encryption method and device based on block chain

Abstract

The invention provides a data security encryption method and device based on a block chain, relates to the technical field of data security, and solves the technical problems that in the prior art, an encryption strategy is separated from data content, and security and efficiency are difficult to balance. The method comprises the following steps: identifying a modal type of to-be-encrypted original data through an artificial intelligence model, and extracting modal features of the original data; uploading the modal type and the modal feature to a block chain network, triggering a corresponding cross-modal encryption strategy according to a preset rule, converting the modal feature into conversion data of a target modal, and performing hash operation on the conversion data to generate a dynamic encryption key; encrypting the original data by using the dynamic encryption key to obtain a first ciphertext, and generating a second ciphertext based on an attribute-based encryption algorithm; and storing the first ciphertext and the second ciphertext into a distributed storage system, and recording the storage address hash and the second ciphertext into a distributed account book of the block chain network together.

Description

Technical Field

[0001] This invention belongs to the field of data security technology, specifically a data security encryption method and device based on blockchain. Background Technology

[0002] With the development of information technology, the data generated by various applications is growing explosively and its modalities are becoming increasingly complex and diverse, including images, text, audio, and video. This data often contains a large amount of sensitive information, such as personal privacy, medical records, or trade secrets, making its secure storage and transmission crucial.

[0003] However, traditional encryption methods rely on static encryption algorithms and key management strategies, making it difficult to adapt to the characteristics and security requirements of different modal data. They suffer from low efficiency and uneven security when processing heterogeneous data; furthermore, they lack intelligent data content perception capabilities and cannot dynamically adjust encryption strength based on modal characteristics, leading to unreasonable allocation of security resources, a problem that is even more pronounced in resource-constrained environments such as mobile edge computing. In addition, existing encryption schemes suffer from insufficient reliability and traceability. For example, traditional centralized key management and auditing mechanisms have single-point-of-failure risks, and operation logs are easily tampered with, making it difficult to meet the transparency and non-repudiation requirements of high-security applications. Although blockchain technology has been introduced due to its decentralized and immutable characteristics, current applications are mostly limited to simple evidence storage and are not deeply integrated with core encryption processes, resulting in low overall credibility and automation of the encryption process. Summary of the Invention

[0004] This application provides a data security encryption method and apparatus based on blockchain, which solves the technical problems of existing encryption strategies being disconnected from data content and the difficulty in balancing security and efficiency.

[0005] To achieve the above objectives, this application adopts the following technical solution: Firstly, a blockchain-based data security encryption method is provided, including: Obtain the original data to be encrypted, identify the modal type of the original data through an artificial intelligence model, and extract the modal features of the original data; The modality type and modality features are uploaded to the blockchain network, and a cross-modal encryption strategy corresponding to the modality type is matched and triggered according to the preset rules deployed on the blockchain network. According to the cross-modal encryption strategy, the original data or the modal features are converted into transformed data of the target modality, and the transformed data is subjected to cryptographic hashing to generate a dynamic encryption key; Using the dynamic encryption key, the original data is encrypted using an encryption algorithm to obtain the first ciphertext. Then, based on the attribute-based encryption algorithm, the dynamic encryption key is bound to the access policy containing the modality type for encryption to generate the second ciphertext. The first and second ciphertexts are stored in a distributed storage system, and the storage address hash is recorded together with the second ciphertext in the distributed ledger of the blockchain network to complete the encrypted evidence storage.

[0006] Based on the above technical solutions, this application provides a blockchain-based data security encryption method that integrates artificial intelligence, blockchain, and cryptography technologies to construct an adaptive, fine-grained, and traceable data security encryption system. First, this application automatically identifies data modality types and extracts features using an artificial intelligence model, achieving intelligent perception and classification of multimodal data and improving the adaptability and automation of the encryption system. Second, by storing modal information and executing smart contracts through a blockchain network, automatic matching and triggering of encryption strategies are achieved, reducing security risks from human intervention and ensuring the transparency and immutability of strategy execution through a decentralized mechanism. Furthermore, by generating dynamic encryption keys through cross-modal conversion, using the data content itself as the key source, the randomness and uniqueness of the keys are enhanced, effectively resisting brute-force and replay attacks. Simultaneously, by combining attribute-based encryption technology, the keys are bound to access policies containing modality types, achieving fine-grained control over data access and ensuring that only users meeting specific attributes can decrypt the data, thus improving the confidentiality and privacy protection of the data. Finally, a distributed storage system is used to store the encrypted data, and a blockchain-based notarization mechanism is used to record the operation hashes. This ensures both the reliability and availability of data storage, and achieves auditability and traceability of the entire operation process, providing comprehensive technical support for data security management. In summary, this application effectively solves the challenges of adaptability, security, and trustworthiness in multimodal data encryption through modal adaptation, policy automation, key dynamization, and decentralized storage, providing an innovative solution for data security protection in scenarios such as cloud computing and the Internet of Things.

[0007] Furthermore, the identification of the modality type of the raw data through an artificial intelligence model includes: An artificial intelligence model is constructed based on deep learning algorithms to obtain a modality classification model; The raw data is input into a pre-trained modality classification model, and the probability distribution of the raw data belonging to each modality type is calculated through the fully connected layer and softmax activation function of the model; wherein, the modality type includes, but is not limited to, image modality, text modality, audio modality and video modality; Select the modality with the highest probability value as the recognition result and output the type identifier of the recognition result.

[0008] Furthermore, the extraction of modal features from the original data includes: For image modalities, key points can be detected and descriptors generated using the scale-invariant feature transform algorithm, or the feature vector output by the bottleneck layer of a neural network model can be used to obtain image modal features. For text modalities, a word embedding model is used to convert the text into word vectors, and document-level feature representations are generated through max pooling or average pooling to obtain text modal features; For audio data, the Mel frequency cepstral coefficient sequence is extracted, and the mean, variance, and dynamic range of the Mel frequency cepstral coefficient sequence are calculated to obtain the audio modal features.

[0009] Furthermore, the step of matching and triggering a cross-modal encryption strategy corresponding to the modality type according to preset rules deployed on the blockchain network includes: A policy mapping table is predefined in the smart contract; the policy mapping table is indexed by modality type and associated with target modality, encryption algorithm parameters and conversion rules. Once the smart contract receives the uploaded modality type and modality characteristics, it queries the policy mapping table for matching and triggers the cross-modal encryption policy process based on the matching result.

[0010] Furthermore, the predefined strategy mapping table includes the following transformation rules: When the modality type is image, the policy mapping table specifies the target modality as text, the encryption algorithm parameters are AES-256-CBC mode, and the conversion rule is to use the contrastive language-image pre-trained CLIP model to convert the image content into descriptive text and use the text hash value as the dynamic encryption key. When the modality type is text, the policy mapping table specifies the target modality as audio, the encryption algorithm parameters are ChaCha20-Poly1305 algorithm, the conversion rule is to use the text-to-speech model to generate the corresponding audio waveform, and then extract the spectral features of the waveform data to generate a dynamic encryption key. When the modality type is audio, the policy mapping table specifies the target modality as image, the encryption algorithm parameters are SM4-CTR mode, the conversion rule is to convert the audio signal into a spectrogram, use a convolutional neural network to extract spectral features to generate a visualization image, extract feature vectors from the generated visualization image, and then calculate the hash value through a cryptographic hash function to generate a dynamic encryption key. When the modality type is video, the policy mapping table supports multi-target modality conversion, including conversion to keyframe sequence images or conversion to audio stream. The encryption algorithm is dynamically selected according to the amount of data. The conversion rule uses time slicing technology combined with 3D convolutional neural network for feature extraction, and the extracted multi-dimensional feature vector is normalized. Then, the SHA-256 algorithm is applied to calculate the hash value and generate a dynamic encryption key. When the data contains multiple modalities, the policy mapping table initiates a cascaded transformation process, first separating the data of each modality, then performing the corresponding cross-modal transformations, and finally generating a dynamic encryption key through feature fusion technology.

[0011] Furthermore, the process of triggering the cross-modal encryption strategy based on the matching result includes... The smart contract sends a conversion request to a cross-modal conversion service deployed on edge nodes or in the cloud. The request includes modal characteristics, target modal identifier, and cryptographic algorithm parameters. The cross-modal conversion service invokes an artificial intelligence model based on the conversion request to convert the original data or modal features into target modal data; Perform cryptographic hashing on the transformed data to generate a dynamic encryption key, and return the key to the smart contract; The smart contract verifies the integrity of the key generation process and triggers subsequent encryption operations.

[0012] Further, the step of binding and encrypting the dynamic encryption key with an access policy containing the modality type includes: The access policy is defined as an attribute-based logical expression; the logical expression includes modal type attribute, user role attribute, and data security level. The dynamic encryption key is encrypted using the public key of an attribute-based encryption system; wherein, the encryption process of the attribute-based encryption system is based on bilinear mapping pair calculation to generate attribute-based ciphertext, and the attribute-based ciphertext is embedded with an access policy, and only users whose attribute set satisfies the access policy can decrypt it; The attribute base ciphertext is associated with the access policy identifier and stored, and then recorded in the blockchain distributed ledger.

[0013] Further, storing the first ciphertext and the second ciphertext in a distributed storage system includes: The first and second ciphertexts are fragmented separately, and a unique identifier is generated for each fragmented data. The fragmented data is uploaded in parallel to the nodes of the distributed storage system, and a replication factor is set. The replication factor represents the number of copies of the data fragment that are redundantly stored in the distributed storage system, and is dynamically set according to the data security level. The distributed storage system returns the root hash of the storage structure; wherein, the root hash serves as a data addressing pointer; The root hash and the metadata of the second ciphertext are packaged together and recorded into the blockchain distributed ledger through a smart contract transaction to complete the evidence storage; When a node failure is detected, a data migration mechanism is triggered to reallocate replicas to other nodes.

[0014] Furthermore, the root hash represents the topological root node hash value obtained by hierarchically aggregating the unique identifiers of all fragmented data through a hash tree structure, and the generation process includes: Use the unique identifier of each data shard as the leaf node of the hash tree, and calculate the hash value of the unique identifier; Combine the leaf nodes in pairs, concatenate the hash values ​​of each pair of nodes, and then calculate the hash value again to obtain the hash value of the parent node. If the number of nodes after combination is odd, then the remaining single leaf node is copied and used to participate in the calculation of the combination and the hash value of the parent node; The process of calculating the combined and parent node hash values ​​is executed recursively and aggregated upwards layer by layer to obtain a unique root node hash value, which is then marked as the root hash.

[0015] Secondly, a blockchain-based data security encryption device is provided, comprising: a communication unit and a processing unit; wherein, The communication unit is used to acquire the original data to be encrypted and transmit the original data to the processing unit; and, The modal types and modal features generated by the processing unit are uploaded to the blockchain network; Receive trigger instructions for cross-modal encryption policies from the blockchain network; The first and second ciphertexts generated by the processing unit are stored in a distributed storage system. The storage address hash is recorded together with the second ciphertext in the distributed ledger of the blockchain network; The processing unit is configured to identify the modal type of the raw data using a built-in artificial intelligence model and extract the modal features of the raw data; and, According to the preset rules received from the blockchain network, the cross-modal encryption strategy corresponding to the modality type is matched and triggered. Based on the cross-modal encryption strategy, the original data or modal features are converted into transformed data of the target modality; Perform cryptographic hashing on the transformed data to generate a dynamic encryption key; Using a dynamic encryption key and an encryption algorithm, the original data is encrypted to obtain the first ciphertext; Based on the attribute-based encryption algorithm, the dynamic encryption key is bound to the access policy containing modal types for encryption to generate a second ciphertext.

[0016] Thirdly, this application provides a blockchain-based data security encryption device, comprising: a processor and a storage medium; the storage medium includes instructions, and the processor is used to execute the instructions to implement the methods described in the first aspect and any possible implementation thereof. This blockchain-based data security encryption device can be an electronic device or a chip within an electronic device.

[0017] Compared with the prior art, the beneficial effects of this application are: This application utilizes an artificial intelligence model to accurately identify and extract features from multimodal data, achieving intelligent adaptation of data encryption strategies. The modality classification model built based on deep learning algorithms can accurately distinguish different modality types, while the feature extraction methods designed for each modality ensure the discriminativeness and effectiveness of feature representations. This allows the encryption system to dynamically adjust security strategies based on the essential characteristics of the data, overcoming the dependence on data format inherent in traditional methods.

[0018] At the encryption strategy execution level, this application innovatively combines blockchain smart contracts with cross-modal conversion technology to construct a highly automated encryption workflow. Through a predefined policy mapping table, the corresponding cross-modal conversion process can be automatically triggered based on the identified modality type, and a dynamic encryption key is generated based on the conversion result. This not only enhances the randomness and unpredictability of the key but also significantly reduces the risk of human intervention through the automated execution mechanism of smart contracts. Simultaneously, by combining attribute-based encryption technology to bind the key with an access policy containing the modality type, fine-grained access control for data decryption is achieved, providing reliable protection for secure data sharing in multi-user scenarios.

[0019] Regarding data storage and integrity assurance, this application employs a dual protection mechanism combining a distributed storage system and blockchain-based evidence storage. By sharding and dynamically allocating copies of encrypted data, both the reliability of data storage and the system's fault tolerance to node failures are ensured. Furthermore, the root hash generated based on a hash tree structure serves as the data addressing pointer, which, combined with the blockchain distributed ledger, ensures the traceability and immutability of the entire data operation process. This multi-layered security system enables this application to effectively verify data integrity while ensuring data confidentiality, making it particularly suitable for application scenarios with extremely high requirements for data security and reliability, such as the Internet of Things and edge computing. Attached Figure Description

[0020] 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 only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0021] Figure 1 A flowchart illustrating a blockchain-based data security encryption method provided in this application embodiment; Figure 2 A flowchart illustrating another blockchain-based data security encryption method provided in this application embodiment; Figure 3 A flowchart illustrating another blockchain-based data security encryption method provided in this application embodiment; Figure 4 A flowchart illustrating another blockchain-based data security encryption method provided in this application embodiment; Figure 5 A schematic diagram of a blockchain-based data security encryption device provided in this application embodiment; Figure 6 This is a schematic diagram of the hardware structure of a blockchain-based data security encryption device provided in an embodiment of this application. Detailed Implementation

[0022] It should be noted that, in this application, the terms "exemplary" or "for example" are used to indicate that something is being described as an example, illustration, or illustration. Any embodiment or design described as "exemplary" or "for example" in this application should not be construed as being more preferred or advantageous than other embodiments or design solutions. Specifically, the use of terms such as "exemplary" or "for example" is intended to present the relevant concepts in a concrete manner.

[0023] To address the technical problems in existing technologies, such as the disconnect between encryption strategies and data content, the difficulty in balancing security and efficiency, insufficient adaptability to multimodal data, lack of fine-grained access control, and poor traceability of operational processes, embodiments of this application provide a data security encryption method and apparatus based on blockchain. The method includes: Obtain the raw data to be encrypted, identify the modal type of the raw data through an artificial intelligence model, and extract the modal features of the raw data; The modality type and modality features are uploaded to the blockchain network, and the cross-modal encryption strategy corresponding to the modality type is matched and triggered according to the preset rules deployed on the blockchain network. Based on the cross-modal encryption strategy, the original data or modal features are converted into transformed data of the target modality, and the transformed data is subjected to cryptographic hashing to generate a dynamic encryption key; Using a dynamic encryption key, the original data is encrypted using an encryption algorithm to obtain the first ciphertext. Then, based on an attribute-based encryption algorithm, the dynamic encryption key is bound to an access policy containing modal types to generate the second ciphertext. The first and second ciphertexts are stored in a distributed storage system, and the storage address hash is recorded together with the second ciphertext in the distributed ledger of the blockchain network to complete the encrypted evidence storage.

[0024] Based on this, this application achieves adaptive, highly secure and traceable multimodal data encryption through the integration of multiple technologies, providing reliable protection for various data security scenarios.

[0025] like Figure 1 As shown in the embodiment of this application, a data security encryption method based on blockchain is provided, including: S1. Obtain the original data to be encrypted, identify the modal type of the original data through an artificial intelligence model, and extract the modal features of the original data.

[0026] Specifically, AI models suitable for modality recognition need to have the ability to classify data with different structures. Image modality data has attributes such as pixel matrix composition and includes spatial texture and color information; text modality data consists of character sequences and contains semantic logical relationships; audio modality data uses time series as its carrier and includes frequency and amplitude features. The corresponding recognition models need to be able to capture the core differences between these modalities. The methods for extracting modal features need to be able to uncover the essential representation of each modality data to ensure the discriminative power and effectiveness of the features.

[0027] In some implementations, AI recognition models can employ common network architectures such as convolutional neural networks (CNNs), recurrent neural networks (RNNs), and Transformer models. CNNs excel at capturing spatial features and are suitable for image modality recognition; RNNs are well-suited for processing sequence data and are adapted for text and audio modality recognition; and Transformer models, through their self-attention mechanism, can effectively extract global features across various modalities, achieving unified multimodal recognition. Methods for extracting modal features include histogram of oriented gradients (HBP), term frequency-inverse document frequency (IF-IVF), and linear predictive cepstral coefficients. These can be achieved by fine-tuning pre-trained models to adapt to specific modalities or by directly processing the raw data using mature feature extraction algorithms.

[0028] S2. Upload the modality type and modality features to the blockchain network, and match and trigger the cross-modal encryption strategy corresponding to the modality type according to the preset rules deployed on the blockchain network.

[0029] The blockchain network is a distributed network composed of multiple nodes using decentralized protocols. It is used to store modal information and execute encryption strategies, ensuring the security and trustworthiness of data and operations. Predefined rules are predefined criteria for the correspondence between modal types and cross-modal encryption strategies. Their function is to automatically match and trigger encryption strategies, reducing human intervention and improving the automation level of the encryption process.

[0030] In some implementations, a blockchain network can consist of consensus nodes, storage nodes, and smart contract execution nodes. Consensus nodes maintain network data consistency through consensus mechanisms such as Proof-of-Work, Proof-of-Stake, or Delegated Proof-of-Stake. Storage nodes are responsible for persistently storing modal information and ledger data. Smart contract execution nodes are dedicated to handling the deployment and execution of smart contracts. Predefined rules are deployed in the blockchain network in the form of smart contracts. Each smart contract contains a mapping table between modal types and cross-modal encryption strategies. When modal types and modal characteristics are uploaded to the blockchain, the smart contract automatically retrieves the mapping table and triggers the execution of the corresponding cross-modal encryption strategy based on the matching result.

[0031] It should be noted that the node distribution of the blockchain network should cover the key links of data processing to ensure the efficiency of modal information uploading and policy triggering; the preset rules should have a certain degree of flexibility and can be adjusted and updated according to the security requirements of actual application scenarios, and the updates of the rules should be verified by the consensus of the blockchain network to ensure their legality and consistency.

[0032] S3. Based on the cross-modal encryption strategy, the original data or modal features are converted into transformed data of the target modality, and cryptographic hashing is performed on the transformed data to generate a dynamic encryption key.

[0033] The core of cross-modal encryption strategy is to utilize the semantic association or feature mapping relationship between different modal data to transform the original data or features of the source modality into transformed data of the target modality. Based on the transformed data, an encryption key is generated to achieve deep binding between the key and the data content. Its function is to improve the randomness, uniqueness and security of the key and avoid the risk that static keys are easily cracked.

[0034] In some implementations, cross-modal encryption is based on a pre-trained cross-modal mapping model, establishing a non-linear mapping relationship from the source modality to the target modality, thus achieving efficient conversion between modalities. Common implementations include using generative adversarial networks (GANs) for bidirectional image-to-text conversion, using encoder-decoder architectures for text-to-audio conversion, and using feature mapping algorithms for audio-to-image conversion. Cryptographic hashing operations can employ common algorithms such as Message Digest 5, Secure Hash Algorithm 1, and Secure Hash Algorithm 256 to hash the converted data and generate a fixed-length dynamic encryption key.

[0035] S4. Using a dynamic encryption key, the original data is encrypted using an encryption algorithm to obtain the first ciphertext. Based on the attribute-based encryption algorithm, the dynamic encryption key is bound to the access policy containing the modal type for encryption to generate the second ciphertext.

[0036] Among them, encryption algorithms that can be used to generate the first ciphertext include common symmetric encryption algorithms such as the Data Encryption Standard (DES), Advanced Encryption Standard (AES), International Data Encryption Algorithm (IDA), and chaotic encryption algorithms. Attribute-based encryption algorithms are asymmetric encryption techniques based on user attributes and access policies. Their core idea is to associate encryption with user attributes, embedding the access policy into the ciphertext. Decryption can only be successful when the user's attribute set satisfies the access policy, thus achieving fine-grained access control.

[0037] In some implementations, step S4 may be implemented by: First, select a suitable symmetric encryption algorithm, and use the dynamic encryption key as the key to encrypt the original data to obtain the first ciphertext; Then, define access policies that include attributes such as modality type, user role, and data security level, and convert the access policies into logical expressions in conjunction normal form or disjunctive normal form. Finally, the dynamic encryption key is bound to the access policy using the public key of the attribute-based encryption algorithm to generate the second ciphertext; the attribute-based encryption algorithm can be a bilinear pair-based encryption scheme, an elliptic curve-based encryption scheme, etc.

[0038] S5. Store the first and second ciphertexts in a distributed storage system, and record the storage address hash along with the second ciphertext in the distributed ledger of the blockchain network to complete the encrypted evidence storage.

[0039] Among them, the distributed storage system is a storage cluster composed of multiple geographically dispersed but logically unified storage nodes. Through technologies such as data sharding, replica redundancy, and load balancing, it achieves high availability, high scalability, and high reliability of data storage. The distributed ledger is a decentralized transaction record database jointly maintained by all nodes in the blockchain network. Its characteristics include immutability, full traceability, and transparency. It is used to record key information such as data storage address and encryption operations to ensure the validity of evidence.

[0040] In some implementations, step S5 may include: First, the first and second ciphertexts are divided into fragments according to the preset fragment size, and a unique identifier is assigned to each fragment. Then, the sharded data is evenly distributed to different nodes of the distributed storage system, and the number of replicas is set according to the data security level; Calculate the storage address hash of each shard, and package the storage address hashes of all shards with the second ciphertext to form transaction data; The transaction data is sent to the blockchain network, and after being verified by the consensus nodes, it is recorded in the distributed ledger to complete the encrypted storage.

[0041] Based on the above technical solutions, this application provides a blockchain-based data security encryption method that uses an artificial intelligence model to achieve intelligent identification and feature extraction of multimodal data, improving the adaptability of the encryption system to different modal data. Leveraging the decentralized nature of the blockchain network and smart contracts, it achieves automated matching and triggering of encryption strategies, ensuring transparency and immutability of operations. By generating dynamic encryption keys through cross-modal conversion and combining them with attribute-based encryption technology, it achieves high key security and fine-grained control over access. The method combines distributed storage with blockchain evidence storage, ensuring the reliability of data storage and the traceability of operational processes.

[0042] In one possible implementation of the embodiments of this application, combined with Figure 1 The above S1 can be implemented through the following S101 and S102, which are explained in detail below: S101. Construct an artificial intelligence modality classification model, input the raw data, and identify the modality type of the data.

[0043] Among them, the artificial intelligence modality classification model is a model built on deep learning algorithms that has the ability to distinguish modalities. Its core function is to learn the feature differences of different modal data and output the modality type to which the original data belongs.

[0044] In some implementations, the construction and inference process of the modality classification model is as follows: 1. Model Architecture Design: A four-layer architecture of "unified input interface - modality-specific encoder - cross-modal feature fusion - general classification head" is adopted to achieve unified modality recognition for single-modal (image, text, audio, video) and multi-modal (such as "image + text" or "audio + video") data. Its network architecture can be shown below: Unified Input Interface Layer: Receives raw data from any modality / multimodality, first performs modality-independent standardization preprocessing—converting all input data into feature tensors of a fixed format, and adding modality placeholders to each input data. For example, for single-modal inputs, only the corresponding placeholder is activated, while for multimodal inputs, all associated placeholders are activated, ensuring that subsequent encoders can call them as needed.

[0045] Modality-specific encoder layer: Lightweight dedicated encoders are designed for common modal types, and the output dimension of each encoder is uniformly 1024-dimensional feature vectors to facilitate subsequent fusion. (1) Image encoder: The MobileNetV3-Small architecture is adopted, the last fully connected layer is removed, and a 1024-dimensional image feature vector is output through global average pooling to adapt to 224×224×3 input; (2) Text encoder: DistilBERT (a lightweight version of Transformer) is used. The output of the last hidden layer is truncated and the sequence features are converted into 1024-dimensional text feature vectors through mean pooling to adapt to text inputs with a maximum length of 512. (3) Audio encoder: The combination of "1D-CNN+BiLSTM" is adopted. 1D-CNN is used to extract local features of the audio spectrum, BiLSTM is used to capture temporal dependencies, and finally the fully connected layer is used to map to a 1024-dimensional audio feature vector to adapt to 128×32 MFCC input. (4) Video encoder: “3D-CNN + attention pooling” is adopted. The 3D-CNN uses a lightweight version of C3D. The output focuses on key frame features through attention pooling and is converted into a 1024-dimensional video feature vector, which is adapted to the input of 16-frame × 224 × 224 × 3 video segments. This layer works through a conditional activation mechanism, where a single-modal input activates only the corresponding encoder, a multimodal input activates all associated encoders, and the inactive encoders output a zero vector.

[0046] Cross-modal feature fusion layer: Employs a self-attention + gating fusion mechanism to achieve direct transfer of single-modal features and deep interaction of multi-modal features. Single-modal scenario: The input contains only one modality feature vector, and the fusion layer directly outputs this feature vector as the global feature without performing any additional fusion operation; Multimodal scenarios: The input contains feature vectors of multiple modalities. First, the correlation weights between different modal features are calculated through a self-attention layer. Then, key fusion features are selected through a gating unit, and finally, a 1024-dimensional global fusion feature is output.

[0047] General Modality Classification Head: Employs a fully connected layer + multi-label Softmax structure. Inputting a global feature vector, the head first compresses the features through two fully connected layers, then outputs the modality type probability distribution and multi-modality label probability through a multi-label Softmax activation function. Modality type probability: the probability of outputting four types of single modalities: image, text, audio, and video; Multimodal label probability: Outputs the binary classification probability of whether it is multimodal; By setting thresholds, such as determining a single modality probability ≥ 0.8 as a single modality, and determining a multimodal modality probability ≥ 0.7 and a probability of two or more single modalities ≥ 0.5 as a multimodal modality, accurate identification of any input modality can be achieved.

[0048] 2. Model Training and Optimization: First, a multimodal training dataset is constructed, containing labeled data such as images, text, and audio. Each sample is labeled with a corresponding modality type label. The error between the model's predicted value and the true label is calculated using the cross-entropy loss function. Then, the loss function is minimized using stochastic gradient descent or Adam optimizer, and the model parameters are iteratively updated. At the same time, methods such as Dropout and L2 regularization are used to prevent the model from overfitting. Finally, a pre-trained modality classification model is obtained.

[0049] 3. Modal type reasoning: The preprocessed data is input into the pre-trained model. After feature extraction and calculation by the model, a vector with dimension C (number of modal types) is output through the fully connected layer. The single modal type probability distribution and multimodal label probability are output by the multi-label Softmax activation function. Finally, the modal type is determined, a unique type identifier is generated, and it is uploaded to the blockchain network simultaneously.

[0050] S102. For the identified modal types, use an adaptation method to extract the modal features of the original data.

[0051] Modal features refer to information that can characterize the essential attributes of a certain type of modal data, such as edge features of images, semantic features of text, and frequency features of audio.

[0052] In some implementations, modal feature extraction requires strict matching with the identified modal type. Specific methods are as follows: 1. Image modal feature extraction: Features can be extracted using scale-invariant feature transformation algorithms or neural network bottleneck layers. (1) SIFT algorithm extraction: This includes scale-space extremum detection, keypoint localization, orientation assignment, and descriptor generation. Scale-space extremum detection is achieved using the Difference of Gaussians (DoG) pyramid, with the following formula: ;in, For the difference of Gaussian image in coordinates (x,y), scale Pixel value at that location, Let be a Gaussian function, k be the scaling factor between adjacent scale layers, I(x,y) be the input image, and * denote convolution operation. This formula is used to detect extreme points in the image at different scales, which are then used as keypoints. Subsequently, a principal orientation is assigned to each keypoint, i.e., a multi-descriptor vector is generated based on the gradient orientation histogram of the keypoint's neighboring pixels, which represents the image modal features.

[0053] (2) Extraction of bottleneck layer of neural network: Using a pre-trained CNN model (such as ResNet, VGG), remove the last fully connected layer and the Softmax layer of the model, and use the output of the second to last fully connected layer (or global average pooling layer) as the feature vector.

[0054] 2. Text modality feature extraction: Feature extraction is achieved using a word embedding model combined with pooling operations. First, word embedding models such as Word2Vec or GloVe are used to map each word in the text to a fixed-dimensional word vector. Taking the Skip-gram model of Word2Vec as an example, its objective function is to maximize the co-occurrence probability of words within the window, as shown in the formula: ;in, Let T be the objective function, T be the length of the text sequence, and m be the window size. For the t-th word, For the given words At that time, words in the window The conditional probability, These are the model parameters. By optimizing this objective function, the word vector for each word is obtained. Then, the word vectors of all words in the text are combined into a matrix, and max pooling or average pooling is used to generate document-level features, which are the text modal features.

[0055] 3. Audio modal feature extraction: Feature extraction is performed using Mel-Frequency Cepstral Coefficients (MFCCs), mainly including steps such as pre-emphasis, framing, windowing, Fourier transform, Mel filtering, and cepstral transform. The Mel-Frequency Cepstral Coefficients conversion formula is as follows: Where f is the linear frequency of the audio signal (unit: Hz). This corresponds to the Mel frequency. The audio spectrum is mapped to the Mel frequency domain using this formula. Mel spectral features are then extracted using a triangular filter group. Finally, the logarithm of the Mel spectrum is taken and a Discrete Cosine Transform (DCT) is performed. The first 13-20 coefficients are taken as MFCC coefficients. The mean, variance, and dynamic range (the difference between the maximum and minimum values) of the MFCC coefficients are further calculated to form a higher-dimensional feature vector, which is the audio modal feature.

[0056] 4. Video modal feature extraction: Three methods are employed: spatiotemporal joint extraction, spatial-temporal separation extraction, and motion feature enhancement extraction. These methods take into account both the spatial texture information and temporal dynamic changes of the video, ensuring that the features can fully represent the essential attributes of the video modality. The specific methods are as follows: (1) Using 3D Convolutional Neural Network (3D CNN) for spatiotemporal joint feature extraction: ① Divide the original video into short segments at fixed time intervals, and perform frame size normalization and pixel value normalization on each segment to ensure that the input format is consistent; ② A pre-trained 3D CNN model is used, which extracts spatiotemporal joint features through multiple 3D convolutional layers and 3D pooling layers; ③ Perform spatiotemporal global average pooling on the feature tensor output by the last convolutional layer of the 3D CNN to compress the "T×H×W×C" tensor (T is the time step, H is the height, W is the width, and C is the number of channels) into a C-dimensional vector. This vector contains both the spatial texture (such as the shape of an object) and the temporal dynamics (such as the motion of an object) information of the video, which is the basic feature of the video modality.

[0057] (2) Spatial-temporal separation feature extraction using 2D CNN combined with Bidirectional Long Short-Term Memory (BiLSTM) network: ①Keyframe extraction: The inter-frame difference method is used to select key frames in the video, and the mean grayscale difference between adjacent frames is calculated. ,formula: ,in Let H be the grayscale value of the t-th frame at (x, y), and let H and W be the frame sizes; when When the value exceeds a preset threshold, the t-th frame is determined to be a key frame, and finally, a multi-frame key frame sequence is extracted. ②2D CNN spatial feature extraction: Input each keyframe into the pre-trained 2D CNN model, remove the last fully connected layer and the Softmax layer, and take the 2048-dimensional spatial feature vector output by the global average pooling layer to obtain the spatial feature matrix of "number of keyframes × 2048". ③BiLSTM temporal modeling: The spatial feature matrix is ​​input into the BiLSTM network. The BiLSTM captures the inter-frame temporal dependencies through LSTM units in both forward and backward directions. Finally, mean pooling is performed on the temporal features output by the BiLSTM to obtain a 512-dimensional feature vector that fuses spatiotemporal information, which is the video modal feature.

[0058] (3) Motion feature enhancement extraction using optical flow and 2D CNN: ① Optical flow calculation: The Farneback dense optical flow algorithm is used to calculate the optical flow of adjacent frames in the video. Calculate the dense optical flow field, where the optical flow field satisfies the constant brightness constraint equation: , where u(x,y) and v(x,y) are the motion velocities (optical flow vectors) of the pixel at (x,y) in the x and y directions, respectively. , for The gradient; by solving this equation, the optical flow vector map of each frame is obtained; ② Optical flow map generation: Convert the optical flow vector map into a visual RGB image, where the x-direction velocity is mapped to the red channel and the y-direction velocity is mapped to the green channel, resulting in "video frame number - 1" optical flow maps (e.g., 16 frames of video generate 15 optical flow maps), and the size of each optical flow map is consistent with the original video frame; ③ Fusion of motion and spatial features: The optical flow map is input into a 2D CNN (such as ResNet18) to extract a 512-dimensional motion feature vector. At the same time, the keyframes of the original video are input into the same 2D CNN to extract a 512-dimensional spatial feature vector. Through feature concatenation or feature weighted fusion, a 1024-dimensional feature vector is generated. This vector covers both the spatial texture and fine-grained motion information of the video, which is the enhanced video modal feature.

[0059] Based on the above technical solution, the modality classification model in S101 enables accurate identification of multimodal data; the modality feature extraction in S102 employs appropriate extraction methods for different modalities to ensure the discriminative power and representational ability of the features.

[0060] In one possible implementation of this application embodiment, the above-mentioned S2 can be specifically implemented by the following S201, S202 and S203, which are described in detail below: S201. Upload the modal types identified in S1 and the extracted modal features to the blockchain network to ensure the integrity of the data upload process and the reliability of the source.

[0061] In some implementations, the upload process must strictly adhere to the three-step specification of data preprocessing, signature verification, and consensus storage, specifically including: First, the client serializes the modal data, including the modal type identifier and modal feature vector, into binary format, and then calculates the data integrity hash value using the Secure Hash Algorithm 256 (SHA-256).

[0062] Next, the client uses its private key to sign the hash value H, obtaining the digital signature S; then it packages the "modal data M, hash value H, digital signature S, and client public key PK" into an upload request and sends it to the consensus node of the blockchain network, such as the verification node in a consortium blockchain.

[0063] After receiving the request, the consensus node first decrypts the digital signature S using the client's public key PK to obtain the decrypted hash value H'. Then, it recalculates the SHA-256 hash value H'' of the modal data M and compares H' with H''. If they match, it means the data source is legitimate and has not been tampered with. After verification, the node broadcasts the upload request to other nodes in the blockchain. Through a practical Byzantine fault tolerance or proof-of-stake consensus mechanism, data storage consensus is achieved. Finally, the modal data M and the hash value H are written into the blockchain distributed ledger, and a unique transaction ID (TXID) is generated for subsequent data source query during strategy matching.

[0064] It should be noted that modal feature vectors may have high dimensionality (such as 512-dimensional image features), and direct uploading would consume a lot of blockchain storage resources. Therefore, dimensionality reduction processing can be performed through principal component analysis or linear discriminant analysis before uploading to ensure storage efficiency.

[0065] S202. Deploy a policy mapping table in the blockchain smart contract to define the correspondence between modal types and cross-modal encryption policies.

[0066] The strategy mapping table, or preset rules, is a mapping relationship between target modality, encryption algorithm parameters, and conversion rules, indexed by modality type. The role of smart contracts is to deploy the strategy mapping table on the blockchain in an immutable and automatically executed manner, providing a trusted rule base for subsequent matching processes.

[0067] In some implementations, the predefined policy mapping table includes the following transformation rules: 1. Modal type is image (index: IMG): Target modality: Text (TXT); Encryption algorithm parameters: The encryption algorithm adopts the Advanced Encryption Standard 256-bit Cipher Block Chaining mode (AES-256-CBC), the initialization vector (IV) is 128 bits long, or 16 bytes, generated by the cryptographically secure pseudo-random number generator CSPRNG, and the key derivation adopts the Hash Message Authentication Code (HMAC-SHA256) to ensure that the dynamic key is strongly correlated with the image features; Conversion rules: ① The input data is the image modal features extracted by S1. If the input is the original image, standardization preprocessing must be performed first; ② Call the contrastive language-image pre-trained model (CLIP-ViT-B / 32 version), input the image data into the model's visual encoder, and output a 1024-dimensional image semantic feature vector; ③ The model's text encoder loads a preset text candidate library and calculates the cosine similarity between the image semantic features and the candidate text features; ④ Select the text with the highest similarity (similarity threshold ≥ 0.8) as the conversion data, perform SHA-256 hash operation on the text to generate a 256-bit hash value, which serves as the core input for the subsequent dynamic encryption key.

[0068] 2. Modal type is text (index: TXT): Target modality: Audio (AUD); Encryption algorithm parameters: The encryption algorithm adopts the ChaCha20-Poly1305 combination algorithm, with a key length of 256 bits, a non-ce (Nonce) length of 96 bits, and a Poly1305 authentication tag length of 128 bits, which is used to verify the integrity of the audio conversion data. Conversion rules: ① The input data is the text modal features extracted by S1. If the input is raw text, it needs to be cleaned, segmented and encoded first; ② Call the text-to-speech (TTS) model (Tacotron 2 encoder + WaveGlow vocoder), input the text token sequence into the Tacotron 2 encoder to generate a Mel spectrogram; ③ The WaveGlow vocoder converts the Mel spectrogram into a 16kHz mono audio waveform, and the audio duration matches the text reading duration; ④ Perform a short-time Fourier transform on the audio waveform data to extract the spectral feature vector, and then generate a 256-bit hash value through SHA-256 hash operation, which is used as a dynamic encryption key.

[0069] 3. Modal type is audio (index: AUD): Target modality: Image (IMG); Encryption algorithm parameters: The encryption algorithm adopts the national cryptographic standard 4 counter mode (SM4-CTR), the key length is 128 bits, and the initial value of the counter is 128 bits; Conversion rules: ① The input data is the audio modal features extracted by S1. If the input is the original audio, noise reduction, resampling and framing must be performed first; ② Mel frequency analysis is performed on the processed audio, and a Mel spectrogram is generated through 256 triangular Mel filter groups. The spectral values ​​are logarithmically mapped to the grayscale range of 0~255; ③ A lightweight convolutional neural network (such as MobileNetV2) is called to enhance the features of the Mel spectrogram, and a 224×224×1 grayscale image is output, preserving the dynamic change information of audio frequency; ④ Pixel value serialization is performed on the enhanced grayscale image, and a 256-bit hash value is generated through SHA-256 hash operation. The first 128 bits are then truncated as the encryption key for the SM4-CTR algorithm, while the complete hash value is retained for subsequent verification.

[0070] 4. Modal type is video (index: VID): Target modality: Multiple targets are available, including keyframe sequence images IMG_seq and audio stream AUD_stream. Dynamic selection is supported based on the amount of video data (IMG_seq for data <1GB, AUD_stream for data ≥1GB). Encryption algorithm parameters: AES-256-CBC is used when the data volume is <1GB, and ChaCha20-Poly1305 is used when the data volume is ≥1GB. All keys are generated by SHA-256 hash and are marked with parameters according to the target modality, such as IMG_seq corresponding to "KEY-Type:IMG" and AUD_stream corresponding to "KEY-Type:AUD". Conversion rules: ① The input data is the video modal features extracted by S1. If the input is the original video, time slicing, frame normalization, and redundant frame removal must be performed first; ② If IMG_seq is selected as the target modality: a 3D convolutional neural network is called to extract video keyframes. SIFT feature extraction is performed on the keyframes and then concatenated into a feature matrix of "number of keyframes × 128". Then, a key is generated by SHA-256 hashing; ③ If AUD_stream is selected as the target modality: a video demultiplexer is called to extract the audio stream. A spectrum image is generated according to the audio modality conversion rules and then hashed to generate a key; ④ After the conversion is completed, the target modality identifier and the key hash are fed back to the smart contract for subsequent encryption process adaptation.

[0071] 5. Modal type is multimodal (index: MULTI, such as "IMG+TXT" or "AUD+VID"): Target mode: The multimodal process is separated to obtain multiple single modes, and then each single mode is processed according to the above conversion rules to obtain the target mode of different single modes; Encryption algorithm parameters: AES-256-GCM (Galois / Counter Mode, which combines encryption and authentication functions) is used, with an IV of 128 bits, an authentication tag of 128 bits, and the key is generated by hashing multimodal features. Transformation Rules: ① Multimodal Separation: Based on the format identifier of the multimodal data, separate the original data or modal features of each individual modality; ② Independent Transformation of Individual Modalities: Process each separated modality separately according to the single-modal transformation rules mentioned above; ③ Transformation Feature Normalization: Perform L2 normalization on the transformation feature hash values ​​(H1, H2, H3, H4, etc.) of each individual modality; ④ Multimodal Feature Fusion: Adopt a fusion strategy of "weighted summation + double hashing". First, allocate fusion weights according to the data security level of each individual modality (e.g., high security level modality weight 0.4, medium security level 0.3, low security level 0.3, and the total weight is 1). The calculation formula is as follows: Where n is the number of individual modes after separation. Let i be the weight of the i-th mode. For multi-dimensional fused feature vectors, The transition features of a single mode after normalization; subsequently, for Perform a double SHA-256 hash operation to obtain a 256-bit final fused hash value; ⑤ Dynamic key generation and verification: Use the final fused hash value as the dynamic encryption key for the AES-256-GCM algorithm, and simultaneously send the conversion records of each individual mode to the blockchain smart contract; The smart contract verifies each... The correlation with the original modal features is verified, and once the dynamic key is valid, it is used for subsequent encryption operations of the first and second ciphertexts.

[0072] It should be noted that the above conversion rules are not limited to the single modality (image, text, audio, video) content preset in the policy mapping table. That is, as long as the source modality before conversion and the target modality after conversion are of different types, the core objective of cross-modal encryption can be achieved—generating a dynamic encryption key strongly correlated with the data content through modal differences, providing a secure foundation for subsequent encryption operations. Furthermore, when the data to be processed is multimodal, in addition to the approach of first separating each single modality, then performing the corresponding rule conversion on each single modality, and finally generating a dynamic key through feature fusion, a method can also be adopted to uniformly convert multimodal data into a single target modality. For example, multimodal data such as "image + audio" and "text + video" can be converted into text form, and then a hash operation can be performed on the unified text data based on the text modality conversion rules to generate a dynamic encryption key. Both conversion paths can adapt to the cross-modal encryption requirements in multimodal scenarios.

[0073] In some implementations, the design of the policy mapping table and the deployment of smart contracts must meet three main requirements: "clear structure, scalability, and easy verification." 1. Policy Mapping Table Structure Design: A key-value pair data structure is adopted, where "Key" is a modal type identifier, such as "IMG", "TXT", "AUD", or "VID" (VID represents video), and "Value" is a custom "Policy" structure containing the following four core fields:

[0074] The purpose of this structure is to clarify the complete logic of "input modality → target modality → encryption parameters → conversion method", ensuring that all necessary parameters can be directly obtained during subsequent matching.

[0075] 2. Smart Contract Development and Deployment: Smart contracts are written using Solidity (Ethereum ecosystem) or Go (Hyperledger Fabric ecosystem). After the contract is written, it is deployed to the blockchain network using a blockchain node deployment tool. The deployment process requires node consensus verification to ensure that the contract code is immutable.

[0076] 3. Policy mapping table extension mechanism: For multimodal data cascading transformation, add "isCascade" (whether to cascade) and "cascadeSteps" (cascade steps) fields to the Policy structure. For example, the policy for multimodal data (image + text) can be defined as: "isCascade:true, cascadeSteps:["IMG→TXT", "TXT→AUD"]", to ensure that the rules can cover complex modal scenarios.

[0077] S203. The smart contract listens to blockchain data, matches the policy mapping table according to the uploaded modality type, and triggers the cross-modality encryption policy.

[0078] The core of this step is that the smart contract automatically associates the data source with the rule base—by listening to the data upload event generated by S201, obtaining the modal type identifier, querying the policy mapping table deployed by S202, and triggering the subsequent conversion process after matching the corresponding policy, the data upload, rule matching and policy triggering are fully automated.

[0079] In some implementations, the matching and triggering process of smart contracts includes the following steps: 1. Event Listening and Data Acquisition: The smart contract predefines the "DataUploaded" event (triggered by the S201 consensus node when data is written to the ledger). The event parameters include "TXID (transaction ID), modalType (modal type), and timestamp (upload time)". The smart contract listens for this event in real time through an "event subscription mechanism". When the event is captured, the blockchain ledger query interface is called to obtain the corresponding modal feature vector based on the TXID, ensuring that the correspondence between modal type and modal feature is correct.

[0080] 2. Strategy matching and legality verification: First, the existence of modal features is verified through smart contracts, then the strategy mapping table is queried, and finally the integrity of the strategy fields is verified to ensure that the matching result is legal and valid.

[0081] 3. Strategy Triggering and Record Traceability: After the smart contract matches a legitimate strategy, it generates a "StrategyTriggered" event. The event parameters include "TXID (associated upload transaction ID), matchedPolicy (matched strategy), and triggerTime (trigger time)". This event is pushed in real time to the "cross-modal conversion service" (such as the CLIP model service deployed based on Docker) deployed on edge nodes or in the cloud, notifying the service to start the conversion process. At the same time, the smart contract writes "TXID, matchedPolicy, and triggerTime" into the "strategy trigger record table" of the blockchain ledger to ensure that the triggering process is traceable and tamper-proof.

[0082] Based on the above technical solutions, S201 ensures the integrity, tamper-proofness, and traceability of the modal data upload process through hash verification, digital signature, and consensus storage; S202 achieves decentralized storage and immutability of rules by deploying a strategy mapping table through smart contracts; and S203 achieves fully automated association of "data-rules-policies" through event-driven, automatic matching, and exception handling, significantly reducing human intervention and improving the efficiency and reliability of the encryption process.

[0083] In one possible implementation of the embodiments of this application, combined with Figure 1 ,like Figure 2 As shown, the above S3 can be implemented through the following S301, S302 and S303, which are explained in detail below: S301: Receive the cross-modal encryption strategy triggered by the blockchain smart contract, parse the strategy parameters, and prepare the technical resources required for conversion.

[0084] This step clarifies the conversion target by analyzing parameters and deploying suitable technical resources, providing clear objectives and hardware support for subsequent conversion operations.

[0085] In some implementations, S301 may include the following operational steps: First, the cross-modal conversion service, deployed in a Docker container on an edge node or in the cloud, receives the conversion request from the smart contract. It then parses the "strategy parameter package" in the request, which must contain four core parameters: targetModal (target modality), transformModel (conversion model), inputType (input type: raw data / modal feature), and hashAlg (hash algorithm). The service then performs an integrity check. If the check fails, the conversion service returns a "parameter error" event to the smart contract, triggering a strategy re-match. If the check passes, it proceeds to the resource preparation phase.

[0086] Next, select and load the pre-trained model based on the "transformModel" parameter. The specific adaptation rules are as follows: If the conversion rule is "image → text" (targetModal="TXT", transformModel="CLIP"): Load the ViT-B / 32 version of the Contrastive Language-Image Pre-training (CLIP) model. The model input requirement is "224×224×3 RGB image", and the output is "probability distribution of 1000 text descriptions". The model weight file needs to be deployed on the GPU node in advance, and the image preprocessing module needs to be initialized.

[0087] If the conversion rule is "text → audio" (targetModal="AUD", transformModel="TTS"): Load a text-to-speech model (such as Tacotron 2), paired with a WaveGlow vocoder. The model input is "the segmented text sequence", and the output is "16kHz mono audio waveform". An audio synthesis environment needs to be configured on the CPU node.

[0088] If the conversion rule is "multimodal cascading" (e.g., "image + text → audio"): start the multi-model collaborative scheduling module, first load the CLIP model to process the image, then load the BERT model to process the text, and finally use the TTS model to fuse bimodal features to generate audio. This requires resource scheduling of multi-model containers through Kubernetes.

[0089] Next, adjust the input format according to the "inputType" parameter (raw data / modal features)—if the input is "modal features", the feature vector needs to be restored to a format that can be input into the model through a feature reconstruction algorithm; if the input is raw data, preprocessing needs to be performed to ensure that the data format is consistent with the model input requirements.

[0090] S302. Perform cross-modal conversion operation to convert the original data or modal features into converted data of the target modality.

[0091] In some implementations, the specific operations for performing cross-modal conversion can be performed by referring to the conversion rules in a predefined policy mapping table. Furthermore, cross-modal conversion must ensure semantic / feature consistency. For example, the text in image-to-text conversion must accurately describe the core content of the image, the audio in text-to-audio conversion must clearly convey the semantics of the text, and the spectrogram in audio-to-image conversion must fully reflect the frequency changes of the audio.

[0092] S303. Perform a cryptographic hash operation on the transformed data to generate a dynamic encryption key with randomness and uniqueness.

[0093] In some implementations, hash operations may include the following steps: First, the conversion data generated by S302 is standardized to ensure that the data format of the input hash algorithm is consistent: if the conversion data is text, the text is encoded into a binary stream in UTF-8 format; if the conversion data is audio, the sampling points of the audio waveform are converted into a binary stream and arranged in big-endian order; if the conversion data is an image (spectral graph), the pixel values ​​of the image are converted into a binary stream in row-major order, ignoring the image format header and retaining only the pixel data.

[0094] The preprocessed data is uniformly named "HashInput" and used as input for the hash algorithm.

[0095] Next, based on the "hashAlg" parameter parsed by S301, a hash algorithm is selected, prioritizing algorithms that conform to national cryptographic standards or internationally accepted high-security algorithms, and the hash value obtained after the hash operation is... , as a dynamic encryption key.

[0096] The generated dynamic key The data is sent to a blockchain smart contract, which verifies its uniqueness using the following rules. ;like If the key verification is successful, it will be used for subsequent S4 encryption operations; if The smart contract notifies the transformation service to re-execute S302 (such as adjusting the candidate text library of the CLIP model) to generate new transformation data and keys.

[0097] Based on the above technical solutions, S301 ensures that the cross-modal conversion target is clear and the resources are available through parameter verification and resource adaptation; S302 adopts differentiated conversion schemes for different modal combinations, covering all cross-modal scenarios in the document, and realizes multimodal adaptive conversion; S303 ensures the high randomness, collision resistance and uniqueness of the dynamic key through standardized hash process and uniqueness verification.

[0098] In one possible implementation of the embodiments of this application, combined with Figure 1 ,like Figure 3 As shown, the above S4 specifically includes the following S401 to S403: S401. Define an access policy that includes modal types, construct an attribute-based logical expression, and provide a basis for permission determination for subsequent key binding encryption.

[0099] The core function of this step is to transform abstract access permissions into machine-parseable formal rules, ensuring that subsequent attribute-based encryption (ABE) can be precisely embedded in the policy to achieve fine-grained access control.

[0100] In some implementations, the definition of an access policy includes the following steps: First, clarify the value range of the three core attributes to avoid ambiguity. The classification criteria are as follows: Modal type attribute (denoted as M): The value strictly corresponds to the modal identifier of S102, that is... ; User role attributes (denoted as R): defined based on the RBAC (Role-Based Access Control) model, i.e. It can be expanded according to the scenario; Data security level attributes (denoted as L): include .

[0101] All attributes must be standardized and registered through blockchain smart contracts to ensure that different nodes have a consistent understanding of the attribute values.

[0102] Using conjunction normal form (AND) and disjunctive normal form (OR) to combine properties, construct Boolean logic expressions with the following format: ;In the formula, For specific modal types, For specific roles, The symbol represents the specific security level; "∧" indicates that both conditions must be met, i.e., conjunction, which is suitable for high-security scenarios; "∨" indicates that "only one condition needs to be met", i.e., disjunction, which is suitable for low-security scenarios.

[0103] Next, the logical expression is checked for contradictions (such as...) by a policy validator deployed on the blockchain node. ) or redundancy (such as When there are contradictions or redundancies, you need to return to the strategy definition interface to modify them; otherwise, assign a unique identifier to the strategy and store the strategy and the identifier together in the blockchain ledger for subsequent ABE encrypted calls.

[0104] S402. Using the dynamic encryption key generated in S3, and combining it with an encryption algorithm that matches the modality type, perform encryption operations on the original data to generate the first ciphertext.

[0105] In some implementations, the process of generating the first ciphertext may include: Based on the correspondence between "modal type → encryption algorithm" in the S202 policy mapping table, select the appropriate algorithm; then generate the necessary auxiliary parameters for the selected algorithm, and the parameter generation must meet the randomness requirement; finally, encrypt the data according to the encryption algorithm, auxiliary parameters and dynamic encryption key to obtain the first ciphertext.

[0106] S403, based on the attribute-based encryption algorithm, uses the blockchain's trusted public key to encrypt the dynamic key, embeds the access policy of S401, and generates a second ciphertext.

[0107] The second ciphertext is the result of encryption using the dynamic encryption key. Attribute-Based Encryption (ABE) is then used to bind the key to the access policy. Therefore, only users whose attribute set meets the policy can decrypt the second ciphertext to obtain the dynamic key, and then decrypt the first ciphertext.

[0108] In some implementations, the process of generating the second ciphertext includes: First, based on the Ciphertext Policy Attribute Base Encryption (CP-ABE) algorithm, the following initialization is performed: Step 1: Choose the bilinear group – Let , Let g be a multiplicative cyclic group of order p, and let g be a prime number p. generator, For bilinear mapping rules, Operations in the mapping to .

[0109] Step 2: Generate system parameters – randomly select α, ( (a group of non-zero integers modulo p) to compute the public key Master private key The public key (PK) is deployed to the blockchain network, while the master private key (MSK) is kept by a trusted institution within the blockchain consortium to prevent leakage.

[0110] Next, ABE encryption requires the use of a trusted key stored on the blockchain and the execution of encryption using the public key key. Then, ABE encryption with embedded access policy is used to generate a second ciphertext: taking CP-ABE as an example, the dynamic key is encrypted. The core formula and steps are as follows: Step 1: Random selection (Encrypted random number), calculation We obtained the first part of the ciphertext, which is related to the master private key.

[0111] Step 2: Configure the access policy for S401 Transform it into a "Linear Secret Sharing Scheme (LSSS) matrix" M, and assign attributes to each row of the matrix, such as "M=IMG" for the first row and "R=DOC" for the second row.

[0112] Step 3: Random selection (k is the number of columns in the matrix), let the secret vector be... Calculate each row of the matrix corresponding share , then calculate This yields the ciphertext portion bound to the attribute.

[0113] Step 4: Calculate the encrypted portion of the dynamic key – Convert to elements in (Through hash mapping), calculate ;in, Represents a dynamic encryption key After hash mapping, the corresponding group element in the bilinear group G2 of the attribute-based cryptosystem serves to convert the binary dynamic key into a mathematical form that conforms to the requirements of bilinear mapping operations. This represents the ciphertext encrypted with a dynamic key that embeds the access policy. The ciphertext contains the group element KG corresponding to the dynamic key and the bilinear mapping term. Only when the user attribute set satisfies the preset access policy can the private key operation be used to cancel the access. Item, from Restore This allows us to deduce the original dynamic key. This enables fine-grained encryption protection using dynamic keys.

[0114] Step 5: Pack the second encrypted message – Combined into the second ciphertext The formula is: Where n is the number of rows in the LSSS matrix, representing the number of attributes. Used for quickly querying the corresponding strategy logic expression during decryption.

[0115] Based on the above technical solution, S401 constructs a fine-grained access policy strongly bound to the modality type through attribute classification, logical modeling, and consistency verification; S402 matches an efficient symmetric encryption algorithm according to the modality type and combines it with a dynamic key to achieve secure encryption of the original data, balancing encryption efficiency and security; S403 binds the dynamic key to the access policy based on the ABE algorithm, and ensures that only users who meet the attributes can obtain the key through bilinear mapping and the blockchain's trusted public key. These steps together constitute a two-layer protection system, where the first ciphertext protects the confidentiality of the original data, and the second ciphertext protects the security of the key, jointly solving the core problems of the disconnect between key and policy and the coarse granularity of access control in existing technologies.

[0116] In one possible implementation of the embodiments of this application, combined with Figure 1 ,like Figure 4 As shown, the above S5 specifically includes the following S501 to S503: S501. Perform fragmentation processing on the first ciphertext and the second ciphertext, generate a unique identifier, dynamically configure a copy based on the data security level, and upload it to the distributed storage system.

[0117] The first and second ciphertexts need to be processed separately. The purpose of sharding is to reduce the storage pressure on a single node and improve the efficiency of parallel uploads. The replica configuration is to cope with node failures and ensure data availability.

[0118] In some implementations, the sharding, replica configuration, and upload process includes the following steps: 1. Definition of Ciphertext Fragmentation Rules: Based on the amount of encrypted data and the storage capacity of the distributed storage nodes, the shard size is set, and the number of shards is calculated using the following formula: Where N is the number of fragments. This indicates rounding up, where S is the original size of the ciphertext. This refers to the size of a single fragment. Fragmentation employs sequential fragmentation and boundary checks: the ciphertext binary stream is cut sequentially, and a 4-byte checksum is added to the end of each fragment, using the following formula: This is used to verify the integrity of the fragmented data after uploading.

[0119] 2. Generation of fragment unique identifiers (IDs): Each shard is assigned a globally unique identifier, using a combination of "UUID + shard hash", with the formula as follows: ;in, A randomly generated 128-bit universally unique identifier. For fragmented data, Generate timestamps for the fragments. Calculate the hash value of the sharded data and the timestamp. Final shard identifier. A 100-character string consisting of a 36-bit UUID and a 64-bit hash.

[0120] 3. Dynamic configuration of replica factors and parallel upload: The replication factor R is the number of redundant replicas of a shard in a distributed storage system. It is dynamically adjusted according to the data security level (L) defined in S401, and the formula is as follows: .

[0121] During upload, a consistent hashing algorithm is used to allocate shards to storage nodes: Map each node IP to a 32-bit hash ring, and select the hash ring that corresponds to... The nearest R nodes act as storage nodes, uploading the sharded data in parallel; after the upload is complete, the nodes return the shard storage address for subsequent root hash calculation.

[0122] S502. Based on the hash tree structure, the unique identifiers of the fragment storage addresses are hierarchically aggregated to generate the root hash, which serves as the core pointer for data addressing and integrity verification.

[0123] Among them, root hash It uses a hash tree to analyze all shards. The unique topological root node value obtained by performing hierarchical hashing has two core functions: first, it serves as a global addressing pointer for distributed storage data; second, it serves as a basis for data integrity verification.

[0124] In some implementations, the steps for generating the root hash include: 1. Hash tree initialization: generation of leaf nodes First, all ShardIDs generated by S501 are used as leaf nodes of the hash tree. A SHA-256 hash value is calculated for each ShardID, and this hash value is used as the hash value of the leaf node. The formula is as follows: ;in, Let N be the 256-bit hash value of the i-th leaf node, and N be the total number of shards.

[0125] 2. Hash tree hierarchical aggregation: parent node calculation The hash value of the parent node is calculated using a "pairwise combination and upward aggregation" method, with the following rules: If the number of nodes in the current level is even (K is even): group the nodes in pairs sequentially, and perform "concatenation + SHA-256 hash" on the hash values ​​of the two nodes in each group to obtain the hash value of the parent node. The formula is: ;in, , The hash values ​​of the two child nodes at the current level. This indicates binary concatenation. Let be the hash value of the j-th parent node.

[0126] If the number of nodes in the current level is odd (K is odd): copy the hash value of the last node, then group and calculate according to the even number rule, using the following formula: .

[0127] 3. Root node generation and verification: Repeat the hierarchical aggregation process until a unique root node hash value is obtained, which is the root hash. After generation, the correctness is verified by reverse verification: starting from the root hash, the relationship between the hash values ​​of child nodes and the hash values ​​of parent nodes is compared layer by layer downwards (e.g., the hash of the root node should be equal to the SHA-256 value of the concatenation of the hashes of its two child nodes). If all levels of verification are consistent, it means that the root hash was generated correctly; if they are inconsistent, the leaf nodes and level aggregations need to be recalculated to avoid hash calculation errors that may cause subsequent addressing failures.

[0128] For example, suppose we generate the root hash for the ShardID of 24 data shards: Leaf nodes: Calculate 24 ; First-level parent nodes: 24 → 12, each .

[0129] Second-level parent nodes: 12 → 6, calculated similarly.

[0130] Third-level parent nodes: 6 → 3 (odd number), copy the third node to get 2 parent nodes, and calculate 2 hash values.

[0131] Root node: 2 → 1, calculation Then, reverse the verification of all levels to confirm that the root hash is correct.

[0132] S503. Package the root hash and the second ciphertext metadata into the blockchain distributed ledger, and start the node failure detection and data migration mechanism to complete the encrypted evidence storage.

[0133] The core of blockchain notarization is to write the root hash and second ciphertext metadata into an immutable ledger; fault handling is achieved through node status monitoring and replica migration to ensure that the distributed storage data is not lost.

[0134] In some implementations, evidence preservation and fault handling include the following steps: 1. Construction of the evidence storage package and invocation of smart contracts: First, the root hash, second ciphertext metadata (C2Meta), timestamp (TS), and custodian public key (PK) are packaged into a "custodian transaction package". Among them, C2Meta contains the ShardID list of the second ciphertext, the policy identifier (PolicyID), and the encryption algorithm type (such as CP-ABE).

[0135] Then, the encrypted evidence storage smart contract on the blockchain is invoked to initiate the evidence storage transaction; after the transaction is verified by the blockchain consensus node, it is recorded in the distributed ledger, generating a unique transaction ID (txid), and the evidence storage is completed.

[0136] 2. Distributed storage node fault detection: A dual mechanism of "heartbeat detection + data reachability verification" is used to monitor node status. Each storage node sends a heartbeat packet (containing node IP, load rate, and shard storage status) to the node management center every 30 seconds. If no heartbeat packet is received for 3 consecutive times or within 90 seconds, the node is marked as "suspected failure". Then, a data read request is sent to the shards stored on the suspected failure node. If there is no response within 5 seconds or the CRC32 verification of the read data fails, the node failure is confirmed, and all shards on that node are marked as "pending migration".

[0137] 3. Fault data migration mechanism: After confirming a node failure, replicas are reallocated according to the replica factor rules, as follows: Step 1: Query the shard column stored on the faulty node to find valid replicas of these shards on other nodes.

[0138] Step 2: Calculate the new storage nodes, such as allocating node6 to ShardID1 and node7 to ShardID3.

[0139] Step 3: Read the sharded data from the valid replica nodes, migrate it to the new nodes in parallel, and update the sharded storage address mapping table.

[0140] Step 4: Recalculate the root hash and update the hash value of the shard address mapping table through a smart contract to ensure addressing consistency.

[0141] It should be noted that the root hash of blockchain evidence storage cannot be modified (the ledger cannot be tampered with), but the shard storage address can be modified through the address update function of the smart contract to avoid addressing failure after a fault migration; at the same time, evidence storage transactions must include the signature of the custodian to prevent malicious nodes from forging evidence storage data.

[0142] Based on the above technical solutions, S501 reduces the pressure on a single node of distributed storage through dynamic sharding and hierarchical replication operations, and balances availability and storage costs by adapting the number of replicas to the security level. S502, based on the root hash generated by the hash tree, achieves globally unique identification and integrity verification of multi-shard data—verifying only the root hash quickly confirms whether all shards have been tampered with, significantly improving data verification efficiency. S503, through blockchain notarization and fault migration, ensures traceability and non-repudiation of notarized information by leveraging the immutability of the ledger, and guarantees continuous data availability through real-time fault handling. In summary, step S5 collaboratively constructs a dual protection system of distributed storage and blockchain notarization, providing a highly available, highly secure, and traceable storage and notarization solution for multimodal encrypted data.

[0143] When using integrated units, Figure 5 A possible structural diagram of a blockchain-based data security encryption device (referred to as a blockchain-based data security encryption device 50) involved in the above embodiments is shown. The blockchain-based data security encryption device 50 includes a processing unit 501 and a communication unit 502, and may also include a storage unit 503. Figure 5 The structural diagram shown can be used to illustrate the structure of a blockchain-based data security encryption device involved in the above embodiments.

[0144] when Figure 5 The schematic diagram shown illustrates the structure of a blockchain-based data security encryption device involved in the above embodiments. The processing unit 501 is used to control and manage the operation of the blockchain-based data security encryption device, the communication unit 502 is used for the blockchain-based data security encryption device to communicate with other devices, and the storage unit 503 is used to store the program code and data of the blockchain-based data security encryption device.

[0145] For example, communication unit 502 is used to upload the identified modal type and extracted modal features to the blockchain network; to receive cross-modal encryption strategy trigger signals sent by smart contracts in the blockchain network; to communicate with the distributed storage system, upload fragmented data of the first ciphertext and the second ciphertext, and receive feedback information related to the storage address; and to package the root hash and the metadata of the second ciphertext and send them to the blockchain distributed ledger through smart contract transactions to complete the communication interaction related to evidence storage.

[0146] Processing unit 501 is used to acquire the original data to be encrypted, identify the modality type of the original data through an artificial intelligence model, and extract the modality features of the original data; to match and trigger the cross-modal encryption strategy corresponding to the modality type according to the preset rules on the blockchain network; to convert the original data or modality features into transformed data of the target modality according to the cross-modal encryption strategy, perform cryptographic hash operation on the transformed data, and generate a dynamic encryption key; to encrypt the original data using the dynamic encryption key and an encryption algorithm to obtain the first ciphertext, and bind the dynamic encryption key with the access policy containing the modality type based on the attribute-based encryption algorithm to generate the second ciphertext; to perform fragmentation processing on the first and second ciphertexts, generate unique identifiers, set a replication factor, coordinate the uploading of fragmented data to the distributed storage system, and also detect node failures in the distributed storage system and trigger a data migration mechanism.

[0147] In one possible implementation, the processing unit 501 is further configured to construct a modality classification model, input the pre-processed raw data into the pre-trained modality classification model, calculate the probability distribution of the raw data belonging to each modality type through a fully connected layer and a softmax activation function, select the modality type with the highest probability value as the recognition result and output the type identifier; it is also configured to define an attribute-based access policy logical expression, which includes modality type attributes, user role attributes and data security level, encrypt the dynamic encryption key using the public key of the attribute-based encryption system, generate attribute-based ciphertext, associate the attribute-based ciphertext with the access policy identifier, store it and record it in the blockchain distributed ledger.

[0148] In one possible implementation, the communication unit 502 is further configured to receive the dynamic encryption key returned by the cross-modal conversion service and transmit it to the processing unit to support subsequent encryption operations; it is also configured to communicate with other nodes in the distributed storage system after node failure detection to exchange information related to copy reallocation and data migration. The processing unit 501 is further configured to verify the converted data generated by the cross-modal conversion to ensure data integrity before performing cryptographic hash operations; it is also configured to perform hierarchical aggregation of the unique identifiers of all fragmented data based on a hash tree structure to generate a root hash as a data addressing pointer.

[0149] This application also provides a hardware structure diagram of a blockchain-based data security encryption device (referred to as a blockchain-based data security encryption device 60), see [link to diagram]. Figure 6 The blockchain-based data security encryption device 60 includes a processor 601, and optionally, a memory 602 connected to the processor 601.

[0150] In the first possible implementation, see Figure 6A blockchain-based data security encryption device 60 further includes a transceiver 603. The processor 601, memory 602, and transceiver 603 are connected via a bus. The transceiver 603 is used to communicate with other devices or communication networks. Optionally, the transceiver 603 may include a transmitter and a receiver. The device in the transceiver 603 that implements the receiving function can be considered as a receiver, which is used to perform the receiving steps in the embodiments of this application. The device in the transceiver 603 that implements the transmitting function can be considered as a transmitter, which is used to perform the transmitting steps in the embodiments of this application.

[0151] Based on the first possible implementation method Figure 6 The structural diagram shown illustrates the structure of a blockchain-based data security encryption device involved in the above embodiments. Figure 6 This can also be illustrated as a system chip in a blockchain-based data security encryption device. In this case, the actions performed by the aforementioned blockchain-based data security encryption device can be implemented by this system chip; the specific actions performed are described above and will not be repeated here.

[0152] In implementation, each step of the method provided in this embodiment can be completed by integrated logic circuits in the processor hardware or by instructions in software. The steps of the method disclosed in the embodiments of this application can be directly manifested as being executed by a hardware processor, or being executed by a combination of hardware and software modules in the processor.

[0153] Although this application has been described in conjunction with specific features and embodiments, it is obvious that various modifications and combinations can be made thereto without departing from the spirit and scope of this application. Accordingly, this specification and drawings are merely illustrative descriptions of the application as defined by the appended claims, and are considered to cover any and all modifications, variations, combinations, or equivalents within the scope of this application. Clearly, those skilled in the art can make various alterations and modifications to this application without departing from the spirit and scope of this application. Thus, if such modifications and variations of this application fall within the scope of the claims of this application and their equivalents, this application is also intended to include such modifications and variations.

Claims

1. A data security encryption method based on blockchain, characterized in that, include: Obtain the original data to be encrypted, identify the modal type of the original data through an artificial intelligence model, and extract the modal features of the original data; The modality type and modality features are uploaded to the blockchain network, and a cross-modal encryption strategy corresponding to the modality type is matched and triggered according to the preset rules deployed on the blockchain network. According to the cross-modal encryption strategy, the original data or the modal features are converted into transformed data of the target modality, and the transformed data is subjected to cryptographic hashing to generate a dynamic encryption key; Using the dynamic encryption key, the original data is encrypted using an encryption algorithm to obtain the first ciphertext. Then, based on the attribute-based encryption algorithm, the dynamic encryption key is bound to the access policy containing the modality type for encryption to generate the second ciphertext. The first and second ciphertexts are stored in a distributed storage system, and the storage address hash is recorded together with the second ciphertext in the distributed ledger of the blockchain network to complete the encrypted evidence storage.

2. The data security encryption method based on blockchain according to claim 1, characterized in that, The process of identifying the modality type of the raw data using an artificial intelligence model includes: An artificial intelligence model is constructed based on deep learning algorithms to obtain a modality classification model; The raw data is input into a pre-trained modality classification model, and the probability distribution of the raw data belonging to each modality type is calculated through the fully connected layer and softmax activation function of the model; where modality types include image modality, text modality, audio modality and video modality; Select the modality with the highest probability value as the recognition result and output the type identifier of the recognition result.

3. The data security encryption method based on blockchain according to claim 1, characterized in that, The extraction of modal features from the raw data includes: For image modalities, key points can be detected and descriptors generated using the scale-invariant feature transform algorithm, or the feature vector output by the bottleneck layer of a neural network model can be used to obtain image modal features. For text modalities, a word embedding model is used to convert the text into word vectors, and document-level feature representations are generated through max pooling or average pooling to obtain text modal features; For audio data, the Mel frequency cepstral coefficient sequence is extracted, and the mean, variance, and dynamic range of the Mel frequency cepstral coefficient sequence are calculated to obtain the audio modal features.

4. The data security encryption method based on blockchain according to claim 1, characterized in that, The step of matching and triggering a cross-modal encryption strategy corresponding to the modality type according to preset rules deployed on the blockchain network includes: A policy mapping table is predefined in the smart contract; the policy mapping table is indexed by modality type and associated with target modality, encryption algorithm parameters and conversion rules. Once the smart contract receives the uploaded modality type and modality characteristics, it queries the policy mapping table for matching and triggers the cross-modal encryption policy process based on the matching result.

5. A data security encryption method based on blockchain according to claim 4, characterized in that, The predefined strategy mapping table includes the following transformation rules: When the modality type is image, the policy mapping table specifies the target modality as text, the encryption algorithm parameters are AES-256-CBC mode, and the conversion rule is to use the contrastive language-image pre-trained CLIP model to convert the image content into descriptive text and use the text hash value as the dynamic encryption key. When the modality type is text, the policy mapping table specifies the target modality as audio, the encryption algorithm parameters are ChaCha20-Poly1305 algorithm, the conversion rule is to use the text-to-speech model to generate the corresponding audio waveform, and then extract the spectral features of the waveform data to generate a dynamic encryption key. When the modality type is audio, the policy mapping table specifies the target modality as image, the encryption algorithm parameters are SM4-CTR mode, the conversion rule is to convert the audio signal into a spectrogram, use a convolutional neural network to extract spectral features to generate a visualization image, extract feature vectors from the generated visualization image, and then calculate the hash value through a cryptographic hash function to generate a dynamic encryption key. When the modality type is video, the policy mapping table supports multi-target modality conversion, including conversion to keyframe sequence images or conversion to audio streams. The encryption algorithm is dynamically selected according to the amount of data. The conversion rules use time slicing technology combined with 3D convolutional neural networks to extract features, and the extracted multi-dimensional feature vectors are normalized. Then, the SHA-256 algorithm is applied to calculate the hash value and generate a dynamic encryption key. When the data contains multiple modalities, the policy mapping table initiates a cascaded transformation process, first separating the data of each modality, then performing the corresponding cross-modal transformations, and finally generating a dynamic encryption key through feature fusion technology.

6. A data security encryption method based on blockchain according to claim 4, characterized in that, The process of triggering a cross-modal encryption strategy based on the matching result includes: The smart contract sends a conversion request to a cross-modal conversion service deployed on edge nodes or in the cloud. The request includes modal characteristics, target modal identifier, and cryptographic algorithm parameters. The cross-modal conversion service invokes an artificial intelligence model based on the conversion request to convert the original data or modal features into target modal data; Perform cryptographic hashing on the transformed data to generate a dynamic encryption key, and return the key to the smart contract; The smart contract verifies the integrity of the key generation process and triggers subsequent encryption operations.

7. A data security encryption method based on blockchain according to claim 1, characterized in that, The step of binding and encrypting the dynamic encryption key with an access policy containing the modality type includes: The access policy is defined as an attribute-based logical expression; the logical expression includes modal type attribute, user role attribute, and data security level. The dynamic encryption key is encrypted using the public key of an attribute-based encryption system; wherein, the encryption process of the attribute-based encryption system is based on bilinear mapping pair calculation to generate attribute-based ciphertext, and the attribute-based ciphertext is embedded with an access policy, and only users whose attribute set satisfies the access policy can decrypt it; The attribute base ciphertext is associated with the access policy identifier and stored, and then recorded in the blockchain distributed ledger.

8. A data security encryption method based on blockchain according to claim 1, characterized in that, The step of storing the first ciphertext and the second ciphertext in a distributed storage system includes: The first and second ciphertexts are fragmented separately, and a unique identifier is generated for each fragmented data. The fragmented data is uploaded in parallel to the nodes of the distributed storage system, and a replication factor is set. The replication factor represents the number of copies of the data fragment that are redundantly stored in the distributed storage system, and is dynamically set according to the data security level. The distributed storage system returns the root hash of the storage structure; wherein, the root hash serves as a data addressing pointer; The root hash and the metadata of the second ciphertext are packaged together and recorded into the blockchain distributed ledger through a smart contract transaction to complete the evidence storage; When a node failure is detected, a data migration mechanism is triggered to reallocate replicas to other nodes.

9. A data security encryption method based on blockchain according to claim 8, characterized in that, The root hash represents the topological root node hash value obtained by hierarchically aggregating the unique identifiers of all fragmented data through a hash tree structure, and the generation process includes: Use the unique identifier of each data shard as the leaf node of the hash tree, and calculate the hash value of the unique identifier; Combine the leaf nodes in pairs, concatenate the hash values ​​of each pair of nodes, and then calculate the hash value again to obtain the hash value of the parent node. If the number of nodes after combination is odd, then the remaining single leaf node is copied and used to participate in the calculation of the combination and the hash value of the parent node; The process of calculating the combined and parent node hash values ​​is executed recursively and aggregated upwards layer by layer to obtain a unique root node hash value, which is then marked as the root hash.

10. A data security encryption device based on blockchain, characterized in that, include: Communication unit and processing unit; wherein, The communication unit is used to acquire the original data to be encrypted and transmit the original data to the processing unit; and, The modal types and modal features generated by the processing unit are uploaded to the blockchain network; Receive trigger instructions for cross-modal encryption policies from the blockchain network; The first and second ciphertexts generated by the processing unit are stored in a distributed storage system. The storage address hash is recorded together with the second ciphertext in the distributed ledger of the blockchain network; The processing unit is configured to identify the modal type of the raw data using a built-in artificial intelligence model and extract the modal features of the raw data; and, According to the preset rules received from the blockchain network, the cross-modal encryption strategy corresponding to the modality type is matched and triggered. Based on the cross-modal encryption strategy, the original data or modal features are converted into transformed data of the target modality; Perform cryptographic hashing on the transformed data to generate a dynamic encryption key; Using a dynamic encryption key and an encryption algorithm, the original data is encrypted to obtain the first ciphertext; Based on the attribute-based encryption algorithm, the dynamic encryption key is bound to the access policy containing modal types for encryption to generate a second ciphertext.

Images