A data access method and device, electronic equipment and storage medium

Abstract

Embodiments of the present application disclose a data access method and device, electronic equipment and a storage medium. The method comprises: submitting attribute proof to a hardware security center, so that the hardware security center performs attribute authentication according to the attribute proof and constructs an attribute private key according to the attribute proof after authentication; receiving the attribute private key sent by the hardware security center, and initiating a data query request to a cloud node, so that the cloud node performs hierarchical verification according to the attribute private key in the data query request, and determines an attribute matching result after the hierarchical verification is passed; receiving the encrypted ciphertext and the attribute matching result sent by the cloud node, and decrypting the encrypted ciphertext according to the attribute matching result and the attribute private key to obtain target plaintext data. The method realizes hierarchical verification of a data access user first, prevents data access users of non-allowed levels from accessing data by force, and protects the data owner's demand for data access permission.

Description

Technical Field

[0001] The present invention relates to the field of integrated circuit data processing technology, and in particular to a data access method, apparatus, electronic device and storage medium. Background Technology

[0002] In the wave of digitalization in integrated circuit design and manufacturing, the demand for sharing multimodal sensitive data by chip design companies and foundries is growing exponentially.

[0003] Currently, access control schemes based on ciphertext policy attribute-based encryption are widely used in multimodal data hierarchical sharing scenarios in integrated circuits. For example, the chip design director is at a higher level than a senior engineer, and a senior engineer is at a higher level than a junior engineer. This hierarchical division automatically grants higher-level users greater access privileges. However, when higher-level users access data they shouldn't have access to, their access operations violate the confidentiality requirements set by the data owner. Summary of the Invention

[0004] This invention provides a data access method, apparatus, electronic device, and storage medium that verifies the hierarchy of data access users beforehand, preventing unauthorized access by users at levels not permitted by the access policy, and protecting the data owner's need for their own data access permissions.

[0005] In a first aspect, embodiments of the present invention provide a data access method, the method comprising:

[0006] Submit attribute proofs to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proofs and construct attribute private keys based on the attribute proofs after authentication.

[0007] It receives the attribute private key sent by the hardware security center and initiates a data query request to the cloud node, so that the cloud node can perform hierarchical verification based on the attribute private key in the data query request, and determine the attribute matching result after the hierarchical verification is successful.

[0008] It receives encrypted ciphertext and attribute matching results sent by the cloud node, and decrypts the encrypted ciphertext according to the attribute matching results and attribute private key to obtain the target plaintext data.

[0009] The data access method provided in this invention requires that when a data accessor needs to obtain a decryption key from a hardware security center, the data accessor's attributes are first authenticated by the hardware security center. Then, the hardware security center generates a unique attribute private key based on the data accessor's corresponding attribute information, thus initially verifying and clarifying the data accessor's attributes. After verifying the authenticity of the data accessor's attributes, the cloud node verifies the data accessor's level based on the access policy corresponding to the data to be accessed. After the level verification is passed, other attributes of the data accessor are further verified, ensuring that the data accessor meets the permissions to access the required data in terms of both level and other attributes. This not only ensures that the data accessor can securely access data with the required permissions, but also solves the problem of high-level users accessing data they shouldn't, thus preventing unauthorized access by users at levels not permitted by the access policy and protecting the data owner's data access permissions. Only when the attribute matching result is successful can it be used as a necessary component to decrypt the encrypted ciphertext. This ensures that the data accessor must have all the attribute information that meets the access policy corresponding to the data to be accessed before the encrypted ciphertext can be decrypted, thereby achieving further data security protection and preventing the leakage of sensitive data privacy.

[0010] Secondly, embodiments of the present invention also provide a data access device, the device comprising:

[0011] The submission module is used to submit attribute proofs to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proofs and construct attribute private keys based on the attribute proofs after authentication.

[0012] The request module is used to receive the attribute private key sent by the hardware security center and initiate a data query request to the cloud node, so that the cloud node can perform hierarchical verification based on the attribute private key in the data query request, and determine the attribute matching result after the hierarchical verification is successful.

[0013] The decryption module is used to receive encrypted ciphertext and attribute matching results sent by the cloud node, and decrypt the encrypted ciphertext according to the attribute matching results and attribute private key to obtain the target plaintext data.

[0014] Thirdly, embodiments of the present invention also provide an electronic device, the electronic device comprising:

[0015] At least one processor; and

[0016] A memory that is communicatively connected to at least one processor; wherein,

[0017] The memory stores a computer program that can be executed by at least one processor, such that the at least one processor is able to perform the data access method of any embodiment of the present invention.

[0018] Fourthly, embodiments of the present invention also provide a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the data access method of any embodiment of the present invention.

[0019] Fifthly, embodiments of the present invention also provide a computer program product, including a computer program that, when executed by a processor, implements the data access method of any embodiment of the present invention.

[0020] It should be noted that the aforementioned computer instructions may be stored, in whole or in part, on a computer-readable storage medium. This computer-readable storage medium may be packaged together with the processor of the data access device, or it may be packaged separately from the processor of the data access device; this application does not impose any limitations on this.

[0021] The descriptions of the second, third, fourth, and fifth aspects in this application can be referred to the detailed description of the first aspect; and the beneficial effects of the descriptions of the second, third, fourth, and fifth aspects can be referred to the analysis of the beneficial effects of the first aspect, which will not be repeated here.

