A secure and scalable IoT access control framework with dynamic attribute updates and policy hiding (2025)

With the rapid development of IoT technology, the amount of data generated by IoT devices is exploding, often containing a large amount of sensitive information, such as personal privacy, trade secrets, etc. Therefore, how to achieve effective data sharing without disclosing sensitive information has become a hot research topic.

Blockchain technology, with its decentralized, tamper proof, and traceable characteristics, provides new ideas for solving security issues in data sharing. Blockchain technology ensures that once data is recorded, it cannot be changed, thus protecting the integrity and authenticity of data. In addition, blockchain technology also supports smart contracts, which can automatically execute contract terms, further improving the efficiency and security of data sharing¹.

The application of blockchain technology in the Internet of Things environment also faces some challenges. Firstly, IoT devices often have limited resources, and how to reduce the impact on device performance while ensuring security is an important research direction². Secondly, data sharing in the Internet of Things environment often requires cross organizational or institutional collaboration, and achieving secure data exchange between different blockchains is also an urgent issue that needs to be addressed. In addition, there are numerous IoT devices, and how to effectively manage and verify the identity of the devices is also the key to ensuring data security³.

Researchers have proposed various solutions to address the aforementioned challenges. For example, by designing a lightweight blockchain structure model and efficient consensus algorithms, the performance of blockchain can be improved to meet the needs of the Internet of Things environment. Meanwhile, by adopting cross chain technology, secure data exchange between different blockchains has been achieved. In addition, research has also been conducted to protect the confidentiality and integrity of data by introducing proxy re-encryption technology and digital summarization technology.

Some work has studied blockchain performance, identity authentication, and data security sharing in the Internet of Things, but it is necessary to pay special attention to the secure sharing of sensitive data. Therefore, our research focuses on the protection of data privacy in the Blockchain Internet of Things. Conduct research on issues such as frequent changes in device and user attributes, public access policies, and one-way access control in the Internet of Things.

Motivations

With the development of big data and Internet of Things technology, data sharing has become increasingly common. However, traditional access control mechanisms often rely on centralized authorization agencies, which not only increases the risk of single point of failure, but may also lead to data leakage and privacy violations. In a dynamically changing data environment, especially in big data and IoT scenarios, there is a need for an access control method that can flexibly respond to changes in access requirements and update access permissions in real-time. Although traditional access control models such as Role Based Access Control (RBAC) and Attribute Based Access Control (ABAC) provide a certain degree of flexibility, they are still insufficient when dealing with complex and dynamic access control policies⁴.

The openness and interconnectivity of IoT systems have brought unprecedented security challenges, especially in terms of access control and privacy protection. Traditional access control mechanisms often suffer from security vulnerabilities and opacity, especially when conducting access control operations in untrusted environments, which can lead to data leakage. In addition, in practical applications, access control policies may need to be updated frequently for various reasons. However, traditional methods often find it difficult to efficiently handle this requirement, especially when involving a large number of users and resources.

The application of blockchain technology, especially in combination with smart contracts, can realize more flexible and fine-grained access control policies. The use of blockchain enables dynamic updating and automatic enforcement of access control policies, improving system response speed and flexibility. Compared with traditional methods, blockchain technology effectively improves the security and transparency of access control through distributed ledger, encrypted storage and consensus mechanism⁵. Traditional IoT systems rely on centralized servers for data management and processing, which not only increases the risk of a single point of failure, but also limits the scalability of the system. Blockchain’s decentralized architecture improves the fault tolerance and scalability of the system. Blockchain provides an open and transparent data recording platform where all transactions are traceable, which helps monitor and audit the behavior of IoT devices and enhances the security of the system.

In addition, in certain application scenarios, it is not only necessary to apply access control to data users, but also to impose certain restrictions on data providers to ensure data security and compliance. Traditional access control mechanisms often only support one-way access control, while the application of blockchain technology can achieve two-way access control, better meeting complex application requirements⁶.

IoT devices are vulnerable to attacks and require a security mechanism to resist various network threats, ensuring the security of devices and data⁷. Public access control policies may become a guide for attackers, so the development of policy hiding technology is crucial for protecting system security.

Therefore, we are committed to developing a bidirectional attribute access control method based on blockchain dynamic updates and policy hiding. This method utilizes the immutability of blockchain and the automation capability of smart contracts to achieve a secure and flexible access control mechanism. By hiding policies and updating dynamic attributes, this method aims to improve the security and privacy protection capabilities of IoT systems, while meeting the dynamically changing access control requirements. It solves the problems of insufficient privacy protection, low security and transparency, difficulty in updating access control policies, and lack of bidirectional access control in traditional access control mechanisms.

Related works

Sahai and Waters⁸ first proposed an identity based Attribute-based Encryption (ABE) scheme, which is characterized by the ability to control access to encrypted data based on user attributes. Since then, ABE has attracted widespread attention from the academic community. Goyal et al.⁹ first divided ABE into Key Policy Attribute Base Encryption (KP-ABE) and Cipher Policy Attribute Base Encryption (CP-ABE). Among them, Cipher Policy Attribute Based Encryption (CP-ABE) allows encryptors to formulate access policies, and only users whose attributes meet the policy can decrypt ciphertext. In Key Policy Attribute Based Encryption (KP-ABE), data can only be viewed when the access structure of the identity key satisfies the attribute.

In order to protect the secure sharing of data in the Blockchain Internet of Things and achieve fine-grained access control, a flexible access control mechanism called Attribute based Access Control is adopted. This mechanism determines access permissions to resources based on dynamically changing attribute information of users or systems, making it particularly suitable for the distributed and rapidly changing environment of BIoT. Numerous researchers have made significant contributions in the research of attribute access control. In 2013, Liu et al.¹⁰ proposed a traceable CP-ABE scheme based on Boneh and Boyen’s short signatures¹¹ for malicious user tracking of decryption keys. This scheme not only supports arbitrary monotonic access structures and has strong expressive power, but also achieves adaptive security under the standard model.

In order to achieve more secure and decentralized access control, researchers have applied blockchain technology to access control and conducted extensive research, dividing it into two categories. A new type of access control mechanism is designed through blockchain architecture, including consensus mechanisms and smart contracts. FAN et al.¹² combined functional encryption with blockchain to propose a reliable and privacy aware access control system, R-PAC. The system allows access to the result form without learning the original information and enables fair interaction with malicious users. R-PAC combines all or nothing encapsulation technology to support dynamic connections and key leakage resistance for users. In addition, Román-Martínez et al.¹³ proposed a service-oriented architecture supported by blockchain technology, which can achieve tamper proof and immutable consent storage for nursing subjects, fine-grained access control to protect health data based on consent, and audit tasks for regulatory agencies or nursing subjects themselves. Another type is to introduce existing access control mechanisms into blockchain to provide permission management services, including role-based access control (RBAC) and attribute-based access control (ABAC). Lu et al.¹⁴ proposed an IoT data access control scheme that combines attribute encryption (ABE) and blockchain technology. This scheme adopts symmetric encryption and ABE algorithm to achieve fine-grained access control, ensuring the security and openness of IoT data. In addition, the combination of blockchain technology and distributed storage has solved the storage bottleneck of blockchain systems. Only the hash value of data, the hash value of ciphertext location, access control policies, and other important information are stored on the blockchain. Afterwards, Wu et al.¹⁵ proposed an attribute based access control scheme that utilizes an additive homomorphic cryptosystem to encrypt attributes and access policies. At the same time, the scheme uses multiple blockchain nodes to collectively decrypt the data and employs zero knowledge proof technology to ensure the correctness of the decryption results.

