A blockchain-based revocable distributed attribute-based encryption method

Abstract

The application provides a kind of revocable distributed attribute-based encryption method based on blockchain, belong to blockchain, internet of things, data sharing and attribute-based encryption (ABE) technical field.Solve the technical problem of privacy leakage existing in the scene of internet of things data sharing.The technical scheme is as follows: including the following steps: S10, system establishment;S20, authority initialization;S30, user registration;S40, user attribute private key generation;S50, data encryption;S60, data access;S70, user attribute revocation.The beneficial effects of the application are: using blockchain and distributed multi-authority ABE to realize fine-grained security sharing of internet of things data, realize forward and backward security of shared data when attribute is revoked, and improve the efficiency of attribute revocation.

Description

TECHNICAL FIELD

[0001] The present application relates to the fields of blockchain, Internet of Things, data sharing and attribute-based encryption, and in particular to a blockchain-based revocable distributed attribute-based encryption method. BACKGROUND

[0002] With the access of massive terminal devices and the rapid development of 5G technology, the Internet of Things (IoT) has become an indispensable part of people's daily life, complementing and supplementing technologies such as edge computing and artificial intelligence, and becoming an important research direction in academia and industry, playing an important role in typical applications such as industrial automation, transportation, energy systems and healthcare. According to Statista, the number of global IoT devices will reach 75 billion by 2025, and the amount of IoT data generated will be approximately 79.4 ZB. These IoT data often contain certain value, such as patient data collected by medical wearable devices, which can improve the accuracy of medical services. Most existing IoT application programs are based on data sharing deployment, with IoT data collected by intelligent sensors uploaded to cloud servers, which store and share the IoT data. IoT data sharing has penetrated into various fields such as smart home, smart healthcare and smart education, and is gradually changing the industrial structure and economic growth mode, having important strategic significance and social and economic value. However, IoT data often contains users' private information, and once leaked, it will pose a serious threat to individuals' property or national security. Therefore, it is of great practical significance to build a secure data sharing platform in the IoT environment.

[0003] The emergence of attribute-based encryption (ABE) provides a feasible solution for secure sharing of IoT data. ABE associates ciphertexts and keys with attribute sets and access structures, and only when the attribute set satisfies the access structure can decryption be successful, ensuring data confidentiality. ABE schemes have the following four characteristics: first, data providers only need to encrypt data based on attributes, without needing to worry about user identity, reducing encryption computation overhead and protecting user privacy; second, only users who meet the access control policy can correctly decrypt the ciphertext, ensuring data confidentiality; third, user keys are related to their embedded random numbers, and different users' keys cannot be combined, preventing collusion attacks between malicious users; and fourth, ABE mechanisms support flexible access control policies, enabling attribute AND, OR, NOT and threshold operations. The flexibility, efficiency and resistance to collusion of ABE make it have good application prospects in the fields of fine-grained access control and privacy protection.

[0004] The original ABE scheme can only support threshold access control policy. In order to express the access control policy more flexibly, Bethencourt et al. proposed a ciphertext policy attribute-based encryption (CP-ABE). In the CP-ABE scheme, the private key is associated with the attribute set, and the ciphertext is associated with the access control policy. If the data provider wants to share the IoT data with people who have certain attributes, it needs to formulate the corresponding access control policy and embed the policy into the ciphertext. Other users want to obtain shared data, and their own attributes need to meet the access control policy of the ciphertext to decrypt the ciphertext. Therefore, CP-ABE is more suitable for fine-grained secure sharing of data in the Internet of Things environment. However, the traditional CP-ABE scheme needs a trusted key generation center to manage the key, and the generation, distribution and revocation of user attribute private keys are excessively dependent on the key generation center. When the key generation center has a security problem, the security of the system will be seriously threatened.

[0005] In order to improve the security problem of the key generation center, scholars have proposed some data sharing schemes based on blockchain. Blockchain is a distributed ledger with a chain structure, which integrates distributed data storage, cryptographic algorithms, peer-to-peer networks, consensus mechanisms and other technologies, and brings hope to solve the trust problem of the key distribution center and the transparent data sharing process. With the help of consensus mechanism and distributed data storage technology, blockchain can provide traceable basis for the generation, distribution and revocation process of user attribute private keys, reducing the absolute trust on the key generation center. Blockchain can also use smart contracts to solve the policy matching problem in the sharing process. The data provider writes the logic of policy matching into the smart contract to automatically execute policy matching in a specific scenario, improve sharing efficiency and simplify the sharing process. In addition, blockchain plays an important role in the transparent sharing process. Compared with traditional sharing platforms, the sharing process recorded in the blockchain is more real and credible. Blockchain uses cryptographic principles and time stamping technology to ensure data integrity, helping entities in the system establish trust. Therefore, using blockchain to store data in the Internet of Things data sharing scenario can guarantee the fairness, justice and openness of the data sharing process.

[0006] However, data access is not static, and with the dynamic change of user attributes, the user's access rights to data need to be adjusted constantly. Therefore, supporting user attribute revocation will be a basic requirement, and by revoking user attributes, it can prevent revoked users from decrypting data ciphertext. Considering that revoked users may retain old decryption keys, ciphertext and key updates are still needed when performing attribute revocation, so as to guarantee the forward and backward security of data sharing. Therefore, it is of great practical significance to use blockchain and distributed CP-ABE technology to realize fine-grained secure sharing of data while ensuring the security of IoT data sharing. SUMMARY

[0007] The application aims to provide a revocable distributed attribute-based encryption method based on a blockchain, which utilizes a blockchain and an attribute-based encryption algorithm to ensure the openness, transparency and traceability of a data sharing process in an Internet of Things environment, effectively prevents unauthorized users from accessing data, maintains the security of shared data, outsources part of decryption calculation of a user to a cloud server, greatly reduces the calculation cost of the user and improves the efficiency of system operation.

[0008] The application idea is that the revocable distributed attribute-based encryption method based on a blockchain provided by the application firstly performs system global initialization, a system administrator constructs a blockchain, generates global public parameters, each authority calculates corresponding attribute public and private key pairs according to the range of the attribute under its jurisdiction, the system administrator generates an identity public and private key pair and a digital certificate for a legal user, the authority calculates a corresponding attribute private key for the legal user according to the attribute set under its jurisdiction, a data provider formulates and encrypts Internet of Things data to be shared by using an access control strategy, and uploads the ciphertexts to a cloud server, a data applicant downloads the ciphertexts of the Internet of Things data from the cloud server, and only when the attribute set of the user meets the access control strategy of the ciphertexts, the shared data can be decrypted and obtained, and when a certain attribute or certain attributes of the user are revoked, the data provider needs to update the ciphertexts, and the data applicant needs to update the attribute private key.

[0009] In order to achieve the above application purpose, the technical scheme adopted by the application is specifically as follows: a revocable distributed attribute-based encryption method based on a blockchain, comprising the following steps:

[0010] S10, system establishment, a platform supervisor PS constructs a blockchain, generates public parameters CP, and obtains a corresponding wallet address and a public and private key pair (sk0, pk0). The PS records the CP and the public key pk0 on a genesis block of the blockchain.

[0011] S20, authority initialization, the platform supervisor PS specifies an attribute set under the jurisdiction of each legal authority AM. The AM randomly selects two numbers as its own private key and the version private key of the attribute under its management, then reads the public parameters CP and the public key pk0 of the PS from the blockchain, and calculates to obtain the attribute public key of the attribute under its jurisdiction and its authorized public key. The AM records the attribute public key set, the attribute hash value and the authorized public key to the blockchain.

[0012] S30, user registration, a user applies for registration to the platform supervisor PS, the PS calculates a public and private key pair and a verification certificate for the legal user, and records the public key of the user as a transaction to the blockchain.

[0013] S40. User attribute private key generation: Data user DU applies for an attribute private key from the authoritative institution AM. AM verifies DU's identity and calculates the attribute private key ask for the legitimate DU. k,j,i AM uses DU's public key and the RSA encryption algorithm to encrypt the set of attribute private keys and uploads a list containing the ciphertext of the attribute private keys to the blockchain. DU can retrieve the ciphertext of the attribute private key from the blockchain based on the transaction record index, and then obtain the attribute private key by decrypting the ciphertext.

