Data sharing method

Abstract

This application relates to a data sharing method. In this method, a first security domain responds to a user's data access request by performing cross-domain security verification on the user. If the verification passes, the first security domain sends decryption information for the target data file to the user, instructing them to decrypt the encrypted data in the target data file to obtain the target data file. The user in this method is a user within a second security domain. The first and second security domains are different security domains. This method enables cross-domain data sharing while ensuring security and privacy during the sharing process, and also allows for tracking and tracing.

Description

Technical Field

[0001] This application relates to the field of data processing, and in particular to a data sharing method. Background Technology

[0002] Data sharing can provide reliable and trustworthy data support for the analysis and visualization of current power grid problems, the intelligent preparation of planning schemes, and can also accelerate the incubation and implementation of data-driven external service products.

[0003] When sharing data, the relevant technologies often employ a centralized approach, which involves using an intermediary proxy to send all data to a unified sharing platform. This approach requires the intermediary proxy to be absolutely trustworthy.

[0004] Furthermore, the centralized approach to data sharing in related technologies can lead to insecurity and privacy breaches during the data sharing process. Summary of the Invention

[0005] Therefore, it is necessary to provide a data sharing method that can improve the security of the data sharing process and effectively prevent privacy leaks, addressing the aforementioned technical problems.

[0006] In a first aspect, embodiments of this application provide a data sharing method, the method comprising:

[0007] The first security domain responds to the data access request from the accessing user by performing cross-domain security authentication on the accessing user; the data access request is used to request access to the target data file stored in the first security domain; the accessing user is a user in the second security domain; the first security domain and the second security domain are different security domains;

[0008] If the cross-domain security verification of the accessing user is successful, the decryption information of the target data file is sent to the accessing user; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0009] In one embodiment, cross-domain security authentication of the accessing user includes:

[0010] The first security domain obtains the cross-domain access credentials and data access requests of the accessing user;

[0011] If the cross-domain authentication of the accessing user is successful, obtain the accessing user's attribute private key;

[0012] If the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, then the decryption information of the target data file is sent to the accessing user; the decryption information includes at least: the encryption key, the hash value of the target data file, the accessing user's attribute private key, and the public parameters of the first security domain.

[0013] In one embodiment, the first security domain obtains the cross-domain access credentials and data access request of the accessing user, including:

[0014] The identity authentication server in the first security domain authenticates the accessing user. After successful authentication, it sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain consortium blockchain to generate cross-domain access credentials and routing information for the accessing user, and then sends the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials.

[0015] The access control center of the first security domain receives cross-domain access credentials and data access requests uploaded by users through the communication channel; the communication channel is established by the users based on routing information.

[0016] In one embodiment, before obtaining the private key of the accessing user's attributes, the method further includes:

[0017] Based on the data access request of the accessing user, the access control center of the first security domain searches for the accessing user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain.

[0018] Compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained from the first security domain;

[0019] If the comparison results are consistent, the cross-domain verification of the accessing user is confirmed to be successful.

[0020] In one embodiment, obtaining the private key of the accessing user's attributes includes:

[0021] The key management center of the first security domain obtains the cross-domain attributes of the accessing user;

[0022] The key management center of the first security domain generates the access user's attribute private key based on the access user's cross-domain attributes and the master key preset by the first security domain.

[0023] In one embodiment, the method further includes:

[0024] The access control center of the first security domain generates a search keyword trap based on the access user's attribute private key and search keywords;

[0025] The access control center of the first security domain matches search keywords based on search keyword traps and shared ciphertext in the first security domain;

[0026] If the matching result meets the preset conditions, the access user's attribute private key and the shared ciphertext of the target data file in the first security domain are determined.

[0027] In one embodiment, the process of accessing a user to decrypt encrypted data in a target data file includes:

[0028] When the hash value of the target data file matches the hash value pre-stored in the local consortium blockchain in the first security domain, the accessing user decrypts the encrypted data file of the target data file according to the decrypted encryption key to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters, attribute private key and encryption key of the first security domain.

[0029] In one embodiment, the process of storing the target data file in the first security domain includes:

[0030] The first security domain responds to data storage requests by storing the encrypted data carried in the data storage request; the encrypted data is generated by the storage user based on the data file to be stored.

[0031] In one embodiment, the encrypted data includes at least the access structure of the data file to be stored, the ciphertext of the keyword, the encrypted data file, the hash value of the encrypted data file, and the signature information of the user storing the data.

[0032] The encrypted data is the data obtained by the storage user through encryption operations; these encryption operations include:

[0033] Generate file keywords and access structure based on the data file to be stored;

[0034] The keyword ciphertext is obtained based on the public parameters of the first security domain, the file keywords, and the access structure;

[0035] Based on the data file to be stored and the preset key, generate an encrypted data file and its hash value.

[0036] The encryption key is obtained based on the preset key, public parameters, and access structure.

[0037] In one embodiment, storing the encrypted data carried in the data storage request includes:

[0038] The first security domain sends encrypted data files to its shared cloud platform for storage, and sends encrypted data to the local consortium blockchain of the first security domain in a preset format.

[0039] In this case, after the smart contract is triggered, the consortium blockchain in the first security domain stores the encrypted data file to the local consortium blockchain in the first security domain.

[0040] Secondly, embodiments of this application provide a data sharing device, the device comprising:

[0041] The response module is used to respond to the data access request of the accessing user and perform cross-domain security verification on the accessing user; the data access request is used to request access to the target data file stored in the first security domain; the accessing user is a user in the second security domain; the first security domain and the second security domain are different security domains;

[0042] The decryption module is used to send decryption information of the target data file to the accessing user if the cross-domain security authentication of the accessing user is successful. The decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0043] Thirdly, embodiments of this application provide a computer device including a memory and a processor. The memory stores a computer program, and the processor executes the computer program to implement the steps of the method provided in any of the embodiments of the first aspect described above.

[0044] Fourthly, embodiments of this application provide a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the steps of the method provided in any of the embodiments of the first aspect described above.

[0045] This application provides a data sharing method in which a first security domain responds to a user's data access request by performing cross-domain security verification on the user. If the user's cross-domain security verification is successful, decryption information for the target data file is sent to the user. This decryption information instructs the user to decrypt the encrypted data in the target data file to obtain the target data file. In this method, the first security domain responds to a user's data access request in a second security domain. Since the first and second security domains are different security domains, cross-domain data sharing is possible. Furthermore, the first security domain performs cross-domain verification on the data access request, ensuring the secure and trustworthy identity of data sharers across different security domains. Only after the user's cross-domain security verification is successful is the decryption information for the target data file sent to the user, allowing the user to decrypt and obtain the target data, further ensuring the security of the data sharing process. Finally, during the data sharing process, the target data file is encrypted during storage, and decryption is required to access the data, thus achieving security during data sharing and effectively preventing data privacy leaks. Attached Figure Description

[0046] Figure 1a This is an application environment diagram of a data sharing method in one embodiment;

[0047] Figure 1b This is a schematic diagram of the structure of a data sharing method in one embodiment;

[0048] Figure 2This is a flowchart illustrating a data sharing method in one embodiment;

[0049] Figure 3 This is a schematic diagram of the data sharing method in another embodiment;

[0050] Figure 4 This is a schematic diagram of the data sharing method in another embodiment;

[0051] Figure 5 This is a flowchart illustrating a data sharing method in another embodiment;

[0052] Figure 6 This is a flowchart illustrating a data sharing method in another embodiment;

[0053] Figure 7 This is a schematic diagram of the data sharing method in another embodiment;

[0054] Figure 8 This is a schematic diagram of the data sharing method in another embodiment;

[0055] Figure 9 This is a flowchart illustrating a data sharing method in another embodiment;

[0056] Figure 10 This is a flowchart illustrating a data sharing method in another embodiment;

[0057] Figure 11 This is a flowchart illustrating a data sharing method in another embodiment;

[0058] Figure 12 This is a flowchart illustrating a data sharing method in another embodiment;

[0059] Figure 13 This is a flowchart illustrating a data sharing method in another embodiment;

[0060] Figure 14 This is a schematic diagram of the data sharing method in another embodiment;

[0061] Figure 15 This is a flowchart illustrating a data sharing method in another embodiment;

[0062] Figure 16 This is a flowchart illustrating a data sharing method in another embodiment;

[0063] Figure 17 This is a structural block diagram of a data sharing device in one embodiment;

[0064] Figure 18 This is an internal structural diagram of a computer device in one embodiment. Detailed Implementation

[0065] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the scope of this application.

