A Fine-Grained Delegated Access Method for Privacy Data with Fair Verification in Cloud Environment

Abstract

The present invention is a method for fine-grained delegated access of private data that can be fairly verified in a cloud environment, belonging to the technical field of private data protection. The method of the present invention uses inner product encryption as the underlying encryption algorithm and designs a fine-grained conditional proxy re-encryption algorithm for protecting the privacy of the receiver; when the user encrypts the original data, a condition set is bound to the original ciphertext, and the condition is hidden in the ciphertext. When generating the re-encryption key, an access policy is set, and the use permission of the re-encryption key by the cloud server is restricted through a fine-grained access control policy; only when the condition of the ciphertext satisfies the policy in the re-encryption key, the original ciphertext can be converted into a ciphertext that can be decrypted by other users; the Pedersen digital commitment technology is introduced to upload the commitment and the digest corresponding to the ciphertext to the blockchain after encryption for the data receiver to verify the decryption result. The method of the present invention can protect the privacy information of the receiver and achieve the verification and fairness arbitration of shared data.

Description

Technical Field

[0001] The present invention belongs to the technical field of privacy data protection, and particularly relates to a fine-grained delegated access method for privacy data 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 the sender and the receiver. 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, encryption 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 the outsourced data with new recipients. Taking the identity-based data sharing scheme as an example, the data owner encrypts the data using the identity identifier (ID) of the initial data recipient and stores it on the cloud server. Only the initial data recipient holding 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, re-encrypt it, and upload it to the cloud server. This approach will greatly waste computing and storage resources, deviating from the original intention of using cloud services.

[0003] The proxy re-encryption (PRE) technology emerged as a solution for the delegated access of privacy data. The PRE technology allows a third-party proxy to convert the data that the initial recipient can decrypt into the data that the new recipient can decrypt, thus achieving more convenient data delegated access. To achieve more flexible data delegated access, some researchers have proposed conditional proxy re-encryption and one-to-many proxy re-encryption schemes.

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

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

[0006] 2) Key generation. The trusted authorization authority generates the private key according to the system public key , the system master key and the user and securely distributes it to the data recipient.

[0007] 3) Data encryption. The sender inputs the system public key , the plaintext , the set of data receivers and the set of conditions to obtain the original ciphertext and upload it to the cloud server.

[0008] 4) Delegated key generation. The original data receiver inputs the system public key , its private key , the set of new data receivers and the access policy to obtain the delegated key and distribute it to the cloud server.

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

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

[0011] In the cloud computing environment, the existing fine-grained delegation access technologies have the following problems:

[0012] 1) They cannot protect the privacy information of the receivers. Specifically, their implementation is based on identity-based broadcast encryption (IBBE), and the ciphertext and re-encrypted ciphertext of this scheme directly expose the identity sets and of the data receivers. The privacy protection problem of the receivers not only concerns the privacy information of the receivers but also involves the information leakage problem of the original data, because an adversary may indirectly infer the information of the original data from the identity information of the receivers.

[0013] 2) They cannot achieve the verifiability and fairness of shared data. Verifiability means that the cloud server may send arbitrary data to the new data receivers without correctly executing the re-encryption process due to resource conservation or other reasons. Since the new data receivers directly obtain the re-encrypted ciphertext from the cloud server, they cannot determine whether the data obtained by decryption is obtained by re-encrypting the original data. Fairness means that the new data receivers may also maliciously accuse the cloud server of not correctly executing the re-encryption process. Summary of the Invention

[0014] In view of the problems existing in the above-mentioned fine-grained delegation 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 delegation access method for privacy data that can be fairly verified in a cloud environment to meet the secure sharing requirements of data in the cloud environment.

[0015] The fine-grained delegation access method for privacy data that can be fairly verified in the cloud environment provided by the present invention includes the following steps:

[0016] Step 1, the trusted authorization agency runs the algorithm according to the input security parameters to obtain the master key and the parameter ; the trusted authorization agency publishes the system parameters 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 authorization agency obtains the predicate vector of the data recipient, generates a key according to and the predicate vector and distributes it to the data recipient;

[0018] Step 3, the data owner specifies the access vector and the condition set , runs the encryption algorithm on the plaintext to output the original ciphertext , the original ciphertext contains the plaintext encrypted data and the Pedersen commitment , calculates the hash value of as , and uploads and to the cloud server;