[0014] S50. Data Encryption: The data provider DP randomly selects a session key κ and uses the AES symmetric encryption algorithm to encrypt the IoT data M to be shared, obtaining the ciphertext DCT. Then, an appropriate access control policy is formulated based on the applicable scope of M. DP reads the public key set related to the access control policy from the blockchain, encrypts the session key κ, calculates the key ciphertext KCT, and then uploads KCT to the cloud server.

[0015] S60. Data Access: Data user DU calls the policy matching function to obtain the ciphertext key KCT from the cloud server. The ciphertext can only be decrypted if DU's attributes satisfy the ciphertext's access control policy. First, DU uses the ciphertext component in KCT to calculate the decryption factor df. j Then the cloud server uses df j DU uses its public key and attribute private key set to calculate the converted ciphertext CTc; finally, DU uses its own private key to decrypt CTc, recover the session key κ, and uses κ to decrypt the data ciphertext DCT to obtain the shared data M.

[0016] S70. User Attribute Revocation: When the authoritative organization AM revokes one or more attributes of a data user DU, the AM invokes a policy matching algorithm to filter out the ciphertext set {KCT} of the session key that needs to be updated. x The relevant data providers (DP) and data users (DU) are involved. The Analyst (AM) runs an algorithm to calculate a new attribute public key, a ciphertext update key (CUK), and a key update key (KUK). The AM sends the CUK to the DP that needs to update its ciphertext via a secure channel and records the KUK in the blockchain. The DP uses the CUK to update the corresponding key ciphertext, and the user's use of the KUK to update their own attribute private key is not revoked.

[0017] The main entities in the blockchain-based IoT data fine-grained secure sharing method include: system administrator, data provider, data applicant, authoritative institution, blockchain, and cloud server.

[0018] Further, step S10 includes:

[0019] S101, Platform Regulator PS Builds Blockchain Select a unique identity id for it PS , generate a public-private key pair {sk0, pk0};

[0020] S102, the platform supervisor PS inputs the security parameter λ, selects a bilinear group G with order N=p1p2p3, where p1, p2, p3 are three different large prime numbers, and selects a hash function H:{0,1}*→G, which can map attributes to elements in the group G;

[0021] S103, let G1 represent a subgroup of the group G with order p1, randomly select a generator g∈G1, and the platform supervisor PS obtains the public parameter CP={N, g∈G1, H(·)};

[0022] S104, the platform supervisor PS secretly saves its private key sk0, and records the public key pk0 and the public parameter CP to the genesis block of the blockchain, so as to facilitate users and authorities to obtain CP and pk0 from the blockchain.

[0023] Further, the step S20 comprises:

[0024] S201, the platform supervisor PS specifies the attribute set under jurisdiction for each authority AM, and requires that there is no repetition between the attributes managed by each AM;

[0025] S202, assuming that the kth authority AM k has an attribute set S k under jurisdiction, the platform supervisor PS selects a wallet address aid as the identity of the AM k , and grants the AM k the corresponding attribute set management authority;

[0026] S203, the authority AM k reads the public parameter CP and the platform supervisor public key pk0 from the genesis block. The AM k selects a random number β k ∈Z N as the private key of the AM k , and for any attribute i∈S k , additionally selects a random number v k,i as the version private key VK k,i of the attribute i, that is, v k,i , and the AM k calculates the ith attribute public key k k,i

[0027] S204, for the authority AM k ​​obtains the version private key of each attribute using the method of step S203, and obtains an attribute version private key set {VK k,i = v k,i , v k,i ∈ Z N} and an attribute public key set

[0028] S205, the authority AM k uses its private key β k to calculate as its authorized public key;

[0029] S206, the authority AM k needs to keep its private key β k and version private key VK k,i secret, and AM k records a set of attribute public keys {PK k,i |i∈S k}, a set of hash values {H(i)|i∈S k} corresponding to each attribute i, and the authorized public key PK k to the authority list L AM-att , which is recorded to the blockchain.

[0030] Further, the step S30 comprises:

[0031] S301, when joining the system, the data provider DP and the data user DU need to apply for registration to the platform supervisor PS first, and submit identity description information Info DU (for example: name, email, etc.), and the PS will select a wallet address uid as the identity identifier of the legal user after verification;

[0032] S302, according to the wallet address uid of the user, the PS selects two random numbers u uid , z uid ∈ Z N , calculates the public key and the private key sk uid = z uid of the user;

[0033] S303, the platform supervisor PS calculates the digital signature of the user using its private key sk0 for the convenience of the authority to verify the identity of the user, and generates the digital certificate Cert(uid) of the user;

[0034] S304, the platform supervisor PS transmits the public key and private key pair (pk uid , sk uidThe user's PK is sent along with a digital certificate (Cert(uid)). uid Recorded on the blockchain.

[0035] Further, step S40 includes:

[0036] S401, Assume that the data user DU has wallet address j. j To the k-th authoritative institution AM k Request a private key for the attribute, U k It is AM k The set of users within the domain, SA is the set of authoritative institutions, j∈U k ,k∈SA,AM k The set of attributes to be managed is S k DU j The attribute i∈S of the application k DU j In order to obtain the attribute private key, in AM k When submitting the application, send your digital certificate Cert(uid) to AM. k AM k Read the public key of the platform regulator PS from the blockchain to verify PK0 DU. j His identity, and obtained the connection with DU j Related components

[0037] S402, Authoritative Organization AM k For legitimate data users DU j Generate attribute private keys for DU j Any attribute i∈S k AM k Read the public parameter CP from the blockchain and use its private key SK. k Attribute public key set {PK k,i |i∈S k}, Attribute set S k Calculate and obtain the private key of the i-th attribute.

[0038] S403, Authoritative Organization AM k Using the RSA encryption algorithm Enc(pk) j ,{ask k,j,i}) Calculate the ciphertext {cask} of the user attribute private key set. k,j,i |k∈SA,j∈U k ,i∈S k};

[0039] S404, Authoritative Organization AM kRecord the user's public key, attribute set and attribute private key ciphertext to the user attribute list L DU-Att In the middle of the list as a transaction record on the blockchain, while recording the index TX j,k Data user DU j According to TX j,k Get attribute private key ciphertext from the blockchain, and use your own private key sk j Decrypt the ciphertext to get the corresponding attribute private key. In the same way, DU j Get all attribute private keys from other authorities, get attribute private key set {ask k′,j′,i′ |k′∈SA,j′∈U k′ ,i′∈S k′}.

[0040] Further, the step S50 comprises:

[0041] S501, the data provider DP selects the session key κ, encrypts the shared Internet of Things data M using the AES symmetric encryption algorithm AES.enc(κ, M), and calculates the data ciphertext DCT=AES.enc(κ, M);

[0042] S502, the data provider DP formulates the corresponding access control policy for the shared Internet of Things data M according to its own attributes and the objects that want to share the data Where A is an nxl matrix, and the function ρ is a mapping from the set {1, 2, …, n} to the attribute set;

[0043] S503, the data provider DP reads the public parameters CP from the genesis block, and reads the attribute public key set {PK k,i |i∈S k} and the authorized public key set {PK k} k∈SA Related to the access control policy from the blockchain, DP uses CP, {PK k,i |i∈S k} and {PK k} k∈SA Encrypt the session key κ to generate the session key ciphertext KCT. The specific process is: DP selects l random numbers s, v2, v3, …, v l ∈Z N * , constructs the vector v=<s, v2, v3, …, v l >, calculates λ i =A i ·v, where A i is the i-th row of the matrix A; select l-1 random numbers ω2, ω3, …, ωl ∈Z N * , constitute a vector ω = <0, ω2, ω3, …, ω l >, calculate ω i = A i · ω. For each row A i of the access control matrix A, DP randomly selects r i ∈Z N * , calculate KCT as:

[0044]

[0045]

[0046]

[0047] ρ(i)∈S k ,k∈SA}

[0048] Where A (A, ρ) represents the access control policy, C0 represents the result of encrypting the session key, κ represents the session key, β k represents the private key of the kth authority, k∈SA represents the kth authority in the authority set SA, e (g, g) represents the bilinear pair operation, C 1,i , C 2,i , C 3,i represent the ciphertext components containing the access control policy, ρ(i) represents the attribute corresponding to the i th row of the access control matrix, v k,ρ(i) represents the attribute ρ(i) version private key of the kth authority.