[0066] The data sharing method provided in this application can be applied to, for example... Figure 1a The application environment shown. Among them, Figure 1a Both the first security domain and the second security domain include at least one device, or at least one type of device; and Figure 1a The first security domain and the second security domain can be deployed on computer devices or terminal devices in any field. These computer devices and terminal devices include, but are not limited to, various personal computers, laptops, tablets, wearable devices, etc. The embodiments of this application do not limit the types of the first security domain and the second security domain.

[0067] Based on the above Figure 1a The first security domain can send an access request to the second security domain, meaning a user in the first security domain is requesting access to the second security domain; conversely, the second security domain can also send an access request to the first security domain, meaning a user in the second security domain is requesting access to the first security domain. The first and second security domains are used merely to distinguish between different security domains and are not used to limit other information.

[0068] This application provides a data sharing method that can prevent data leakage during the sharing process and ensure the security and reliability of the data sharing process.

[0069] The technical solutions of this application and how they solve the aforementioned technical problems will be described in detail below through embodiments and in conjunction with the accompanying drawings. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. To make the objectives, technical solutions, and advantages of the embodiments of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments.

[0070] Before providing a detailed description of the embodiments of this application, the first security domain and the accessing user of the embodiments of this application will be described. Please refer to... Figure 1b As shown, security domain A and security domain B represent two different security domains in the data sharing process. However, the access request objects in the data sharing process are different, and the specific references of the first and second security domains are also different. For example, Figure 1b In this embodiment, when the access request object in the data sharing process is security domain A, the first security domain refers to security domain A, the second security domain refers to security domain B, and the accessing user refers to the accessing user in security domain B. Conversely, when the object in the data sharing process is security domain B, which is the domain for data sharing, the first security domain refers to security domain B, the second security domain refers to security domain A, and the accessing user refers to the accessing user in security domain A.

[0071] It should also be noted that when a user sends an access request to the first security domain, both data access and data storage processes are involved. Whether security domain A shares data with security domain B or vice versa, the methods used for data access and storage are identical. Specifically, before a user in security domain A sends an access request to security domain B, security domain B first needs to store the data to be shared. Then, the user in security domain A accesses the stored data in security domain B through the access method. Conversely, before a user in security domain B sends an access request to security domain A, security domain A first needs to store the data to be shared. Then, the user in security domain B accesses the stored data in security domain A through the access method.

[0072] The data access process will now be described using specific examples.

[0073] In one embodiment, such as Figure 2 As shown, a data sharing method is provided. This embodiment relates to the specific process by which a first security domain, in response to a user's data access request, performs cross-domain security verification on the user. If the user's cross-domain security verification passes, the first security domain sends decryption information of the target data file to the user. This embodiment includes the following steps:

[0074] S201, the first security domain responds to the data access request of the accessing user and performs cross-domain security authentication on the accessing user; the data access request is used to request access to the target data file stored in the first security domain; the accessing user is a user in the second security domain; the first security domain and the second security domain are different security domains.

[0075] A security domain is a collection of logical or physical assets with the same security requirements. The principle of security domain division is to group all computers with the same security level or requirements into the same network segment, and to implement access control at the network segment boundaries. Access between different security domains needs to be controlled through policy settings. Accessing users are those who need to make data access requests; they exist within a security domain and access data in other security domains through these users.

[0076] The first security domain responds to the user's data access request. The data access request can be data information that the user needs to access from the first security domain, or it can be the user's identity information.

[0077] When the first security domain receives a data access request from a user, it first performs cross-domain security verification on the user to verify whether the user's identity is trustworthy.

[0078] The target data file is the data that the user needs to access from the first security domain. The target data file can be in the form of at least one message or file. In practical applications, the type of target data file is not limited.

[0079] In one embodiment, the first security domain responds to a user's data access request by sending a data access request message to the first security domain. The first security domain can directly receive the user's data access request message. The message can be sent via POST or GET.

[0080] Optionally, the first security domain may perform cross-domain verification for accessing users by sending the received data access request to the cross-domain consortium blockchain, which then checks whether the data access request information is correct.

[0081] As mentioned earlier, the specific references to the first and second security domains differ depending on the access request object during the data sharing process. Figure 3 In this scenario, the first security domain refers to security domain A, the second security domain refers to security domain B, and the accessing user refers to the user in security domain B. Based on this scenario, after receiving a data access request from the user in security domain B, security domain A will perform cross-domain security verification on the user in security domain B.

[0082] And in Figure 4 In this scenario, the first security domain refers to security domain B, the second security domain refers to security domain A, and the accessing user refers to the user accessing the security domain A. Based on this scenario, after receiving a data access request from the user accessing the security domain A, security domain B will perform cross-domain security verification on the user accessing the security domain B.

[0083] A cross-domain consortium blockchain, also known as a cross-domain consortium blockchain, can store the behavior of users' cross-domain data access requests, digital identity certificates and certificate authorization records of each security domain, and is jointly maintained by the identity authentication service nodes and access control centers of each security domain.

[0084] S202, if the cross-domain security verification of the accessing user is successful, decryption information of the target data file is sent to the accessing user; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0085] In the above embodiment, the first security domain performs cross-domain security verification on the data access request. If the cross-domain security verification of the accessing user is successful, the first security domain will send the decryption information of the target data file to the accessing user. The accessing user can decrypt the encrypted data of the target data file according to the decryption information to obtain the target encrypted data requested by the accessing user.

[0086] Optionally, the first security domain sends the decryption information of the target data file to the accessing user, which can be sent via GET or POST.

[0087] In one embodiment, the decryption information can instruct the accessing user to decrypt the encrypted data of the target data file. The decryption method can be to decrypt the encrypted data of the target data file according to a preset decryption algorithm to obtain the target data file.

[0088] In another embodiment, the decryption information can instruct the user to decrypt the encrypted data of the target data file. The decryption can also be performed using a preset neural network model. The decryption information and the encrypted data of the target data file are used as inputs to the neural network model. After training the neural network model, the target data file is finally output.

[0089] In another embodiment, the decryption information can instruct the user to decrypt the encrypted data of the target data file. The decryption method can also be a pre-configured decryption program, which takes the decryption information and the encrypted data of the target data file as input data to the decryption program. After running the pre-configured decryption program, the target data file is obtained.

[0090] See above for further details. Figure 3 and Figure 4 The scene shown.

[0091] exist Figure 3 In this scenario, if the cross-domain security verification of the accessing user is successful, the decryption information of the target data file is sent to the accessing user. Specifically, security domain A performs cross-domain security verification on the accessing user in security domain B. If the cross-domain security verification of the accessing user in security domain B is successful, then security domain A sends the decryption information of the target data file to the accessing user in security domain B. The decryption information can instruct the accessing user in security domain B to decrypt the encrypted data of the target data file.

[0092] And in Figure 4In this scenario, if the cross-domain security verification of the accessing user is successful, the decryption information of the target data file is sent to the accessing user. Specifically, security domain B performs cross-domain security verification on the accessing user of security domain A. If the cross-domain security verification of the accessing user in security domain A is successful, then security domain B sends the decryption information of the target data file to the accessing user of security domain A. The decryption information can instruct the accessing user of security domain A to decrypt the encrypted data of the target data file.

[0093] The data sharing method provided in this application embodiment involves a first security domain responding to a user's data access request by performing cross-domain security verification on the user. If the user's cross-domain security verification is successful, decryption information for the target data file is sent to the user. This decryption information instructs the user to decrypt the encrypted data in the target data file to obtain the target data file. In this method, the first security domain responds to a user's data access request in a second security domain. Since the first and second security domains are different security domains, cross-domain data sharing is possible. Furthermore, the first security domain performs cross-domain verification on the data access request, ensuring the secure and trustworthy identity of data sharers across different security domains. Only after the user's cross-domain security verification is successful is the decryption information for the target data file sent to the user, allowing the user to decrypt and obtain the target data, further ensuring the security of the data sharing process. Finally, during the data sharing process, the target data file is encrypted during storage, and decryption is required to access the data, thus achieving security during data sharing and effectively preventing data privacy leaks.

[0094] Based on any of the foregoing embodiments, in one embodiment, such as Figure 5 As shown, cross-domain security verification for accessing users includes the following steps:

[0095] S501, the first security domain obtains the cross-domain access credentials and data access request of the accessing user.

[0096] Cross-domain access credentials are credentials that allow a user to access data across domains, proving that the user's identity is trustworthy. Specifically, when the cross-domain consortium blockchain receives a data access request from the first security domain, it generates a cross-domain access credential based on the user's data access request.

[0097] Optionally, the first security domain obtains the cross-domain access credentials and data access request of the accessing user. This can be done by the first security domain directly obtaining the cross-domain access credentials of the accessing user from the cross-domain consortium blockchain, or by the cross-domain consortium blockchain sending the cross-domain access credentials of the accessing user to the first security domain.

