Anti-key abuse data sharing system and method based on attribute password and block chain

Abstract

The invention belongs to the technical field of data sharing, and particularly relates to an anti-key abuse data sharing system and method based on an attribute password and a block chain. The system comprises a data provider, a data demander, an attribute mechanism party, a block chain and a data storage service provider. The attribute mechanism party generates a key pair and publishes a public key on the block chain; the data provider encrypts the shared data and uploads the description information and the access control strategy to the block chain; a data demander searches required data on the block chain and sends a request, the block chain informs a related attribute mechanism party, and the related attribute mechanism party performs attribute encryption by using a public key of the demander and generates a zero-knowledge proof; the smart contract verifies the validity of the encryption attribute; and finally, the data demander decrypts by using the private key to obtain the decrypted attribute and further obtain the final data. According to the method, the problems of insufficient privacy protection, key abuse and insufficient data auditing capability in the data sharing process are effectively solved, and safe and efficient data sharing and use are realized.

Description

Technical Field

[0001] The present invention belongs to the field of data sharing technology, and specifically relates to a data sharing system and method that is resistant to key abuse based on attribute cryptography and blockchain. Background Art

[0002] Attribute cryptography is an encryption scheme [1] that controls access to data based on the user's specific attributes and permissions. In attribute cryptography, the encryptor defines an access control policy for the ciphertext. Only decryptors that meet the policy can decrypt the ciphertext. Each user has a set of attributes related to their characteristics (such as identity, occupation, geographic location, and time). The encryption process uses a specific attribute combination to generate the ciphertext. The decryption process relies on the matching of the decryptor's private key and the attribute combination. Attribute cryptography is an encryption scheme suitable for cloud computing and data sharing scenarios, ensuring data security while providing flexible access control.

[0003] Zero-knowledge proof is a cryptographic technique[2] that allows one party (the prover) to prove to another party (the verifier) that a statement is true without revealing any specific information. This method ensures three major properties: completeness (true statements can convince the verifier), soundness (false statements cannot mislead the verifier), and zero-knowledge (the verifier does not obtain additional information about the statement). These properties of zero-knowledge proof are particularly suitable for scenarios with strict privacy protection requirements. They are widely used in anonymous authentication, secret voting, privacy protection, and secure communication, and can effectively ensure the security and privacy of sensitive information.

[0004] Blockchain is a distributed ledger technology that ensures data consistency and integrity through a multi-node consensus mechanism. Its core features include immutability, decentralization, and cryptographically secured data security [3]. Each block contains a series of transactions that are linked to the previous block through a hash function, ensuring data irreversibility and enhancing the system's ability to resist external attacks. Ethereum is an innovative blockchain. Its security is based on distributed storage, cryptography, and consensus algorithms. A smart contract is a program designed to establish an agreement between distributed nodes. Once a smart contract is executed in the Ethereum Virtual Machine (EVM), it will be written to the blockchain, making it traceable and irreversible. Summary of the Invention

[0005] The present invention aims to provide a data sharing system and method that is resistant to key abuse based on attribute cryptography and blockchain, so as to solve the problems of insufficient privacy protection, key abuse and insufficient data auditing capabilities in data sharing, thereby realizing safe and efficient data sharing and use.

[0006] The architecture of the key-abuse-resistant data sharing system proposed in this invention based on attribute cryptography and blockchain is shown inFigure 1 As shown, it includes the following five parts: data providers, data demanders, attribute institutions, blockchain and data storage service providers; among which:

[0007] (1) Data providers: Data providers are holders of data (such as digital assets, communication keys, NFTs, files, and other electronic information). Data providers select appropriate access control policies based on existing attribute mechanisms, encrypt the data to be shared using the attribute encryption function ABEEncrypt[4], and transmit the ciphertext to the data storage service provider for use by data demanders; then, the data description information is published on the blockchain;

[0008] (2) Data demander: After initialization, the data demander has a key pair (sk u ,pk u ), and the public key pk u Registered on the blockchain. When the description information uploaded by the data provider to the blockchain meets the requirements of the data demander, the data demander will send a request to the blockchain to obtain the data. The blockchain will respond to the data demander and send him the key that meets the access control policy in the form of ciphertext. The data demander will eventually use his private key sk u Decrypt the data using the attribute decryption function ABEDecrypt[4] to obtain the required data;