[0049] S504, the data provider DP uploads the data ciphertext DCT of the shared data M, the access control policy A (A, ρ) and the session key ciphertext KCT to the cloud server, and the cloud server records the address URL of the ciphertext and the description information of the shared data M on the blockchain.

[0050] Further, the step S60 comprises:

[0051] S601, the data user DU j with the wallet address j retrieves the description information of the shared data in the blockchain through the keyword, finds the required information, and calls the policy matching function. Only when the attribute of itself meets the access control policy set by the data provider DP, the smart contract in the blockchain will send the storage address URL of the data ciphertext DCT x and the session key ciphertext KCT x of the shared data M x to the DU j , and the DUj The encrypted data stored in the cloud server by the DP can be obtained via the URL. j The process of acquiring data will be recorded in the shared list L. data middle;

[0052] S602, due to data user DU j Due to limited computing power, some complex calculations in the decryption process need to be outsourced to cloud servers. Firstly, DU j Using session key ciphertext KCT x The ciphertext component C in 1,i and your private key sk j Calculate the decryption factor df j :

[0053]

[0054] Where z j This indicates that the data user DU has wallet address j. j The private key, i.e., z j =sk j .

[0055] S603, Data User DU j Decryption factor df is transmitted via a secure channel. j PK with your own public key j and attribute private key set {ask k,j,i |k∈SA,i∈S k Send to the cloud server ESC;

[0056] S604, Cloud Server ESC in User Attribute List L DU-Att DU Search and Data Users j Related attribute public key set {PK k,j}, the common subset P of computed attributes j,A ={ρ(i):i∈l}∩{PK k,j}, where l is a set of row numbers in the access control matrix A. For set P j,A Regarding these properties, ESC will further check whether there exists a subset Ic such that Ic is a linear combination of vectors (1,0,…,0). If it exists, ESC selects a set of constants {c}. i ∈Z N}, where i represents the i-th row of the access control matrix, such that ∑ i c i A i = (1,0,…,0), ESC calculates the converted ciphertext CT. c :

[0057]

[0058] Where ω i =A i ·ω,λ i =A i ·v,v·(1,0,…,0)=s,ω·(1,0,…,0)=0. The cloud server ESC transmits CT via a secure channel. c Send to DU j ;

[0059] S605, Data User DU j Obtain the converted ciphertext CT c Then, using his private key sk j Decoding CT c Restore session key κ:

[0060]

[0061] S606, Data User DU j Decrypting the ciphertext DCT using the session key κ x , obtain shared data M x M x =Dec(κ,DCT) x ).

[0062] Further, step S70 includes:

[0063] S701, Assuming the data requester The attribute μ was determined by the authoritative organization AM k Cancel, AM k Call the strategy matching function to filter out those caused by cancellation. The session key ciphertext set {KCT} that needs to be updated for the μ attribute x}, AM k Search shared list L data Filter out those matching {KCT} x The relevant DP and DU, AM k Notify users in the search results to update their ciphertext or key;

[0064] S702, Authoritative Organization AM k Choose a random value v again k,μ ′∈Z N The new version of the private key VK as the revocation attribute μ k,μ =v k,μ ′, update the public key of attribute μ To ensure the security of attribute revocation, DP needs to use the encrypted update key CUK. μThe ciphertext associated with the revocation attribute μ is updated, and the unrevoked user who possesses the revocation attribute μ needs to use the key update key KUK j,μ The key associated with μ is updated. AM k Using its private key SK k , the new version key VK k,μ , the old version key VK k,μ , and the attribute public key set of the unrevoked user The following is obtained And

[0065] S703, the authority AM k Records the process of attribute revocation to the revocation list L R-Att , and then records the list and the key update key KUK j,μ To the blockchain, and then AM k Sends CUK μ To the data provider DP who needs to update the ciphertext through a secure channel;

[0066] S704, DP obtains the ciphertext update key CUK μ Through a secure channel, updates the session key ciphertext KCT x Associated with the revoked attribute μ. DP reselects the session key κ', and calculates the updated data ciphertext DCT ud = AES.enc(κ', M) using the AES symmetric encryption algorithm. This process can be performed in advance when the attribute is revoked;

[0067] S705, the update of part of the ciphertext component CT μ = {C0, C 3,i} can greatly improve the efficiency of attribute revocation. DP calculates the update of C0 in KCT x Using κ':

[0068]

[0069] The calculation of C0 can also be performed locally in advance, so the main calculation overhead of attribute revocation is to update the ciphertext C 3,i Associated with the revoked attribute μ. DP updates C μ In KCT x Using the ciphertext update key CUK 3,i :

[0070]

[0071] Get the updated session key ciphertext KCT ud :

[0072]

[0073]

[0074]

[0075]

[0076]

[0077] DP will update the ciphertext KCT ud to the cloud server. By providing the ciphertext update key provided by AM k , the proposed scheme can guarantee the forward security of the access control system, that is, if the newly added user has attributes that meet the access control policy, he can decrypt the session key ciphertext. And the revoked user cannot decrypt the session key ciphertext KCT k,j,i using the old version of the attribute private key set {ask k |k∈SA,i∈S ud} cannot decrypt the session key ciphertext KCT i , because the cloud server ESC will select a set of constants {c N ∈Z When the vector (1,0,…,0) cannot be obtained, the decryption will stop. Therefore, it is impossible to decrypt the conversion ciphertext to obtain the updated session key κ′, and further decrypt the data ciphertext;

[0078] S706, when the key ciphertext is updated, the unrevoked user who meets the ciphertext access control policy needs to update its attribute private key. The authority AM finds the user who needs to update the attribute private key in the list L DU-Att and records it as a list {list DU}, AM notifies each user in {list DU} to update the attribute private key. Each unrevoked user DU j with revoked attribute μ, where DU j does not contain users who need attribute revocation, obtains the corresponding key update key KUK j,μ through the smart contract, and DU j updates its attribute private key ask j,μ K k,j,i in K j,μ :

[0079]

[0080] where K j ′ ,μ denotes the updated attribute private key component. v k,μ denotes the version private key of attribute μ owned by the kth authority.

[0081] get the updated attribute private key ask' k,j,μ :

[0082]

[0083]

[0084] Since the wallet address u j of the DU j is unique, these KUK j,μ are different for all unrevoked users, so the revoked user cannot use the KUK j,μ of other unrevoked users to update his own key, ensuring the backward security of data sharing.

[0085] S707, after the unrevoked user updates his own attribute private key, he obtains the updated key ciphertext KCT ud and data ciphertext DCT ud from the cloud server ESC. Repeat the steps of S602, S603, S604, S605 and S606, the unrevoked user first obtains the decryption factor df j ', then sends the updated key set {ask' k,j,i |k∈SA,i∈S k} and his own public key pk j to the ESC. The ESC selects a set of constants {c i ∈Z N} such that Σ i c i A i =(1,0,…,0), then decrypts KCT ud to get the conversion ciphertext CT' c , then the unrevoked user recovers the session key κ' using his own private key sk j , and finally uses κ' to decrypt DCT ud to get the shared Internet of Things data M x .

[0086] Compared with the prior art, the present application has the following beneficial effects:

[0087] (1) The revocable distributed attribute-based encryption method based on blockchain provided by the present application combines blockchain with distributed attribute-based encryption scheme, uses consensus-driven blockchain framework to map the trust problem of key distribution from the authority to the distributed ledger, and realizes decentralized key management in the Internet of Things environment.

[0088] (2) The application provides a blockchain-based revocable distributed attribute-based encryption method, which records the sharing process of the whole IoT data on the blockchain, and guarantees the fairness, justice and openness of the data sharing process by using the characteristics of the blockchain, such as non-tamperability, traceability and auditability.

[0089] (3) The application provides a blockchain-based revocable distributed attribute-based encryption method, which applies the distributed attribute-based encryption scheme to the data sharing of the Internet of Things, realizes the fine-grained authorization of user data while protecting the privacy of the user, effectively prevents unauthorized users from accessing the data, and guarantees the security of the IoT data sharing.

[0090] (4) The application provides a blockchain-based revocable distributed attribute-based encryption method, which uses the smart contract in the blockchain to assist the authority to realize the revocation of the user attributes, the data provider updates the ciphertext related to the revoked attributes, and the unrevoked user updates the attribute private key of the user, so that the forward and backward security of the shared data is guaranteed, and the efficiency of the attribute revocation is improved.