[0098] Please continue reading Figure 3 and Figure 4 .

[0099] exist Figure 3 In this scenario, security domain A sends a data access request from a user in security domain B to the cross-domain consortium blockchain. The cross-domain consortium blockchain then generates cross-domain access credentials based on the user's data access request and sends them to security domain A. Meanwhile... Figure 4 In this scenario, security domain B sends the data access request sent by the user in security domain A to the cross-domain consortium blockchain. The cross-domain consortium blockchain generates cross-domain access credentials based on the user's data access request and then sends them to security domain B.

[0100] S502, if the cross-domain authentication of the accessing user is successful, obtain the accessing user's attribute private key.

[0101] The first security domain sends the received data access request from the user to the cross-domain consortium blockchain for cross-domain verification of the user. Based on the data access request and the preset cross-domain verification method, the first security domain verifies the user's data access request. If the user's cross-domain verification is successful, the first security domain obtains the user's attribute private key.

[0102] In one embodiment, the preset cross-domain verification method can be a preset neural network model. The data access request is used as the input of the neural network model. After the neural network model is trained, the final output of the cross-domain verification result is output. If the cross-domain verification is successful, the access user's attribute private key will also be output.

[0103] In another embodiment, the preset cross-domain verification method can also be a preset verification algorithm. The data access request is used as the input data of the preset verification algorithm. By calling the verification algorithm, the verification result is finally output. If the cross-domain verification is successful, the access user's attribute private key will be obtained according to the preset generation algorithm.

[0104] S503, if the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, then send the decryption information of the target data file to the accessing user; the decryption information includes at least: the encryption key, the hash value of the target data file, the accessing user's attribute private key, and the public parameters of the first security domain.

[0105] The access user's attribute private key obtained in the above embodiment is matched with the pre-configured shared ciphertext in the first security domain. If the matching result is consistent with the preset result, the first security domain sends the decryption information of the target data file to the access user in the second security domain.

[0106] The decryption information includes at least: encryption key, hash value of target data file, private key of accessing user attribute, and public parameters of the first security domain. The decryption information can be obtained directly from the local consortium blockchain in the first security domain. The local consortium blockchain is used to store information such as the address value of data file stored on the shared cloud platform, hash value of original data file, hash value of encrypted data file, and access control policy of local resources, and is jointly maintained by all nodes in the domain.

[0107] In one embodiment, if the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, the specific implementation of the matching determination is as follows: according to a preset matching algorithm, the accessing user's attribute private key and the pre-configured shared ciphertext in the first security domain are used as inputs to the matching algorithm. By running the matching algorithm, the matching result is finally obtained. The matching result is compared with the preset matching result. If the two are consistent, it is determined that the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain.

[0108] In another embodiment, if the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, the specific implementation of the matching judgment is as follows: based on a pre-trained neural network model, the accessing user's attribute private key and the pre-configured shared ciphertext in the first security domain are used as inputs to the neural network model. By training the neural network model, the matching result is directly output to determine whether the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain.

[0109] The data sharing method provided in this embodiment involves a first security domain acquiring the cross-domain access credentials and data access request of the accessing user. If the cross-domain verification of the accessing user is successful, the accessing user's attribute private key is obtained. If the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, decryption information of the target data file is sent to the accessing user. The decryption information includes at least: an encryption key, the hash value of the target data file, the accessing user's attribute private key, and public parameters of the first security domain. In this method, the accessing user can obtain the decryption information of the target data file, which can be used to instruct the accessing user to decrypt the encrypted data of the target data file, thereby obtaining the target data file. This method achieves security in the data sharing process and effectively prevents the leakage of data privacy.

[0110] Based on the previous embodiments where the first security domain obtains the cross-domain access credentials of the accessing user, the following embodiment will provide a detailed explanation. In one embodiment, such as... Figure 6 As shown, the first security domain obtains the cross-domain access credentials and data access request of the accessing user, including the following steps:

[0111] S601, the identity authentication server of the first security domain authenticates the accessing user. After successful authentication, it sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain consortium blockchain to generate cross-domain access credentials and routing information for the accessing user, and sends the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials.

[0112] In the above embodiments, the first security domain responds to the data access request of the accessing user by having its identity authentication server respond to the data access request of the accessing user. When the identity authentication server of the first security domain receives the data access request of the accessing user, it authenticates the accessing user. The authentication method is that the identity authentication server of the first security domain searches for the accessing user's identity information in the cross-domain consortium blockchain and compares the identity information of the accessing user found in the cross-domain consortium blockchain with the identity information in the data access request of the accessing user. If the two match, it means that the accessing user's authentication is successful.

[0113] The identity authentication server in the first security domain authenticates the accessing user. After successful authentication, it sends the data access request to the cross-domain consortium blockchain, instructing the consortium blockchain to generate cross-domain access credentials and routing information for the accessing user. In one embodiment, the generation of cross-domain access credentials and routing information for the accessing user can be achieved by the nodes in the cross-domain consortium blockchain first confirming the accessing user's identity to be consistent, that is, reaching a consensus among the nodes in the cross-domain consortium blockchain. Then, the accessing user's data access request is stored in the cross-domain consortium blockchain as a blockchain transaction. The cross-domain attribute authorization institution in the cross-domain consortium blockchain assigns cross-domain attributes to the accessing user based on the accessing user's identity information. After the nodes in the cross-domain consortium blockchain reach a consensus, a cross-domain smart contract is triggered, and then an access credential is generated. The cross-domain attributes and access credential are then sent to the accessing user as cross-domain access credentials.

[0114] In addition, once all nodes in the cross-domain consortium blockchain reach a consensus, the cross-domain consortium blockchain will also generate routing information, which is the routing information of the access control center in the first security domain.

[0115] Each security domain includes a certificate authority, an identity authentication server, and an access control center. The cross-domain consortium blockchain includes a cross-domain attribute authorization authority, and connects the identity authentication server and access control center from each security domain to the cross-domain consortium blockchain.

[0116] A cross-domain consortium blockchain, also known as a cross-domain consortium blockchain, is used to store cross-domain access behavior data, digital identity certificates and certificate authorization records of each domain, and is jointly maintained by the identity authentication service nodes and access control centers of each domain.

[0117] The Cross-domain Attribute Authorization Authority (CDAA) is responsible for assigning cross-domain attributes to cross-domain data visitors.

[0118] Authentication Server (AS): The Authentication Server is responsible for verifying the legitimacy and security of nodes within its security domain. Simultaneously, the AS uploads the certificate authorization logs for its domain to the cross-domain consortium blockchain, allowing all cross-domain identity server nodes to mutually trust the identity certificates from each domain. Upon successful verification, the AS returns the verification result to the domain's Certificate Authority (CA), which then issues a digital identity authentication certificate. Furthermore, the AS uploads the hash values ​​of all node digital identity certificates, the list of legitimate users, and the certificate revocation list to the cross-domain shared blockchain and the local blockchain for sharing among all members both within and outside the domain.

[0119] Access Control Center (ACC): Responsible for access control of data within this security domain, including access control for intra-domain data sharing between users within this security domain and access control for users outside the security domain to access data in this domain, and uploading cross-domain access behavior to the cross-domain consortium blockchain for storage.

[0120] Users in each security domain include storage users and access users. Storage users represent the producers or owners of the data, while access users represent the users who need to access the data.

[0121] Depending on the access request object during the data sharing process, the specific references to the first and second security domains will differ, such as... Figure 7 and Figure 8 As shown.

[0122] exist Figure 7 In the scenario shown, the first security domain refers to security domain A, the second security domain refers to security domain B, and the accessing user is the user in security domain B. Specifically, the identity authentication server of the first security domain authenticates the accessing user in the second security domain. After successful authentication, security domain A sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain attribute authorization authority in the cross-domain consortium blockchain to generate the cross-domain attribute of the accessing user. The data access request is also stored as a blockchain transaction in the cross-domain blockchain. The cross-domain blockchain also generates access credentials and routing information of the access control center of security domain A according to the smart contract, and sends the cross-domain attribute and access credentials as cross-domain access credentials to the accessing user in security domain B.

[0123] And in Figure 8 In this scenario, the first security domain refers to security domain B, the second security domain refers to security domain A, and the accessing user is the user in security domain A. Specifically, the identity authentication server of the first security domain authenticates the accessing user in the second security domain. After successful authentication, security domain B sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain attribute authorization agency in the cross-domain consortium blockchain to generate the cross-domain attribute of the accessing user. The data access request is also stored as a blockchain transaction in the cross-domain blockchain. The cross-domain blockchain also generates access credentials and routing information of the access control center of security domain B according to the smart contract, and sends the cross-domain attribute and access credentials as cross-domain access credentials to the accessing user in security domain A.