[0022] In this application, the names of the aforementioned data access devices do not limit the devices or functional modules themselves. In actual implementation, these devices or functional modules may appear under other names. As long as the functions of each device or functional module are similar to those in this application, they fall within the scope of the claims of this application and their equivalents.

[0023] These or other aspects of this application will become more readily apparent in the following description. Attached Figure Description

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

[0025] Figure 1 A flowchart illustrating a data access method provided in an embodiment of the present invention;

[0026] Figure 2 A flowchart illustrating another data access method provided in an embodiment of the present invention;

[0027] Figure 3 This is a schematic diagram of the structure of a data access device provided in an embodiment of the present invention;

[0028] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Detailed Implementation

[0029] The present invention will now be described in further detail with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and not intended to limit it. Furthermore, it should be noted that, for ease of description, the accompanying drawings show only the parts relevant to the present invention, and not all of the structures.

[0030] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0031] The terms “initial” and “target” in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0032] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0033] Before discussing the exemplary embodiments in more detail, it should be noted that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe the operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the figures. The process can correspond to a method, function, procedure, subroutine, subroutine, etc. Moreover, embodiments and features in the embodiments of the present invention can be combined with each other without conflict.

[0034] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0035] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0036] Figure 1 This is a flowchart illustrating a data access method provided in an embodiment of the present invention. This embodiment is applicable to scenarios involving the sharing of multimodal sensitive data in integrated circuits, where access authentication is performed on entities needing to access shared sensitive data to protect the security of shared sensitive data and the rights of data owners. This method can be executed by a data access device, which can be implemented in hardware and / or software and can be configured in an electronic device. In this embodiment, the electronic device can be a data user (data accessor); when the electronic device is a data accessor, it mainly refers to the device used by the entity needing to access shared sensitive data, such as a computer or server used by employees in a chip foundry who need to access chip design data. (Continuing to refer to...) Figure 1 Specifically, it includes the following steps:

[0037] S101. Submit the attribute proof to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proof and construct the attribute private key based on the attribute proof after authentication.

[0038] The hardware security center is used to centrally manage cryptographic keys and operations via hardware. In this embodiment, the hardware security center can be a Tiered Key Control Center (TKCC). Attribute proof refers to the qualifications and attribute level possessed by the data accessor. In this embodiment, attribute proof can be types of proof such as "Senior Process Engineer," "Graphics Processing Unit (GPU) Layout Interpretation," and "Timing Simulation Analysis." Attribute authentication is the operation performed by the hardware security center to authenticate the attribute proof of the data accessor. The attribute private key is the decryption key bound to the attribute information in the attribute proof possessed by the data accessor.

[0039] Specifically, when a data access user needs to access multimodal sensitive data such as chip design drawings, they can submit attribute proof to the hardware security center. The hardware security center first authenticates the attribute proof submitted by the data access user to determine whether the attributes are genuinely possessed. Then, after the attribute authentication is passed, the attribute information possessed by the data access user in the attribute authentication can be determined as the data access user's attribute set, and an attribute private key can be constructed based on pre-generated system-level public parameters.

[0040] In this embodiment, when a data access user needs to obtain a decryption key from the hardware security center, the user must first undergo attribute authentication by the hardware security center. Then, the hardware security center generates a unique attribute private key based on the user's corresponding attribute information. This achieves preliminary verification and clarification of the data access user's attributes, providing a foundation for determining the user's access permissions in the future.

[0041] S102. Receive the attribute private key sent by the hardware security center and initiate a data query request to the cloud node so that the cloud node can perform hierarchical verification based on the attribute private key in the data query request, and determine the attribute matching result after the hierarchical verification is passed.

[0042] In this embodiment, the cloud node stores the data that the data accessor needs to access. In this embodiment, the cloud node can be a Layered Verification Cloud Node (LVC). The data query request carries an attribute private key, which informs the cloud node of the data that needs to be retrieved. Layered verification verifies whether the attribute level possessed by the data accessor matches the allowed access level in the access policy corresponding to the data currently needed. The attribute matching result further verifies whether all attribute information possessed by the data accessor satisfies the access policy corresponding to the data currently needed. In this embodiment, if satisfied, the attribute matching result contains a specific necessary component for decrypting the ciphertext; if not satisfied, the attribute matching result is a random or meaningless value.

[0043] Specifically, after constructing the attribute private key, the hardware security center sends it to the data accessor. The data accessor can then initiate a data query request to the cloud node to inform it that it needs to access the target data. The cloud node first performs a hierarchical verification based on the access policy in the data requested by the data accessor and the data accessor's hierarchy in the attribute private key. If the hierarchy specified in the access policy matches the data accessor's hierarchy, the hierarchical verification passes; otherwise, it fails. Furthermore, after the hierarchical verification passes, the cloud node continues to perform matching calculations based on the "other attribute requirements" in the access policy and the "other attributes possessed" in the data accessor's attribute private key to obtain the attribute matching result.

[0044] In this embodiment, after verifying the authenticity of the data visitor's attributes, the cloud node first verifies the data visitor's level based on the access policy corresponding to the data to be accessed. After the level verification is passed, other attributes of the data visitor are further verified to ensure that the data visitor meets the permission requirements to access the data required, whether in terms of level or other attributes. This not only ensures that the data visitor can securely access the data when they have the necessary access permissions, but also solves the problem that high-level users may access data they should not be able to access without authorization, thus preventing data owners from meeting their confidentiality requirements. This achieves the goal of verifying the data visitor's level first, preventing data visitors at levels not permitted by the access policy from accessing the data without authorization, and protecting the data owner's requirements for their own data access permissions.