[0009] (3) Attribute institution: There are multiple attribute institutions in this system, each of which has its own independent key pair (sk θ ,pk θ ), and the public key pk θ Registered on the blockchain; these institutions provide attribute keys to data demanders by responding to attribute application requests on the blockchain. They operate independently on a global scale and autonomously distribute and manage attribute keys.

[0010] (4) Blockchain: Blockchain is a decentralized, tamper-resistant server that provides support for reliable storage and verifiable computation. In this invention, it is used to manage (i.e., store and verify) the keys of attribute cryptography and provide access control policy verification services. In this system, Ethereum is selected as the blockchain because it can host smart contracts and is a public blockchain ecosystem that does not require permission to access.

[0011] (5) Data storage service provider: Since the storage space of blockchain is limited and not suitable for storing ciphertext, the present invention introduces a data storage service provider as a server specifically used to store the ciphertext uploaded by the data provider.

[0012] (6) In this invention, several functions are designed to achieve key abuse resistance and data auditability, including ABEEncKey[4], getKey[4], genProofs[4], checkKey[4], and judgeAttrs[4]. Through these functions and attribute cryptographic functions, the integrity and availability of the entire data sharing scheme can be ensured. Next, these functions are explained in detail:

[0013] ABEEncKey function is called by the attribute authority to replace the traditional attribute password attribute authority to generate decrypted attributes. In order to be able to transmit on the public channel, it replaces the encryption of attributes and generates encrypted attributes. After receiving the attribute application request from the blockchain, the attribute authority then uses the public key pk u The ABEEncKey function is called locally, and the generated encrypted attributes are then uploaded to the blockchain.

[0014] The genProofs function is called by the attribute authority. Considering the possibility that the attribute authority could act maliciously, generating an incorrect attribute that prevents the final data requester from decrypting and obtaining the data, this paper utilizes zero-knowledge proof technology to design the genProofs function. After the attribute authority calls ABEEncKey, it calls the genProofs function again to generate a zero-knowledge commitment for the generated encrypted attribute and upload it to the blockchain along with the encrypted attribute. The checkKey function verifies the authenticity of this commitment without leaking any attribute information. This design allows verification that the attribute authority has encrypted the correct attribute without exposing any attribute information, thereby achieving attribute auditability in the scheme.

[0015] The checkKey function is automatically executed by the smart contract on the blockchain. Upon receiving the encrypted attributes and their binding commitments uploaded by the attribute authority, the smart contract automatically calls the checkKey function to verify the zero-knowledge proof, ensuring that the attribute authority encrypted the correct attributes. Because this function is executed on the blockchain, the encrypted attributes are publicly verifiable.

[0016] The judgeAttrs function is automatically called and executed by the blockchain. The data storage service provider needs to be able to determine whether the data demander is truly authorized to access the uploaded ciphertext. To this end, we allow the data storage service provider to check whether the data demander actually possesses the legal attributes from the attribute agency. The legal attribute set is composed of the attributes published by each attribute agency. The present invention designs a mechanism to judge the validity of the combined attributes through smart contracts on the blockchain. Assuming that the combined attributes correspond to the attribute set [u] of the data demander, if a malicious user forges the attribute set, [u] will only contain those attribute sets that have passed the checkKey verification. Therefore, the data storage service provider will only send the ciphertext to them when the attribute set [u] of the data demander meets the access control policy.

[0017] The getKey function is called locally by the data demander. When the encrypted attributes uploaded by all attribute agencies pass the blockchain verification, that is, pass the checkKey function, the data demander downloads the encrypted attributes from the blockchain and uses his own private key sk u Decrypt the encrypted attributes to obtain the attributes. When all attributes are decrypted, the data demander can decrypt the data ciphertext of the data provider through the decrypted attribute set and finally obtain the data.

[0018] The auditable data sharing method for key abuse resistance based on attribute cryptography and blockchain provided by this invention is divided into five stages: initialization, data encryption, data request, key verification, and data decryption. The specific steps are as follows:

[0019] (1) Initialization;