[0124] S602, the access control center of the first security domain receives cross-domain access credentials and data access requests uploaded by the accessing user through the communication channel; the communication channel is established by the accessing user based on routing information.

[0125] Based on the routing information obtained in the above embodiments, the accessing user establishes a communication channel with the first security domain, and then the accessing user sends cross-domain access credentials and data access requests to the access control center of the first security domain.

[0126] Please continue reading Figure 7 and Figure 8 .

[0127] exist Figure 7 In this scenario, a user in security domain B establishes a communication channel with the access control center in security domain A. Then, the user in security domain B sends cross-domain access credentials and a data access request to the access control center in security domain A. Figure 8 In this scenario, an access user in security domain A establishes a communication channel with the access control center in security domain B, and then the access user in security domain A sends cross-domain access credentials and data access requests to the access control center in security domain B.

[0128] The data sharing method provided in this embodiment involves an identity authentication server in the first security domain authenticating the accessing user. After successful authentication, the server sends a data access request to the cross-domain consortium blockchain, instructing the blockchain to generate cross-domain access credentials and routing information for the accessing user. The blockchain then sends the cross-domain access credentials to the accessing user. The access control center of the first security domain receives the cross-domain access credentials and data access request uploaded by the accessing user through a communication channel established by the user based on the routing information. This method generates cross-domain access credentials for the accessing user based on the cross-domain consortium blockchain, and then sends the cross-domain access credentials and data access request to the access control center of the first security domain. This achieves trusted sharing during the data sharing process, improves data sharing security, and prevents data leakage during data sharing. The cross-domain consortium blockchain stores the data access request as a blockchain transaction, enabling tracking and tracing during the data sharing process.

[0129] Based on the preceding embodiments, in one embodiment, such as Figure 9 As shown, before obtaining the private key for the access user's attributes, the following steps are also included:

[0130] S901, based on the data access request of the accessing user, the access control center of the first security domain searches for the accessing user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain.

[0131] The pre-stored cross-domain access credentials of the accessing user are the cross-domain access credentials generated by the cross-domain consortium blockchain after the identity authentication server of the first security domain in the above embodiment has successfully authenticated the accessing user and sent the accessing user's data access request to the cross-domain consortium blockchain.

[0132] The access control center of the first security domain searches for the user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain based on the user's data access request. In one embodiment, the search can be performed by the access control center of the first security domain using a pre-configured search algorithm. Specifically, the user's data access request is used as input data to the search algorithm, and the algorithm is run to obtain the user's pre-stored cross-domain access request.

[0133] Please continue reading Figure 7 and Figure 8 .

[0134] The access control center of the first security domain searches for the access user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain. Figure 7 In this scenario, the access control center of security domain A searches the cross-domain consortium blockchain for the user's pre-stored cross-domain access credentials; while... Figure 8 In this scenario, the access control center of security domain B searches for the pre-stored cross-domain access credentials of the accessing user in the cross-domain consortium blockchain.

[0135] S902, compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained from the first security domain.

[0136] The cross-domain access credentials obtained by the first security domain for the accessing user are the cross-domain access credentials transmitted by the access control center of the first security domain through the communication channel, as described in the above embodiment.

[0137] Optionally, the pre-stored cross-domain access credentials are compared with the cross-domain access credentials of the accessing user obtained by the first security domain. The comparison can be made by directly comparing the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained by the first security domain to determine whether the values ​​are completely consistent.

[0138] S903 If the comparison results are consistent, the cross-domain verification of the accessing user is confirmed to be successful.

[0139] If the comparison between the pre-stored cross-domain access credentials and the cross-domain access credentials of the accessing user obtained from the first security domain is consistent, it indicates that the accessing user's cross-domain access credentials are trustworthy, and it can be determined that the accessing user's cross-domain verification is successful.

[0140] The data sharing method provided in this embodiment involves the following steps: Based on a user's data access request, the access control center of the first security domain searches for the user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain. The pre-stored cross-domain access credentials are then compared with the user's cross-domain access credentials obtained by the first security domain. If the comparison results match, the user's cross-domain verification is deemed successful. This method verifies the user's cross-domain access credentials to ensure their trustworthiness, thus achieving credibility in the data sharing process.

[0141] Based on the preceding embodiments, in one embodiment, such as Figure 10 As shown, obtaining the private key for accessing a user's attributes includes the following steps:

[0142] S1001, the key management center of the first security domain obtains the cross-domain attributes of the accessing user.

[0143] The Key Manager Center (KMC) is responsible for generating public and master keys for data access control policies and employs hardware-based security mechanisms to ensure the security of the Key Manager Center.

[0144] According to the above embodiment, the pre-stored cross-domain access credentials are compared with the cross-domain access credentials of the accessing user obtained by the first security domain to determine that the cross-domain verification of the accessing user is successful. After the cross-domain verification of the accessing user is successful, the key management center of the first security domain will obtain the cross-domain attribute of the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials.

[0145] In one embodiment, the key management center of the first security domain may send a request signal to the access control center of the first security domain, so that the key management center of the first security domain can directly obtain the cross-domain attributes of the accessing user from the access control center of the first security domain.

[0146] In another embodiment, the access control center of the first security domain may directly send the cross-domain attribute of the accessing user to the key management center of the first security domain after receiving the cross-domain verification of the accessing user.

[0147] S1002, the key management center of the first security domain generates the access user's attribute private key based on the cross-domain attribute of the access user and the preset master key of the first security domain.

[0148] The master key can be used to generate the private key, ensuring the security of data over the transmission line.

[0149] In one embodiment, the attribute private key of the accessing user can be generated by using a key generation algorithm. The cross-domain attribute of the accessing user and the preset master key of the first security domain are used as inputs to the key generation algorithm. By running the key generation algorithm, the attribute private key of the accessing user is finally output.

[0150] In another embodiment, the method of generating the access user's attribute private key can also be to use a pre-trained neural network model, taking the access user's cross-domain attributes and the preset master key of the first security domain as input to the neural network model, and outputting the access user's attribute private key after the neural network model is trained.

[0151] The data sharing method provided in this embodiment involves the key management center of the first security domain acquiring the cross-domain attributes of the accessing user. Based on the cross-domain attributes and the preset master key of the first security domain, the key management center generates an attribute private key for the accessing user. This method, by generating the accessing user's attribute private key from the cross-domain attributes, achieves data security during the sharing process and effectively prevents data privacy leaks.

[0152] Based on the preceding embodiments, in one embodiment, such as Figure 11 As shown, this embodiment involves the process by which the access control center of the first security domain generates a search keyword trap based on the access user's attribute private key and search keywords. The access control center then matches the search keywords against the search keyword trap and shared ciphertext within the first security domain. If the matching result meets preset conditions, the specific process of determining the access user's attribute private key and the shared ciphertext of the target data file within the first security domain is then described. This embodiment includes the following steps:

[0153] S1101, the access control center of the first security domain generates a search keyword trap based on the access user's attribute private key and search keywords.

[0154] A search threshold can be generated based on the key and the content to be retrieved. The search keyword threshold is generated based on the accessing user's attribute private key and the search keywords. The search keywords are the keywords that the accessing user needs to access the data in the first security domain.

[0155] In one embodiment, the search keyword trap can be generated using the Trapdoor algorithm, which takes the user's private key and the search keyword as input to the algorithm and obtains the search keyword trap by running the algorithm.

[0156] S1102, the access control center of the first security domain matches the search keywords based on the search keyword trap and the shared ciphertext in the first security domain.

[0157] The shared ciphertext in the first security domain consists of pre-configured public parameters and keyword ciphertext for the first security domain.

[0158] In one embodiment, the search keywords are matched. The matching method can be based on a keyword matching algorithm. Specifically, the search keyword trap and the shared ciphertext in the first security domain are used as input to the algorithm. Through the operation of the algorithm, the search keywords are matched to obtain the matching results.

[0159] S1103, if the matching result meets the preset conditions, then determine the shared ciphertext of the target data file in the first security domain and the attribute private key of the accessing user.

[0160] In one embodiment, the preset condition can be 1, and the matching result can be 0 or 1. If the matching result is 1 and matches the preset condition, then the shared ciphertext of the target data file in the first security domain is determined to be the private key of the accessing user.

