Fair-verifiable privacy data fine-grained entrusted access method in cloud environment

Abstract

The invention relates to a privacy data fine-grained entrusting access method capable of fairly verifying in a cloud environment, and belongs to the technical field of privacy data protection. According to the method, inner product encryption is used as a bottom layer encryption algorithm, and a fine-grained conditional proxy re-encryption algorithm for receiver privacy protection is designed; a condition set is bound for an original ciphertext when a user encrypts original data, conditions are hidden in the ciphertext, an access strategy is set when a re-encryption key is generated, and the use permission of a cloud server to the re-encryption key is limited through a fine-grained access control strategy; when and only when the condition of the ciphertext meets the strategy in the re-encryption key, the original ciphertext can be converted into the ciphertext which can be decrypted by other users; a Pedersen digital commitment technology is introduced, and after encryption is completed, an abstract which is committed to correspond to a ciphertext is uploaded to a block chain, so that a data receiver verifies a decryption result. According to the method, privacy information of a receiver can be protected, and shared data verification and fairness arbitration are realized.

Description

Technical Field

[0001] The present invention belongs to the technical field of privacy data protection, and specifically relates to a privacy data fine-grained delegated access method that can be fairly verified in a cloud environment. Background Art

[0002] The rise of cloud computing has unlocked massive storage and computing resources for individual and enterprise users. Through cloud services, individuals and enterprises can efficiently and reliably transmit, store, and distribute data between senders and receivers. However, as the network environment faced by cloud servers becomes increasingly complex, data owners often outsource their private data to cloud storage in encrypted form. Currently, cryptographic primitives such as broadcast encryption (BE) and identity-based encryption (IBE) have been studied to achieve these goals. However, such solutions lack the flexibility to share outsourced data with new recipients. Taking the identity-based data sharing scheme as an example, the data owner encrypts the data using the identity (ID) of the initial data recipient and stores it in the cloud server. Only the initial data recipient who holds the key corresponding to the ID can decrypt the data. When the initial data recipient wants to share the data with a new user, he must download the data and re-encrypt it before uploading it to the cloud server. This approach will greatly waste computing and storage resources, deviating from the original intention of using cloud services.

[0003] Proxy re-encryption (PRE) technology has emerged as a solution for delegated access to private data. PRE technology allows a third-party agent to convert data that can be decrypted by the initial recipient into data that can be decrypted by the new recipient, thereby achieving more convenient delegated access to data. To achieve more flexible delegated access to data, some researchers have proposed proxy re-encryption that supports conditions and one-to-many proxy re-encryption schemes.

[0004] Fine-grained delegated access technology is based on broadcast encryption and proxy re-encryption mechanisms, and can achieve fine-grained delegated access to encrypted data shared by multiple users in cloud computing through access agencies. Figure 1 As shown, the entities involved in this technology include a trusted authority, a cloud server, a data owner, and a data receiver. The implementation process includes the following steps:

[0005] 1) System initialization: The trusted authority generates the system public key PK and the system master key MSK.

[0006] 2) Key generation: The trusted authority generates a private key SK based on the system public key PK, system master key MSK and user ID and distributes it securely to the data recipient.

[0007] 3) Data encryption: The sender inputs the system public key PK, plaintext m, data recipient set S and condition set L to obtain the original ciphertext CT and upload it to the cloud server.

[0008] 4) Delegated key generation. The original data recipient inputs the system public key PK, its private key SK, and the new data recipient set S ′ and access policies Obtain the delegation key DK and distribute it to the cloud server.

[0009] 5) Re-encryption. The cloud server obtains the re-encrypted ciphertext CT based on the system public key PK, the original ciphertext CT and the delegated key DK. ′ .

[0010] 6) Data decryption: The user obtains the ciphertext CT from the cloud server and uses its key SK to decrypt the plaintext m.

[0011] In the cloud computing environment, the existing fine-grained delegated access technology has the following problems:

[0012] 1) It is impossible to protect the privacy information of the receiver. Specifically, their implementation is built on identity-based broadcast encryption (IBBE), and the ciphertext and re-encrypted ciphertext of this scheme directly expose the identity set S and S of the data receiver. ′ The receiver's privacy protection problem not only concerns the receiver's privacy information, but also involves the information leakage of the original data, because the adversary may indirectly infer the information of the original data from the receiver's identity information.

[0013] 2) The verifiability and fairness of shared data cannot be achieved. Verifiability means that the cloud server may not correctly perform the re-encryption process to save resources or other reasons and send arbitrary data to the new data recipient. Since the new data recipient directly obtains the re-encrypted ciphertext from the cloud server, it cannot be sure that the decrypted data is obtained by re-encrypting the original data. Fairness means that the new data recipient may also maliciously accuse the cloud server of not correctly performing the re-encryption process. Summary of the invention

[0014] In response to the problems existing in the above-mentioned fine-grained delegated access technology, such as the inability to protect the privacy information of the recipient and the inability to achieve the verifiability and fairness of shared data, the present invention proposes a fine-grained delegated access method for private data that can be fairly verified in a cloud environment to meet the requirements for secure sharing of data in a cloud environment.

[0015] The method for fine-grained delegated access to private data in a cloud environment that can be fairly verified provided by the present invention comprises the following steps:

[0016] Step 1: The trusted authority runs the Setup algorithm based on the input security parameter λ to obtain the master key msk and parameter mpk; the trusted authority publishes the system parameter mpk and deploys the smart contract Record on the blockchain; the smart contract Record is used to record data encryption and re-encryption operations;

[0017] Step 2: The trusted authority obtains the predicate vector of the data recipient, generates a key based on the msk and the predicate vector, and issues it to the data recipient;

[0018] Step 3: Data owner specifies access vector And condition set S, run the encryption algorithm on the plaintext m, and output the original ciphertext The original ciphertext contains the plaintext encrypted data and the Pedersen commitment w, compute The hash value hCT is obtained, and hCT and w are uploaded to the cloud server;

[0019] Step 4: When the original data recipient needs to share the data stored in the cloud with the new data recipient, the original data recipient uses its own key, the predicate vector of the new data recipient, and the access policy T to create a re-encryption key and send it to the cloud server; let the key of the original data recipient be The predicate vector of the new data receiver is The generated re-encryption key is

[0020] Step 5: The cloud server re-encrypts the key The original ciphertext under set S Convert to re-encrypted ciphertext The re-encrypted ciphertext contains re-encrypted data and Pedersen commitment w ′ , cloud server computing The hash value hRCT is calculated The hash value hRK is then uploaded to the blockchain as a re-encryption proof;

[0021] The cloud server determines whether And T(S) = 1, if so, output the re-encrypted ciphertext Otherwise, output the calculation error mark; is the calculation vector The inner product of, T(S) is to test whether the set S satisfies the access strategy T;

[0022] Step 6: When a user needs to decrypt data, he uses his own key Decrypt the ciphertext. is the user's predicate vector. If the original ciphertext When the ciphertext is valid and When , output the plaintext m, otherwise output the calculation error mark; if it is a re-encrypted ciphertext When the ciphertext is valid and When , output the plaintext m, otherwise output the calculation error mark;

[0023] Step 7: When the data recipient accuses the cloud server of not returning the correct re-encryption result, the data recipient applies to the blockchain to execute the smart contract judge; the smart contract judge issues the re-encryption key uploaded by the data recipient. Original ciphertext and re-encrypted ciphertext Make a judgment, if is a correct If the re-encrypted ciphertext is correct, output 1, otherwise output 0; 1 indicates correct re-encryption, and 0 indicates incorrect re-encryption.

[0024] The present invention improves the security of data sharing in a cloud computing environment, and its advantages and positive effects are:

[0025] (1) The method of the present invention designs a fine-grained conditional proxy re-encryption algorithm for receiver privacy protection. Inner product encryption (IPE) is used as the underlying encryption algorithm to protect data confidentiality and the identity privacy of data receivers. Except for the data owner, all other entities cannot infer any information about the receiver from the re-encryption key and the re-encrypted ciphertext. The data receiver can only know whether he can decrypt the data, but cannot know the information of other receivers. At the same time, the fine-grained access control policy is combined to ensure that only the specified data can be re-encrypted by the cloud server.

[0026] (2) The method of the present invention introduces the Pedersen digital commitment technology. After completing the encryption, the data owner uploads the summary corresponding to the commitment and the ciphertext to the blockchain for the data recipient to verify the decryption result, thereby achieving the verifiability of the re-encryption. After completing the re-encryption, the cloud server also needs to upload the re-encrypted ciphertext, the re-encryption key and the summary of the original ciphertext to the blockchain. When the data recipient believes that the re-encrypted ciphertext is incorrect, the smart contract can be called for arbitration, thereby achieving fairness. BRIEF DESCRIPTION OF THE DRAWINGS

[0027] Figure 1 This is a diagram of a data sharing solution based on proxy re-encryption;

[0028] Figure 2 It is an implementation framework diagram of the fair verifiable fine-grained delegated access method for privacy data of the present invention. DETAILED DESCRIPTION

[0029] The present invention will be further described in detail below with reference to the accompanying drawings and embodiments.

[0030] like Figure 2 As shown, the entities involved in the fair verifiable fine-grained delegated access method for private data in a cloud environment proposed by the present invention include: a trusted authorization agency, a data owner, a cloud server, a data receiver, and a blockchain network. Among them:

[0031] The trusted authority establishes the system public key and system master key and maintains the entire system. At the same time, the trusted authority generates encryption keys for each sender and decryption keys for each receiver.

[0032] The data owner usually specifies a predicate vector and a set of conditions and encrypts the data, then outsources the ciphertext to a cloud server.

[0033] The cloud server stores the ciphertext from the data owner. In addition, the cloud server can receive the re-encryption key from the original data recipient and use the re-encryption key to perform a re-encryption operation on the original ciphertext.

[0034] Data recipients include original data recipients and new data recipients, who can obtain the key corresponding to their predicate vectors from a trusted authority. After the data recipient obtains the original ciphertext or re-encrypted ciphertext from the cloud server, it can use its key to decrypt the ciphertext. In addition, the original data recipient can provide the re-encryption key to the cloud server to authorize the new data recipient to obtain access rights to the data.

[0035] The blockchain is a decentralized ledger that contains smart contracts. The blockchain network responds to the arbitration request of the data recipient by storing the ciphertext and the commitment of the re-encryption proof, and fairly verifying whether the re-encrypted ciphertext is correct.

[0036] The implementation process of the fair verifiable fine-grained delegated access method for private data in a cloud environment of the present invention is as follows:

[0037] Step 1: Initialize the system, select the security parameter λ, and the trusted authority runs the Setup algorithm. Setup(1 λ )→(mpk,msk), output parameter mpk and master key msk. For convenience, the input of the remaining algorithms all implicitly contains parameter mpk.

[0038] Choose a bilinear map e: in and They are all multiplicative cyclic groups of prime order p. The size of the group is determined by λ. Let g and h be The generator of . Select the random number and in is a set of integers of order p. Define a hash function and generate:

[0039]

[0040] The trusted authority saves the master key msk and discloses the system parameter mpk. Finally, the trusted authority deploys the smart contract Record on the blockchain, as shown in smart contract 1, which is used to record data encryption and re-encryption operations.

[0041]

[0042] Commitment is the Pedersen commitment, which is w in the encryption algorithm; UploadCT, or UploadCiphertext, is what the data owner needs to execute after uploading the ciphertext to the cloud. The purpose is to record the hash hCT and commitment w corresponding to the ciphertext on the blockchain.