[0019] Step 4, when the original data recipient needs to share the data stored in the cloud with a new data recipient, the original data recipient creates a re-encryption key using its own key, the predicate vector of the new data recipient, and the access policy and sends it to the cloud server; let the key of the original data recipient be , the predicate vector of the new data recipient be , and the generated re-encryption key be ;

[0020] Step 5, the cloud server converts the original ciphertext under the set to the re-encryption ciphertext according to the re-encryption key ; the re-encryption ciphertext contains the re-encrypted data and Pedersen's commitment The hash value of cloud server computing is calculated The hash value of is calculated Then upload to the blockchain as a re - encryption proof;

[0021] The cloud server determines whether it meets If so, output the re - encrypted ciphertext Otherwise, output a calculation error flag; is the inner product of the calculation vector and is to check whether the set meets the access policy ;

[0022] Step 6, when a user needs to decrypt data, use their own key to decrypt the ciphertext is the predicate vector of this user. If it is the original ciphertext , when the ciphertext is valid and , output the plaintext , otherwise output a calculation error flag; If it is a re - encrypted ciphertext for , when the ciphertext is valid and , output the plaintext , otherwise output a calculation error flag;

[0023] Step 7, when the data receiver accuses the cloud server of not returning the correct re - encryption result, apply to the blockchain to execute the smart contract Judge; The smart contract Judge judges the re - encryption key uploaded by the data receiver, the original ciphertext and the re - encrypted ciphertext . If is a correct re - encrypted ciphertext of , output 1, otherwise output 0; 1 indicates correct re - encryption, 0 indicates incorrect re - encryption.

[0024] The present invention improves the security of data sharing in a cloud computing environment. Its advantages and positive effects are as follows:

[0025] (1) The method of the present invention designs a fine-grained conditional proxy re-encryption algorithm for receiver privacy protection, using inner product encryption (IPE) as the underlying encryption algorithm to protect data confidentiality and the identity privacy of data receivers. Except for the data owner, no other entity can infer any information about the receiver from the re-encryption key and the re-encrypted ciphertext. The data receiver can only know whether it can decrypt the data, but cannot know the information of other receivers. At the same time, combined with the fine-grained access control policy, it ensures 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 the data owner completes the encryption, it uploads the commitment and the digest corresponding to the ciphertext to the blockchain for the data receiver to verify the decryption result, so as to achieve the verifiability of re-encryption. After the cloud server completes the re-encryption, it also needs to upload the re-encrypted ciphertext, the re-encryption key and the digest of the original ciphertext to the blockchain. When the data receiver believes that the re-encrypted ciphertext is incorrect, it can call the smart contract for arbitration to achieve fairness. Brief Description of the Drawings

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

[0028] Figure 2 is an implementation framework diagram of the fine-grained delegated access method for privacy data that can be fairly verified in the present invention. Detailed Embodiments

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

[0030] As Figure 2 shown, the entities involved in the fine-grained delegated access method for privacy data that can be fairly verified in the 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 authorization agency establishes the system public key and the system master key and maintains the entire system. At the same time, the trusted authorization agency generates an encryption key for each sender and a decryption key for each receiver.

[0032] The data owner usually specifies a predicate vector and a condition set and encrypts the data, and then outsources the ciphertext to the 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 receiver and perform a re-encryption operation on the original ciphertext using the re-encryption key.

[0034] The data receivers include the original data receiver and the new data receiver, and can obtain the key corresponding to their predicate vectors from a trusted authorization agency. After the data receiver obtains the original ciphertext or re-encrypted ciphertext from the cloud server, it can decrypt the ciphertext with its key. In addition, the original data receiver can provide the re-encryption key to the cloud server to authorize the new data receiver to obtain the access right to the data.

[0035] A blockchain is a decentralized ledger containing smart contracts. The blockchain network responds to the arbitration requests of data receivers by storing the commitments of ciphertexts and re-encryption proofs, and fairly verifying whether the re-encrypted ciphertexts are correct.

[0036] The implementation process of the fine-grained delegated access method for privacy data that can be fairly verified in the cloud environment of the present invention is as follows in 7 steps:

[0037] Step 1, perform system initialization, select security parameters , the trusted authorization agency runs algorithm, , output parameters and the master key . For convenience, the input of the remaining algorithms implicitly includes the parameter .