[0020] The system initializes the data sharing process. First, each attribute provider locally calls the attribute initialization function to generate its key pair. Then, the data requester also generates its own key pair locally. Next, all attribute providers and data requesters publish their public keys to the blockchain for sharing. Finally, the data provider downloads and collects the public keys of all attribute providers from the blockchain.

[0021] (2) data encryption;

[0022] The data provider designs an access control policy based on the registered attribute agency. The policy specifies which attributes published by the attribute agency must be met in order to decrypt the ciphertext. Subsequently, the data provider calls the attribute encryption function ABEEncrypt to encrypt the data to be shared and generate ciphertext. The data provider then uploads the ciphertext to the data storage service provider and publishes the data description and access control policy to the blockchain, such as Figure 2 shown.

[0023] (3) data request;

[0024] After browsing the required data on the blockchain, the data demander sends a request to the blockchain. Subsequently, the blockchain notifies the relevant attribute agencies in the access control policy. Then, the attribute agencies that receive the notification use the public key of the data demander to call the ABEEncKey function to encrypt their respective attributes into encrypted attributes. At the same time, the attribute agencies call the genProofs function to generate zero-knowledge proof commitments corresponding to the attributes. Finally, these attribute agencies return the encrypted attributes and their corresponding commitments to the blockchain, such as Figure 3 shown.

[0025] (4) key verification;

[0026] After receiving the encrypted attributes and corresponding commitments uploaded by the attribute agency, the blockchain smart contract will automatically call the checkKey function to achieve public verifiability of the encrypted attributes. If checkKey returns True, it means that the attribute agency is honest. At this time, the blockchain will notify the data demander to download the encrypted attributes from the blockchain. In order to prevent offline collusion attacks between attribute agencies, the smart contract will also call the judgeAttrs function to determine whether the access control policy in the data ciphertext meets the sufficient attribute set. Once the conditions are met, the smart contract will notify the data storage service provider to send the corresponding data ciphertext to the data demander, such as Figure 3 shown.

[0027] (5) data decryption;

[0028] After obtaining the ciphertext, the data demander uses his own private key to call the getKey function locally to decrypt all the encrypted attributes. Subsequently, the data demander uses the decrypted attribute set to call the ABEDecrypt function to decrypt the ciphertext and obtain the final data, such as Figure 4 As shown. At this point, the entire data sharing process is completed.

[0029] The technical features and functional advantages of the present invention mainly include:

[0030] Data sharing is of great significance in today's information age. It can improve the efficiency of organizations and individuals, promote innovation, optimize resource allocation, and enhance transaction transparency. The advantage of using attribute cryptography is that it can achieve fine-grained access control, ensure data confidentiality, provide flexible access policies, and support access modes for multiple identities [5]. However, the abuse of attribute cryptography keys mainly manifests as illegal authorization and key leakage, which may lead to security risks such as impersonation attacks or unauthorized decryption [6].

[0031] To address these issues, the present invention designs a data sharing framework that can be used in the metaverse. It adopts a decentralized attribute cryptography scheme, and the distribution of attributes is managed by a responsible attribute organization. Specifically, a secure and efficient blockchain-driven data sharing framework is proposed, which uses a decentralized attribute cryptography scheme to ensure data confidentiality and fine-grained access control. For the first time, the present invention simultaneously considers the privacy and accountability mechanism of blockchain-based attribute keys, generates non-interactive zero-knowledge proofs to ensure accountability, and automatically verifies through smart contracts. In addition, the present invention also implements the verification of access control policies in smart contracts. The framework can be applied to decentralized games (GameFi), allowing players to flexibly sell or issue in-game items. This approach provides players with a transparent and secure system for participating in game activities, and the game ecosystem can also be supervised by a decentralized autonomous organization (DAO) [7].

[0032] This invention effectively addresses the issues of insufficient privacy protection, key abuse, and insufficient data auditing capabilities during data sharing, enabling secure and efficient data sharing and use. Based on this auditable key management mechanism, this invention demonstrates significant advantages in the decentralized sector, particularly for virtual item transactions in decentralized games and virtual asset exchanges within the metaverse, comprehensively enhancing security and data exchange efficiency in these areas. BRIEF DESCRIPTION OF THE DRAWINGS