[0043] Step 2: Key generation: The trusted authority runs the KeyGen algorithm based on the master key msk and the predicate vector Output the key for this identity Issue keys to data recipients.

[0044] Specifically, the trusted authority obtains the predicate vector of the data recipient Select random number Generate Keys Finally, the trusted authority sends the key to Return to the data recipient. Different data recipients have their own predicate vectors, and the trusted authority runs the KeyGen algorithm to generate corresponding keys for different data recipients. for The predicate vector of the data receiver.

[0045] Step 3: Data encryption. Given plaintext data m, the data owner usually specifies an attribute vector and a condition set S = {A1, A2, ..., A ξ}, and run the Encrypt algorithm to encrypt the data, Output original ciphertext A τ It is the τth element in the set S, τ∈[ξ].

[0046] First, randomly select For any τ∈[ξ], calculate Then generate the ciphertext And upload the ciphertext to the cloud server. Access vector is a vector for setting data access permissions, and the condition set S stores the constraints for the server to perform re-encryption operations. w is the Pedersen commitment value. C0、C i , E, and E0 are all intermediate parameters.

[0047] make is the hash value of the original ciphertext, the data owner performs the transaction Upload the hash and commitment to the blockchain.

[0048] Step 4: Generate re-encryption key. If the original data recipient attempts to share the data stored in the cloud with the new data recipient, the original data recipient can use his key to The predicate vector of the new data recipient and access policy T, run the ReKeyGen algorithm to create a re-encryption key And send it to the cloud server.

[0049] First, randomly select data make calculate is the LSSS (Linear Secret Sharing Scheme) matrix. Then randomly select And calculate the intermediate parameters for any τ∈[l] Finally, randomly select And generate the re-encryption key In this paper, as in the vectors D0, D1, D2, D3, D4, t, R. R i etc. are all intermediate parameters and will not be described in detail.

[0050] Step 5: Re-encryption. The cloud server uses the re-encryption key Run the ReEncrypt algorithm to convert the original ciphertext under the condition set S Convert to re-encrypted ciphertext when 0 and T(S)=1, the algorithm outputs a re-encrypted ciphertext Otherwise output ⊥. is the calculation vector The inner product of , T(S) is used to check whether the condition set S satisfies the access policy T. ⊥ indicates the computation error flag returned by the algorithm.

[0051] When T(S) = 1, let I = {i:ρ(i)∈S} be the LSSS matrix The set of rows corresponding to the condition set S in . Calculate the constant satisfy in is a matrix Then calculate B0 = where τ is the condition in S

[0052] The index of ρ(i). When Then calculate E′0=B0·B1 / e(E,D3)=Y δζ Finally, the cloud server generates the re-encrypted ciphertext represents the re-encrypted data, and w′ is the Pedersen commitment value.

[0053] However, it may be accused of returning incorrect results to the data recipient even if it provides the correct re-encrypted ciphertext. Therefore, the cloud server needs to store the re-encryption proof in the blockchain. Specifically, let is the hash value of the re-encrypted ciphertext, is the hash value of the re-encryption key. The cloud server executes the transaction Upload the hash value to the blockchain as proof of re-encryption.

[0054] Step 6: Data decryption. When a data user needs to decrypt data, enter the key Original ciphertext Or re-encrypt the ciphertext To decrypt, When the ciphertext is valid and or , output plaintext m; otherwise output ⊥. The key of any user and step 2 The method of obtaining is the same.

[0055] If the predicate vector of the data user With the specified access vector or Orthogonal, that is or Then the ciphertext in the cloud storage can be decrypted and the commitment w or w can be retrieved from the blockchain ′ to verify its correctness.

[0056] For the original ciphertext The original data recipient uses his key calculate Then calculate If w=h H(m) f H(L) , indicating that the decryption is correct, and the output is plaintext m.

[0057] For re-encrypted ciphertext The new data recipient uses its key calculate Then, calculate and get If w ′ =h H(m) f H(L) , output plaintext m.