[0091] (5) The application combines the blockchain, attribute-based encryption and other technologies to realize the fine-grained security sharing of the data of the Internet of Things, effectively resists the collusion attack between malicious nodes, and guarantees the forward and backward security of the sharing process. BRIEF DESCRIPTION OF DRAWINGS

[0092] The accompanying drawings are included to provide a further understanding of the application, and constitute a part of the specification, which together with the embodiments of the application are used to explain the application, and do not constitute a limitation on the application.

[0093] Fig. 1 A flowchart of a blockchain-based revocable distributed attribute-based encryption method provided by the application.

[0094] Fig. 2 A model diagram of a blockchain-based revocable distributed attribute-based encryption method provided by the application. DETAILED DESCRIPTION

[0095] In order to make the purpose, technical scheme and advantages of the application more clear, the application is further described in detail below in combination with the drawings and embodiments. Of course, the specific embodiments described herein are only used to explain the application, and do not limit the application.

[0096] EMBODIMENT

[0097] Referring to Figs. 1-2 The embodiment provides a blockchain-based revocable distributed attribute-based encryption method, and the entities thereof include a system administrator, a data provider, a data applicant, an authority, a blockchain and a cloud server.

[0098] comprising the following steps:

[0099] S10, system establishment, the platform supervisor PS constructs a blockchain, generates a public parameter CP, and obtains a corresponding wallet address and a public-private key pair (sk0, pk0). The PS records the CP and the public key pk0 on the genesis block of the blockchain.

[0100] S20, authority initialization, the platform supervisor PS specifies a set of attributes under jurisdiction for each legal authority AM. The AM randomly selects two numbers as its own private key and the version private key of the attribute it manages, then reads the public parameter CP and the public key pk0 of the PS from the blockchain, and calculates the attribute public key of the attribute under jurisdiction and the authorization public key of the AM. The AM records the attribute public key set, the attribute hash value, and the authorization public key to the blockchain.

[0101] S30, user registration, the user applies to the platform supervisor PS for registration, and the PS calculates the public-private key pair and the verification certificate for the legal user, and records the public key of the user as a transaction to the blockchain.

[0102] S40, user attribute private key generation, the data user DU applies to the authority AM for an attribute private key, the AM verifies the identity of the DU, and calculates the attribute private key ask k,j,i for the legal DU. The AM encrypts the attribute private key set using the public key of the DU and the RSA encryption algorithm, and uploads the list recording the attribute private key ciphertext to the blockchain. The DU can obtain the attribute private key ciphertext from the blockchain according to the index of the transaction record, and then obtain the attribute private key by decrypting the ciphertext.

[0103] S50, data encryption, the data provider DP randomly selects a session key κ, encrypts the Internet of Things data M to be shared using the AES symmetric encryption algorithm to obtain data ciphertext DCT, and formulates a corresponding access control policy according to the applicable range of M The DP reads the public key set related to the access control policy from the blockchain, encrypts the session key κ, and calculates the key ciphertext KCT. Then the DP uploads the KCT to the cloud server.

[0104] S60, data access, the data user DU calls a policy matching function to obtain the key ciphertext KCT from the cloud server, and only when the attributes of the DU meet the access control policy of the ciphertext can the ciphertext be decrypted. First, the DU calculates a decryption factor df j using the ciphertext components in KCT; then the cloud server calculates a conversion ciphertext CTc using df j , the public key of the DU, and the attribute private key set; finally, the DU decrypts CTc using its own private key to recover the session key κ, and uses κ to decrypt the data ciphertext DCT to obtain the shared data M.

[0105] S70, when the authority AM revokes certain attribute of the data user DU, the AM invokes the strategy matching algorithm to screen out the data provider DP and the data user DU related to the session key ciphertext set {KCT x} that needs to be updated. The AM runs the algorithm to obtain the new attribute public key, the ciphertext update key CUK and the key update key KUK. The AM sends the CUK to the DP that needs to update the ciphertext through a secure channel, and records the KUK in the block chain. The DP updates the corresponding key ciphertext using the CUK, and the user who is not revoked updates his own attribute private key using the KUK.

[0106] Among them, the main entities in the distributed attribute-based encryption method based on blockchain revocation include: system administrator, data owner, data applicant, authority, blockchain, cloud server.

[0107] The step S10 specifically comprises the following steps:

[0108] S101, the platform supervisor PS constructs a blockchain Select a unique identity id for it PS , generate a public and private key pair {sk0, pk0};

[0109] S102, the platform supervisor PS inputs the security parameter λ, selects a bilinear group G with order N=p1p2p3, where p1, p2, p3 are three different large prime numbers, and selects a hash function H:{0,1}*→G, which can map attributes to elements in the group G;

[0110] S103, let G1 represent a subgroup of the group G with order p1, randomly select a generator g∈G1, and the platform supervisor PS obtains the public parameter CP={N, g∈G1, H(·)};

[0111] S104, the platform supervisor PS secretly saves its private key sk0, and records the public key pk0 and the public parameter CP in the genesis block of the blockchain, so that users and authorities can obtain CP and pk0 from the blockchain.

[0112] Step S20 comprises the following steps:

[0113] S201, the platform supervisor PS specifies the attribute set under jurisdiction for each authority AM, and requires that there is no repetition between the attributes managed by each AM;

[0114] S202, assuming that the attribute set under jurisdiction of the kth authority AM k is S k , the platform supervisor PS specifies the attribute set under jurisdiction for each authority AM kSelect a wallet address aid as its identity, and grant AM k Corresponding attribute set management authority;

[0115] S203, the authority AM k Read the public parameters CP and platform supervisor public key pk0 from the genesis block. AM k Select a random number β k ∈Z N As the private key of AM k For any attribute i∈S k , select another random number v k,i As the version private key VK of attribute i k,i =v k,i , AM k Calculate the i-th attribute public key k Using β k,i And v

[0116] S204, for all attributes under the jurisdiction of the authority AM k Use the method of step S203 to obtain the version private key of each attribute, get the attribute version private key set {VK k,i =v k,i ,v k,i ∈Z N} and the attribute public key set

[0117] S205, the authority AM k Use its private key β k , calculate As its own authorization public key;

[0118] S206, the authority AM k Need to keep its private key β k And version private key VK k,i , AM k Record each attribute i corresponding to a group of attribute public keys {PK k,i |i∈S k}, a group of hash values {H(i)|i∈S k} and authorization public key PK k In the authority list L AM-att , this list will be recorded in the blockchain.

[0119] Step S30 includes the following steps:

[0120] S301, the data provider DP and the data user DU need to apply for registration to the platform supervisor PS when joining the system, and submit identity description information Info DU(For example: name, email, etc.), and after the PS verifies the user, a wallet address uid is selected as the identity of the legal user;

[0121] S302, according to the wallet address uid of the user, the PS selects two random numbers u uid , z uid ∈Z N , calculates the public key of the user and the private key sk uid =z uid ;

[0122] S303, the platform supervisor PS calculates the digital signature of the user using the private key sk0 for the convenience of the authority to verify the identity of the user generates the digital certificate Cert(uid) of the user;

[0123] S304, the platform supervisor PS sends the public-private key pair (pk uid ,sk uid ) and the digital certificate Cert(uid) to the user through a secret channel, and records the pk uid of the user on the blockchain.

[0124] Step S40 includes the following steps:

[0125] S401, assuming that the data user DU j with a wallet address j applies for an attribute private key to the kth authority AM k , U k is a set of users in the domain of AM k , SA is a set of authorities, j∈U k , k∈SA, the attribute set managed by AM k is S k , and the attribute i applied for by DU j is in S k . In order to obtain the attribute private key, the digital certificate Cert(uid) of DU j is sent to AM k at the same time as the application is submitted to AM k , and the public key pk0 of the platform supervisor PS is read from the blockchain by AM k to verify the identity of DU j , and the component related to DU j is obtained

[0126] S402, the authority AM k generates an attribute private key for the legal data user DU j , and for any attribute i in S j of DU k, AM k Read the public parameters CP from the blockchain, and use its private key SK k , attribute public key set {PK k,i |i∈S k}, attribute set S k Calculate the i-th attribute private key