[0161] The data sharing method provided in this embodiment involves the access control center of the first security domain generating a search keyword trap based on the access user's attribute private key and search keywords. Then, the search keywords are matched against the search keyword trap and the shared ciphertext in the first security domain. If the matching result meets preset conditions, the access user's attribute private key and the shared ciphertext of the target data file in the first security domain are determined. This method, by obtaining a search keyword trap based on the search keywords, using the shared ciphertext of the first security domain and the keyword trap, and employing a matching algorithm, determines the matching result between the shared ciphertext of the first security domain and the keyword trap. If the matching result meets preset conditions, the access user's attribute private key and the shared ciphertext of the target data file in the first security domain are determined. This achieves trusted sharing during the data sharing process, improves data sharing security, and prevents data leakage during data sharing.

[0162] Based on the preceding embodiments, in one embodiment, the process of an accessing user decrypting the encrypted data of a target data file includes: when the hash value of the target data file matches the hash value pre-stored in the local consortium blockchain in the first security domain, the accessing user decrypts the encrypted data file of the target data file according to the decrypted encryption key to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters of the first security domain, the attribute private key, and the encryption key.

[0163] In one embodiment, the encrypted data file of the target data file is obtained by the accessing user providing access credentials and the hash value of the target data file to the shared cloud platform of the first security domain. After receiving the access credentials and the hash value of the target data file, the shared cloud platform will send the encrypted data file of the target data file to the accessing user.

[0164] According to the above embodiment, if the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, then decryption information of the target data file is sent to the accessing user. This decryption information includes at least: an encryption key, the hash value of the target data file, the accessing user's attribute private key, and public parameters of the first security domain. The hash value of the target data file obtained by the accessing user is the hash value of the target data file itself.

[0165] The hash value pre-stored in the local consortium blockchain in the first security domain is the hash value of the target data file that is pre-stored in the local consortium blockchain when the target data file is stored.

[0166] The hash value of the target data file is compared with the hash value pre-stored in the local consortium blockchain in the first security domain. If the two results match, the accessing user will decrypt the encrypted data file of the target data file using the decrypted encryption key to obtain the target data file.

[0167] In one embodiment, the accessing user decrypts the encrypted data file of the target data file using the decrypted encryption key to obtain the target data file. The decryption method can be based on a pre-trained neural network model, where the decrypted encryption key and the encrypted data file of the target data file are used as inputs to the neural network model. After training the neural network model, the target data file is finally output.

[0168] Optionally, the decrypted encryption key is determined by the accessing user based on the public parameters, attribute private key, and encryption key of the first security domain. The method of determination is to use the public parameters, attribute private key, and encryption key of the first security domain as input data for the decryption algorithm, and obtain the decrypted encryption key by running the decryption algorithm.

[0169] Based on the preceding embodiments, in one embodiment, the storage process of the target data file in the first security domain includes: the first security domain responding to the data storage request by storing the encrypted data carried in the data storage request; the encrypted data is generated by the storage user based on the data file to be stored.

[0170] Encrypted data is generated based on the data file to be stored. After the encrypted data is generated, the storage user sends a data storage request to the first security domain and then stores the encrypted data carried in the data storage request.

[0171] In one embodiment, the encrypted data is generated by the storage user based on the data file to be stored. The generation method can be to use a pre-configured program, take the data to be stored as the input of the program, call the program, and finally output the encrypted data.

[0172] Alternatively, the encrypted data can be stored directly in the local blockchain of the first security domain.

[0173] Please continue reading Figure 7 and Figure 8 .

[0174] exist Figure 7 In this scenario, a storage user in security domain A generates encrypted data from the data file to be stored and stores the encrypted data in security domain A; Figure 8 In this scenario, the storage user in security domain B generates encrypted data from the data file to be stored and stores the encrypted data in security domain B.

[0175] Based on the preceding embodiments, in one embodiment, such as Figure 12As shown, the encrypted data includes at least the access structure of the data file to be stored, the ciphertext of the keyword, the encrypted data file, the hash value of the encrypted data file, and the signature information of the storage user; therefore, the encrypted data is obtained by the storage user through an encryption operation; wherein the encryption operation includes the following steps:

[0176] S1201, Generate file keywords and access structure based on the data file to be stored.

[0177] The file keyword is a keyword generated based on the file to be stored. Searching for the file keyword will find the file to be stored. The access structure is an access control policy structure used for file access control. It can ensure that the file to be stored is not accessed or used illegally.

[0178] Optionally, file keywords can be obtained from the file to be stored using an extraction algorithm; access structures can be obtained from the file to be stored using a decision tree method.

[0179] S1202, obtain the keyword ciphertext based on the public parameters of the first security domain, the file keywords, and the access structure.

[0180] In one embodiment, keyword ciphertext is obtained based on the public parameters of the first security domain, file keywords, and access structure. This can be achieved by generating keyword ciphertext using a keyword ciphertext generation algorithm. Specifically, the public parameters of the first security domain, file keywords, and access structure are used as input to the algorithm, and the keyword ciphertext is obtained by running the algorithm.

[0181] Optionally, based on the system parameters of the key management center of the first security domain, public parameters and a master key can be generated through an initialization algorithm; the system parameters can be randomly set or a given value can be directly provided. The public parameters can be broadcast to the local consortium blockchain of the first security domain, and the master key can be stored in the key management center of the first security domain.

[0182] S1203, based on the data file to be stored and the preset key, generate an encrypted data file and the hash value of the encrypted data file.

[0183] The preset key is a pre-defined key used to encrypt the data files to be stored.

[0184] In one embodiment, an encrypted data file and its hash value are generated based on the data file to be stored and a preset key. The generation method can be through an encryption algorithm. Specifically, the data file to be stored is the data that needs to be encrypted, the preset key is the key in the encryption algorithm, and the encrypted data file to be stored, i.e., the encrypted data file and its hash value, are obtained by running the encryption algorithm.

[0185] The hash value of an encrypted data file can be used to detect whether the data file to be stored has been modified.

[0186] S1204. Obtain the encryption key based on the preset key, public parameters, and access structure.

[0187] In one embodiment, an encryption key is obtained based on a preset key, public parameters, and access structure. This encryption key can be obtained by using an encryption algorithm, taking the preset key, public parameters, and access structure as input, and then calling the algorithm to obtain the encryption key. In practical applications, this application does not limit the encryption algorithm used.

[0188] By encrypting the files with a preset key, the security and privacy of the stored files are ensured.

[0189] The data sharing method provided in this application generates file keywords and access structures based on the data file to be stored. It obtains keyword ciphertext based on the public parameters of the first security domain, the file keywords, and the access structures. It generates an encrypted data file and its hash value based on the data file to be stored and a preset key. Finally, it obtains an encryption key based on the preset key, public parameters, and access structures. This method improves the security and privacy of data during the sharing process by generating file keywords, access structures, an encrypted data file, its hash value, and an encryption key based on the file to be stored.

[0190] Based on the preceding embodiments, in one embodiment, such as Figure 13 As shown, storing the encrypted data carried in the data storage request includes the following steps:

[0191] S1301, the first security domain sends the encrypted data file to the shared cloud platform of the first security domain for storage, and sends the encrypted data to the local consortium blockchain of the first security domain in a preset format.

[0192] A local consortium blockchain, also known as a local consortium blockchain (BC), is used to store information such as the address value of data files stored on a shared cloud platform, the hash value of the original data file, the hash value of the encrypted data file, and access control policies of local resources. It is jointly maintained by all nodes within the domain.

[0193] In one embodiment, the first security domain sends the encrypted data file obtained in the above embodiment to the shared cloud platform of the first security domain, and the sending method can be the POST method.

[0194] In another embodiment, the first security domain sends the encrypted data file obtained in the above embodiment to the shared cloud platform of the first security domain, and the sending method can be the get method.

[0195] The access structure of the data file to be stored, the ciphertext of the keywords, the encrypted data file, the hash value of the encrypted data file, and the signature information of the storage user are used as encrypted data. The encrypted data is then sent to the local consortium blockchain of the first security domain in a preset format. Optionally, the data can be sent via broadcast.

[0196] Storing user signature information means storing the user's digital signature information in the security domain, which is a valid proof of the authenticity of encrypted data.

[0197] Optionally, the preset format can be a chained storage format or an indexed storage format. In practical applications, the embodiments of this application do not limit the preset format.

[0198] S1302, after the smart contract is triggered, the consortium blockchain of the first security domain stores the encrypted data file to the local consortium blockchain of the first security domain.

[0199] In one embodiment, after the first security domain sends the encrypted data file to the shared cloud platform of the first security domain for storage and sends the encrypted data to the local consortium blockchain of the first security domain in a preset format, a smart contract is triggered. The smart contract can be a data-on-chain smart contract, which means that after the smart contract listens for the message of the encrypted data file, it will store the encrypted data file in the consortium blockchain of the first security domain in the form of a blockchain transaction record. The format of the transaction record adopts the encoding format of JavaScript Object Notation (JSON).