[0058] Step 7: Arbitration. The data receiver can accuse the cloud server of not returning the correct re-encryption result. At this time, the arbitration algorithm is executed. Enter the re-encryption key and the original ciphertext And re-encrypt the ciphertext if is a correct If the re-encrypted ciphertext is , the algorithm outputs 1. Otherwise, it outputs 0.

[0059] The data recipient can accuse the cloud server of not returning the correct re-encryption result. When a dispute occurs between the data recipient and the cloud server, the data recipient can apply to the blockchain network to execute the arbitration smart contract Judge to realize the fairness judgment request of the data recipient, as shown in the smart contract 2 below.

[0060]

[0061] Smart contract Judge is maintained by each node on the blockchain. After receiving the input, it executes: Calculate the hash value hRCT of the re-encrypted ciphertext, obtain the record corresponding to the hash value hRCT from the re-encryption operation record RecordRCT of the blockchain, and calculate and The hash value of the data is used to determine whether it is consistent with the hRK and hCT in the corresponding record. If they are inconsistent, it means that the data receiver is malicious. If they are consistent, according to the uploaded Recalculate the re-encrypted ciphertext, calculate the hash value of the re-encrypted data and compare it with the hRCT calculated at the beginning. If they are the same, it means that the cloud server has performed the re-encryption correctly, otherwise the cloud server has not performed the re-encryption correctly.

[0062] Using the method of the present invention, the original text can be correctly decrypted only when the inner product of the vector corresponding to the receiver's key and the encrypted or re-encrypted vector is 0, and in this process, the cloud and the data receiver or external adversary cannot obtain the information of other data receivers, thereby realizing the privacy protection of the receiver. At the same time, the key policy attribute-based encryption (KP-ABE) is integrated to realize fine-grained authorization for data sharing. When encrypting the original data, the user binds a condition set S to the original ciphertext, hides the condition in the ciphertext, and sets the access policy T when generating the re-encryption key. The original ciphertext can be converted into a ciphertext that can be decrypted by other users only when and only when the condition of the ciphertext satisfies the policy in the re-encryption key. The cloud server's use of the re-encryption key is restricted by a fine-grained access control policy, and only those data whose condition set S satisfies the access policy T can be re-encrypted to the new data receiver. In the general proxy re-encryption scheme, if the cloud server obtains the re-encryption key, it can perform re-encryption operations on all ciphertexts that can be decrypted by the original receiver. In addition, the scheme provides an additional verifiable mechanism and fairness guarantee. For malicious cloud servers, the data recipient can verify the decrypted data. For the accusation initiated by the data recipient, the fairness of the arbitration result is guaranteed through blockchain and smart contracts.

[0063] Except for the technical features described in the specification, all of them are known technologies to those skilled in the art. The present invention omits the description of known components and known technologies to avoid redundancy and unnecessary limitation of the present invention. The implementation methods described in the above embodiments do not represent all implementation methods consistent with the present application. On the basis of the technical solution of the present invention, various modifications or variations that can be made by those skilled in the art without creative labor are still within the protection scope of the present invention.

Claims