[0127] S403, the authority AM k Use the RSA encryption algorithm Enc(pk j , {ask k,j,i}) to calculate the ciphertext of the user attribute private key set {cask k,j,i |k∈SA,j∈U k ,i∈S k};

[0128] S404, the authority AM k Record the user's public key, attribute set and attribute private key ciphertext in the user attribute list L DU-Att , and record the list as a transaction record on the blockchain, and record the index TX j,k of the transaction. The data user DU j obtains the attribute private key ciphertext from the blockchain according to TX j,k , and decrypts the ciphertext using its own private key sk j to obtain the corresponding attribute private key. In the same way, the DU j obtains all attribute private keys from other authorities, and obtains the attribute private key set {ask k′,j′,i′ |k′∈SA,j′∈U k′ ,i′∈S k′}.

[0129] Step S50 includes the following steps:

[0130] S501, the data provider DP selects a session key κ, encrypts the shared Internet of Things data M using the AES symmetric encryption algorithm AES.enc(κ,M), and calculates the data ciphertext DCT=AES.enc(κ,M);

[0131] S502, the data provider DP formulates a corresponding access control policy for the shared Internet of Things data M according to its own attributes and the objects to which it hopes to share data where A is an nxl matrix, and the function ρ is a mapping from the set {1,2,…,n} to the attribute set;

[0132] S503, the data provider DP reads the public parameters CP from the genesis block, and reads the attribute public key set {PKk,i |i∈S k} and authorized public key set {PK k} k∈SA DP utilizes CP. {PK k,i |i∈S k}, {PK k} k∈SA Encrypt the session key κ and generate the session key ciphertext KCT. The specific process is as follows: DP selects l random numbers s, v2, v3, ..., v l ∈Z N * Construct vectors v = <s, v2, v3, ..., v l >, calculate λ i =A i ·v, where A i It is the i-th row of matrix A; select l-1 random numbers ω2, ω3, ..., ω l ∈Z N * This forms a vector ω = <0, ω2, ω3, ..., ω l >, calculate ω i =A i ·ω. For each row A of the access control matrix A i DP randomly selects r i ∈Z N * The KCT is calculated as follows:

[0133]

[0134]

[0135]

[0136] ρ(i)∈S k ,k∈SA}

[0137] in This represents the access control policy, C0 represents the result of encrypting the session key, κ represents the session key, and β represents the access control policy. k The private key of the k-th authority, k∈SA, where k represents the k-th authority in the set of authorities SA, e(g,g) denotes the bilinear pairing operation, and C 1,i C 2,i C 3,i This represents a ciphertext component containing access control policies, where ρ(i) represents the attribute corresponding to the i-th row of the access control matrix, and v k,ρ(i) Let ρ(i) represent the version private key of the k-th authoritative institution attribute.

[0138] S504, Data Provider DP will share the encrypted data (DCT) of data M, and access control policies. The session key ciphertext KCT is uploaded to the cloud server, and the cloud server records the address URL where the ciphertext is stored and the description information of the shared data M on the blockchain.

[0139] Step S60 includes the following steps:

[0140] S601, Data user DU with wallet address j j By retrieving descriptive information of shared data in the blockchain using keywords, and finding the required information, a policy matching function is invoked. Only when the data provider's attributes meet the access control policy set by the data provider (DP) will the smart contract in the blockchain release the shared data M. x Data Encryption DCT x and session key ciphertext KCT x Send the storage address URL to DU j DU j The encrypted data stored in the cloud server by the DP can be obtained via the URL. j The process of acquiring data will be recorded in the shared list L. data middle;

[0141] S602, due to data user DU j Due to limited computing power, some complex calculations in the decryption process need to be outsourced to cloud servers. Firstly, DU j Using session key ciphertext KCT x The ciphertext component C in 1,i and your private key sk j Calculate the decryption factor df j :

[0142]

[0143] Where z j This indicates that the data user DU has wallet address j. j The private key, i.e., z j =sk j .

[0144] S603, Data User DU j Decryption factor df is transmitted via a secure channel. j PK with your own public key j and attribute private key set {ask k,j,i |k∈SA,i∈S k Send to the cloud server ESC;

[0145] S604, Cloud Server ESC in User Attribute List L DU-AttDU Search and Data Users j Related attribute public key set {PK k,j}, the common subset P of computed attributes j,A ={ρ(i):i∈l}∩{PK k,j}, where l is a set of row numbers in the access control matrix A. For set P j,A Regarding these properties, ESC will further check whether there exists a subset Ic such that Ic is a linear combination of vectors (1,0,…,0). If it exists, ESC selects a set of constants {c}. i ∈Z N}, where i represents the i-th row of the access control matrix, such that ∑ i c i A i = (1,0,…,0), ESC calculates the converted ciphertext CT. c :

[0146]

[0147] Where ω i =A i ·ω,λ i =A i ·v,v·(1,0,…,0)=s,ω·(1,0,…,0)=0. The cloud server ESC transmits CT via a secure channel. c Send to DU j ;

[0148] S605, Data User DU j Obtain the converted ciphertext CT c Then, using his private key sk j Decoding CT c Restore session key κ:

[0149]

[0150] S606, Data User DU j Decrypting the ciphertext DCT using the session key κ x , obtain shared data M x M x =Dec(κ,DCT) x ).

[0151] Step S70 includes the following steps:

[0152] S701, Assuming the data requester The attribute μ was determined by the authoritative organization AM k Cancel, AM k Call the strategy matching function to filter out those affected by cancellation. the session key ciphertext set {KCT x} that needs to be updated by the revoked attribute μ k retrieve the sharing list L data filter out the DP and DU related to {KCT x} that needs to be updated by the revoked attribute μ k notify the users in the retrieval result to update their ciphertexts or keys;

[0153] S702, the authority AM k reselect a random value v k,μ '∈Z N the new version private key VK k,μ = v k,μ ' of the revoked attribute μ In order to ensure the security of attribute revocation, the DP needs to use the ciphertext update key CUK μ to update the ciphertext related to the revoked attribute μ, and the unrevoked user who has the revoked attribute μ needs to use the key update key KUK j,μ to update the key related to μ. The AM k uses its private key SK k , the new version key VK k,μ ', the old version key VK k,μ , and the attribute public key set of the unrevoked user to calculate and

[0154] S703, the authority AM k records the process of attribute revocation in the revocation list L R-Att , and then records the list and the key update key KUK j,μ on the blockchain, and then the AM k sends CUK μ to the data provider DP that needs to update the ciphertext through a secure channel;

[0155] S704, the DP obtains the ciphertext update key CUK μ through a secure channel, and updates the session key ciphertext KCT x related to the revoked attribute μ. The DP reselects the session key κ', and calculates the updated data ciphertext DCT ud = AES.enc(κ', M) using the AES symmetric encryption algorithm. This process can be performed in advance when the attribute is revoked;

[0156] S705, the update of part of the ciphertext component CT μ = {C0, C 3,i} can greatly improve the efficiency of attribute revocation. The DP calculates the update KCT x ​C0in the ciphertext C

[0157]

[0158] The calculation of C0can also be done locally in advance, so the main calculation overhead of attribute revocation is to update the ciphertext C 3,i associated with the revoked attribute μ μ The DP updates the ciphertext C x in KCT 3,i :

[0159]

[0160] The updated session key ciphertext KCT ud is obtained:

[0161]

[0162]

[0163]

[0164]

[0165]

[0166] The DP uploads the updated ciphertext KCT ud to the cloud server. Through the ciphertext update key provided by the AM k , the proposed scheme can guarantee the forward security of the access control system, that is, if a newly added user has attributes that satisfy the access control policy, he can decrypt the session key ciphertext. The revoked user cannot decrypt the session key ciphertext KCT ud using the old version of the attribute private key set {ask k,j,i |k∈SA,i∈S k}, because when the cloud server ESC performs outsourcing decryption, it will select a set of constants {c i ∈Z N} to calculate When the vector (1,0,…,0) cannot be obtained, the decryption stops. Therefore, the updated session key κ' cannot be obtained by decrypting the conversion ciphertext, and the data ciphertext cannot be decrypted;