[0033] Figure 1 This is a framework diagram of the key-abuse-resistant auditable data sharing system and method based on attribute cryptography and blockchain of the present invention.

[0034] Figure 2 It is a diagram of the workflow of data encryption in the present invention.

[0035] Figure 3 It is a diagram of the workflow of data request and key verification in the present invention.

[0036] Figure 4 It is a diagram of the workflow of data decryption in the present invention.

[0037] Figure 5 This is a diagram illustrating the time consumption of related off-chain functions in the present invention.

[0038] Figure 6 This is a graphic representation of the gas consumption of the on-chain related functions in the present invention on the blockchain. DETAILED DESCRIPTION

[0039] This paper proposes a blockchain-driven data sharing solution based on decentralized attribute cryptography, enabling secure key management, effectively addressing key abuse, and ensuring the accountability of authoritative institutions. Specifically, the invention utilizes a blockchain to store encrypted attributes and attaches non-interactive zero-knowledge proofs. After the attribute authority publishes them, the encrypted attributes are publicly verified through smart contracts. Ultimately, data requesters, after passing blockchain access control verification, obtain decrypted attributes and access the desired data.

[0040] The present invention is further illustrated below using examples and accompanying figures. To ensure the traceability and uniqueness of the data sharing process, we use a globally unique identifier (GID) as the unique identifier for each data sharing process. Assuming that a data provider wishes to share an electronic photo m, the data sharing method is divided into five stages:

[0041] (1) Initialization

[0042] The system initializes the data sharing. First, each attribute organization calls the attribute initialization function ABEAuthSetup locally to obtain its key pair (sk θ ,pk θ ), then the data demander generates its key pair locally (sk u ,pk u ). Then, all attribute agencies and data demanders publish their public keys on the blockchain for sharing. Finally, the data provider downloads and collects the public keys {pk θ}.

[0043] (2) Data encryption

[0044] The data provider encrypts a random value M into a ciphertext C←ABEEncrypt(M,ACP,{pk θ}), where ACP is the designed access control policy. Subsequently, the data provider encrypts the electronic photo m as ct←m⊕kdf(M), where kdf[4] is a key derivation function used to convert the random value M into a key that can be used for XOR operation, and ⊕ represents XOR operation. The data provider then stores (ct, C) on the data storage service provider and publishes the data description information and ACP on the blockchain.

[0045] (3) Data Request

[0046] After browsing the required data on the blockchain, the data demander sends a request to the blockchain. The request contains a set of tuples (GID, {u, pk θ} θ∈ACP), where u belongs to the attribute issued by the attribute authority. Then, the blockchain notifies the attribute authority that appears in the ACP. Next, (GID, pk u ,u) attribute institution uses the public key pk of the data demander u , locally call the attribute encryption function to generate the encryption attribute EK←ABEEncKey(GID,u,sk θ ,pk u ). At the same time, the local function genProofs is called to generate zero-knowledge proofs corresponding to the attributes. Finally, the attribute authority sends the encrypted attributes and the corresponding commitments (EK, proofs) back to the blockchain.

[0047] (4) Key Verification

[0048] After receiving the encrypted attributes and corresponding commitments (EK, proofs) uploaded by the attribute authority, the blockchain smart contract automatically calls the checkKey(EK, proofs, GID, u) function to publicly verify the encrypted attributes. If checkKey outputs True, it indicates that the attribute authority is honest, and the blockchain notifies the data requester to download the encrypted attributes EK from the blockchain. To mitigate offline collusion attacks between attribute authorities, the smart contract calls the judgeAttrs([u], ACP) function to determine whether the ACP in the data ciphertext C satisfies the sufficient attribute set {EK}. If so, the data storage service provider is notified to send the corresponding data ciphertext (ct, C) to the data requester.

[0049] (5) Data decryption

[0050] After obtaining the ciphertext (ct, C), the data demander uses his own private key sk locally u By calling getKey(EK,sk u ) function decrypts all encrypted attributes K. Next, the data requester uses the decrypted attribute set {K} to call the ABEDecrypt(C,{K}) function to decrypt the ciphertext C to obtain the random value M. Finally, by calculating m←ct⊕kdf(M), the data requester obtains the electronic photo m shared by the data provider. This completes data sharing.