[0045] S103. Receive the encrypted ciphertext and attribute matching result sent by the cloud node, and decrypt the encrypted ciphertext according to the attribute matching result and the attribute private key to obtain the target plaintext data.

[0046] The encrypted ciphertext is the ciphertext uploaded to the cloud node storage after the data owner encrypts the target plaintext data using the encryption key issued by the hardware security center. The target plaintext data is the data that the data accessor currently needs to access.

[0047] Specifically, after calculating the attribute matching result, the cloud node can send the encrypted ciphertext and the attribute matching result back to the data accessor, regardless of the result. If the attribute matching result is successful, the result contains the necessary components for decrypting the ciphertext, and the ciphertext can be directly decrypted using the attribute matching result and the attribute private key to obtain the target plaintext data. If the attribute matching result is unsuccessful, even if the data accessor obtains the ciphertext, they cannot decrypt it using the attribute matching result and the attribute private key, and therefore cannot obtain the target plaintext data.

[0048] In this embodiment, the attribute matching result can only be used as a necessary component to decrypt the encrypted ciphertext when it passes the test. This ensures that the attribute information possessed by the data accessor must fully meet the access policy corresponding to the data to be accessed before the encrypted ciphertext can be decrypted, thereby achieving further security protection of the data and preventing the leakage of sensitive data privacy.

[0049] The data access method provided in this invention requires that when a data accessor needs to obtain a decryption key from a hardware security center, the data accessor's attributes are first authenticated by the hardware security center. Then, the hardware security center generates a unique attribute private key based on the data accessor's corresponding attribute information, thus initially verifying and clarifying the data accessor's attributes. After verifying the authenticity of the data accessor's attributes, the cloud node verifies the data accessor's level based on the access policy corresponding to the data to be accessed. After the level verification is passed, other attributes of the data accessor are further verified, ensuring that the data accessor meets the permissions to access the required data in terms of both level and other attributes. This not only ensures that the data accessor can securely access data with the required permissions, but also solves the problem of high-level users accessing data they shouldn't, thus preventing unauthorized access by users at levels not permitted by the access policy and protecting the data owner's data access permissions. Only when the attribute matching result is successful can it be used as a necessary component to decrypt the encrypted ciphertext. This ensures that the data accessor must have all the attribute information that meets the access policy corresponding to the data to be accessed before the encrypted ciphertext can be decrypted, thereby achieving further data security protection and preventing the leakage of sensitive data privacy.

[0050] Figure 2 This is a flowchart illustrating another data access method provided by an embodiment of the present invention. This embodiment details the steps of obtaining the attribute private key, determining the attribute matching result, and obtaining the target plaintext data, based on the above embodiments. In this embodiment, to facilitate the demonstration of the interaction between the data owner and the data accessor, the method is specifically described using an electronic device where both the data owner and the data accessor use the same device. That is, in this embodiment, the electronic device can also be the data owner; when the electronic device is the data owner, it mainly refers to the entity that owns the multimodal sensitive data (such as a computer or server used by users in government departments, financial institutions, medical institutions, etc.), and possesses ownership of its own data.

[0051] Continue to refer to Figure 2 The method may also include:

[0052] S201. Send an encryption request to the hardware security center so that the hardware security center can construct the system master private key based on the number of supported multimodal attributes and the number of chip layers, and determine the public parameters based on the parameters in the system master private key.

[0053] In this embodiment, S201-S203 represent interactions between the data owner and the hardware security center and the cloud node, respectively. The encryption request informs the hardware security center that the target plaintext data belonging to the data owner needs to be encrypted. The supported multimodal attribute count is the maximum number of multimodal attributes that the current electronic device can support; in this embodiment, it refers to the maximum number of multimodal attributes that the system can process simultaneously (e.g., the total number of different types of attributes such as chip functional specification text, layout images, and timing simulation audio does not exceed this value) set during system initialization. In actual scenarios, the number of attributes used may be less than this value; its purpose is to reserve expandable attribute capacity for the system while avoiding excessive computational complexity due to an unlimited number of attributes. The chip level count refers to the maximum number of chip industry job levels that the current electronic device can support during initialization; in this embodiment, it is used to standardize the permission boundaries of different job levels (such as design director, senior engineer, junior engineer, technician, etc.) in the integrated circuit industry chain, ensuring hierarchical access control of multimodal chip data (layout images, functional specification text, timing simulation audio, etc.).

[0054] Specifically, when a data owner needs to encrypt target plaintext data, they can first send an encryption request to the hardware security center. Upon receiving the encryption request, the hardware security center constructs the system master private key using security parameters, the number of supported multimodal attributes, and the number of chip layers, and calculates the system's public parameters.