1. A method for fine-grained delegated access to private data in a cloud environment that can be fairly verified, characterized in that: The steps include: Step 1: The trusted authority runs the Setup algorithm based on the input security parameter λ to obtain the master key msk and parameter mpk; the trusted authority discloses the system parameter mpk and deploys the smart contract Record on the blockchain; Smart contract Record is used to record data encryption and re-encryption operations; Step 2: The trusted authority obtains the predicate vector of the data recipient, generates a key based on the msk and the predicate vector, and issues it to the data recipient; Step 3: Data owner specifies access vector And condition set S, run the encryption algorithm on the plaintext m, and output the original ciphertext The original ciphertext contains the plaintext encrypted data and the Pedersen commitment w, compute The hash value hCT is obtained, and hCT and w are uploaded to the cloud server; Step 4: When the original data recipient needs to share the data stored in the cloud with the new data recipient, the original data recipient uses its own key, the predicate vector of the new data recipient, and the access policy T to create a re-encryption key and send it to the cloud server; let the key of the original data recipient be The predicate vector of the new data receiver is The generated re-encryption key is Step 5: The cloud server re-encrypts the key The original ciphertext under set S Convert to re-encrypted ciphertext The re-encrypted ciphertext contains re-encrypted data and Pedersen commitment w ′ , cloud server computing The hash value hRCT is calculated The hash value hRK is then uploaded to the blockchain as a re-encryption proof; The cloud server determines whether And T(S) = 1, if so, output the re-encrypted ciphertext Otherwise, output the calculation error mark; is the calculation vector The inner product of, T(S) is to test whether the set S satisfies the access strategy T; Step 6: When a user needs to decrypt data, he uses his own key Decrypt the ciphertext. is the user's predicate vector; if it is the original ciphertext When the ciphertext is valid and When , output the plaintext m, otherwise output the calculation error mark; if it is a re-encrypted ciphertext When the ciphertext is valid and When , output the plaintext m, otherwise output the calculation error mark; Step 7: When the data recipient accuses the cloud server of not returning the correct re-encryption result, the data recipient applies to the blockchain to execute the smart contract judge; the smart contract judge issues the re-encryption key uploaded by the data recipient. Original ciphertext and re-encrypted ciphertext Make a judgment, if is a correct If the re-encrypted ciphertext is correct, output 1, otherwise output 0; 1 indicates correct re-encryption, and 0 indicates incorrect re-encryption.

2. The method according to claim 1, characterized in that In step 1, the trusted authority selects a bilinear mapping in and They are all multiplicative cyclic groups of prime order p. Let g and h be Generator of ; choose a random number and in is a set of integers of order p; Defining a hash function and generate:

3. The method according to claim 2, characterized in that In step 3, let the set S = {A1, A2, ..., A ξ }, the data owner first randomly selects For any τ∈[ξ], calculate the intermediate parameter Then generate the ciphertext w is the Pedersen commitment value.

4. The method according to claim 1 or 3, characterized in that: In step 4, the original data receiver first randomly selects data make calculate is the linear secret sharing scheme LSSS matrix; then randomly select And calculate the intermediate parameters for any τ∈[l] Finally, randomly select Generate re-encryption key 5. The method according to claim 4, characterized in that In step 5, the cloud server executes: When T(S) = 1, let I = {i:ρ(i)∈S} be the LSSS matrix The set of rows corresponding to the set S in the calculation satisfies the condition Constants is a matrix The i-th row of where τ is the index of condition ρ(i) in S; when When calculating the intermediate parameters Then calculate the intermediate parameter E′0=B0·B1 / e(E,D3)=Y δζ ; Finally generate the re-encrypted ciphertext 6. The method according to claim 5, characterized in that In step 6, when the user's predicate vector u is consistent with the specified access vector or When orthogonal, the user uses the key Decrypt the ciphertext and retrieve the Pedersen commitment from the blockchain to verify the correctness of the data; When the user is the original data receiver, the original ciphertext Calculate intermediate parameters get If the Pedersen commitment w = h H(m) f H(L) , output plaintext m; When the user is a new data recipient, the ciphertext is re-encrypted Calculate intermediate parameters Recalculate Then get If the Pedersen commitment w′=h H(m) f H(L) , output plaintext m.

7. The method according to claim 1 or 2, characterized in that: In step 7, the smart contract Judge executes: (1) According to the uploaded Calculate the hash value hRCT and obtain the record corresponding to the hash value from the re-encryption operation record of the blockchain; (2) Calculate the uploaded and The hash value is compared with the value in the record. If they are consistent, the next step is executed. If they are inconsistent, the conclusion that the data recipient is malicious is returned. (3) According to the uploaded Recalculate the re-encrypted ciphertext, calculate the hash value of the re-encrypted data and compare it with the hRCT calculated in (1). If they are the same, output 1, otherwise output 0.

Images