[0200] In this context, data on-chain means that data is packaged into a block through a consensus mechanism to become a new block, and linked to previous blocks, thus becoming immutable data on the chain.

[0201] All historical data on the local consortium blockchain can be traced and queried, ensuring data integrity.

[0202] The data sharing method provided in this embodiment involves a first security domain sending encrypted data files to a shared cloud platform for storage, and sending the encrypted data to a local consortium blockchain within the first security domain in a preset format. Upon triggering a smart contract, the consortium blockchain of the first security domain stores the encrypted data files on its local blockchain. This method, by storing the encrypted data files on the shared cloud platform, storing the encrypted data on the local consortium blockchain, and storing the encrypted data files as blockchain transaction records after triggering the smart contract, improves data security and privacy during the sharing process and ensures that the data is traceable and verifiable.

[0203] In one embodiment, such as Figure 14 As shown, Figure 14 A system model diagram was constructed. Figure 14 In this context, a security domain refers to an area managed by a Certificate Authority (CA). For example, the domain comprised of the Southern Power Grid is one security domain, while the domains comprised of various departments within other government agencies are another. They each have different root CAs. Nodes in a cross-domain consortium blockchain consist of identity authentication servers and access control centers within their respective security domains. They jointly maintain the consensus of the cross-domain consortium blockchain, transmitting identity trust consensus across domains through the consortium blockchain. They are both blockchain network nodes within their respective security domains and cross-domain nodes, uploading different access behavior information to different blockchains for storage.

[0204] Within each security domain, a consortium blockchain is established. Authoritative nodes with high security levels and strong computing and storage capabilities, such as identity authentication servers and access control servers within each security domain, serve as cross-domain nodes to form a cross-domain consortium blockchain. Members of the cross-domain consortium blockchain jointly maintain a complete record of cross-domain access and conduct joint identity authentication for cross-domain visitors, preventing centralized identity authentication fraud. Furthermore, each cross-domain access is stored as a blockchain transaction within the consortium blockchain, enhancing the verifiability of data access and the right to use data, ensuring that data usage rights are traceable throughout the entire data sharing process.

[0205] By connecting the identity authentication servers of each security domain to a cross-domain consortium blockchain, trusted and publicly verifiable authorization for identity authentication between domains is achieved, ensuring the trustworthiness of data owners and data visitors during data sharing. Then, the access control center of the accessed domain performs attribute-encrypted access control decisions based on ciphertext policies on the cross-domain nodes after successful identity authentication, determining whether the visitor has the authority to perform data operations.

[0206] One embodiment uses an attribute-based searchable encryption method based on a ciphertext policy to perform fine-grained access control on shared data; the access control process is automatically executed by a blockchain smart contract to ensure the trustworthiness of the access process and solve the problem of vulnerability to centralized access control; and the blockchain records the transfer of usage rights every time data is shared, enabling traceability of the entire process of data usage rights transfer and facilitating clear understanding of the rights and responsibilities of all parties.

[0207] like Figure 15 As shown, in one embodiment, a data sharing method is also included. This embodiment takes the existence of security domain A (hereinafter referred to as domain A) and security domain B (hereinafter referred to as domain B), with data stored in security domain A, a user in security domain B accessing data in security domain A, and a data owner in security domain A and a data accessor in security domain B as an example. Figure 16 As shown, Figure 16 This is a data storage procedure, which includes the following steps S1501-S1505. This embodiment includes:

[0208] S1501, set a system parameter in the key management center of domain A, and generate system public parameters and master key through initialization algorithm.

[0209] S1502 stores the system public parameters and master key in the key management center and broadcasts the system public parameters to the consortium blockchain of domain A.

[0210] S1503, the data owner of domain A selects the file to be shared, encrypts it, and obtains the encrypted data file and encrypted data;

[0211] The encrypted data includes the file keyword KW, access structure T, keyword ciphertext C, hash value of the encrypted file HashEncfile, and encryption key Enckey; the encryption process is as follows:

[0212] The data owners of each security domain extract the file keywords KW;

[0213] Configure the access structure for file access control;

[0214] Based on the file keyword KW, the system public parameter pub, and the access structure, the keyword ciphertext C is determined using a keyword ciphertext generation algorithm.

[0215] Based on the file and the symmetric key, we obtain the encrypted data file Encfile and the hash value HashEncfile of the encrypted file;

[0216] The encryption key Enckey is determined based on the symmetric key key, the system public parameter pub, and the access structure T.

[0217] S1504, The data owner of domain A uploads the encrypted data file to the shared cloud platform of domain A and broadcasts the encrypted data and the data owner's digital signature to domain A in a preset format;

[0218] The preset format is <access structure T, keyword ciphertext C, hash value of encrypted file HashEncfile, encryption key Enckey> digital signature.

[0219] S1505, after completing S1-S3, triggers the data on-chain smart contract. After the smart contract listens to all messages on the chain about encrypted data files, it automatically generates a blockchain transaction record and stores it in the local consortium chain.

[0220] S1506, The data visitor sends a data sharing request to the identity authentication server of domain A.

[0221] The data sharing request includes domain B's digital identity certificate, user identity, digital signature, the security domain to be accessed, and attribute set;

[0222] S1507, Domain A's authentication server receives a data sharing request and obtains cross-domain access credentials and cross-domain routing information based on the request.

[0223] In this process, after receiving a data sharing request, the identity authentication server of domain A verifies the identity of the data accessor. Once the verification is successful, the sharing request data is forwarded to the cross-domain consortium blockchain. After the consensus nodes of the cross-domain consortium blockchain reach a consensus, the cross-domain attribute authorization agency of the cross-domain consortium blockchain assigns cross-domain attributes to the user's identity information based on the access domain. The data sharing request information of domain B is stored in the cross-domain consortium blockchain as a blockchain transaction, and a cross-domain smart contract is triggered to generate a cross-domain access credential. The routing information of the access control center of the access domain is then returned. The cross-domain access credential contains cross-domain attributes.

[0224] S1508 After obtaining cross-domain access credentials and cross-domain routing information, the data access user establishes a communication connection with the access control center of domain A and sends cross-domain access credentials and data sharing request messages to the access control center of domain A.

[0225] S1509 After receiving the data access request information, the access control center of domain A performs cross-domain verification on the data accesser in the cross-domain consortium blockchain. If the identity is found to be untrustworthy, a rejection message is returned; if the identity is found to be trustworthy, step S1510 is performed.

[0226] S1510 After receiving the verification information, the access control center of domain A sends the cross-domain attributes of the data visitor to the key management center. The key management center uses the key generation algorithm to generate the private key of the data visitor's attributes and returns it to the access control center of domain A.

[0227] S1511, after receiving the data visitor's attribute private key, the access control center of domain A uses a keyword trap generation algorithm to generate a search keyword trap.

[0228] S1512, the Domain A Access Control Center uses the shared keyword ciphertexts of the Domain A local consortium blockchain to perform keyword matching. If the matching result is 1, it returns the encryption key bound to the keyword ciphertext, the hash value of the bound target encrypted file, and the address of the shared cloud server. At the same time, it sends the attribute private key and system public parameters to the data accesser.

[0229] S1513 After receiving the encryption key, the data accessor uses the decryption algorithm to decrypt the encryption key to obtain the decrypted key.

[0230] S1514, the data accessor provides access credentials and the hash value of the target encrypted file to the domain A shared cloud platform. After receiving the access credentials and the hash value of the target encrypted file, the shared cloud platform provides encrypted data. The data accessor compares the hash value of the encrypted data with the hash value sent by the access control center. If the comparison is consistent, the data accessor uses the decrypted key to decrypt the encrypted data and obtain the plaintext.

[0231] The implementation principle and technical effect of each step in the data sharing method provided in this embodiment are similar to those in the previous data sharing method embodiments, and will not be repeated here.

[0232] It should be understood that although the steps in the flowcharts of the above embodiments are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowcharts of the above embodiments may include multiple steps or multiple stages. These steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the steps or stages in other steps.

[0233] In addition, embodiments of this application also provide a data sharing device, such as... Figure 17 As shown, in one embodiment, the data sharing device 1700 includes: a response module 1701 and a decryption module 1702, wherein:

[0234] The response module 1701 is used to respond to the data access request of the accessing user and perform cross-domain security verification on the accessing user; the data access request is used to request access to the target data file stored in the first security domain; the accessing user is a user in the second security domain; the first security domain and the second security domain are different security domains;

[0235] The decryption module 1702 is used to send decryption information of the target data file to the accessing user if the cross-domain security verification of the accessing user is successful. The decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0236] In one embodiment, the response module 1701 includes:

[0237] The first acquisition unit is used to acquire the cross-domain access credentials and data access requests of the accessing user;

[0238] The second acquisition unit is used to obtain the user's attribute private key after the cross-domain authentication of the accessing user is passed.

[0239] The decryption unit is used to send decryption information of the target data file to the accessing user if the accessing user's attribute private key matches the shared ciphertext of the target data file pre-configured in the first security domain. The decryption information includes at least: the encryption key, the hash value of the target data file, the accessing user's attribute private key, and the public parameters of the first security domain.

[0240] In one embodiment, the first acquisition unit includes:

[0241] The verification subunit is used to authenticate the accessing user. After successful authentication, it sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain consortium blockchain to generate cross-domain access credentials and routing information for the accessing user, and then sends the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials.

[0242] The receiving subunit is used to receive cross-domain access credentials and data access requests uploaded by the accessing user through the communication channel; the communication channel is established by the accessing user based on routing information.

[0243] In one embodiment, the device further includes:

[0244] The lookup module is used to search for the user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain based on the user's data access request.

[0245] The comparison module is used to compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained from the first security domain.

[0246] The verification module is used to determine that the cross-domain verification of the accessing user has passed if the comparison results are consistent.

[0247] In one embodiment, the second acquisition unit includes:

[0248] Get sub-units to retrieve cross-domain attributes of the accessing user;

[0249] The generation sub-unit is used to generate the access user's attribute private key based on the access user's cross-domain attributes and the master key preset in the first security domain.

[0250] In one embodiment, the device further includes:

[0251] The generation module is used to generate search keyword traps based on the accessing user's attribute private key and search keywords;

[0252] The matching module is used to match search keywords based on the search keyword trap and the shared ciphertext in the first security domain;

[0253] The determination module is used to determine the shared ciphertext of the target data file in the first security domain and the attribute private key of the accessing user if the matching result meets the preset conditions.

[0254] In one embodiment, the decryption module 1702 includes:

[0255] The processing unit is used to decrypt the encrypted data file of the target data file according to the decrypted encryption key when the hash value of the target data file is consistent with the hash value pre-stored in the local consortium blockchain in the first security domain, so as to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters of the first security domain, the attribute private key and the encryption key.

[0256] In one embodiment, the device further includes:

[0257] The storage module is used by the first security domain to store the encrypted data carried in the data storage request in response to the data storage request; the encrypted data is generated by the storage user based on the data file to be stored.

[0258] In one embodiment, the device further includes:

[0259] The first generation module is used to generate file keywords and access structures based on the data file to be stored.

[0260] The first processing module is used to obtain the keyword ciphertext based on the public parameters of the first security domain, the file keywords, and the access structure.

[0261] The second generation module is used to generate an encrypted data file and a hash value of the encrypted data file based on the data file to be stored and a preset key.

[0262] The second processing module is used to obtain the encryption key based on the preset key, public parameters, and access structure.

[0263] In one embodiment, the storage module includes:

[0264] The first storage unit is used to send encrypted data files to the shared cloud platform of the first security domain for storage, and to send encrypted data to the local consortium blockchain of the first security domain in a preset format.

[0265] The second storage unit is used by the consortium blockchain of the first security domain to store encrypted data files to the local consortium blockchain of the first security domain after the smart contract is triggered.

[0266] Specific limitations regarding the data sharing device can be found in the limitations of the data sharing method described above, and will not be repeated here. Each module in the aforementioned data sharing device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0267] In one embodiment, a computer device is provided, which may be a terminal, and its internal structure diagram may be as follows: Figure 18 As shown, the computer device includes a processor, memory, communication interface, display screen, and input devices connected via a system bus. The processor provides computing and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs stored in the non-volatile storage media. The communication interface is used for wired or wireless communication with external terminals; wireless communication can be achieved through Wi-Fi, carrier networks, NFC (Near Field Communication), or other technologies. When the computer program is executed by the processor, it implements a data sharing method. The display screen can be an LCD screen or an e-ink screen. The input devices can be a touch layer covering the display screen, buttons, a trackball, or a touchpad mounted on the computer device casing, or an external keyboard, touchpad, or mouse.

[0268] Those skilled in the art will understand that Figure 18The structure shown is merely a block diagram of a portion of the structure related to the present application and does not constitute a limitation on the computer device to which the present application is applied. Specific computer devices may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0269] In one embodiment, a computer device is provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to perform the following steps:

[0270] In response to a user's data access request, cross-domain security authentication is performed on the user; the data access request is used to request access to a target data file stored in the first security domain; the user is a user in the second security domain; the first security domain and the second security domain are different security domains;

[0271] If the cross-domain security verification of the accessing user is successful, the decryption information of the target data file is sent to the accessing user; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0272] In one embodiment, the processor performs the following steps when executing a computer program:

[0273] Obtain the cross-domain access credentials and data access requests of the accessing user;

[0274] Cross-domain authentication for the accessing user is successful; obtain the accessing user's private key.

[0275] If the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, then the decryption information of the target data file is sent to the accessing user; the decryption information includes at least: the encryption key, the hash value of the target data file, the accessing user's attribute private key, and the public parameters of the first security domain.

[0276] In one embodiment, the processor performs the following steps when executing a computer program:

[0277] The system authenticates the accessing user. After successful authentication, the system sends a data access request to the cross-domain consortium blockchain to instruct the blockchain to generate cross-domain access credentials and routing information for the accessing user, and then sends the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials.

[0278] It receives cross-domain access credentials and data access requests uploaded by users through a communication channel; the communication channel is established by the users based on routing information.

[0279] In one embodiment, the processor performs the following steps when executing a computer program:

[0280] Based on the data access request of the accessing user, the access control center of the first security domain searches for the accessing user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain.

[0281] Compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained from the first security domain;

[0282] If the comparison results are consistent, the cross-domain verification of the accessing user is confirmed to be successful.

[0283] In one embodiment, the processor performs the following steps when executing a computer program:

[0284] Retrieve cross-domain attributes of the accessing user;

[0285] Generate the access user's attribute private key based on the cross-domain attributes of the accessing user and the master key preset in the first security domain.

[0286] In one embodiment, the processor performs the following steps when executing a computer program:

[0287] Generate a search keyword trap based on the accessing user's private key and search keywords;

[0288] Match search keywords based on the search keyword gate and the shared ciphertext in the first security domain;

[0289] If the matching result meets the preset conditions, the access user's attribute private key and the shared ciphertext of the target data file in the first security domain are determined.

[0290] In one embodiment, the processor performs the following steps when executing a computer program:

[0291] When the hash value of the target data file matches the hash value pre-stored in the local consortium blockchain in the first security domain, the encrypted data file of the target data file is decrypted according to the decrypted encryption key to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters, attribute private key and encryption key of the first security domain.

[0292] In one embodiment, the processor performs the following steps when executing a computer program:

[0293] In response to a data storage request, the encrypted data carried in the data storage request is stored; the encrypted data is generated by the storage user based on the data file to be stored.

[0294] In one embodiment, the processor performs the following steps when executing a computer program:

[0295] Generate file keywords and access structure based on the data file to be stored;

[0296] The keyword ciphertext is obtained based on the public parameters of the first security domain, the file keywords, and the access structure;

[0297] Based on the data file to be stored and the preset key, generate an encrypted data file and its hash value.

[0298] The encryption key is obtained based on the preset key, public parameters, and access structure.

[0299] In one embodiment, the processor performs the following steps when executing a computer program:

[0300] The encrypted data file is sent to the shared cloud platform of the first security domain for storage, and the encrypted data is sent to the local consortium blockchain of the first security domain in a preset format.

[0301] After the smart contract is triggered, the encrypted data file is stored in the local consortium blockchain of the first security domain.

[0302] The computer device provided in the above embodiments has a similar implementation principle and technical effect to the above method embodiments, and will not be described again here.

[0303] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, the computer program performing the following steps when executed by a processor:

[0304] In response to a user's data access request, cross-domain security authentication is performed on the user; the data access request is used to request access to a target data file stored in the first security domain; the user is a user in the second security domain; the first security domain and the second security domain are different security domains;

[0305] If the cross-domain security verification of the accessing user is successful, the decryption information of the target data file is sent to the accessing user; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file.

[0306] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0307] Obtain the cross-domain access credentials and data access requests of the accessing user;

[0308] Cross-domain authentication for the accessing user is successful; obtain the accessing user's private key.

[0309] If the accessing user's attribute private key matches the shared ciphertext of the target data file pre-configured in the first security domain, then the decryption information of the target data file is sent to the accessing user; the decryption information includes at least: the encryption key, the hash value of the target data file, the accessing user's attribute private key, and the public parameters of the first security domain.