[0055] For example, first, a security parameter λ is chosen. This parameter determines the security level of the key. The larger the value, the larger the group size is usually, and therefore the more secure it is (but the computational efficiency will decrease). Further, a group generation algorithm is run, i.e., an elliptic curve satisfying the security properties is selected, or computation is performed based on a group over a finite field, to obtain a complete group description, i.e., a bilinear group (G, G) of order p with prime numbers. r (g, p, e). Here, G is an additive cyclic group of order p; in elliptic curve cryptography, this group is the set of points on the elliptic curve; the encryption and key generation of all chip multimodal attributes are based on the operational rules of this group, ensuring data security within the group. G r G is a multiplicative cyclic group of order p; typically a multiplicative subgroup of a finite field, it is the "result output space" of a bilinear mapping used to carry the ciphertext operation results of multimodal data (such as chip layout images and functional specification text), ensuring that the encryption results of different modal data can be uniformly verified. g is a generator of group G; the secret exponents of the chip's multimodal attributes (such as hierarchy and permission identifiers) are embedded into the key and ciphertext through powers of g. p is the order of the group, a very large prime number; group G and G... r Both contain p elements. e is a bilinear mapping function that accepts two elements from G and maps them to G.r One of the elements. Also, from the integer ring Zp modulo p. * A set of secret indices is randomly selected, including a, b, s1, ..., s. n ,θ1,...,θ t Where 'a' is the system-level secret index, used to construct the core component of the master private key. 'b' is also a system-level secret index, used to construct the hierarchical verification component of public parameters, working in conjunction with the hierarchical index θ to achieve chip-level access control. s1, ..., s n There are n numbers, each corresponding to a multimodal attribute (e.g., s1 represents "text specifications", s2 represents "layout image", ... up to the number of supported multimodal attributes n). θ1, ..., θ t There are t numbers, each corresponding to a chip level (e.g., θ1 represents "Director Level", θ2 represents "Senior Engineer Level", and so on, up to the chip level t). Furthermore, these secret indices are treated as a set {}, which is the system master private key TMSK = {a, b, s1, ..., s...} n ,θ1,...,θ t Finally, using a public base g, exponentiation is performed on each secret number in the system master private key TMSK; that is, for a, e(g, g) is calculated. a For b, calculate g. b For each multimodal attribute s i ,calculate For each chip level θ j ,calculate Collect all the calculated values ​​into a set to obtain the system's common parameters: TPP = { , , ,..., , ,..., }

[0056] Optionally, after the system master private key and public parameters are built in the hardware security center, the system master private key can be kept safe by itself, and the public parameters TPP can be publicly released.

[0057] S202. Receive the public parameters and encrypt the data to be encrypted according to the access policy and the public parameters to obtain the encrypted ciphertext.

[0058] The access policy is a set of rules established by the data owner for accessing the data to be encrypted, such as access qualifications or access requirements. In this embodiment, the access policy may include hierarchical requirements and multimodal attribute constraints. The data to be encrypted in this embodiment can be any data that the data owner currently needs to encrypt, or data that a data accessor will need to access later.

[0059] Specifically, after receiving the public parameters, the data owner can encrypt the data to be encrypted according to the access policy and the public parameters, and finally obtain the encrypted ciphertext.

[0060] For example, public parameters are received, and the data to be encrypted is encrypted according to the access policy and the public parameters to obtain encrypted ciphertext, including:

[0061] (i) Use common parameters to process the data to be encrypted to obtain the ciphertext component of the message.

[0062] Specifically, we can start with Zp * Then randomly select a secret value l, and based on the secret value and the public parameters e(g, g), a The encrypted data m is processed to obtain the ciphertext component of the message. .

[0063] (ii) Determine the hierarchical ciphertext component and the attribute vector ciphertext component based on the common parameters, and combine the message ciphertext component, the attribute vector ciphertext component and the hierarchical ciphertext component into encrypted ciphertext.

[0064] Specifically, this step further includes:

[0065] (1) Select a secret value and determine the hierarchical ciphertext component based on the secret value and the public parameters.

[0066] This secret value is the same as the secret value l mentioned above.

[0067] Specifically, it can be based on each of the public parameters. Determine j levels of ciphertext components .

[0068] (2) Transform the access strategy into a vector form to obtain the vector access strategy, and determine the attribute vector ciphertext components based on the secret value, public parameters and vector access strategy.

[0069] Specifically, since the access strategy P may be in text or other forms and cannot be directly calculated, the access strategy containing hierarchy and attribute constraints can be converted into a vector form v = (v1, ..., v2) using a strategy mathematical encoding method. nThis refers to the vector access strategy; the number of strategies x represents the number of access strategies. Furthermore, the ciphertext components of the attribute vector can be determined based on the secret value, common parameters, and vector access strategies. Where i∈[1,n].

[0070] (3) Combine the message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component into an encrypted ciphertext.

[0071] Specifically, after calculating the message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component, the components can be combined into encrypted ciphertext: .

[0072] In this embodiment, the data owner encrypts the data using the public parameters provided by the hardware security center and the access policy set by themselves. This allows them to incorporate their own security permission requirements for the data into the data protection, providing a protective basis for subsequent data access users to have the same attributes in order to successfully decrypt and obtain the data.

[0073] S203. Upload the encrypted ciphertext and access policy to the cloud node storage.

[0074] Specifically, data owners can upload encrypted ciphertext, access policies, and data digests of the encrypted ciphertext to cloud nodes for storage.

[0075] S204. Submit attribute proof to the Hardware Security Center so that the Hardware Security Center can determine the attribute authentication result based on the attribute proof.

[0076] In this embodiment, steps S204-S209 represent interactions between the data visitor and the hardware security center and the cloud node, respectively. Optionally, the attribute verification in this embodiment may also include the data visitor's identity information.