In order to ensure the timeliness, flexibility, and security of access control in the BIoT environment, researchers have introduced attribute updates and policy hiding related technologies into access control and proposed various solutions. For example, Ying et al.¹⁶ design a security-enhanced Attribute Cuckoo Filter (se-ACF) to hide the access policy and propose a new CP-ABE system, called Privacy-Preserving Policy Updating ABE (3PU-ABE), which effectively integrates policy hiding and policy updating. Gao et al.¹⁷ propose a new trustworthy secure ciphertext-policy and attribute hiding access control scheme based on blockchain, named TrustAccess, to achieve trustworthy access while guaranteeing the privacy of policy and attribute. Zhang et al.¹⁸ propose an efficient policy hiding and policy updating attribute-based data sharing scheme. The proposals support user revocation, which solves the collusion between the revoked users and unrevoked users or the cloud. Strategy confusion is a very popular solution in recent years. In 2017, Yang et al.¹⁹ implemented policy hiding using Bloom filters. However, in 2021, Zhang et al.²⁰ proposed an improvement to Yang et al.’s research by using fuzzy Bloom filters to resist dictionary attacks. In Ref In the studies of Hur²¹, Fan et al²², and Zhong et al²³, data owners also confused attributes in access policies, but users had to use pairing operations to resolve the confusion, which was computationally expensive.

Recently, some other types of ABE schemes have been proposed to achieve different functional objectives. For example, Han et al.²⁴ proposed a dual strategy attribute encryption scheme for distributed outsourcing. This scheme combines the existing CP-ABE and KP-ABE schemes and proposes two access structures and attribute set structures. Yan et al.²⁵ proposed an efficient and reliable anti leakage scheme based on attribute encryption, which achieves timely key updates and decryption capabilities for revoking leaked keys. Cheng et al.²⁶ proposed a blockchain-based decentralized access control scheme (BLUMA-CPABE) that uses multi-authority ciphertext policy attribute-based encryption (MA-CP-ABE). The scheme utilizes both on-chain and off-chain mechanisms to reduce the computational burden of the blockchain, and a verifiable key distribution method ensures the security and reliability of the keys. Hou et al.²⁷ proposed a new blockchain based verifiable outsourcing attribute encryption system, which solves the problem of data users being unable to verify the correctness of plaintext in outsourcing decryption ABE schemes with payment.

Our contributions

At present, most blockchain based access control methods are one-way, and user access policies are public, which cannot simultaneously meet the needs of dynamic attribute updates, two-way verification of users and data, and secure data transmission. Therefore, it is necessary to design a new ABE scheme to solve the above problems. Therefore, this article proposes a bidirectional attribute access control method in the blockchain Internet of Things that integrates dynamic attribute updates and user policy hiding, which is used to manage massive data in the Internet of Things environment and enable users to efficiently and securely access private data in the network. Our contributions are summarized as follows.

1. (1)

   Dynamically update attributes. Attribute updates enable users to dynamically update their access permissions to private data.

2. (2)

   Access control policy hiding. Encrypt the plaintext data and user policies on the user side before uploading, which fully guarantees the security of user attribute privacy. The scheme utilizes the transparency of blockchain to address the privacy leakage of access policies. In addition to this, in blockchain-based CP-ABE, we use the multiplicative homomorphic ElGamal cryptosystem to provide complete attribute privacy protection while acquiring keys.

3. (3)

   Bidirectional attribute access control. The bidirectional permission verification enhances the security of privacy data access.

4. (4)

   Blockchain network. Using a blockchain network with distributed characteristics to replace centralized servers in the Internet of Things for user authorization, key management, and attribute updates.

In addition, we have demonstrated that the proposed DUPH-BAAC scheme can resist indistinguishable selective access structures and selective plaintext attacks, and has IND-sAS-CPA security. In addition, performance analysis was conducted on this scheme in terms of functionality, computational overhead, and time efficiency.

In this section, we will introduce some preliminary content, including blockchain technology, bilinear mapping, and monotonic access structures, as shown below.

Blockchain technology

Blockchain technology is a decentralized distributed ledger technology that uses cryptographic methods to ensure the security and integrity of data. Blockchain is composed of data records called blocks, which are linked together according to specific rules, forming a continuously growing chain structure²⁸.

Blockchain is divided into three categories: shared blockchain, private blockchain, and federated blockchain²⁹. This paper uses federated blockchain. Blockchain has the characteristics of decentralization, transparency, security, and non-tampering. It is not controlled by a central institution but is jointly maintained and verified by multiple nodes in the network, thereby reducing the risk of a single point of failure.

Blockchain technology has a wide range of applications, such as cryptocurrencies (Bitcoin, Ethereum, etc.), smart contracts, supply chain management, digital identity verification, etc. It is seen as a technology with revolutionary potential that can change the business models and data management methods of traditional industries.

Bilinear mapping

Set up \(G_0\) and \(G_1\) are two multiplicative cyclic groups, whose orders are prime numbers p. g is the generator of \(G_0\) , e is a bilinear mapping, \(e:G_{0}\times G_{0}\rightarrow G_{1}\) . Bilinear mapping has the following characteristics:

1. (1)

   Bilinear: \(\forall u,v\in G_{0}\) , \(a,b\in Z_{P}\) , all of these make \(e(u^{a},v^{b})=e(u,v)^{ab}\) .

2. (2)

   Non-degenerative: \(\exists g\in G_{1}\) , so that \(e(g,g)\ne 1\) .

If your \(G_0\) group operations and bilinear mappings in \(\textrm{e}{:}G_{0}\times G_{0}\rightarrow G_{1}\) all are effective and calculable, then \(G_0\) is a bilinear group. Note that the mapping e is symmetric, that is, \(e(g^{a},g^{b})=e(g,g)^{ab}=e(g^{b},g^{a})\) .

Monotonic access structure

Set up \(\{1,2,\ldots ,n\}\) a group of participants, a collection \(\Gamma \subseteq 2^{\{1,2,...,n\}}\) is monotonous if and only if \(\forall {B,C}\): if \(B\subseteq \Gamma\) and \(B\subseteq C\), all make \(c\subseteq \Gamma\). A single access structure \(c\subseteq \Gamma\) is the set consisting of non-empty subsets of \(\{1,2,\ldots ,n\}\), such as \(\Gamma \subseteq 2^{\{1,2,...,n\}}/\emptyset\). The set in \(\Gamma\) is called the authorization set, while the set not in \(\Gamma\) is called the unauthorized set.

Linear secret sharing scheme

The definition of Linear Secret Sharing Scheme (LSSS) is as follows.

Set up \(\textit{P}\) a participant collection, a secret sharing scheme \(\text {n}\) on \(Z_{p}\) is linear and needs to be met:

1. (1)

   The secret sharing value of each participant construct a vector on \(Z_{p}\)

2. (2)

   There exists a secret sharing matrix \(\textit{M}\) for row \(\textit{m}\) and column \(\textit{d}\) of \(_{\Pi }\) . \(\rho\) is a mapping function, mapping each row of \(\textit{M}\) to each participant of \(\textit{P}\) . For each row of \(\textit{M}\) , \(M_{i}(i\in [1,m])\) corresponds to participant \(\rho (i)\) . Given a column vector \(\vec {v}=(s,r_{2},\ldots ,r_{d})\) , where \(s\in {Z}_{p}\) is the secret sharing value and \(r_2,...,r_d\) is a random value. \(M\vec {v}\) represents the m secret sharing values of secret s about \(_{\Pi }\), and \(\lambda _{i}=(M\vec {v})_{i}\) is the secret sharing value of participant \(\rho (i)\).

Linear secret sharing schemes have the property of linear reconstruction. Assuming \(_{\Pi }\) is a linear secret sharing scheme for monotonic access structure \(\textit{A}\). \(\textit{S}\) represents an authorization set, and \(I\subseteq \{1,\ldots ,m\}\) is defined as \({I}=\{x|\rho (x)\in S\}\). By using the Gaussian elimination method, the constant set \(\{\omega _{x}\in Z_{p}\}_{x\in I}\) and \(\Sigma _{i\in I}\omega _{i}M_{i}=(1,0,\ldots ,0)\) can be constructed, and the secret sharing value \(\Sigma _{x\in I}\omega _{i}\lambda _{i}=S\) can be further reconstructed.