[0310] In one embodiment, when the computer program is executed by a processor, it performs the following steps: authenticating the accessing user; after successful authentication, sending a data access request to the cross-domain consortium blockchain to instruct the cross-domain consortium blockchain to generate cross-domain access credentials and routing information for the accessing user, and sending the cross-domain access credentials to the accessing user; the cross-domain access credentials include cross-domain attributes and access credentials.

[0311] It receives cross-domain access credentials and data access requests uploaded by users through a communication channel; the communication channel is established by the users based on routing information.

[0312] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0313] Based on the data access request of the accessing user, the access control center of the first security domain searches for the accessing user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain.

[0314] Compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained from the first security domain;

[0315] If the comparison results are consistent, the cross-domain verification of the accessing user is confirmed to be successful.

[0316] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0317] Retrieve cross-domain attributes of the accessing user;

[0318] Generate the access user's attribute private key based on the cross-domain attributes of the accessing user and the master key preset in the first security domain.

[0319] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0320] Generate a search keyword trap based on the accessing user's private key and search keywords;

[0321] The search keywords are matched based on the search keyword gate and the shared ciphertext in the first security domain;

[0322] If the matching result meets the preset conditions, the access user's attribute private key and the shared ciphertext of the target data file in the first security domain are determined.

[0323] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0324] When the hash value of the target data file matches the hash value pre-stored in the local consortium blockchain in the first security domain, the encrypted data file of the target data file is decrypted according to the decrypted encryption key to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters, attribute private key and encryption key of the first security domain.

[0325] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0326] In response to a data storage request, the encrypted data carried in the data storage request is stored; the encrypted data is generated by the storage user based on the data file to be stored.

[0327] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0328] Generate file keywords and access structure based on the data file to be stored;

[0329] The keyword ciphertext is obtained based on the public parameters of the first security domain, the file keywords, and the access structure;

[0330] Based on the data file to be stored and the preset key, generate an encrypted data file and the hash value of the encrypted data file;

[0331] The encryption key is obtained based on the preset key, public parameters, and access structure.

[0332] In one embodiment, when the computer program is executed by a processor, it performs the following steps:

[0333] The encrypted data file is sent to the shared cloud platform of the first security domain for storage, and the encrypted data is sent to the local consortium blockchain of the first security domain in a preset format.

[0334] After the smart contract is triggered, the encrypted data file is stored in the local consortium blockchain of the first security domain.

[0335] The computer-readable storage medium provided in the above embodiments has a similar implementation principle and technical effect to the above method embodiments, and will not be described again here.

[0336] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the methods described above. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include at least one of non-volatile and volatile memory. Non-volatile memory can include read-only memory (ROM), magnetic tape, floppy disk, flash memory, or optical storage, etc. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM can be in various forms, such as static random access memory (SRAM) or dynamic random access memory (DRAM), etc.

[0337] The technical features of the above embodiments can be combined in any way. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as there is no contradiction in the combination of these technical features, they should be considered to be within the scope of this specification.

[0338] The embodiments described above are merely illustrative of several implementation methods of this application, and while the descriptions are relatively specific and detailed, they should not be construed as limiting the scope of the invention patent. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of this application, and these all fall within the protection scope of this application. Therefore, the protection scope of this patent application should be determined by the appended claims.

Claims

1. A data sharing method, characterized in that, The method includes: In response to a user's data access request, the first security domain performs cross-domain security verification on the user; the data access request is for requesting access to a target data file stored in the first security domain; the user is a user in the second security domain; the first security domain and the second security domain are different security domains. If the cross-domain security verification of the accessing user is successful, then the decryption information of the target data file is sent to the accessing user; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file; The cross-domain security verification of the accessing user includes: The identity authentication server of the first security domain authenticates the accessing user. After successful authentication, it sends the data access request to the cross-domain consortium blockchain to instruct the cross-domain consortium blockchain to generate cross-domain access credentials and routing information for the accessing user, and sends the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials. The access control center of the first security domain receives the cross-domain access credentials and the data access request uploaded by the accessing user through a communication channel; the communication channel is established by the accessing user based on the routing information. If the cross-domain verification of the accessing user is successful, obtain the accessing user's attribute private key; If the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain, then the decryption information of the target data file is sent to the accessing user.

2. The method according to claim 1, characterized in that, The decryption information includes at least: the encryption key, the hash value of the target data file, the private key of the accessing user, and the public parameters of the first security domain.

3. The method according to claim 1 or 2, characterized in that, Before obtaining the private key of the accessing user's attributes, the method further includes: Based on the data access request of the accessing user, the access control center of the first security domain searches for the accessing user's pre-stored cross-domain access credentials in the cross-domain consortium blockchain. Compare the pre-stored cross-domain access credentials with the cross-domain access credentials of the accessing user obtained by the first security domain. If the comparison results are consistent, the cross-domain verification of the accessing user is confirmed to be successful.

4. The method according to claim 1 or 2, characterized in that, The step of obtaining the access user's attribute private key includes: The key management center of the first security domain obtains the cross-domain attributes of the accessing user; The key management center of the first security domain generates the attribute private key of the accessing user based on the cross-domain attribute of the accessing user and the preset master key of the first security domain.

5. The method according to claim 1 or 2, characterized in that, The method further includes: The access control center of the first security domain generates a search keyword trap based on the access user's attribute private key and search keywords; The access control center of the first security domain matches the search keywords based on the search keyword trap and the shared ciphertext in the first security domain; If the matching result meets the preset conditions, then the attribute private key of the accessing user is determined to be the shared ciphertext of the target data file in the first security domain.

6. The method according to claim 1 or 2, characterized in that, The process by which the accessing user decrypts the encrypted data in the target data file includes: When the hash value of the target data file matches the hash value pre-stored in the local consortium blockchain in the first security domain, the accessing user decrypts the encrypted data file of the target data file according to the decrypted encryption key to obtain the target data file; the decrypted encryption key is determined by the accessing user based on the public parameters of the first security domain, the attribute private key and the encryption key.

7. The method according to claim 1 or 2, characterized in that, The storage process of the target data file in the first security domain includes: The first security domain responds to a data storage request by storing the encrypted data carried in the data storage request; the encrypted data is generated by the storage user based on the data file to be stored.

8. The method according to claim 7, characterized in that, The encrypted data includes at least the access structure of the data file to be stored, the keyword ciphertext, the encrypted data file, the hash value of the encrypted data file, and the signature information of the storage user; The encrypted data is obtained by the storage user through an encryption operation; wherein the encryption operation includes: Generate file keywords and access structure based on the data file to be stored; The keyword ciphertext is obtained based on the public parameters of the first security domain, the file keywords, and the access structure; Based on the data file to be stored and the preset key, generate the encrypted data file and the hash value of the encrypted data file; The encryption key is obtained based on the preset key, the public parameters, and the access structure.

9. The method according to claim 8, characterized in that, The step of storing the encrypted data carried in the data storage request includes: The first security domain sends the encrypted data file to its shared cloud platform for storage, and sends the encrypted data to its local consortium blockchain in a preset format. Specifically, after the smart contract is triggered, the consortium blockchain of the first security domain stores the encrypted data file in the local consortium blockchain of the first security domain.

10. A data sharing device, characterized in that, The device includes: The response module is used by the first security domain to respond to a data access request from an accessing user and perform cross-domain security verification on the accessing user; the data access request is used to request access to a target data file stored in the first security domain; the accessing user is a user in the second security domain; the first security domain and the second security domain are different security domains. The decryption module is used to send decryption information of the target data file to the accessing user if the cross-domain security verification of the accessing user is successful; the decryption information is used to instruct the accessing user to decrypt the encrypted data of the target data file to obtain the target data file. The response module includes: The first acquisition unit is used by the identity authentication server of the first security domain to authenticate the accessing user. After the authentication is successful, the data access request is sent to the cross-domain consortium chain to instruct the cross-domain consortium chain to generate the cross-domain access credentials and routing information of the accessing user, and to send the cross-domain access credentials to the accessing user. The cross-domain access credentials include cross-domain attributes and access credentials. The first acquisition unit is further configured to receive, from the access control center of the first security domain, the cross-domain access credentials and the data access request uploaded by the access user through a communication channel; the communication channel is established by the access user based on the routing information; The second acquisition unit is used to acquire the access user's attribute private key if the cross-domain verification of the access user is successful. The decryption unit is configured to send decryption information of the target data file to the accessing user if the accessing user's attribute private key matches the pre-configured shared ciphertext in the first security domain.

Images