[0077] Specifically, when a data access user needs to access multimodal sensitive data such as chip design drawings, they can submit attribute proof to the hardware security center. The hardware security center first authenticates the attribute proof submitted by the data access user to determine whether the attribute is a genuine attribute. If it is a genuine attribute, the attribute authentication result is deemed successful; otherwise, the attribute authentication result is deemed unsuccessful.

[0078] S205. Receive the attribute authentication result sent by the hardware security center, and when the attribute authentication result is successful, initiate an acquisition request to the hardware security center so that the hardware security center can construct the attribute private key based on the acquisition request and the attribute proof.

[0079] Specifically, the data accessor receives the attribute authentication result from the hardware security center. If the attribute authentication result is successful, the data accessor can directly initiate a request to the hardware security center, which can then construct the attribute private key based on the attribute proof. If the attribute authentication result is unsuccessful, the hardware security center will not begin constructing the attribute private key even if the data accessor initiates a request to the hardware security center.

[0080] For example, the process by which the hardware security center constructs the attribute private key is as follows: The hardware security center creates an attribute list U based on the information in the data accessor's attribute certificate, which includes the data accessor's level and specific attributes, such as department, position, and projects involved. Then, from Zp... * Then randomly select a set of secret values ​​r = {r1, ..., r2} b}, where b is the number of attributes owned by the data accessor. Then, using a and b from the system master private key, and the aforementioned... Calculate the basic component key , where θ k For the hierarchical secret set {θ1, ..., θ} from the master private key t Select the θ that corresponds to the data visitor level number k from the list. Also, for each attribute u in user U... f Computational attribute private key component , where K f To be with s f The corresponding attribute private key component, each s f For the attribute u in user U f The corresponding s1, ..., s n The attributes in the data. Finally, the hierarchical attribute private key (attribute private key) can be constructed. In this embodiment, "{}" represents a set.

[0081] S206. Receive the attribute private key sent by the hardware security center.

[0082] Specifically, after the data accessor generates the attribute private key in the hardware security center, they can receive the attribute private key sent by the hardware security center.

[0083] In this embodiment, when a data accessor requests a key for decryption from the hardware security center, the data accessor must first undergo real-time verification of its own qualifications by the hardware security center. After confirming that the data accessor's qualifications are genuine, an attribute private key is generated based on the data accessor's own attribute qualifications. In this way, even if the data accessor obtains the attribute private key, the attributes possessed by the data accessor in the attribute private key must be consistent with the access policy required by the ciphertext to be decrypted in order to decrypt the encrypted ciphertext.

[0084] S207. Initiate a data query request to the cloud node so that the cloud node can perform hierarchical verification based on the attribute private key and the public parameters disclosed by the hardware security center, and determine the attribute matching result based on the attribute private key and the public parameters when the hierarchical verification result is passed.

[0085] Specifically, after a data user obtains the attribute private key, they can initiate a data query request to the cloud node. The cloud node can then perform a level verification on the data user based on the attribute private key and the publicly available parameters published by the hardware security center. This verification checks whether the data user's actual level matches the level required to decrypt the encrypted ciphertext. If they match, the level verification is successful, and the cloud node determines the attribute matching result based on the attribute private key and the public parameters. If they do not match, the level verification fails, and the cloud node either randomly generates an attribute matching result or directly reports the level verification failure result to the data user.

[0086] For example, in hierarchical verification, cloud nodes can use equations Verification. Furthermore, after successful verification, attribute matching results can be calculated based on the encrypted TCT text. In the verification process, in addition to directly calculating the attribute matching result, it can also be determined whether the data visitor is performing a first-time verification. If it is, the attribute matching result can be calculated directly; if it is not, the attribute matching result B' stored after the first verification can be retrieved directly. That is, the attribute matching result will be stored.

[0087] S208. Receive the encrypted ciphertext and attribute matching result, and verify the decryption qualification according to the access policy corresponding to the attribute proof and the encrypted ciphertext.

[0088] Specifically, after the cloud node calculates the attribute matching result, it can directly send the encrypted ciphertext and the attribute matching result to the data accesser. The data accesser can then verify whether it has the qualification to decrypt the encrypted ciphertext based on the access policy corresponding to the attribute proof and the encrypted ciphertext.

[0089] For example, after obtaining the encrypted ciphertext and attribute matching results, the data access user will first determine whether it meets the decryption qualification based on its own attribute list U and the access policy of the ciphertext, that is, the inner product of the user's attribute vector u and policy vector v satisfies the condition. If the result is positive, the verification is successful; where u represents each vector in U, and v represents the vector access strategy corresponding to u in the vector access strategy.

[0090] S209. When the decryption qualification is passed, the encrypted ciphertext is decrypted according to the attribute private key, the ciphertext component of the message sent by the cloud node, the attribute matching result, and the hierarchical ciphertext component to obtain the target plaintext data.

[0091] Specifically, if the data accessor meets the decryption qualification, i.e., the decryption qualification is passed, the data accessor can decrypt the encrypted ciphertext according to the attribute private key, the ciphertext component of the message sent by the cloud node, the attribute matching result, and the hierarchical ciphertext component to obtain the target plaintext data; if the data accessor does not meet the decryption qualification, i.e. the decryption qualification is not passed, even if the data accessor uses the attribute private key, the ciphertext component of the message sent by the cloud node, the attribute matching result, and the hierarchical ciphertext component to decrypt the encrypted ciphertext, it will not be able to obtain the correct target plaintext data.