[0038] Select a bilinear mapping , where , and are all multiplicative cyclic groups of prime order p, the size of the group is determined by , let be the generators of , respectively. Select random numbers and , where is the order integer set. Define hash functions , and , generate:

[0039] ;

[0040] .

[0041] The trusted authorization agency saves the master key , and publishes the system parameters . Finally, the trusted authorization agency 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.

[0042]

[0043] where commitment is the Pedersen commitment, i.e., in the encryption algorithm ; UploadCT, i.e., UploadCiphertext, is what the data owner needs to execute after uploading the ciphertext to the cloud, aiming to record the hash hCT corresponding to the ciphertext and the commitment on the blockchain.

[0044] Step 2, key generation. The trusted authorization agency runs the algorithm, and according to the master key and the predicate vector outputs the key of this identity and issues the key to the data receiver.

[0045] Specifically, the trusted authorization agency obtains the predicate vector of the data receiver, selects a random number and generates the key . Finally, the trusted authorization agency returns the key to the data receiver through a secure channel. Different data receivers have their own predicate vectors, and the trusted authorization agency runs the algorithm to generate corresponding keys for different data receivers. Here, let be the predicate vector of the data receiver.

[0046] Step 3, data encryption. Given the plaintext data , the data owner usually specifies an attribute vector and a condition set , and runs the algorithm to encrypt the data , and outputs the original ciphertext . is the rd element in the set .

[0047] First, randomly select . For any , calculate . Then generate the ciphertext and upload the ciphertext to the cloud server. The access vector is the vector for setting data access permissions, and the condition set stores the constraints for the server to perform re-encryption operations. is the Pedersen commitment value. Such as in the ciphertext , , , , are both intermediate parameters.

[0048] Let be the hash value of the original ciphertext. The data owner executes the transaction to upload the hash value and the commitment to the blockchain.

[0049] Step 4, re-encryption key generation. If the original data recipient attempts to share the data stored in the cloud with a new data recipient, it can use its key , the predicate vector of the new data recipient and the access policy , run algorithm to create a re-encryption key , , and send it to the cloud server.

[0050] First, randomly select data , let , calculate , be the LSSS (Linear Secret Sharing Scheme) matrix. Then randomly select , and for any calculate the intermediate parameter . Finally, randomly select , and generate the re-encryption key . In the text, vectors such as , , , , , , , , , etc. are all intermediate parameters and will not be elaborated further.

[0051] Step 5, re-encryption. The cloud server runs algorithm according to the re-encryption key to convert the original ciphertext under the condition set into a re-encrypted ciphertext , . When , the algorithm outputs a re-encrypted ciphertext ; otherwise it outputs . is to calculate the inner product of the vector , is to check whether the condition set satisfies the access policy . Indicates the calculation error identifier returned by the algorithm.

[0052] When holds, let be the row set corresponding to the condition set in the LSSS matrix . Calculate the constant satisfying , where is the -th row of the matrix . Then calculate , where is the index of the condition . When holds, calculate . Then calculate . Finally, the cloud server generates the re-encrypted ciphertext . Represents the re-encrypted data, 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 be the hash value of the re-encrypted ciphertext, be the hash value of the re-encryption key. The cloud server executes the transaction to upload the hash values to the blockchain as the re-encryption proof.

[0054] Step 6, data decryption. When a data user needs to decrypt the data, input the key and decrypt the original ciphertext or the re-encrypted ciphertext . , when the ciphertext is valid and or holds, output the plaintext ; otherwise output . The key of any user is obtained in the same way as in Step 2.

[0055] If the predicate vector of the data user is orthogonal to the specified access vector or , that is, or , then the ciphertext in the cloud storage can be decrypted, and its correctness can be verified by retrieving the commitment or from the blockchain.

[0056] For the original ciphertext , the original data recipient uses its key to calculate . Then calculate . If it satisfies , it indicates that the decryption is correct, and the plaintext is output.

[0057] For the re-encrypted ciphertext , the new data recipient uses its key to calculate . Then, calculate , and obtain . If , the plaintext is output.