[0051] The main process of this invention was experimentally tested on a Ubuntu 22.04 LTS virtual machine in VMware Workstation 16, with an Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz and 4GB RAM. The test results are as follows: In the off-chain test, Figure 5The time cost of the operation for each attribute in the data sharing is shown. The results show that the cost of executing the ABEEncKey function locally is about 1.3 milliseconds. The cost of the corresponding zero-knowledge proof generated by the genProofs function is about 1.4 milliseconds. The cost of the getKey function to obtain the decrypted attributes is about 0.19 milliseconds. The smart contract uses the judgeAttrs function to check whether a set of attributes constitutes a valid attribute of the decrypted ciphertext. By randomly selecting AND and OR gates in the access control policy, in the on-chain test, we evaluated the gas consumption cost of the judgeAttrs and checkKey functions for smart contracts with 10 to 100 attributes respectively. Figure 6 As shown, the gas consumption of the judgeAttrs and checkKey functions is linearly related to the number of attributes, and the gas consumption of the judgeAttrs function increases significantly faster than that of the checkKey function, especially when the number of attributes is large.

[0052] References:

[0053] [1]Rouselakis Y,Waters B.Efficient statically-secure large-universemulti-authority attribute-based encryption[C]International Conference onFinancial Cryptography and Data Security,2015:315-332.

[0054] [2]Boneh D, Shoup VA graduate course in applied cryptography[J].2020.

[0055] [3] Yu K, Tan L, Aloqaily M, et al. Blockchain-enhanced data sharing with traceable and direct revocation in IIoT[J]. IEEE transactions on industrialinformatics, 2021:7669-7678.

[0056] [4]Zhang L,Ou Z,Hu C,et al.Data sharing in the metaverse with keyabuse resistance based on decentralized CP-ABE[J].IEEE Transactions onComputers,2024.

[0057] [5]Bethencourt J,Sahai A,Waters B.Ciphertext-policy attribute-basedencryption[C]IEEE symposium on security and privacy.2007:321-334.

[0058] [6]Hei Y,Liu J,Feng H,et al.Making MA-ABE fully accountable:Ablockchain-based approach for secure digital right management[J].ComputerNetworks,2021

[0059] [7]Gadekallu T R,Wang W,Yenduri G,et al.Blockchain for the metaverse:A review[J].Future Generation Computer Systems,2023,143:401-419。

Claims

1. A data sharing system that resists key abuse based on attribute cryptography and blockchain, characterized in that: It includes the following five parts: data providers, data demanders, attribute institutions, blockchain and data storage service providers; among which: (1) Data provider: The data provider is the holder of the data. The data provider selects the appropriate access control policy based on the existing attribute structure, encrypts the data to be shared using the attribute encryption function ABEEncrypt, and transmits the ciphertext to the data storage service provider for use by data demanders. The data description information is then published on the blockchain. (2) Data demander: After initialization, the data demander has a key pair (sk u ,pk u ), and the public key pk u Registered on the blockchain; when the description information uploaded by the data provider to the blockchain meets the requirements of the data demander, the data demander sends an application to the blockchain to obtain the data; the blockchain responds to the data demander and sends him the key that meets the access control policy in the form of ciphertext; the data demander finally uses his private key sk u Decrypt using the attribute decryption function ABEDecrypt to obtain the required data; (3) Attribute institution: The system has multiple attribute institutions, each of which has its own independent key pair (sk θ ,pk θ ), and the public key pk θ Registered on the blockchain; these institutions provide attribute keys to data demanders by responding to attribute application requests on the blockchain. They operate independently on a global scale and autonomously distribute and manage attribute keys. (4) Blockchain: As a decentralized, tamper-proof server, it provides support for reliable storage and verifiable computing; specifically, it is used to manage the keys of attribute passwords and provide access control policy verification services; (5) Data storage service provider: a server dedicated to storing ciphertext uploaded by data providers.