Policy hiding

Policy hiding is a concept in cryptography, especially in the field of access control and data security. It aims to allow users to access sensitive data while preventing them or any unauthorized entity from knowing the specific policy that controls access. In environments involving the handling of sensitive information, this technique is essential to protect the privacy and security of data.

Hardness assumptions

Decision linear Diffie–Hellman assumption: Let \(\{a_i\}\), \(\{c_i\}\), \(\textit{b}\), and \(Z\) be random elements in \(\mathbb {Z}_p^*\), where \(i\in [0,t-1]\). \(\textit{G}\) is a generator in group \(\mathbb {G}\).The [decision linear] Diffie–Hellman (DLDH) assumption holds in group \(\mathbb {G}\) if no probabilistic polynomial-time (PPT) algorithm can distinguish the tuple \([G,G^b,\{G^{b(a_i+c_i)},G^{-c_i}\}_{i=0}^{t-1},G^{ab}]\) from \([G,G^b,\{G^{b(a_i+c_i)},G^{-c_i}\}_{i=0}^{t-1},Z]\) with a nonnegligible advantage.

Decision bilinear Diffie–Hellman assumption: Let \(\textit{a}\), \(\textit{b}\), \(\textit{c}\) and \(\textit{z}\) be random element in \(\mathbb {Z}_p^*\), and \(\textit{G}\) be a generator in \(\mathbb {G}\). The decision bilinear Diffie-Hellman (DBDH) assumption holds in group \(\mathbb {G}\) if no PPT algorithm can distinguish the tuple \([G,G^a,G^b,G^c,e(G,G)^{abc}]\) from \([G,G^a,G^b,G^c,e(G,G)^z]\) with a nonnegligible advantage.

Distributed key generation protocol

Distributed Key Generation Protocol is a protocol used to securely generate keys, allowing multiple participants to collaborate to generate a shared key without sharing private information.

Among them, the blockchain networks discussed in this chapter are all alliance blockchain networks composed of authentic and trusted consensus nodes. The alliance blockchain has a set of trusted node management consensus protocols, and other authorized nodes can generate data in the blockchain and store data on the chain. Secondly, the consensus nodes in the blockchain complete the update operation of the ledger in the chain to maintain consistent ledger status for all nodes. The specific functions of the alliance blockchain in this article are: (1) The consensus nodes in the blockchain use a distributed key generation protocol to initialize system parameters. (2) Responsible for generating, storing, and distributing keys. (3) Responsible for dynamic updates of attributes. The central key management authority and local key issuing authority belong to the blockchain network.

As shown in Fig. 1, the DUPH-BAAC scheme consists of six entities: central key management agency, local key issuing agency, cloud server, data owner, data user, and audit center organization. Next, we will provide a detailed description of the seven entities mentioned above.

1. (1)

   Central Key Management Agency (CKA). CKA is a trusted central key management organization in the scheme, responsible for managing the static attribute range of users, registering, authenticating, and identifying all users, distributing private keys and certificates to authorized users, and distributing updated keys.

2. (2)

   Local Key Authority (LKA). LKA is a trusted local key issuing authority in the scheme, responsible for managing the dynamic attribute range of users, distributing dynamic private keys, and updating dynamic keys to users.

3. (3)

   Cloud Server (CS). Cloud servers are used to store encrypted data and verify user permissions. The cloud server obtains the user identity key of the data user and makes a judgment. When the user attribute set meets the user access control structure and the ciphertext attribute set meets the ciphertext access control structure, the ciphertext is pre-decrypted and the pre-decrypted intermediate ciphertext is returned to the data user. When attributes are updated, the server also receives updates for ciphertext and ciphertext addresses.

4. (4)

   Data Owner (DO). Any IoT device or person can generate data. The data owner formulates access policies encrypts local messages and sends them to the cloud server for storage. The data owner updates the ciphertext attributes or user access policies in the ciphertext based on personal needs. The data owner can quickly verify the correctness of the ciphertext. Once an error is found in the ciphertext, they can submit an audit request to the audit center.

5. (5)

   Data User (DU). Each data consumer has a set of attributes and a unique identity key. The data consumer sends the identity key to the cloud server, which then performs permission verification. The data user also obtains the intermediate ciphertext pre-decrypted by the cloud server and then decrypts it to obtain plaintext information.

6. (6)

   Audit Center (AC). The audit center institution is a third-party trusted institution responsible for receiving audit requests from data owners and users, and publicly verifying the calculation results of cloud servers. After confirming that the ciphertext is incorrect, the audit center will send the audit results to the blockchain network based on specific responsibility allocation.

7. (7)

   Blockchain Network (BCN). Blockchain network is a distributed database system that allows multiple participants to jointly maintain a constantly growing list of data records, known as blocks. Each block contains a set of transaction records that are linked together and protected by cryptography to ensure the immutability and integrity of the data.

The research on bidirectional attribute access control methods based on dynamic updates and policy hiding of blockchain is mainly divided into five stages. The first part is the data encryption stage. The data owner encrypts the ciphertext attribute set, user access structure, and plaintext on the local device, and then sends them to the cloud server. The second part is the strategy hiding stage. The data owner sends ciphertext addresses with access policies to the blockchain through storage transactions³⁰. Users who want to access data owned by the data owner match the attribute set and hidden policy locally. If the match is successful, the user will generate an access certificate without privacy leakage through the ElGamal password system, which will then broadcast to other nodes in the blockchain network and trigger the smart contract deployed at each node in the blockchain network to verify the validity of the certificate. Once an agreement is reached, the data owner will generate a key and send access transactions to the blockchain network. Access transactions are used to record the access control history of data owners and are traceable and tamper resistant. The third part is the data decryption stage. Once a consensus is reached on the access transaction, the cloud server obtains the user identity key of the data user and makes a judgment. When the user attribute set meets the user access control structure and the ciphertext attribute set meets the ciphertext access control structure, the ciphertext is pre-decrypted and the intermediate ciphertext is returned to the data user³¹. The data user receives intermediate ciphertext from the cloud server and decrypts the plaintext data³². The fourth part is the dynamic update stage of attributes. When the attributes of the data consumer are updated, the user key and user identity key are updated accordingly. The data owner runs ciphertext updates, and ciphertext address updates, and the data user performs access certificate updates. The fifth part is the cloud audit stage. Data users can quickly verify the correctness of ciphertext, and once they discover errors in ciphertext, they submit audit requests to the audit center. After confirming that the ciphertext is incorrect, the audit center will send the audit results to the blockchain network based on specific responsibility allocation.

System process

The DUPH-BAAC program consists of the following components. Table 1 provides the meanings of the relevant symbols used in this scheme.

(1) Initialization

\(CKASetup(\lambda )\rightarrow \{GP, SK_{CKA}, PK_{CKA}\}\). The initialization of the central key management authority (CKA) is performed in the central key management authority of the consortium blockchain. Take the randomly generated public parameter \(\lambda\) as input and output the global public key \(\textit{GP}\). At the same time, the algorithm outputs its own signing private key \(SK_{CKA}\) and signing public key \(PK_{CKA}\).

\(LKASetup(GP)\rightarrow \{PK_{U}, SK_{U}\}\). The local key authority (LKA) initialization is performed in the local key authority of the consortium blockchain. Using global public key \(\textit{GP}\) as input, output the corresponding user public key \(PK_{U}\) and user private key \(SK_{U}\) for each data user.

(2) Generation of user identity key

\(UIDKeyGen(GP, PK_{U}, SK_{U}, UID, K, (P, \eta ))\rightarrow UK_{UID}\). User identity key generation is run by the local key authority (LKA). User identity key generation is run by the Local Key Authority (LKA). LKA takes global public key \(\textit{GP}\) , user public key \(PK_{U}\) , user private key \(SK_{U}\) , user attribute set \(\textit{K}\) , ciphertext access structure \((P,\eta )\) , and user identification \(\dot{UID}\) as inputs to generate the user identity key \({UK}_{UID}\) for the data consumer.