[0092] For example, when the decryption qualification is passed, the encrypted ciphertext is decrypted, and the complete computer decomposition verification process is shown in the following formula:

[0093] ;

[0094] By performing the above operations, the target plaintext data m can be successfully recovered.

[0095] In this embodiment, the risk of multimodal sensitive information being speculated upon is completely eliminated by using an inner product vector mapping that is entirely hidden through the access policy, i.e., whether the decryption qualification is met. Hierarchical attribute management strictly restricts unauthorized access to lower-level data by upper-level users, ensuring the control of the data owner in hierarchical scenarios such as government affairs and healthcare. Furthermore, since the attribute matching results for the same data accesser can be stored during the attribute matching result determination stage, the permission matching results can be reused for accessers at the same level and with the same attributes, significantly reducing the redundant computation overhead of cloud nodes. In large-scale sensitive data sharing scenarios, computational efficiency is improved by more than half, meeting the real-time access requirements of sensitive data in sensitive scenarios such as government affairs and finance.

[0096] It is worth noting that all user information and user data obtained in this embodiment are only used for encryption and decryption in this embodiment, and are only used to protect the data and the data owner's rights to it. Furthermore, all personal information obtained must be confirmed by the user.

[0097] Optionally, in this embodiment, lattice cryptography can also be used to construct an attribute encryption scheme. This scheme leverages the shortest vector problem on a lattice to ensure security, offering low computational complexity and resistance to quantum attacks, making it suitable for resource-constrained devices in government, finance, and other fields. For example, data owners can encrypt sensitive data using lattice-based attribute encryption and set hierarchical access policies. Data access users can obtain the plaintext through a lattice-based decryption algorithm if the attributes are satisfied.

[0098] Optionally, in this embodiment, a decentralized index network for sensitive data can also be constructed using distributed hash table technology. Data summaries and access policies are stored in the distributed hash table network, and distributed data retrieval is achieved through consistent hashing. Combined with the access control logic of a lightweight distributed ledger, data owners can set hash-locking conditions for data access (such as unlocking access after paying a corresponding fee), enabling cross-level data sharing and access management, reducing resource consumption from cloud servers, and improving the efficiency of sensitive data sharing.

[0099] Optionally, in this embodiment, identity-based cryptography can also be used, with the data visitor's identity information (such as user ID, practitioner's business identification number, etc.) as the public key, and a trusted key generation center generating hierarchical identity private keys. The data owner encrypts the data based on the visitor's identity hierarchy and attributes, and the visitor decrypts it using the identity private key, realizing "identity + hierarchy" access control and simplifying the key management process.

[0100] Figure 3 This is a schematic diagram of the structure of a data access device provided in an embodiment of the present invention, such as... Figure 3 As shown, the device includes:

[0101] The submission module 301 is used to submit attribute proofs to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proofs and construct attribute private keys based on the attribute proofs after authentication.

[0102] The request module 302 is used to receive the attribute private key sent by the hardware security center and initiate a data query request to the cloud node, so that the cloud node can perform hierarchical verification based on the attribute private key in the data query request, and determine the attribute matching result after the hierarchical verification is passed.

[0103] The decryption module 303 is used to receive the encrypted ciphertext and attribute matching results sent by the cloud node, and decrypt the encrypted ciphertext according to the attribute matching results and the attribute private key to obtain the target plaintext data.

[0104] Based on the above embodiments, the submission module 301 is specifically used for:

[0105] Submit attribute proof to the hardware security center so that the hardware security center can determine the attribute authentication result based on the attribute proof; receive the attribute authentication result sent by the hardware security center, and when the attribute authentication result is successful, initiate an acquisition request to the hardware security center so that the hardware security center can construct the attribute private key based on the acquisition request and the attribute proof.

[0106] Based on the above embodiments, the request module 302 is specifically used for:

[0107] A data query request is sent to the cloud node so that the cloud node can perform hierarchical verification based on the attribute private key and the public parameters published by the hardware security center. If the hierarchical verification result is successful, the attribute matching result is determined based on the attribute private key and the public parameters.

[0108] Based on the above embodiments, the decryption module 303 is specifically used for:

[0109] Receive the encrypted ciphertext and attribute matching result, and verify the decryption qualification according to the access policy corresponding to the attribute proof and the encrypted ciphertext; when the decryption qualification is passed, decrypt the encrypted ciphertext according to the attribute private key, the ciphertext component of the message sent by the cloud node, the attribute matching result, and the hierarchical ciphertext component to obtain the target plaintext data.

[0110] Based on the above embodiments, the device further includes an encryption module, which is specifically used for:

[0111] An encryption request is sent to the hardware security center so that the hardware security center can construct a system master private key based on the number of supported multimodal attributes and the number of chip layers, and determine the public parameters based on the parameters in the system master private key; the public parameters are received, and the data to be encrypted is encrypted according to the access policy and the public parameters to obtain encrypted ciphertext; the encrypted ciphertext and access policy are uploaded to the cloud node storage.

[0112] Based on the above embodiments, the module receives public parameters and encrypts the data to be encrypted according to the access policy and the public parameters to obtain encrypted ciphertext. Specifically, the encryption module is used for:

[0113] The data to be encrypted is processed using common parameters to obtain the message ciphertext component; the hierarchical ciphertext component and the attribute vector ciphertext component are determined based on the common parameters, and the message ciphertext component, the attribute vector ciphertext component and the hierarchical ciphertext component are combined to form the encrypted ciphertext.