2. The data sharing system according to claim 1, characterized in that: It also includes the design of the following functions: ABEEncKey, getKey, genProofs, checkKey and judgeAttrs; among them: ABEEncKey function is called by the attribute agency; after obtaining the attribute application of the blockchain, the attribute agency uses the public key pk u Call the ABEEncKey function locally and then upload the generated encrypted attributes to the blockchain; The genProofs function is called by the attribute authority and is designed using zero-knowledge proof technology. After the attribute authority calls ABEEncKey, it continues to call the genProofs function to generate a zero-knowledge commitment for the generated encrypted attributes and upload it to the blockchain along with the encrypted attributes. The checkKey function is responsible for verifying the authenticity of the commitment without leaking any attribute information. The checkKey function is automatically executed by the smart contract on the blockchain. Upon receiving the encrypted attributes and their binding commitments uploaded by the attribute authority, the smart contract will automatically call the checkKey function to verify the zero-knowledge proof to ensure that the attribute authority has encrypted the correct attributes. The judgeAttrs function is automatically called and executed by the blockchain. The data storage service provider needs to be able to determine whether the data demander is truly authorized to access the uploaded ciphertext. To this end, the data storage service provider is allowed to check whether the data demander actually possesses the legitimate attributes from the attribute agency. The legitimate attribute set is composed of the attributes published by each attribute agency. A specific mechanism is designed to judge the validity of the combined attributes through smart contracts on the blockchain. Assuming that the combined attributes correspond to the attribute set [u] of the data demander, if a malicious user forges the attribute set, [u] will only contain those attribute sets that have passed the checkKey verification. Therefore, the data storage service provider will only send the ciphertext to the data demander if the attribute set [u] of the data demander satisfies the access control policy. The getKey function is called locally by the data demander. When all the encrypted attributes uploaded by the attribute agency pass the blockchain verification, that is, after passing the checkKey function, the data demander downloads the encrypted attributes from the blockchain and uses his own private key sk u The encrypted attributes are decrypted to obtain the attributes. When all attributes are decrypted, the data demander decrypts the data ciphertext of the data provider through the decrypted attribute set and finally obtains the data.

3. The data sharing method based on the data sharing system according to claim 2, characterized in that: The specific steps are as follows: (1) Initialization; First, each attribute agency calls the attribute initialization function locally to generate its key pair, and then the data demander also generates its own key pair locally. Next, all attribute agencies and data demanders publish their public keys to the blockchain for sharing. Finally, the data provider downloads and collects the public keys of all attribute agencies from the blockchain. (2) data encryption; The data provider designs an access control policy based on the registered attribute organization. This policy specifies which attributes published by the attribute organization must be met in order to decrypt the ciphertext. The data provider then calls the attribute encryption function ABEEncrypt to encrypt the data to be shared and generate ciphertext. The data provider then uploads the ciphertext to the data storage service provider and publishes the data description and access control policy on the blockchain. (3) data request; After browsing the required data on the blockchain, the data demander sends a request to the blockchain; Subsequently, the blockchain notifies the relevant attribute agencies in the access control policy. The notified attribute agencies then use the public key of the data requester to call the ABEEncKey function to encrypt their respective attributes into encrypted attributes. Simultaneously, the attribute agencies call the genProofs function to generate zero-knowledge proof commitments corresponding to the attributes. Finally, these attribute agencies return the encrypted attributes and their corresponding commitments to the blockchain. (4) key verification; After receiving the encrypted attributes and corresponding commitments uploaded by the attribute agency, the blockchain smart contract automatically calls the checkKey function to achieve public verifiability of the encrypted attributes. If checkKey returns True, it indicates that the attribute agency is honest. At this time, the blockchain notifies the data demander to download the encrypted attributes from the blockchain. To prevent offline collusion attacks between attribute agencies, the smart contract also calls the judgeAttrs function to determine whether the access control policy in the data ciphertext meets the sufficient attribute set. Once the conditions are met, the smart contract notifies the data storage service provider to send the corresponding data ciphertext to the data demander. (5) data decryption; After obtaining the ciphertext, the data demander uses his own private key to locally call the getKey function to decrypt all encrypted attributes; Subsequently, the data demander uses the decrypted attribute set to call the ABEDecrypt function to decrypt the ciphertext and obtain the final data.

Images