(3) Data encryption

\(Enc(GP, PK_{U}, SK_{U}, UID, (F, \rho ), \Lambda , M)\rightarrow D\). The data encryption method is executed by the data owner. Using global public key \(\textit{GP}\) , user public key \({PK_{U}}\) , user private key \(SK_{U}\) , user identification \(\text {UID}\) , user access structure \((F,\rho )\) , ciphertext attribute set \(\Lambda\) , and plaintext \(\textit{M}\) as inputs, output ciphertext \(\textit{D}\).

(4) Encrypted address generation

\(AddressGen(GP, PK_{U}, UK_{UID}, D)\rightarrow Address\). The generation of ciphertext addresses is performed by the data owner. The data owner takes the global public key \(\textit{GP}\) , user public key \({PK_{U}}\) , user identity key \({UK}_{UID}\), and ciphertext \(\textit{D}\) as inputs to generate the ciphertext address \(\textit{Address}\) , which is used for indexing ciphertext \(\textit{D}\).

(5) Encrypted text decryption

The decryption of ciphertext consists of two steps, including the cloud server outsourcing decryption stage \(OutDec(GP, D, UK_{UID})\rightarrow D^{\prime }\) and user decryption stage \(UserDec(D, D^{\prime }, UK_{UID})\rightarrow M\).