[0114] Based on the above embodiments, the hierarchical ciphertext component and the attribute vector ciphertext component are determined according to common parameters, and the message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component are combined into encrypted ciphertext. The encryption module is specifically used for:

[0115] Select a secret value and determine the hierarchical ciphertext component based on the secret value and public parameters; convert the access policy into vector form to obtain the vector access policy, and determine the attribute vector ciphertext component based on the secret value, public parameters, and vector access policy; combine the message ciphertext component, attribute vector ciphertext component, and hierarchical ciphertext component into encrypted ciphertext.

[0116] The data access device provided in the embodiments of the present invention can execute the data access method provided in any embodiment of the present invention, and has the corresponding functional modules and beneficial effects of executing the method.

[0117] It is worth noting that in the embodiments of the data access device described above, the various units and modules included are only divided according to functional logic, but are not limited to the above division, as long as the corresponding functions can be achieved; in addition, the specific names of each functional unit are only for easy differentiation and are not used to limit the scope of protection of the present invention.

[0118] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present invention. Figure 4 A block diagram is shown of an exemplary electronic device 11 suitable for implementing embodiments of the present invention. Figure 4 The electronic device 11 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of the present invention.

[0119] like Figure 4 As shown, the electronic device 11 is represented in the form of a general-purpose computing electronic device. The components of the electronic device 11 may include, but are not limited to: one or more processors or processing units 16, system memory 28, and bus 18 connecting different system components (including system memory 28 and processing unit 16).

[0120] Bus 18 represents one or more of several bus architectures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus using any of the various bus architectures. For example, these architectures include, but are not limited to, the Industry Standard Architecture (ISA) bus, the Micro Channel Architecture (MAC) bus, the Enhanced ISA bus, the Video Electronics Standards Association (VESA) local bus, and the Peripheral Component Interconnect (PCI) bus.

[0121] Electronic device 11 typically includes a variety of computer system readable media. These media can be any available media that can be accessed by electronic device 11, including volatile and non-volatile media, removable and non-removable media.

[0122] System memory 28 may include computer system readable media in the form of volatile memory, such as random access memory (RAM) 30 and / or cache memory 32. Electronic device 11 may further include other removable / non-removable, volatile / non-volatile computer system storage media. By way of example only, storage system 34 may be used to read and write non-removable, non-volatile magnetic media (… Figure 4 Not shown; usually referred to as a "hard drive"). Although Figure 4As not shown, disk drives for reading and writing to removable non-volatile disks (e.g., "floppy disks") and optical disc drives for reading and writing to removable non-volatile optical discs (e.g., CD-ROMs, DVD-ROMs, or other optical media) may be provided. In these cases, each drive may be connected to bus 18 via one or more data media interfaces. System memory 28 may include at least one program product having a set (e.g., at least one) of program modules configured to perform the functions of the embodiments of the present invention.

[0123] A program / utility 40 having a set (at least one) of program modules 42 may be stored, for example, in system memory 28. Such program modules 42 include, but are not limited to, an operating system, one or more application programs, other program modules, and program data. Each or some combination of these examples may include an implementation of a network environment. Program modules 42 typically perform the functions and / or methods described in the embodiments of the present invention.

[0124] Electronic device 11 can also communicate with one or more external devices 14 (e.g., keyboard, pointing device, display 24, etc.), and with one or more devices that enable a user to interact with electronic device 11, and / or with any device that enables electronic device 11 to communicate with one or more other computing devices (e.g., network card, modem, etc.). This communication can be performed via input / output (I / O) interface 22. Furthermore, electronic device 11 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 20. Figure 4 As shown, network adapter 20 communicates with other modules of electronic device 11 via bus 18. It should be understood that, although... Figure 4 As not shown, other hardware and / or software modules may be used in conjunction with electronic device 11, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0125] The processing unit 16 executes various functional applications and page displays by running programs stored in the system memory 28, such as implementing the data access method provided in this embodiment. Of course, those skilled in the art will understand that the processor can also implement the technical solutions of the data access method provided in any embodiment of this invention.

[0126] This invention provides a computer-readable storage medium storing a computer program thereon, which, when executed by a processor, implements, for example, the data access method provided in this invention. The computer storage medium of this invention can be any combination of one or more computer-readable media. The computer-readable medium can be a computer-readable signal medium or a computer-readable storage medium. The computer-readable storage medium can be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of computer-readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable computer disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage device, magnetic storage device, or any suitable combination thereof. In this document, a computer-readable storage medium can be any tangible medium containing or storing a program that can be used by or in conjunction with an instruction execution system, apparatus, or device.

[0127] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying computer-readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. Computer-readable signal media may also be any computer-readable medium other than computer-readable storage media, capable of sending, propagating, or transmitting programs for use by or in connection with an instruction execution system, apparatus, or device.

[0128] Program code contained on a computer-readable medium may be transmitted using any suitable medium, including but not limited to: wireless, wire, optical fiber, RF, etc., or any suitable combination thereof.

[0129] This invention also provides a computer program product, including a computer program that, when executed by a processor, implements the data access method provided in any embodiment of this invention.

[0130] Computer program code for performing the operations of this invention can be written in one or more programming languages ​​or a combination thereof. Programming languages ​​include object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages—such as the "C" language or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0131] Those skilled in the art will understand that the modules or steps of the present invention described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. Optionally, they can be implemented using computer-executable program code, thereby allowing them to be stored in a storage device for execution by a computing device, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the present invention is not limited to any particular combination of hardware and software.