[0167] S706、When the key ciphertext is updated, the unrevoked users who satisfy the ciphertext access control policy need to update their attribute private keys. The authority AM finds the users who need to update the attribute private keys in the list L DU -Attand records them into the list {list DU}, and the AM notifies {listDU Each user updates the attribute private key in. Each unrevoked user DU j where DU j does not contain users whose attributes need to be revoked, gets the corresponding key update key KUK j,μ from the smart contract, and DU j uses KUK j,μ to update its attribute private key ask k,j,i in K j,μ :

[0168]

[0169] where K j ' ,μ denotes the updated attribute private key component. v k,μ denotes the version private key of authority k that owns attribute μ.

[0170] Get the updated attribute private key ask' k,j,μ :

[0171]

[0172]

[0173] Since the wallet address u j of DU j is unique, these KUK j,μ are different for all unrevoked users, so revoked users cannot use the KUK j,μ of other unrevoked users to update their own keys, ensuring the backward security of data sharing;

[0174] S707, after the unrevoked user updates its attribute private key, it obtains the updated key ciphertext KCT ud and data ciphertext DCT ud from the cloud server ESC. Repeat the steps of S602, S603, S604, S605, and S606. The unrevoked user first obtains the decryption factor df j ', then sends the updated key set {ask' k,j,i |k∈SA,i∈S k} and its public key pk j to the ESC. The ESC selects a set of constants {c i ∈Z N} such that ∑ i c i A i = (1, 0, …, 0), and then computes KCTud Decryption of the conversion ciphertext CT' c Then the non-revoked user uses his own private key sk j to recover the session key κ', and finally uses κ' to decrypt DCT ud to obtain the shared IoT data M x .

[0175] In this embodiment, the functions, computational overhead, storage overhead, etc. of the scheme are compared with related schemes. The functions of the comparative schemes mainly consider the use of groups, the security of attribute revocation, etc.; the computational overhead comparison mainly considers the key generation time, data encryption time, data decryption time and attribute revocation time; the storage overhead comparison mainly considers the storage overhead of users, the storage overhead of blockchains and the storage overhead of cloud servers. Among them, AM represents the authority, ESC represents the cloud server, DU represents the user, G q is a group of order prime q, the bit length of q is 160 bits, E q is a power multiplication operation on the group G q , m q is a multiplication operation on the group G q , p q is a bilinear pair operation on the group G q . It is assumed that G i is a group of order prime p i , i = 1, 2, 3, the bit length of p i is 517 bits, E i is a power multiplication operation on the group G i , m i is a multiplication operation on the group G i , p i is a bilinear pair operation on the group G i , R represents the number of revoked attributes. NN A represents the number of all AMs in the cloud storage system, |q| represents the size of the group G q , |p| represents the size of the group G1, n uid,i represents the number of attributes of the DU uid , n aid,i represents the number of attributes managed by the AM aid , TX represents the transaction size, and AMM represents the data storage module in the trusted cloud server.

[0176] Table 1 Comparison of functions of schemes

[0177]

[0178] Table 1 gives the comparison of the attribute revocation security of the present embodiment and other schemes. Scheme 1 is constructed based on a composite order group, which meets adaptive security, but the scheme cannot revoke the attributes of the user. Scheme 2 is constructed based on a prime order group, which only meets selective security, scheme 2 realizes the attribute revocation function by using the block chain, but only realizes the access control of data through the access control list, and does not update the key and the ciphertext, which does not meet the backward security of the user attribute revocation. Scheme 3 does not meet the backward security, and uses the cloud server to update the ciphertext, which cannot resist collusion attacks. In scheme 4, there is a fully trusted entity AMM, but it is difficult to find a fully trusted entity in a distributed Internet of Things scene. However, schemes 2, 3 and 4 only meet the weak selective security model, that is, the attribute set of the revoked user is selected before the system is initialized, and in the actual IoT scene, the attacker can adaptively select the attribute set of the revoked user, so schemes 2, 3 and 4 cannot meet the security requirements of the actual IoT application scene. The present embodiment can meet the security requirements of adaptive user attribute revocation, and does not require any trust center, records the user attribute revocation process to the distributed ledger of the block chain, updates the version key component in the ciphertext and the key through the combination of on-chain and off-chain, and realizes the forward and backward security of the user attribute revocation.

[0179] Table 2 comparison of computational overhead

[0180]

[0181] Table 2 shows some improvements of the present embodiment: (1) Data decryption is very important for IoT devices with limited computing power. The present embodiment only needs one power multiplication operation and one multiplication operation, outsources the double linear pair complex operation in the decryption process to the cloud server, and the user only needs to perform a small amount of simple calculation to obtain the original data of the IoT. Therefore, the data decryption algorithm of the present embodiment is faster than that of schemes 1 and 2; (2) The main computational overhead of attribute revocation is ciphertext update and key update. The ciphertext update of the present embodiment is the fastest among all schemes, and when the data provider updates the session key ciphertext, only R multiplication operations are performed on the p1 order subgroup G1, and the more the number of revoked attributes is, the more obvious the advantage of the present embodiment is. In the key update stage, the computational overhead of the present embodiment is slightly higher than that of schemes 3 and 4, but the difference is within an acceptable range. (3) Compared with schemes 1 and 2, the present embodiment can guarantee the forward and backward security of data sharing; compared with schemes 2, 3 and 4, the present embodiment has a higher security level, allows the system to adaptively revoke the attributes of the user, meets the forward and backward security of adaptive user attribute revocation, and is more suitable for fine-grained secure data sharing in an untrusted Internet of Things scene.

[0182] Table 3 comparison of storage overhead

[0183]

[0184] Table 3 shows the storage overhead of users (DUs), blockchain and the storage module (AMM) in the cloud server. The key design in Scheme 3 is complex, and the user terminal stores attribute private and public key pairs, increasing the storage pressure of the IoT terminal device. When the user attribute update frequency is high, the user frequently obtains the key update key KUK from the authority, and the communication overhead of the two is huge. If the interaction volume increases sharply in a short time, the system will be blocked or even down. In addition, the security of the data transmission process cannot be guaranteed, and the data is stolen and tampered with maliciously and cannot be traced back, and the security of data sharing is seriously threatened. In order to solve this problem, Scheme 4 introduces a trusted entity AMM, which records all attribute public keys managed by the authority (AM), and the interaction data between entities is received and broadcasted through the AMM. Although the interaction information between entities is stored by the AMM, it can reduce the storage overhead of the user, but it increases the storage overhead of the system. When the user attribute is revoked, the key update key KUK and the updated attribute public key PK' uid,i are recorded in the AMM, and the AMM records KUK and PK' uid,iCompared with scheme 3, the system communication overhead of the process is doubled for sending to the non-revoked user. In addition, in the untrusted Internet of Things (IoT) scene, most entities are semi-trusted, and the assumption of scheme 4 is too strong, and the trusted centralized server almost does not exist in the IoT scene, and when the AMM is problematic, the security of the system cannot be guaranteed. The application uses blockchain technology to replace the trusted centralized server of the AMM, without any trusted entity, and maps the trust of the system on the authority to a distributed ledger, records the mapping relationship between the data applicant and the attribute, and uses a smart contract to assist the authority to realize the revocation of the user attribute, and records the process of revoking the user attribute on the chain. Although the blockchain increases the additional storage overhead, it can reduce the storage overhead of the user at the system level, guarantee the security of data sharing, and play an important role in the untrusted IoT scene. When the user applies for the attribute private key, the attribute public key and the attribute private key ciphertext are recorded on the chain, reducing the storage overhead of the user's IoT terminal device, and solving the problem of absolute trust of the user to the authority. When the data provider executes the encryption algorithm, the attribute public key is obtained through the smart contract without local storage, reducing the storage overhead of the data provider, and the process of obtaining the attribute public key is traceable and tamper-proof, guaranteeing the integrity and verifiability of the shared data. When the user attribute is revoked, the authority records KUK on the chain, the non-revoked user calls the revocation contract to obtain KUK, and updates the attribute private key off-chain, and the updated attribute private key can correctly decrypt the updated ciphertext, while the revoked attribute user cannot update the attribute private key, and cannot decrypt the updated ciphertext using the old version of the private key, guaranteeing the forward and backward security of the shared data. In summary, compared with scheme 3, we realize the revocation of the user attribute and improve the security of data sharing; compared with scheme 4, we do not rely on any trusted entity, have a higher security level, meet the forward and backward security of adaptive user attribute revocation, and are more suitable for secure sharing of data in the untrusted IoT scene.