\(OutDec(GP, D, UK_{UID})\rightarrow D^{\prime }\). The outsourced decryption method is executed by the cloud server. Firstly, determine whether the user and ciphertext meet the user access permissions, that is, whether the ciphertext attribute set \(\Lambda\) meets the ciphertext access structure \({(P,\eta )}\) , and whether the user attribute set \(\textit{K}\) meets the user access structure \((F,\rho )\). This method takes global public key \(\textit{GP}\) , data ciphertext \(\textit{D}\), and user identity key \(UK_{UID}\) as inputs, an outputs intermediate ciphertext \({D'}\).

\(UserDec(D, D^{\prime }, UK_{UID})\rightarrow M\). User decryption is performed by the user on the local device. Take ciphertext \(\textit{D}\), intermediate ciphertext \({D'}\), and user identity key \(UK_{UID}\) as inputs, and output data plaintext \(\textit{M}\).

(6) Attribute update

\(UAttrUpdate(k)\rightarrow (k, K)\). The attribute update method is run by the LKA in the blockchain. Assuming the updated user attribute value is \(\textit{K}\), the authorization center runs the attribute update method to generate the attribute update tuple (k,K).

(7) User key update

The key update stage is divided into two parts, user key update \({UKUpdate(GP, (k, K))}\rightarrow PK_{U}^{\prime }\), \(SK_{U}^{\prime }\) and user identity key update \(UIDKUpdate(GP, SK_{U}^{\prime }, UK_{UID}, (k, K))\rightarrow UK_{UID}^{\prime }\).

\(UKUpdate(GP, SK_{U}^{\prime }, UK_{UID}, (k, K))\rightarrow UK_{UID}^{\prime }\), \(SK_{U}^{\prime }\). User key update. The user key update method is run by blockchain LKA. This method takes global public key \(\text {GP}\) and update tuple (k,K) as inputs, and outputs the updated user public key \({PK_{U}}^{\prime }\) and user private key \(SK_{U}^{\prime }\).

\(UIDKUpdate(GP, SK_{U}^{\prime }, UK_{UID}, (k, K))\rightarrow UK_{UID}^{\prime }\). The user identity key update method is run by the blockchain LKA. This method takes the global public key \(\textit{GP}\), updated user private key \(SK_{U}^{\prime }\), user identity key \(UK_{UID}\), and updated tuple (k,K) as inputs, and outputs the updated user identity key \(UK_{UID}^{\prime }\).

(8) Encrypted text update

\(DUpdate(GP, PK_{U}^{\prime }, D)\rightarrow DD\) The ciphertext update method is run by the data owner. When the user’s attributes are updated, the data owner updates the ciphertext in the data list. This method takes the global public key \(\textit{GP}\), the updated user public key \(PK_{U}^{\prime }\), and the ciphertext \(\textit{D}\) to be updated as inputs, and outputs the updated ciphertext \(\textit{DD}\).

(9) Encrypted address update

\(AddressUpdate(GP, PK_{U}, UK_{UID}^{\prime }, Address)\rightarrow Address^{\prime }\). The ciphertext address update is run by the data owner. When the user attribute set is updated, the data owner updates the ciphertext address corresponding to the ciphertext. This method takes the global public key \(\text {GP}\), the updated user public key \(PK_{U}^{\prime }\), the user identity key \(UK_{UID}^{\prime }\), and the ciphertext address Address to be updated as inputs, and outputs the updated ciphertext address \(Address^{\prime }\).

(10) Access proof update

\({ProofUpdate(GP, SK_{U}^{\prime }, Pro)}\rightarrow Pro^{\prime }\). The access proof update method is executed by the blockchain node. When the user attribute set is updated, the blockchain node updates the user access proof. This method takes the global public key \(\textit{GP}\), the updated user private key \(USK^{\prime }\), and the ciphertext access proof Pro to be updated as inputs, and outputs the updated ciphertext access proof \(Pro^{\prime }\).

(11) Encrypted text verification \(Verify(GP, D, V)\rightarrow VR\). The algorithm is executed by the data owner, inputting global parameter GP, outsourcing ciphertext D , validation information \(\textit{V}\), and outputting ciphertext verification result VR.

Security model

The security model of the DUPH-BAAC scheme is defined as follows:

Definition 1

Assuming that there is no probability, that \(\mathscr {A}\) polynomial time adversary can win the following game with an undeniable advantage, then the DUPH-BAAC scheme satisfies the indistinguishability under selective access structures and selective plaintext attacks (IND-sAS-CPA). In the game, \(\mathscr {A}\) is the adversary, \(\mathscr {C}\) is the challenger, \(\lambda\) and U are sets of security parameters and system attributes, respectively.

1. (1)

   (1) Initialization stage

   Adversary \(\mathscr {A}\) submits a challenged user access structure \((F^{*},{\rho ^{*}})\) and ciphertext attribute set \({\Lambda ^{*}}\) to the challenger \(\mathscr {C}\).

2. (2)

   (2) System establishment stage

   \(\mathscr {C}\) run method CKASetup to output the global public key GP of the system. At the same time, the algorithm outputs its own signature private key \({{SK_{CKA}}}\) and signature public key \(PK_{CKA}\). Send the public key \(PK_{CKA}\) to \(\mathscr {A}\), and the system’s global public key GP will be saved by itself.

3. (3)

   (3) Query phase 1

   At this stage, adversary \(\mathscr {A}\) adaptively executes any of the following queries to obtain the user identity key corresponding to the user attribute set K and ciphertext access structure \((P,\eta )\).

   1. (a)

      \(O_{LKASetup}(GP)\): challenger \(\mathscr {C}\) runs the local key issuance method LKASetup to generate the corresponding user public key \(PK_{U}\) and user private key \(SK_{U}\), and sends them to \(\mathscr {A}\).

   2. (b)

      \(O_{UIDKeyGen}(SK_{U},UID)\): adversary \(\mathscr {A}\) submits identity identification UID to Challenger \(\mathscr {C}\). Challenger \(\mathscr {C}\) runs the user identity key generation function UIDKeyGen to generate the corresponding user identity key \(UK_{UID}\), and sends it to adversary \(\mathscr {A}\).

4. (4)

   Challenge stage adversary

   adversaries \(\mathscr {A}\) submit two equally long challenge plaintext messages \(M_{0}\) and \(M_{1}\). adversary \(\mathscr {A}\) provides the challenged user access structure \((F^{*},\rho ^{*})\) and ciphertext attribute set \(\Lambda ^{*}\), so that the user attribute set K in query stage 1 does not meet \({(}F^{*},\rho ^{*})\), and the ciphertext access structure \((P,\eta )\) does not meet \(\Lambda ^{*}\). Challenger \(\mathscr {C}\) selects a message \({M}_{b}\),\(b\in \{0,1\}\), obtains the ciphertext \(D^{*}\) through the encryption function \(Enc((F^{*},\rho ^{*}),\Lambda ^{*},M_{b})\), and returns it to adversary \(\mathscr {A}\).

5. (5)

   Query phase 2

   The enemy \(\mathscr {A}\) repeats the steps of query stage 1. Among them, both user attribute set K and ciphertext access structure \({(P,\eta )}\) still do not meet the challenge of user access structure \((F^{*},\rho ^{*})\) and ciphertext attribute set \(\Lambda ^{*}\).

6. (6)

   Guess the adversary

   Conjecture \({b^{\prime }}\) on output b of adversary \(\mathscr {A}\).

In this security game, the enemy’s advantage in winning the game is defined as follows:

If the adversary fails to win the above game with an undeniable advantage within any polynomial time, then the DUPH-BAAC scheme can resist indistinguishable choice access structure and choice plaintext attacks and has IND-sAS-CPA security.

This section introduces the detailed construction of our DUPH-BAAC scheme, mainly including system initialization, policy hiding, ciphertext decryption, dynamic attribute updates, and ciphertext verification.

System initialization

Part 1: Initialize the Central Key Management Authority (CKA) in the blockchain and generate the global public key \(\textit{GP}\). Meanwhile, CKA defines the scope of static attributes and establishes its own signature private key \(SK_{CKA}\) and public key \(PK_{CKA}\).

Step 1: The system selects the bilinear group \(G_{0}\) of order \(\textit{q}\). Among them, \(G_{0}\) includes the generator g and bilinear mapping \(G_{0}\times G_{0}\rightarrow G_{T}\);

Step 2: The system selects the appropriate hash function \(H{:}\{0,1\}^{*}\rightarrow G_{0}\);

Step 3: Generate a global public key through input parameters and mathematical calculations \(GP=\{g,H\}\).

Part 2: Local Key Authority (LKA) initialization in blockchain, outputting the corresponding user public key and user private key for each user. There is an LKA within a certain range. Locally deployed LKA generates its own public and private keys. Each LKA defines a dynamic attribute range.

Step 1: The local key issuing authority \(LKA_{i}(i=1,{2},\ldots ,n)\) manages part of the user attribute set \({\tilde{U}}_{i}\) and ciphertext attribute set \({\tilde{U}}_{i}\).

Step 2: \(LKA_{i}\) Randomly select parameters \(\alpha _{q}\in Z_{p}^{*}(q\in \overline{U}_{i})\) and \(\beta _{\dot{a}}\in Z_{P}^{*}(d\in \widehat{U}_{i})\) based on attribute set \(U_{i}=\tilde{U}_{l}\cup \hat{U}_{l}\);

Step 3: Generate user public key \(PK_{U}=\{e(g,g)^{\alpha _{i}},g^{\beta _{i}}\}\) and user private key \(SK_{U}=\{\alpha _{i},\beta _{i}\}\) for the user based on the calculation.

Generation of user identity key

The user identity key generation method is run by LKA. The method takes as input the global public key \(\textit{GP}\), the user’s public key \(PK_{U}\), the user’s private key \(SK_{U}\), the user’s attribute set \(\textit{K}\), the ciphertext access structure \((P,\eta )\), and the user’s identification \(\textit{UID}\), and outputs the user identity key \(UK_{UID}\).

Step 1: Assume that \(\textit{N}\) is a matrix of \(l_0\times k_0\), randomly selected \(\varphi \in Z _P^*\), \(y_i\in Z _P^*(i=2, \ldots , k_0)\), \(\varphi\) is the user secret value to be shared;

Step 2: Construct vectors \(\vec {\nu }_{k_0}=(\varphi , y_2, ..., y_{k_0})^T\), and vectors \(\vec {w}_{k_0}=(0, y_2, ..., y_{k_0})^T\), based on the randomly selected \(\varphi\) and \(y_{i}\);

Step 3: Assuming \(N_{x}\) that is the first row \(\textit{x}\) of the matrix \(\textit{N}\), compute \(\sigma _{k_0}=N_{x}\cdot \vec {\nu _{k_0}}, \tau _{k_0}=N_{x}\cdot \vec {w_{k_0}}\);

Step 4: For each \(N _{x}\) randomly selected random number \(\mu _i\in Z _P^*\), \(x=1, 2, \ldots , l_0\) perform the following calculations:

Step 5: The local key management organization \(\textit{UID}\) creates a value \(U_{t}\) for the user identity that belongs to each user attribute \(U_{t}\) and performs the following calculations:

Step 6: A user identity key \(UK_{UID}\) is generated by the above calculation and sent to the vehicle user.

Data encryption

The data encryption method is performed by the data owner. The method takes as input the global public key \(\textit{GP}\), the user public key \(PK_{U}\), the user private key \(SK_{U}\), the user identification \(\textit{UID}\), the user access structure \((F,\rho )\), the ciphertext attribute set \(\Lambda\), and the plaintext \(\textit{M}\), and outputs the ciphertext \(\textit{D}\).

Step 1: Assuming \(\textit{F}\) a matrix of \(l_e\times k_e\), randomly choose \(s\in Z_P^*\), \(t_j\in Z_P^*(j=2, \ldots , k_e)\), \(\textit{s}\) to be the secret value of the ciphertext to be shared;

Step 2: Construct vectors \(\vec {\nu }_{k_e}=(s, t_2,..., t_{k_e})^T\) and vectors \(\vec {w}_{k_e}=(0, t_2,..., t_{k_e})^T\), based on the selected \(\textit{s}\) and \(t_j\);

Step 3: Assuming that \(F_{x}\) is row \(\textit{x}\) of the matrix \(\textit{F}\), perform the calculation \(\lambda _{k_e}=F_x\cdot \vec {\nu _{k_e}}, \mu _{k_e}=F_x\cdot \vec {w_{k_e}}\);

Step 4: For each \(F_{x}\) randomly select \(r_x\in Z _p^*, x=1, 2, \ldots , l_e\), and perform the following calculation:

Step 5: The vehicle data owner creates the value \(D_{k}\) for each cipher attribute \(i(i\in \Lambda )\) corresponding to the encrypted file and performs the following calculations:

Step 6: The ciphertext \(\textit{D}\) is generated by the above calculation and sent to the cloud server.

Encrypted address generation

The ciphertext address is generated by the data owner. The method takes global public key \(\textit{GP}\), user public key \(PK_{U}\), user identity key \(UK_{UID}\) and ciphertext \(\textit{D}\) as input and outputs ciphertext address \(\textit{Address}\).

The cipher text is encrypted into cipher address by calculating the formula:

Access control policy hiding

Step 1: The data owner sends the ciphertext address with hidden access control policy to the blockchain network through a transaction, that is,

Among them, S is used to identify storage transactions, Address represents the ciphertext address (such as the hash value of ciphertext) and is used to index ciphertext D. \(\textit{checkCode}\), \(\textit{sign}\) is a digital signature generated by the private key of the data owner, used to prove that the transaction was indeed sent by the data owner.

Step 2: After generating \(Tx_{storage}\), it will broadcast to other nodes in the blockchain for verification. Verify the validity of the transaction through \(\textit{sign}\), and verify the validity of the ciphertext through \(\textit{checkCode}\).

Step 3: Compare the received message digest \(\textit{MD}\) generated by \(Tx_{storage}\). with the message digest \(\textit{MD}\) generated by decrypting \(\textit{sign}\) using the data owner’s public key \(BPK_{DO}\) to verify the validity of \(Tx_{storage}\). If equal, then \(Tx_{storage}\) is valid.

Step 4: The user matches \(\vec {x}\) locally from the blockchain and generates \(\vec {v}\) locally based on a set of attributes. Once \(\vec {x}\cdot \vec {v}=0\) means successful matching, the user will generate a Proof to trigger the smart contract for verification, where,

Among them, \(BP{K}_{DU}\) represents the public key registered by the user in the blockchain network, \(\text {Address}\) represents the ciphertext address that the user wants to access, \((E(\vec {v})=(E(v_{1}),E(v_{2}),...,E(v_{n}))\) is the result of encrypting each element in \({\vec {v}}\) using the ElGamal encryption system, and \(\text {sign}\) is the digital signature of user \(\text {Proof}\).

Step 5: Verify the validity of the signature of Proof. Broadcast Proof to other nodes in the blockchain network and trigger each smart contract to verify whether the user has access rights, and generate access transaction \(Tx_{access}\) for users who meet the access control policy, namely

A is used to identify access transactions, time represents the generation time of \(T{x}_{access}\), and \(\text {sign}\) is used to prove that \(T{x}_{access}\) is indeed sent by the data owner. The access publisher of \(T{x}_{access}\) needs to be consistent with the owner of its storage address.

Ciphertext decryption

The ciphertext decryption consists of two steps, including the cloud server outsourcing decryption stage and the user decryption stage.

The outsourced decryption method is executed by the cloud server. Firstly, determine whether the user and ciphertext meet the user access permissions, that is, whether the ciphertext attribute set \(\Lambda\) meets the ciphertext access structure \((P,\eta )\) , and whether the user attribute set K meets the user access structure \((F,\rho )\). This method takes the global public key GP, data ciphertext D, and user identity key \(UK_{UID}\) as inputs, and outputs the intermediate ciphertext \({D}^{\prime }\). The specific calculation is as follows:

Step 1: If the cloud server randomly selects \(c_{x}\in \mathbb {Z}_{P}^{*}\) to make \(\Sigma _{x\in K}c_{x}\lambda _{x}=s\), \(\Sigma _{x\in K}c_{x}\mu _{x}=0\),then it indicates that the ciphertext attribute set \(\Lambda\) satisfies the ciphertext access structure \(({P},\eta )\);

Step 2: If the cloud server randomly selects \(d_{y}\in \mathbb {Z}_{P}^{*}\) to make \({\Sigma _{y\in \Lambda }d_{y}}\sigma _{y}=\varphi\) and \(\Sigma _{y\in A}d_{y}\tau _{y}=0\), then it indicates that the user attribute set K satisfies the user access structure \((F,\rho )\);

Step 3: If both steps 1 and 2 pass the verification, the cloud server will perform proxy decryption services on the relevant ciphertext and generate intermediate ciphertext \(_{D^{\prime }}\). If either stage of steps 1 or 2 fails verification, the decryption process will terminate.

User decryption is performed by the user on the local device. Take ciphertext D , intermediate ciphertext \(_{D^{\prime }}\), and user identity key \(UK_{UID}\) as inputs, and output data M in plaintext. The specific calculation is as follows:

Attribute update

When the user’s attributes are updated, the user key and user identity key are updated accordingly. The data owner runs ciphertext updates and ciphertext address updates, and the user performs access-proof updates.

Step 1: UserAttrRevoke(). The attribute update method is run by LKA in the blockchain. Assuming the updated user attribute value is k, the authorization center runs the attribute update method to generate the attribute update tuple (k,K).

Step 2: The key update phase is divided into two parts, including user key update and user identity key update.

The user key update method is run by blockchain LKA. This method takes attribute update tuple (k,K) as input, and authorization center \(CN_{i}(i=1,2,\ldots ,n)\) dynamically updates attribute set \(U_{i}\) based on update tuple (k,K), while randomly selecting parameters \(a_{q}^{\prime }\in Z_{P}^{*}(q\in \overline{U}_{i})\) and \(\beta _{d}^{\prime }\in \mathbb {Z}_{p}^{*}(d\in \hat{U}_{i})\) based on the updated attribute set. Finally, generate the updated user public key \(PK_{U}^{\prime }=\{e(g,g)^{\alpha _{i}^{\prime }},g^{\beta _{i}^{\prime }}\}\) and user private key \(SK_{U}^{\prime }=\{\alpha _{i}^{\prime },\beta _{i}^{\prime }\}\).

The user identity key update method is run by blockchain LKA. This method takes the global public key \(\text {GP}\), updated user private key \(SK_{U}^{\prime }\), user identity key \(UK_{UID}\), and updated tuple (k,K) as inputs, and outputs the updated user identity key \(UK_{UID}^{\prime }\), user identity key \(UK_{UID}\), and updated tuple (k,K) as inputs, and outputs the updated user identity key \(UK_{UID}^{\prime }\). When user attributes are updated, the blockchain updates the user identity key according to the following rules, and the specific calculation is as follows:

Assuming the update tuple is (k,K); Update the \(SK_{U}^{\prime }\) value in the original user identity key to \(UK_{UID}=\{(P,\eta ),U,\{U_{x,1}, U_{x,2},U_{x,3}\}_{x=1,2,...,l_{0}},\{U_{t}\}_{t\in K}\}\) and the value in \(U_{t}\) to \(U_{t}=g^{\alpha _{t}}H(UID)^{\beta _{t}}(t\in k)\).

Step 3: DUpdate(). The ciphertext update method is run by the data owner. This method takes the global public key GP, the updated user private key \(SK_{U}^{\prime }\) , and the ciphertext D to be updated as inputs, and outputs the updated ciphertext DD. When user attributes are updated, the data owner updates the ciphertext in the data list, and the specific calculation is as follows:

Update \(D_{x,1}\), \(D_{x,3}\) in each ciphertext \(D=\{(F,\rho ),D,\{D_{x,1},D_{x,2},D_{x,3}\}_{x=1,2,...,i_{0}},\{D_{k}\}_{k\in A}\}\) to \(D_{x,1}=e(g,g)^{\lambda _{x}}e(g,g)^{\alpha _{\beta (x)}^{\prime }r_{x}}, D_{x,3}=g^{\beta _{\beta (x)}^{\prime }r_{x}}g^{\mu _{x}}\).

Step 4: AddressUpdate(). The ciphertext address update is run by the data owner. This method takes the global public key GP, the updated user public key \(PK_{U}^{\prime }\), the user identity key \(UK_{UID}^{\prime }\), and the ciphertext address \(\text {Address}\) to be updated as inputs, and outputs the updated ciphertext address \(Address^{\prime }\). When the user attribute set is updated, the data owner updates the ciphertext address corresponding to the ciphertext, and the specific calculation is as follows:

Update \(Idx_{1, w}\) and \(Idx_{2, i}\) in each ciphertext address \(Address=\{\left\{ Idx_{1, w}\right\} _{w\in U_{W}},Idx_{2, i}\}\) to \(I dx_{1, w}=e(g,g)^{\alpha _{w}^{\prime }\cdot \varphi \cdot H(kw_{k})},Idx_{2, i}=g^{\beta _{i}^{\prime }\cdot \varphi }\).

Step 5: \(ProofUpdate(GP, SK_{U}^{\prime }, Pro)\rightarrow Pro^{\prime }\). The access proof update method is executed by blockchain nodes. This method takes the global public key GP, the updated user private key \(SK_{U}^{\prime }\), and the ciphertext access proof Pro to be updated as inputs, and outputs the updated ciphertext access proof \(Pro^{\prime }\). When the user attribute set is updated, the blockchain node updates the user access certificate, and the specific calculation is as follows:

Update each pro in \(Pro=\{pro_{i}\} \textrm{to} pro_{i}=(g^{\alpha _{i}^{\prime }/\beta _{i}^{\prime }})^{H(kw)}\).

Ciphertext verification

\(Verify(GP, D, V)\rightarrow VR\). The data owner selects the security parameter \(\theta\), and for all \(i\in \{1,\ldots ,l\}\), selects the random number \(b_{i}\in \{0,1\}^{\theta }\) to calculate:

Calculate validation information:

Data owner verification:

If the above equation is true, it means that the ciphertext verification is passed and the verification result \({VR}=1\) is output; Otherwise, it indicates that the ciphertext verification failed and the verification result \({VR}=0\) is output.

In this section, the performance and security of the system were analyzed. Specifically, in terms of performance, we compared the functionality, computational cost, and time efficiency of some ABE schemes with ours. In terms of security, we have demonstrated that our scheme can resist indistinguishable selective access structures and selective plaintext attacks, and has IND-sAS-CPA security.

Performance analysis

In Table 2, we compared the existing five ABE schemes with our scheme in terms of attribute updates, policy hiding, bidirectional attribute access control, ciphertext verification, and outsourced decryption. Among them, “\(\surd\)” indicates that the scheme in the table supports this method. “\(\times\)” indicates that the scheme in the table does not support this method. From Table 2, it is evident that the functionality of the DUPH-BAAC scheme is much stronger than existing access control schemes.

In Table 3, we compared the differences in computational cost between the existing five ABE schemes and our scheme. Among them, \(\textit{E}\) represents exponential operation, \(\textit{n}\) represents the number of encrypted files, \(\textit{P}\) represents linear operation, \(\textit{H}\) represents hash operation, \(\textit{i}\) represents the number of attributes in the authorization authority, \(M_{i}\) represents the number of ciphertext attributes that meet the access control policy, and \(M_{e}\) represents the number of user attributes.

Table 3 mainly presents the computational costs of key components such as data encryption, ciphertext address, attribute update, ciphertext verification, outsourced decryption, and user decryption. In this scheme, the user first needs to perform \((3M_{i}+2M_{e})\) exponential operation and a hash operation to encrypt the plaintext data, where only one exponential operation is required for each ciphertext attribute. The user performs a hash and \((2i+M_{\textrm{i}})\) exponential operation on each ciphertext attribute to generate the ciphertext address. In addition, the attribute update operation only requires one hash operation. Then, ciphertext verification requires a linear and logarithmic operation. Finally, in the decryption phase, this article is divided into cloud server outsourcing decryption (denoted as Cloud) and user decryption (denoted as User). The \((M_{i}+M_{e})\) linear operation performed by the cloud server performs pre-decryption, while the user only needs to perform one exponential operation to decrypt the intermediate ciphertext into plaintext. In addition, this scheme has been compared in computational cost with other access control schemes in Table 3, such as OUAC³³, NVO-CP-ABE³⁴, PAB-MKS³⁵, DCDV³⁶, and BC-SABE³⁷.

The simulation experiments of this scheme were conducted on an Ubuntu 16.X desktop system using a 3.20 GHz Intel Core i7-8700 CPU and 4 GB RAM. All encryption schemes were implemented using the Python-based rapid prototyping encryption scheme framework Charm v.0.50.

In Table 4, we list the encryption and decryption times of our scheme in the experiment. From the table, it can be seen that the more attributes there are, the longer the running time of encryption algorithms and cloud decryption algorithms, which is consistent with the theoretical analysis results in Table 3.

In Fig. 2, we further compared the encryption and decryption time overhead of our scheme with other schemes. For ease of comparison, we set the number of complete nodes to n=10.

The comparison of encryption time efficiency between the DUPH-BAAC scheme and the OUAC scheme, BC-SABE scheme is shown in Fig. 2a. The time cost of the encryption algorithms in all three schemes increases with the number of attributes. However, it can be seen in Fig. 2a that under the same experimental conditions, the time cost of the proposed scheme is slightly lower than that of existing access control schemes, which have a certain time efficiency advantage.

The comparison of decryption time efficiency between the DUPH-BAAC scheme, NVO-CP-ABE scheme, and BC-SABE scheme is shown in Fig. 2b. The decryption time of all three schemes is linearly related to the number of attributes. Due to the DUPH-BAAC scheme in this chapter dividing the decryption process into two parts: user decryption and cloud server pre-decryption, it can be seen from Fig. 2b that the increased computational cost with the increase of attribute count does not have a significant impact on user decryption, but rather the cloud server bears the computational cost caused by the increase of attributes. This decryption mode reduces the computational pressure of lightweight terminal devices and is more suitable for IoT environments. Due to the use of bidirectional attribute access control methods to ensure the safe sharing of user data, the time cost of cloud server decryption will be slightly higher than other unidirectional attribute access control schemes, but within an acceptable time range.

Figures 3, 4 and 5 show the time cost comparison between the DUPH-BAAC scheme and the DUPH-BAAC scheme’s attribute dynamic update section (DUPH-BAAC-RE). Among them, Fig. 3a shows the time required for key updates during attribute dynamic updates, and it can be observed that the time cost is linearly related to the number of attribute updates.

Figure 3b shows the ciphertext update time, and it can be found that the ciphertext update time is independent of the number of attribute updates. Because this scheme places a large amount of update calculations in the blockchain network responsible for updating management keys, it reduces the update time of ciphertext on the user side.

Figures 4a, b, and 5a respectively show the comparison of decryption time, ciphertext address update time, and access proof generation time after the attribute update compared to before the attribute update. From these figures, the time cost after the attribute update is consistent with the DUPH-BAAC scheme, and there is no additional computational cost added due to the attribute update function.

Figure 5b compares the computational cost of the ciphertext verification part between this scheme and existing schemes. The solution requires the data owner to send a challenge message to the policy update cloud server, wait for the cloud computing results before proceeding with verification, and require a verification key from the administrator. However, in this chapter, the verification algorithm does not require communication processes or verification keys.

The experimental results indicate that the DUPH-BAAC scheme does not reduce the time efficiency of the scheme while achieving attribute updates. The DUPH-BAAC solution relies on the good computing power of cloud servers to achieve outsourced decryption, reducing the computational pressure and time cost of data acquirers during the data decryption phase. In addition, the ciphertext verification method of the DUPH-BAAC scheme does not require communication processes and verification keys, achieving a more efficient ciphertext verification process. Therefore, this scheme has certain practical application value.

When designing a bidirectional attribute access control scheme that supports dynamic updates and policy hiding, close attention should be paid to two issues Security. This article demonstrated in the previous section that this scheme has IND-sAS-CPA security. This article proposes to change the centralized authorization method in traditional IoT access control to the distributed blockchain, achieving key management and updates in the scheme, and thereby reducing the risk of key leakage. This article uses a linear secret-sharing scheme in the access control scheme, thereby increasing the reliability and security of the scheme’s Efficiency. To analyze the time efficiency of the scheme, this article uses the same construction method to construct the scheme in this chapter and the comparison scheme. In the same environment and variable, it can be found that this scheme has certain advantages in functionality, computational overhead, and time efficiency. In addition, considering the limited resources of IoT terminal devices, this solution utilizes cloud servers to provide outsourced decryption operations for authorized users during the decryption phase, reducing the decryption time cost for users. This scheme is managed by distributed blockchain user keys, and blockchain nodes do not need to respond to user requests in real-time to generate keys. Therefore, this article does not analyze the efficiency of key generation time.

Security analysis

Blockchain-assisted dynamic update and policy-hiding bi-directional attribute access control scheme satisfies several security properties, and the specific analysis is as follows.

1. (1)

   Collusion resistance: For attribute-based encryption schemes, it is important to prevent collusion attacks between adversaries. In our CP-ABE scheme, in order to decrypt a ciphertext, an adversary must obtain the mathematical equation \(\frac{e(g,g)^s}{e(g,g)^\varphi }\). When an adversary does not possess a certain attribute, he needs to conspire with a co-conspirator who possesses that attribute. However, during key generation, different adversaries use different random numbers for their private keys. By conspiring, the adversary must get the mathematical equation \(\prod _{s\ne 0}\frac{e(g,g)^s}{e(g,g)^\varphi }\cdot \frac{e(g,g)^s}{e(g,g)^{\varphi ^*}}\) in the decryption phase. However, \(\varphi\) is a random number in the adversary’s key and \(\varphi ^{*}\) is an arbitrary number in the co-conspirator’s key. So, they cannot work together to compute the mathematical equation \(\frac{e(g,g)^s}{e(g,g)^\varphi }\). This is why this scheme is resistant to the conspiratorial attack.

2. (2)

   Task confidentiality: This is the most basic security feature to ensure task security. In our system, tasks are encrypted and uploaded to the cloud server platform, which is considered strange. In the worst case scenario, the cloud server platform may try to recover the task information. However, it either does not have the key or the attributes do not comply with the access control policy. Therefore, the scheme ensures the privacy of the tasks.

3. (3)

   Decentralization: By using blockchain, we can implement user authorization, key management and attribute update. In this process, dynamic update of user access rights to private data is realized. It avoids DDoS attacks, single point of failure and leakage of important data that can be encountered on centralized management platforms.

4. (4)

   Policy privacy protection: In our scheme, policies are considered as private data that need to be protected. We propose CP-ABE with policy hiding property. In the encryption phase, the data owner’s plaintext data and access policies are encrypted to fully secure the attribute privacy. In addition to this, in blockchain-based CP-ABE, we use the multiplicative homomorphic ElGamal cryptosystem to provide complete attribute privacy protection while acquiring keys. This approach ensures policy privacy.

5. (5)

   Integrity and traceability: Our solution can ensure the integrity of task data and the traceability of access control information through the blockchain. Staff can compare the hash value of the task ciphertext in the cloud server platform with the information stored in the blockchain to determine whether the task has been modified. Meanwhile, all authorization records are stored in the blockchain as immutable access transactions. Therefore, no one can deny their behavior.

6. (6)

   Security analysis of DUPH-BAAC scheme: we now prove that the above CP-ABE scheme is selectively secure under the DBDH assumption.

Theorem 1

If the adversary cannot achieve victory in the indistinguishable choice plaintext attack security challenge with an undeniable advantage in probability polynomial time, then the DUPH-BAAC scheme has IND-sAS-CPA security.

Proof

If adversary \(\textit{A}\) wins the IND-sAS-CPA secure game with an advantage of \({\theta }\), then build a simulator \(\textit{G}\) that can solve the DBDH problem with an advantage of \(_{\theta /2}\). Provide a DBDH problem instance \(g,A=g^{a},B=g^{b},C=g^{c},Z\) and send it to simulator \(\textit{G}\). Where \(Z=e(g,g)^{abc}\) or \(Z=e(g,g)^{d}\). The purpose of simulator \(\textit{G}\) is to distinguish between \(Z=e(g,g)^{abc}\) or \(Z=e(g,g)^{d}\), where \(Z\in \mathbb {Z}_{p}^{*}\).

During the initialization phase, adversary \(\textit{A}\) submits a challenged user access structure \((F^{*},\rho ^{*})\) and ciphertext attribute set \(\Lambda ^{*}\) to challenger \(\textit{C}\).

During the system establishment phase, Challenger \(\textit{C}\) executes the \(\textit{CKASetup}\) method and outputs the global public key \(\textit{GP}\) of the system. The challenger randomly selects the \(\textit{q}\)-order bilinear group \(G_{0}\) and hash operation function \(\textit{g}\) with generator \(\textit{g}\) and bilinear mapping \(G_{0}\times G_{0}\rightarrow G_{T}\), and obtains the global public key \(GP=\{g,H\}\) through calculation.

In query stage 1, challenger \(\textit{C}\) runs the local key issuance method \(\textit{LKASetup}\) to generate the user public key \(PK_{U}\) and user private key \(SK_{U}\) of adversary \(\textit{A}\), and sends them to \(\textit{A}\).

Adversary \(\textit{A}\) submits identity \(\textit{UID}\) to Challenger \(\textit{C}\). Challenger \(\textit{C}\) runs the user identity key generation function \(\textit{UIDKeyGen}\) to generate the corresponding user identity key \(UK_{UID}=\{(P,\eta ),U,\{U_{x,1},U_{x,2},U_{x,3}\}_{x=1,2,...,l_{0}},\{U_{t}\}_{t\in K}\}\), and sends the generated user identity key to adversary \(\textit{A}\).

During the challenge phase, adversary \(\textit{A}\) submits two equally long challenge plaintext messages \(M_{0}\) and \(M_{1}\). Adversary \(\textit{A}\) provides the user access structure \((F^{*},\rho ^{*})\) and ciphertext attribute set \(\Lambda ^{*}\) to accept the challenge, so that the user attribute set K in query stage 1 does not meet \((F^{*},\rho ^{*})\), and the ciphertext access structure \((P,\eta )\) does not meet \(\Lambda ^{*}\). Challenger \(\textit{C}\) selects a message \(M_{b}\), \(b\in \{0,1\}\), obtains ciphertext \(D^{*}\) by running the encryption function \(Enc((F^{*},\rho ^{*}),\Lambda ^{*},M_{b})\), and returns ciphertext \(D^{*}\) to adversary \(\textit{A}\).

Repeat the steps of query stage 1 for adversary \(\textit{A}\) in query stage 2. Among them, both user attribute set \(\textit{K}\) and ciphertext access structure \((P,\eta )\) still do not meet the challenge of user access structure \((F^{*},\rho ^{*})\) and ciphertext attribute set \(\Lambda ^{*}\).

In the guessing stage, adversary \(\textit{A}\) guesses the value \(b^{\prime }\) of \(\textit{b}\) based on ciphertext \(D^{*}\). When \(b={b^{\prime }}\), simulator \(\textit{G}\) outputs “successful”, otherwise it outputs “failed”.

When \(Z=e(g,g)^{abc}\), adversary \(\textit{A}\) can obtain information about \(D^{*}\). At this point, the probability of adversary \(\textit{A}\) winning is:

When \(Z=e(g,g)^{abc}\), due to the uncertainty of \(\textit{d}\), enemy \(\textit{A}\) cannot obtain any information about \({D^{*}}\). The probability of adversary \(\textit{A}\) winning currently is:

Therefore, the advantages of simulator G in solving DBDH difficulties are:

In summary, there is a method that can solve the DBDH problem with an undeniable advantage \(\theta /2\) in polynomial time. However, this contradicts the DBDH problem, which is a difficult mathematical problem. Therefore, the DUPH-BAAC scheme can resist indistinguishable choice access structures and choice plaintext attacks, which means that the DUPH-BAAC scheme has IND-sAS-CPA security.

This article proposes a bidirectional attribute access control scheme that supports dynamic updates and policy hiding to adapt to complex and ever-changing IoT environments, ensuring accurate and secure data sharing among users. The dynamic update of attributes meets the needs of users for their own data access policies or attribute changes. Policy hiding ensures that data users no longer worry about their attribute leakage, ensuring a safer and more reliable data-sharing process. In the decryption phase, the scheme hands over a large amount of computing to cloud servers, reducing the computational pressure on IoT terminals. The ciphertext verification method of this scheme does not require communication processes and verification keys, achieving a more efficient ciphertext verification process. The solution uses alliance blockchain instead of traditional centralized key management services, and consensus nodes jointly generate key parameters through DKG, improving the security of the Internet of Things system. Finally, the security and performance analysis shows that the scheme has good security and practicality.

This scheme has made significant progress in protecting privacy and improving data security, but there are still some limitations. The process of dynamic updating and policy hiding may introduce additional computation and communication overheads that affect the overall performance of the system. How to efficiently manage and update the attributes and access policies of a large number of IoT devices is another problem faced by existing schemes. In the future, we will investigate more efficient algorithms and protocols to reduce the computational and communication overhead in the dynamic updating and policy hiding process. We will develop scalable management and update mechanisms to accommodate the growing number of IoT devices while maintaining system stability and responsiveness. We will investigate new security techniques and strategies to improve the system’s resilience to attacks, including resistance to emerging threats such as quantum computing. By addressing these limitations and exploring new research directions, this proposal is expected to achieve wider applications in the future and provide stronger support for protecting data security and privacy in IoT environments.