[0132] Furthermore, the acquisition, storage, use, and processing of data in the technical solution of this invention all comply with the relevant provisions of national laws and regulations.

[0133] Note that the above description is merely a preferred embodiment of the present invention and the technical principles employed. Those skilled in the art will understand that the present invention is not limited to the specific embodiments described herein, and various obvious changes, readjustments, and substitutions can be made without departing from the scope of protection of the present invention. Therefore, although the present invention has been described in detail through the above embodiments, the present invention is not limited to the above embodiments, and may include many other equivalent embodiments without departing from the concept of the present invention, the scope of which is determined by the scope of the appended claims.

Claims

1. A data access method, characterized in that, The method includes: Submit an attribute proof to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proof and construct an attribute private key based on the attribute proof after authentication. The system receives the attribute private key sent by the hardware security center and initiates a data query request to the cloud node, so that the cloud node performs hierarchical verification based on the attribute private key in the data query request, and determines the attribute matching result after the hierarchical verification is passed. The system receives the encrypted ciphertext sent by the cloud node and the attribute matching result, and decrypts the encrypted ciphertext according to the attribute matching result and the attribute private key to obtain the target plaintext data.

2. The method according to claim 1, characterized in that, The step of submitting attribute proof to the hardware security center, so that the hardware security center can perform attribute authentication based on the attribute proof and construct an attribute private key based on the attribute proof after authentication, includes: Submit the attribute proof to the hardware security center so that the hardware security center can determine the attribute authentication result based on the attribute proof; The system receives the attribute authentication result sent by the hardware security center, and when the attribute authentication result is successful, it initiates an acquisition request to the hardware security center so that the hardware security center can construct the attribute private key based on the acquisition request and the attribute proof.

3. The method according to claim 1, characterized in that, The step of initiating a data query request to the cloud node, enabling the cloud node to perform hierarchical verification based on the attribute private key in the data query request, and determining the attribute matching result after the hierarchical verification is successful, includes: A data query request is initiated to the cloud node, so that the cloud node performs hierarchical verification based on the attribute private key and the public parameters disclosed by the hardware security center, and determines the attribute matching result based on the attribute private key and the public parameters when the hierarchical verification result is passed.

4. The method according to claim 3, characterized in that, The process of receiving encrypted ciphertext sent by the cloud node and the attribute matching result, and decrypting the encrypted ciphertext according to the attribute matching result and the attribute private key to obtain the target plaintext data, includes: Receive the matching result between the encrypted ciphertext and the attribute, and verify the decryption qualification according to the access policy corresponding to the encrypted ciphertext based on the attribute proof; When the decryption qualification is passed, the encrypted ciphertext is decrypted according to the attribute private key, the ciphertext component of the message sent by the cloud node, the attribute matching result, and the hierarchical ciphertext component to obtain the target plaintext data.

5. The method according to claim 4, characterized in that, The method also includes: An encryption request is sent to the hardware security center so that the hardware security center can construct a system master private key based on the number of supported multimodal attributes and the number of chip layers, and determine the public parameters based on the parameters in the system master private key; Receive the public parameters, and encrypt the data to be encrypted according to the access policy and the public parameters to obtain the encrypted ciphertext; The encrypted ciphertext and the access policy are uploaded to the cloud node storage.

6. The method according to claim 5, characterized in that, The process of receiving the public parameters and encrypting the data to be encrypted according to the access policy and the public parameters to obtain the encrypted ciphertext includes: The data to be encrypted is processed using the aforementioned public parameters to obtain the ciphertext component of the message; The hierarchical ciphertext component and the attribute vector ciphertext component are determined based on the common parameters, and the message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component are combined to form the encrypted ciphertext.

7. The method according to claim 6, characterized in that, The step of determining the hierarchical ciphertext component and the attribute vector ciphertext component based on the public parameters, and combining the message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component into the encrypted ciphertext includes: Select a secret value, and determine the hierarchical ciphertext component based on the secret value and the common parameter; The access strategy is converted into vector form to obtain a vector access strategy, and the attribute vector ciphertext component is determined based on the secret value, the public parameter, and the vector access strategy. The message ciphertext component, the attribute vector ciphertext component, and the hierarchical ciphertext component are combined to form the encrypted ciphertext.

8. A data access device, characterized in that, The device includes: The submission module is used to submit attribute proofs to the hardware security center so that the hardware security center can perform attribute authentication based on the attribute proofs and construct attribute private keys based on the attribute proofs after authentication. The request module is used to receive the attribute private key sent by the hardware security center and initiate a data query request to the cloud node, so that the cloud node performs hierarchical verification based on the attribute private key in the data query request, and determines the attribute matching result after the hierarchical verification is passed. The decryption module is used to receive the encrypted ciphertext sent by the cloud node and the attribute matching result, and decrypt the encrypted ciphertext according to the attribute matching result and the attribute private key to obtain the target plaintext data.

9. An electronic device, characterized in that, include: One or more processors; Memory, used to store one or more programs. When the one or more programs are executed by the one or more processors, the one or more processors implement the data access method as described in any one of claims 1 to 7.

10. A readable storage medium having a computer program stored thereon, characterized in that, When the program is executed by the processor, it implements the data access method as described in any one of claims 1 to 7.

Images