[0185] The above description is only the preferred embodiment of the application, and is not intended to limit the application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principles of the application shall be included in the protection scope of the application.

Claims

1. A blockchain-based revocable distributed attribute-based encryption method, characterized in that, Includes the following steps: S10. System establishment: The platform regulator PS constructs the blockchain, generates public parameter CP, obtains the corresponding wallet address and public-private key pair (sk0, pk0), and records CP and public key pk0 on the genesis block of the blockchain. S20. Initialization of authoritative institutions: The platform regulator PS assigns a set of attributes to be managed by each legitimate authoritative institution AM. AM randomly selects two numbers as its own private key and the version private key of the attribute it manages, respectively. Then, it reads the public parameter CP and PS's public key pk0 from the blockchain, calculates the attribute public key of the managed attribute and its own authorized public key, and records the attribute public key set, attribute hash value and authorized public key into the blockchain. S30. User registration: Users apply for registration with the platform regulator PS. PS calculates the public and private key pairs and verifies the certificates for legitimate users, and records the user's public key as a transaction record on the blockchain. S40. User attribute private key generation: Data user DU applies for an attribute private key from the authoritative institution AM. AM verifies DU's identity and calculates the attribute private key ask for the legitimate DU. k,j,i AM uses DU's public key and RSA encryption algorithm to encrypt the set of attribute private keys and uploads the list of attribute private key ciphertexts to the blockchain. DU retrieves the attribute private key ciphertexts from the blockchain according to the transaction record index and then obtains the attribute private key by decrypting the ciphertexts. S50. Data Encryption: The data provider DP randomly selects a session key κ and uses the AES symmetric encryption algorithm to encrypt the IoT data M to be shared, obtaining the ciphertext DCT. Then, an appropriate access control policy is formulated based on the applicable scope of M. DP reads the public key set related to the access control policy from the blockchain, encrypts the session key κ, calculates the key ciphertext KCT, and then uploads KCT to the cloud server. S60. Data Access: Data user DU calls the policy matching function to obtain the ciphertext key KCT from the cloud server. The ciphertext can only be decrypted if the attributes of DU satisfy the access control policy of the ciphertext. First, DU uses the ciphertext component in KCT to calculate the decryption factor df. j Then the cloud server uses df j DU uses its public key and attribute private key set to calculate the converted ciphertext CTc; finally, DU uses its own private key to decrypt CTc, recover the session key κ, and uses κ to decrypt the data ciphertext DCT to obtain the shared data M. S70. User Attribute Revocation: When the authoritative organization AM revokes one or more attributes of a data user DU, the AM invokes a policy matching algorithm to filter out the ciphertext set {KCT} of the session key that needs to be updated. x The relevant data provider DP and data user DU, AM runs an algorithm to calculate and obtain a new attribute public key, ciphertext update key CUK and key update key KUK. AM sends CUK to the DP that needs to update the ciphertext through a secure channel and records KUK in the blockchain. DP uses CUK to update the corresponding key ciphertext. Users cannot revoke the use of KUK to update their own attribute private key. The blockchain-based revocable distributed attribute-based encryption method includes: system administrator, data owner, data applicant, authoritative institution, blockchain, and cloud server.

2. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S10 includes the following steps: S101, Platform Regulator PS Builds Blockchain Choose a unique identity ID for it PS Generate a public-private key pair {sk0,pk0}; S102. The platform regulator PS inputs the security parameter λ, selects a bilinear group G of order N = p1p2p3, where p1, p2, and p3 are three distinct large prime numbers, and selects a hash function H:{0,1}*→G, which maps attributes to elements in group G. S103. Let G1 denote a subgroup of order p1 in group G. Randomly select a generator g∈G1, and the platform supervisor PS obtains the common parameter CP={N,g∈G1,H(·)}. S104. The platform regulator PS secretly stores its private key sk0 and records the public key pk0 and public parameter CP in the genesis block of the blockchain, so that users and authoritative institutions can obtain CP and pk0 from the blockchain.

3. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S20 includes the following steps: S201. The platform regulator (PS) assigns a set of attributes to each authoritative agency (AM) for jurisdiction, and requires that there be no overlap between the attributes managed by each AM. S202, Assume the kth authoritative institution AM k The set of attributes under jurisdiction is S k The platform regulator PS is a legitimate AM. k Choose the wallet address AID as its identity identifier and grant AM k Corresponding attribute set management permissions; S203, Authoritative Organization AM k Read the public parameters CP and the platform regulator's public key pk0, AM from the genesis block. k Select random number β k ∈Z N As AM k The private key, for any attribute i∈S k Then select another random number v k,i VK as the version private key for attribute i k,i =v k,i AM k Using β k and v k,i Calculate the public key of the i-th attribute. S204, Regarding authoritative institutions AM k For all managed attributes, obtain the version private key for each attribute using the method in step S203, resulting in an attribute version private key set {VK}. k,i =v k,i ,v k,i ∈Z N } and attribute public key set S205, Authoritative Organization AM k Using its private key β k ,calculate Use it as your own authorized public key; S206, Authoritative Organization AM k Its private key β needs to be kept secret. k and version private key VK k,i AM k For each attribute i, a set of attribute public keys {PK} k,i |i∈S k A set of hash values ​​{H(i)|i∈S} k } PK with authorized public key k Recorded in the list of authoritative institutions L AM-att In this process, the list will be recorded in the blockchain.

4. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S30 includes the following steps: S301. When joining the system, data providers (DP) and data users (DU) need to first apply for registration with the platform regulator (PS) and submit their identity description information (Info). DU After the PS verification is successful, a wallet address UID will be selected for the legitimate user as their identity identifier; S302. Based on the user's wallet address uid, PS selects two random numbers u. uid , z uid ∈Z N Calculate the user's public key and private key sk uid =z uid ; S303, the platform regulator PS, uses its private key sk0 to calculate digital signatures for users in order to facilitate verification of user identities by authoritative institutions. Generate the user's digital certificate Cert(uid); S304, Platform Regulator PS transmits public-private key pairs (pk) via a secret channel. uid ,sk uid The user's PK is sent along with a digital certificate (Cert(uid)). uid Recorded on the blockchain.

5. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S40 includes the following steps: S401, Assume that the data user DU has wallet address j. j To the k-th authoritative institution AM k Request a private key for the attribute, U k It is AM k The set of users within the domain, SA is the set of authoritative institutions, j∈U k ,k∈SA,AM k The set of attributes to be managed is S k DU j The attribute i∈S of the application k DU j In order to obtain the attribute private key, in AM k When submitting the application, send your digital certificate Cert(uid) to AM. k AM k Read the public key of the platform regulator PS from the blockchain to verify PK0 DU. j His identity, and obtained the connection with DU j Related components S402, Authoritative Organization AM k For legitimate data users DU j Generate attribute private keys for DU j Any attribute i∈S k AM k Read the public parameter CP from the blockchain and use its private key SK. k Attribute public key set {PK k,i |i∈S k }, Attribute set S k Calculate and obtain the private key of the i-th attribute. S403, Authoritative Organization AM k Using the RSA encryption algorithm Enc(pk) j ,{ask k,j,i }) Calculate the ciphertext {cask} of the user attribute private key set. k,j,i |k∈SA,j∈U k ,i∈S k }; S404, Authoritative Organization AM k Record the user's public key, attribute set, and attribute private key ciphertext into the user attribute list L. DU-Att The list is then recorded on the blockchain as a transaction, along with its index TX. k,j Data user DU j According to TX k,j Retrieve the attribute private key ciphertext from the blockchain and use your own private key sk j Decrypt the ciphertext to obtain the corresponding attribute private key, and then use the same method to DU j Obtain all attribute private keys from other authoritative institutions to obtain the attribute private key set {ask}. k′,j′,i′ |k′∈SA,j′∈U k′ ,i′∈S k′ } 6. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S50 includes the following steps: S501, Data provider DP selects session key κ, uses AES symmetric encryption algorithm AES.enc(κ,M) to encrypt shared IoT data M, and calculates the data ciphertext DCT=AES.enc(κ,M); S502. The data provider DP formulates a corresponding access control policy A(A,ρ) for the shared IoT data M based on its own attributes and the objects to which it wishes to share the data, where A is an n×l matrix and the function ρ is a mapping from the set {1,2,…,n} to the attribute set. S503, Data Provider DP reads the public parameter CP from the genesis block and reads the attribute public key set {PK} associated with the access control policy from the blockchain. k,i |i∈S k } and authorized public key set {PK k } k∈SA DP utilizes CP, A(A,ρ), {PK k,i |i∈S k }, {PK k } k∈SA Encrypt the session key κ and generate the session key ciphertext KCT; The specific process is as follows: DP selects l random numbers s, v2, v3, ..., v l ∈Z N * Construct vectors v = <s, v2, v3, ..., v l >, calculate λ i =A i ·v, where A i It is the i-th row of matrix A; select l-1 random numbers ω2, ω3, ..., ω l ∈Z N * This forms a vector ω = <0, ω2, ω3, ..., ω l >, calculate ω i =A i ·ω, for each row A of the access control matrix A i DP randomly selects r i ∈Z N * The KCT is calculated as follows: ρ(i)∈S k ,k∈SA} in This represents the access control policy, C0 represents the result of encrypting the session key, κ represents the session key, and β represents the access control policy. k The private key of the k-th authority, k∈SA, where k represents the k-th authority in the set of authorities SA, e(g,g) denotes the bilinear pairing operation, and C 1,i C 2,i C 3,i This represents a ciphertext component containing access control policies, where ρ(i) represents the attribute corresponding to the i-th row of the access control matrix, and v k,ρ(i) Represents the version private key of the k-th authoritative authority attribute ρ(i); S504, Data Provider DP will share the encrypted data (DCT) of data M, and access control policies. The session key ciphertext KCT is uploaded to the cloud server, and the cloud server records the address URL where the ciphertext is stored and the description information of the shared data M on the blockchain.

7. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S60 includes the following steps: S601, Data user DU with wallet address j j By retrieving descriptive information of shared data in the blockchain using keywords, and finding the required information, a policy matching function is invoked. Only when the data provider's attributes meet the access control policy set by the data provider (DP) will the smart contract in the blockchain release the shared data M. x Data Encryption DCT x and session key ciphertext KCT x Send the storage address URL to DU j DU j The encrypted data stored in the cloud server by the URL is obtained. j The process of acquiring data will be recorded in the shared list L. data middle; S602, due to data user DU j With limited computing power, some complex calculations in the decryption process need to be outsourced to cloud servers. First, DU j Using session key ciphertext KCT x The ciphertext component C in 1,i and your private key sk j Calculate the decryption factor df j : Where z j This indicates that the data user DU has wallet address j. j The private key, i.e., z j =sk j ; S603, Data User DU j Decryption factor df is transmitted via a secure channel. j PK with your own public key j and attribute private key set {ask k,j,i |k∈SA,i∈S k Send to the cloud server ESC; S604, Cloud Server ESC in User Attribute List L DU-Att DU Search and Data Users j Related attribute public key set {PK k,j }, the common subset P of computed attributes j,A ={ρ(i):i∈l}∩{PK k,j }, where l is a set of row numbers in the access control matrix A, for set P j,A For these properties, ESC will further check whether there exists a subset Ic such that Ic is a linear combination of vectors (1,0,…,0). If it exists, ESC will select a set of constants {c}. i ∈Z N }, where i represents the i-th row of the access control matrix, such that ∑ i c i A i = (1,0,…,0), ESC calculates the converted ciphertext CT. c : Where ω i =A i ·ω,λ i =A i ·v,v·(1,0,…,0)=s,ω·(1,0,…,0)=0; The cloud server ESC transmits CT through a secure channel. c Send to DU j ; S605, Data User DU j Obtain the converted ciphertext CT c Then, using his private key sk j Decoding CT c Restore session key κ: S606, Data User DU j Decrypting the ciphertext DCT using the session key κ x , obtain shared data M x M x =Dec(κ,DCT) x ).

8. The blockchain-based revocable distributed attribute-based encryption method according to claim 1, characterized in that, Step S70 includes the following steps: S701, Assuming the data requester The attribute μ was determined by the authoritative organization AM k Cancel, AM k Call the strategy matching function to filter out those caused by cancellation. The session key ciphertext set {KCT} that needs to be updated for the μ attribute x }, AM k Search shared list L data Filter out those matching {KCT} x The relevant DP and DU, AM k Notify users in the search results to update their ciphertext or key; S702, Authoritative Organization AM k Choose a random value v again k,μ ′∈Z N The new version of the private key VK as the revocation attribute μ k,μ =v k,μ ′, update the public key of attribute μ To ensure the security of attribute revocation, DP needs to use the encrypted update key CUK. μ To update and revoke the ciphertext associated with the revoke attribute μ, users who have not revoked the revoke attribute μ need to use the key update key KUK. j,μ Update the key associated with μ, AM k Using its private key SK k New version key VK k,μ ′、Old version key VK k,μ and the set of public keys for attributes of users who have not been revoked Calculation obtained and S703, authoritative organization AM k Record the attribute cancellation process in the cancellation list L. R-Att Then update the list and key KUK. j,μ Recorded on the blockchain, then AM k CUK via secure channel μ Send to the data provider (DP) that needs the encrypted data updated; S704 and DP obtain the ciphertext update key CUK through a secure channel. μ Update and revoke the session key ciphertext KCT associated with attribute μ. x DP reselects the session key κ′ and uses the AES symmetric encryption algorithm to calculate the updated ciphertext DCT. ud =AES.enc(κ′,M), this process can be performed in advance when the attribute is revoked; S705, partial encrypted component CT μ ={C0,C 3,i The update of} improves the efficiency of attribute revocation, and DP uses κ′ to calculate and update KCT. x C0 in: The computation of C0 is performed locally beforehand, so the computational cost of attribute revocation is updating the ciphertext C associated with the revoked attribute μ. 3,i DP uses the encrypted update key CUK μ For KCT x C in 3,i Update: Obtain the updated session key ciphertext KCT ud : DP will update the ciphertext KCT ud Uploaded to the cloud server, via AM k The provided ciphertext update key and the proposed scheme guarantee forward security of the access control system. Specifically, newly added users with attributes that satisfy the access control policy can decrypt the session key ciphertext, while users whose accounts are revoked can decrypt it. Using the old version's attribute private key set {ask k,j,i |k∈SA,i∈S k Unable to decrypt session key ciphertext KCT ud Because when the cloud server ESC performs outsourced decryption, it selects a set of constants {c i ∈Z N }calculate Decryption stops when the vector (1,0,…,0) is not obtained, so it is impossible to decrypt the converted ciphertext to obtain the updated session key κ′, and therefore impossible to decrypt the data ciphertext. S706. When the ciphertext is updated, unrevoked users who meet the ciphertext access control policy need to update their attribute private keys. The authoritative organization AM will update the list L. DU-Att Find the users who need to update their private keys and record them in a list {list DU }, AM notification {list DU In the}, each user updates the attribute private key, and each non-revoked user DU with the revocation attribute μ... j DU j Users who do not require attribute revocation can obtain the corresponding key update key KUK through a smart contract. j,μ DU j Using KUK j,μ Update its attribute private key ask k,j,i K in j,μ : Where K′ j,μ This indicates the updated private key component, v k,μ This represents the version private key of attribute μ owned by the k-th authority; Get the updated attribute private key ask' k,j,μ : Due to DU j wallet address u j They are unique, therefore these KUK j,μ This is different for all users who have not revoked their accounts, so for users who have revoked their accounts... Unable to use other users' KUK accounts that have not been revoked j,μ Updating your own key ensures backward security for data sharing; S707. After the user updates their attribute private key without revocation, the updated key ciphertext KCT is retrieved from the cloud server ESC. ud and data encryption DCT ud Repeat steps S602, S603, S604, S605, and S606. For users who have not yet withdrawn their accounts, the decryption factor df′ is first calculated. j Then the updated key set {ask′ k,j,i |k∈SA,i∈S k } and your own public key PK j Send to ESC, ESC selects a set of constants {c i ∈Z N }, making ∑ i c i A i = (1,0,…,0), then for KCT ud Decryption yields the converted ciphertext CT′ c Then, without revoking the user's use of their private key sk j Recover the session key κ′, and finally use κ′ to decrypt the DCT. ud Get shared IoT data M x .

Images