[0058] Step 7, arbitration. The data recipient can accuse the cloud server of not returning the correct re-encryption result. At this time, the arbitration algorithm is executed , input the re-encryption key , and the original ciphertext and the re-encrypted ciphertext . If is a correct re-encrypted ciphertext, 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 fairness judgment request of the data recipient can be realized by applying to the blockchain network to execute the arbitration smart contract Judge, as shown in the following smart contract 2.

[0060]

[0061] The 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 according to the uploaded , obtain the record record corresponding to the hash value hRCT from the re-encryption operation record RecordRCT on the blockchain, calculate and hash values, and determine whether they are consistent with hRK and hCT in the corresponding record record. If they are inconsistent, it means that the data recipient 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 initially calculated hRCT. If they are the same, it means that the cloud server has correctly executed the re-encryption. Otherwise, the cloud server has not correctly executed the re-encryption.

[0062] Using the method of the present invention, the original text can be correctly decrypted only when the inner product of the key corresponding vector of the receiver and the encrypted or re-encrypted vector is 0. Moreover, during this process, the cloud and the data receiver or external adversaries cannot obtain the information of other data receivers, thus realizing the privacy protection of the receivers. Meanwhile, key-policy attribute-based encryption (KP-ABE) is integrated to achieve fine-grained authorization for data sharing. When the user encrypts the original data, a set of conditions is bound to the original ciphertext , and the conditions are hidden in the ciphertext. An access policy is set when generating the re-encryption key . Only when the conditions of the ciphertext satisfy the policy in the re-encryption key can the original ciphertext be converted into a ciphertext that can be decrypted by other users. By restricting the usage rights of the re-encryption key by the cloud server through a fine-grained access control policy, only those data whose condition sets satisfy the access policy

[0063] can be re-encrypted to new data receivers. In a 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, this scheme additionally provides a verifiable mechanism and fairness guarantee. For a malicious cloud server, the data receiver can complete the verification of the decrypted data. For the accusations initiated by the data receiver, the fairness of the arbitration result is ensured through blockchain and smart contracts. Except for the technical features described in the specification, they are all known technologies to those skilled in the art. The present invention omits the description of well-known components and well-known technologies to avoid redundancy and unnecessary limitation of the present invention. The described implementation manners in the above embodiments do not represent all implementation manners consistent with the present application. Based on the technical solution of the present invention, various modifications or deformations 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 will enter the security parameters ,run Algorithm to obtain the master key and parameters ; Trusted authority discloses system parameters , deploy 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 according to Generate a key with the predicate vector and issue it to the data receiver; Step 3: Data owner specifies access vector and conditional set , for plaintext Run the encryption algorithm and output the original ciphertext , the original ciphertext contains the plaintext encrypted data and Pedersen Commitment ,calculate Hash value ,Will and Upload 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 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 Will gather The original ciphertext Convert to re-encrypted ciphertext ; The re-encrypted ciphertext contains re-encrypted data and Pedersen Commitment , cloud server computing Hash value ,calculate Hash value , then Upload to the blockchain as proof of re-encryption; The cloud server determines whether , if so, output the re-encrypted ciphertext , otherwise the calculation error mark is output; is the calculation vector The inner product of is the test set Whether the access policy is satisfied ; 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 the plain text is output , otherwise the calculation error mark is output; if it is a re-encrypted ciphertext , when the ciphertext is valid and When the plain text is output , otherwise the calculation error mark is output; 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 are all multiplicative cyclic groups of prime order p. Let They are , Generator of ; choose a random number and ,in for The set of integers of order; Defining a hash function , and ,generate: ； 。 3. The method according to claim 2, characterized in that In step 3, let the set , the data owner first randomly selects , for any , calculate the intermediate parameters ; Then generate the ciphertext ; 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 for any Calculate intermediate parameters ; Finally, randomly select , generate the re-encryption key .

5. The method according to claim 4, characterized in that In step 5, the cloud server executes: when season is the LSSS matrix The corresponding set The set of rows that satisfy the condition Constants , is a matrix No. OK, is a set of test conditions Whether the access policy is satisfied ; Then calculate the intermediate parameters ,in yes medium conditions The index of When calculating the intermediate parameters ; Then calculate the intermediate parameters ; 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 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 is met , output plain text ; When the user is a new data recipient, the ciphertext is re-encrypted Calculate intermediate parameters ; recalculate ; then get ; If the Pedersen commitment is met , output plain text .

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