Traceable Attribute-Based Encryption Scheme Using BIM Collaborative Design

Abstract

BIM collaborative design involves numerous participants from various specialties who create and share vast amounts of design data at different design stages to ensure the efficient transmission of design data between these specialties. It is imperative for the BIM collaborative design platform to guarantee the security of design data and effectively trace any instances of malicious leakage or tampering. Therefore, this paper proposes a traceable ciphertext-policy attribute-based encryption scheme (TCP-ABE) that formulates a dynamic data access control mechanism based on different participants and effectively tracks malicious users in the event of risks such as tampering, theft, and unauthorized access to BIM data. In this scheme, the user’s identity information is embedded into their private key as a key component, ensuring that only users who satisfy the access policy can decrypt it. The compromised private key allows for tracing of the user’s identity. Additionally, Linear Secret Sharing Scheme (LSSS) is employed as the access structure with the user’s attribute set divided into an attribute name set and an attribute value set to protect privacy by concealing the latter within the access policy. Furthermore, the scheme integrates blockchain with cloud storage as a trusted third-party storage mechanism to ensure data integrity. Finally, the TCP-ABE scheme is comprehensively evaluated by comparing its strengths and weaknesses with other algorithms. This evaluation includes a theoretical analysis of functional and computational time overhead aspects, as well as an experimental analysis of initialization time, data encryption time, and data decryption time. The scheme exhibits excellent performance across all stages and encompasses the most comprehensive functionalities, as demonstrated by the comparative analysis and experimental results.

1. Introduction

BIM collaborative design encompasses the full life cycle of a construction project, involving various participants such as the owner, designers, constructors, operators, and others. The BIM collaborative design platform facilitates information accessibility, effective communication among participants, and real-time sharing of design information. Designers can also acquire relevant suggestions through the platform and make improvements and modifications to the design content [1]. In this case, it is necessary for the BIM collaborative design platform to set different usage permissions based on the specific duties and expertise of participants to avoid resource conflicts. During the design phase, when numerous modifications are made and there is a need to backtrack on certain operations, it is possible to trace the original designer or modifier’s information. Malicious users might also share and leak decryption rights to third parties for economic gains, and those responsible for leaks need to be held accountable. Therefore, given the characteristics of multiphase, multiparticipant BIM collaborative design, there are new security requirements for BIM collaborative design platforms. It is essential not only to ensure the safety of the design data but also to set access permissions based on different users and trace file modification records, ensuring secure and efficient collaborative design. Moreover, in certain scenarios, users may upload encrypted data to a centralized cloud server that is only partially trusted, thereby heavily relying on the honesty of the cloud server for data reliability. It becomes impossible to determine whether stored data have been tampered with and there exists a risk of single-point failure. Consequently, this paper proposes a traceable ciphertext-policy attribute-based encryption scheme (TCP-ABE) capable of tracing specific users. This scheme embeds the user’s identity information into their private key as an essential component, ensuring that only authorized users who satisfy access policies can decrypt the data while also enabling traceability in case of key compromise or misuse. Additionally, by representing the user’s attribute set as attribute name and value pairs, privacy protection is enhanced by concealing attribute values within access policies. Finally, through combining blockchain technology and cloud storage as a trusted third-party storage solution, issues such as single-point failure, data modification, and deletion can be mitigated while guaranteeing data integrity.

2. Related Work

2.1. Security Permissions in BIM Collaborative Design

Traditional BIM collaborative design mostly relies on the built-in work-sharing or model-linking modes in BIM design platform. However, this method has drawbacks such as high computer performance requirements, one-way updates, and the inability to record and trace BIM model information after each design. Cloud services can alleviate the constraints that local computer performance imposes on the efficiency of the BIM collaborative design process. As a result, researchers have proposed combining cloud services with BIM technology and have developed a cloud-based BIM collaborative design platform [2]. The cloud-based BIM collaborative design platform encompasses several main functionalities, including modules for BIM model construction, task and time progress management, security and permission management, conflict detection and design change, legal regulation detection, knowledge management, and extended function analysis built upon the BIM model. The BIM model construction module, task and time progress management module, and security and permission management module form the functional foundation of the entire collaborative platform [3,4]. The primary function of the security and permission management module is to ensure data security and manage access permissions. Access permission management mainly involves three tasks: firstly, preventing unauthorized users from gaining access to protected data; secondly, enabling authorized users to access protected data; and thirdly, promptly handling access permission granting, transfer, and revocation requests [5].

In BIM collaborative design, the owner acts on the demand side of collaborative design and presents requirements for the functional use of the construction project throughout its entirety. Additionally, they serve as the ultimate recipient. Based on these requirements, professional designers proceed with specialized designs accordingly. Architectural engineers develop building schemes, create BIM building models, visualize them, etc. Structural engineers engage in activities such as modeling BIM structural models, analyzing building structures, and designing them. The MEP engineers are responsible for equipment part modeling within BIM models and conducting the analysis and design of building equipment. Within the BIM collaborative design platform, various design engineers access various data on cloud servers from different locations. All project participants are assigned varying levels of access permissions in accordance with their respective rights and responsibilities, as depicted in Figure 1. Additionally, different data have varying sharing scopes, collaborative awareness needs, and security requirements. As BIM collaborative design progresses, the permissions of each participant are constantly changing. For owners, their permissions include reading design data and making requests and approvals. For design units, project managers or professional heads have the authority to read and review design data; professional design engineers have permission to modify their own data and request access to read and invoke other professional design data.

The BIM collaborative design platform necessitates the establishment of a robust information security protection mechanism and access management system. Since all data are stored in cloud servers, malicious modifications or deletions by malevolent users could lead to severe data security issues. Therefore, establishing a reasonable security permission management mechanism in the BIM collaborative design platform, accurately and securely recording the BIM design process, and holding leakers accountable have become urgent issues to address. Aiming to address the security issues prevalent in BIM collaborative design platforms, several researchers have commenced exploring diverse security technologies as potential solutions for enhancing BIM security applications. Nawari et al. [6] highlight the potential of blockchain technology in offering secure data storage and rights management, as well as facilitating effective BIM change tracking and ensuring data ownership. The decentralization, traceability, and anti-tampering characteristics of blockchain can effectively address BIM’s issues with drawing information records, data security, and other issues. However, the existing blockchain technology is not appropriate for handling substantial volumes of data. Tao et al. [7] introduced a framework called distributed common data environment (DCDE) that combines blockchain with Interplanetary File System (IPFS) to guarantee the security of design modifications in BIM collaborative design. The integration of BIM with blockchain encounters the challenge of sensitive data leakage due to the lack of access control methods. Tao et al. [8] also proposed a confidentiality-minded framework (CMF) for blockchain-based design collaboration and designed an Encryption-blockchain integration method. Access control is ensured through the encryption of sensitive BIM data within the blockchain. Combining the characteristics of collaborative BIM platforms related to data security, Das et al. [9] conduct a comprehensive literature review to evaluate the suitability of four prominent security technologies—cryptographic protocols, distributed database technology, cloud security, and blockchain technology—for enhancing BIM security. Two conceptual frameworks are proposed; one aims to support cryptographic key hierarchy schemes for ensuring data sharing through the creation of multiple layers of security, while the other presents a blockchain-based framework designed to record BIM changes within the untrusted environment of a construction project.

Research findings demonstrate that integrating cloud technology with other cutting-edge technologies, such as distributed database systems, encryption protocols, and blockchain, can significantly enhance the security of BIM. BIM collaborative design platforms need to establish dynamic data access control mechanisms for different participants. This ensures that each participant in the platform performs their respective duties with clear rights and responsibilities and can effectively trace design behaviors. When risks such as BIM data tampering, loss, theft, and unauthorized access occur, the platform should be able to effectively trace these malicious users and hold them accountable. This paper proposes TCP-ABE, which integrates encryption algorithms and blockchain technology to establish a data access control mechanism based on different participants. The aim is to effectively mitigate risks such as tampering, theft, and unauthorized access to BIM data by efficiently tracking malicious users.

2.2. Attribute-Based Encryption Scheme

Attribute-based encryption (ABE) [10] is a public key cryptography technique that enables data owners to grant access to their encrypted data based on specific attributes without disclosing any explicit identity information during the authorization process. In particular, ABE employs encryption and decryption keys to encrypt and decrypt data while utilizing attributes as conditions for controlling access to encrypted content. Users are granted decryption privileges solely upon satisfying the corresponding access control policy. ABE has gained significant popularity in the field of data sharing due to its flexible access control with fine-grained granularity. It can be categorized into two principal types: key-policy ABE (KP-ABE) [11] and ciphertext-policy ABE (CP-ABE) [12]. In KP-ABE, the private key is linked to the access policy, whereas the ciphertext is directly associated with the user attributes. It is suitable for applications such as paid video systems, digital rights management, and shared audit logs. In CP-ABE, the user attribute is linked to the private key, while the access policy is linked to the ciphertext. The access policy is determined by the data owner who decides which users with specific attributes are granted access to the ciphertext. Due to its advantages in flexibility and application range for access control scenarios, CP-ABE is considered more appropriate for BIM collaborative platforms.

In the CP-ABE scheme, users with identical attributes may have decryption keys that are the same. This could potentially enable certain malicious individuals to distribute their private decryption keys to unauthorized users without being traceable or held accountable. To tackle the issue of user key leakage, numerous CP-ABE schemes incorporating traceability features have been proposed. Kiayias et al. [13] utilized a traceable CP-ABE scheme with black-box functionality, leading to the production of multiple shared parameters and encrypted data. The CP-ABE scheme proposed by Ning et al. [14] allows for traceability without any polynomial constraint on the number of attributes. Liu et al. [15] introduced a method of CP-ABE that incorporates white-box traceability and direct user revocation functions. In the event of identifying a malicious user, their decryption privileges can be revoked from the password system. Additionally, Zhang et al. [16] introduced a multiauthority CP-ABE scheme that facilitates fast tracking and ensures the responsibility of malevolent users while maintaining adaptability and security. Han et al. [17] implemented a CP-ABE method to track the user responsible for key leakage by representing the user as a leaf node in a binary tree and encrypting the node value into the key. Bouchaala et al. [18] presented a TRAK-CPABE scheme with traceability and no key escrow, implementing white-box tracking that can directly revoke users but has security risks. For cloud data-sharing scenarios, Ning et al. [19] proposed an encrypted data-sharing system that combines white-box and black-box traceability with CP-ABE, enabling the effective identification of malicious users involved in decryption key leakage. Ning et al. [20] introduced a cloud storage service that utilizes a white-box traceable CP-ABE system. This system is designed to ensure traceability and security by employing non-interactive traceable pairing-friendly commitment with a perfectly binding key. It supports any monotone access structures and achieves full security within the standard model.

In certain CP-ABE schemes, access policies are made publicly available. The access policy is directly embedded within the ciphertext and is transmitted or stored alongside it. However, if the access policy contains sensitive information, it may inadvertently compromise users’ privacy. To address this limitation, several schemes with policy hiding have been successively proposed. Zhang et al. [21] proposed a large universe CP-ABE scheme with partially hidden access policies, denoted as PH-CP-ABE. To effectively address concerns regarding data security and user privacy, they introduce PASH as an efficient solution. The cornerstone of PASH is a CP-ABE scheme that supports both large universe and partially hidden access policies. Hahn et al. [22] present a general CP-ABE scheme featuring a hidden policy, ciphertext of constant size, and traceability. The proposed scheme effectively enforces hidden access policies using wildcards and ensures constant-sized ciphertexts regardless of the number of attributes involved. Additionally, to prevent the intentional distribution of decryption keys by users, each key is embedded with a unique identifier point, thereby achieving traceability. Gao et al. [23] propose a blockchain-based trusted secure ciphertext-policy and attribute-hiding access control scheme, named TrustAccess, to ensure trusted access while preserving policy and attribute privacy. They developed OHP-CP-ABE, a large universe and hidden-policy CP-ABE for blockchain that utilizes the transparency of blockchain to encrypt data and solve the privacy-leakage problem of access policy. Sun et al. [24] proposed a lightweight policy-hiding CP-ABE scheme for the IoT-oriented s-health application, enabling lightweight encryption and decryption operations while preserving the confidentiality of user attributes. However, the efficiency of this scheme remains suboptimal. Zhang et al. [25] propose a large universe ciphertext-policy ABE (CP-ABE) scheme that supports partially hidden access structures (PHAS) and highly efficient key revocation. The scheme achieves partial policy hiding but requires sharing the generator matrix with all permutations when determining whether the user attribute set is satisfied, resulting in inefficiency.

In summary, the CP-ABE scheme exhibits some problems such as malicious key disclosure, single functionality, restricted expression of access structures, and suboptimal efficiency. In view of the aforementioned problems, this study presents an encryption method called traceable CP-ABE (TCP-ABE) that ensures traceability. By incorporating user identity information into the encryption key, the key owner can be effectively traced in case of its leakage or misuse. Moreover, by depicting the user’s attribute collection using names and values of attributes. The privacy of users is preserved by concealing the attribute value within the access policy. Finally, by integrating blockchain with the BIM collaborative design platform as trusted third-party storage, issues related to single-point failures, data modification, and data deletion can effectively be avoided, thereby ensuring data integrity.

3. Traceable Attribute-Based Encryption Schemes

3.1. Scheme Design

3.1.1. System Model

The scheme is composed of six entities: the data owner, data producer, data user, BIM collaborative design platform, blockchain, and attribute authorization center. The specific structure is illustrated in Figure 2, with each entity explained in detail below:

(1)

Data owner: The data owner is the project owner whose permissions include reading data, confirming data, and allocating permissions to other users. They do not have editing rights.

(2)

Data producer: Data producers refer to various professional design engineers involved in BIM collaborative design. In terms of access control, they have full control over the data they produce and can edit it. Data producers use symmetric encryption to encrypt data to be shared and then store it on the BIM collaborative design platform. After successful storage, they use a symmetric key, “aeskey”, for attribute-based encryption. Finally, they store the hash value returned by the BIM collaborative design platform and the encrypted symmetric key on the blockchain using a data on-chain algorithm.

(3)

Data user: Design engineers are not only data producers, but also data users. They have rights such as viewing, invoking, and reviewing data produced by other design engineers. The decryption key owned by the data user is linked to its own set of attributes. The symmetric key, “aeskey”, is decrypted by the data user who possesses attributes that comply with the access policy after retrieving data from the blockchain using the data-acquisition algorithm. The symmetric key is employed for decryption, and the corresponding encrypted file is downloaded from the BIM collaborative design platform.

(4)

Attribute authorization center: The attribute authorization center is responsible for initialization, completing user registration, and issuing keys based on user attributes. In cases of key leakage or misuse, the attribute authorization center can trace the malicious user through the key and hold them accountable.

(5)

BIM collaborative design platform: Project participants can engage in live communication and decision making, as well as design and review activities on the BIM collaborative design platform. This enables the design, integration, and sharing of project information. Any authorized user can use the BIM collaborative design platform according to their granted permissions.

(6)

Blockchain: As a distributed ledger, the blockchain features consistent data storage, tamper resistance, and nonrepudiation. It ensures secure data sharing through the BIM collaborative design platform hash value and the ciphertext of symmetric keys stored on the chain.

3.1.2. Formal Definitions

The primary components of the TCP-ABE scheme encompass eight algorithms as follows:

(1)

Initialization: Setup (1^λ) →PK,MSK. The attribute authorization center utilizes this algorithm for scheme initialization. The input for the algorithm is a security parameter 1^λ which generates the system common parameters PK and the master secret key MSK.

(2)

Key generation: KeyGen (PK,MSK,id,S) → (SK_id,S). The attribute authorization center input includes the system common parameters PK, the system master secret key MSK, the user identity id, and user attributes S. It then proceeds to execute the key-generation algorithm which based on the attribute set S to generate the user’s private key SK_id,S.

(3)

Data encryption: Encrypt (PK,M, $\mathbb{A}$) → CT. The data producer utilizes an encryption algorithm to generate the ciphertext CT by incorporating the common parameters PK, plaintext data M, and access structure $\mathbb{A}$ as input parameters.

(4)

Data upload: GST (id,addr,CT,timestamp) → Tx_storage. The data producers execute the data upload algorithm. The algorithm takes the data producer’s id, the address “addr” returned by the BIM collaborative design platform, the ciphertext CT, and the timestamp as inputs and outputs the storage transaction Tx_storage.

(5)

Data acquisition: GAT (IndexID,id,timestamp) → Tx_access. The data users execute the data-acquisition algorithm. The algorithm’s input comprises the data IndexID, data user’s id, and timestamp, and outputs the acquisition transaction Tx_access.

(6)

Data decryption: Decrypt (CT,PK,SK_id,S) → M or ⊥. After obtaining ciphertext CT through contract retrieval, the data user executes the decryption algorithm using the ciphertext CT, the system common parameters PK and their private key SK_id,S as input. The algorithm generates the plaintext data M only when attribute S of the data user satisfies access structure $\mathbb{A}$.

(7)

Key integrity check: KeySanityCheck (PK,SK_id,S) → 1 or 0. The attribute authorization center inputs the system common parameters PK and the user’s private key SK_id,S to check the integrity of the key before tracing it. If the key is deemed valid, an output of 1 is generated; otherwise, an output of 0 is produced.

(8)

Key tracing: Trace (PK,SK_id,S) → id. After successfully passing the key integrity check, the attribute authorization center utilizes the system common parameters PK and the user’s private key SK_id,S as inputs to execute the key-tracking algorithm, thereby generating the id of the key owner.

3.1.3. Tracking Security Model

The utilization of an interactive game involving adversary A and challenger B is employed as a method for demonstrating the tracking security model.

(1) Initialization: The setup algorithm is executed by challenger B, producing the system common parameters PK and system master private key MSK, and sending PK to adversary A.

(2) Private key query: Adversary A requests challenger B for the private key that corresponds to a set of the attribute (id₁,S₁), (id₂, S₂), …, (id_q, S_q). The private key is generated by challenger B using the KeyGen algorithm to produce the private key SK_idi,Si, which is subsequently provided to adversary A.

(3) Key forgery: Adversary A produces a forged key sk*. If Trace(PK,sk*) ≠ ⊥ and Trace(PK,sk*)$\notin${(id₁, S₁), (id₂, S₂), …, (id_q, S_q)}, then adversary A is declared the winner.

Definition 1.

The proposed scheme is considered to be traceable if it provides a negligible advantage for Adversary A in winning the above game within any polynomial time.

3.2. System Implementation

3.2.1. Initialization

The attribute authorization center employs the group generator algorithm ϑ(1^λ), taking the security parameter of 1^λ as input, and producing the parameter (N = p₁p₂p₃p₄,G,G_T,e). Herein, p₁, p₂, p₃, p₄ represent the orders of $G_{p_1},G_{p_2},G_{p_3},G_{p_4}$, respectively. These are distinct securing prime numbers. The generators are p₁, p₂, p₃, p₄, and G,G_T satisfies the bilinear group e: G × G → G_T. In addition, the attribute domain is set to U = $\mathbb{Z}$_N. Following this, the Setup algorithm is executed.

Setup(1^λ) → PK,MSK: First, choose α,a,b ∈ $\mathbb{Z}$_N at random. Randomly choose g,u ∈ $G_{p_1}$, then randomly choose X₄,d ∈ $G_{p_4}$. Then, $\mathcal{H}$:{0,1}* →$\mathbb{Z}$_N is used to calculate H = ud and Y = e(g,g)^α. Finally, the system common parameters PK and master secret key MSK are generated as the output. Equations (1) and (2) are computed as:

PK = (N,g,g^a,g^b,Y,H,X₄)

(1)

MSK = (α,u,d)

(2)

3.2.2. Key Generation

The user submits their id and set of attributes S to the attribute authorization center. The user’s attribute set consists of two parts: S = (I_S,S) and I_S ⊆ $\mathbb{Z}$_N. Here, I_S denotes the set of attribute names and $S={\left\{s_i\right\}}_{i\in I_S}$ represents the corresponding set of attribute values. The user’s private key is generated using the KeyGen algorithm once it has been confirmed by the attribute authorization center, and is then securely transmitted to them through a secure channel.

KeyGen(PK,MSK,id,S) → (SK_id,S): The algorithm takes the system common parameters PK, the master secret key MSK, the user identity id, and the user attribute set S as inputs. It then randomly chooses t ∈$\mathbb{Z}$_N and $R,R^{\prime },{R^{″},\{R_i\in G_{p_3}\}}_{\forall i\in I_s}$. With c = $\mathcal{H}(K^{\prime },L)$, the calculation is given in Equation (3):

$$\begin{array}{c}K=g^{\alpha /(b+c)}{g}^{\mathit{at}}R, K^{\prime }=g^t{R}^{\prime }\\ L=id, L^{\prime }=g^{bt}{R}^{″}\\ {\{K_i={\left(g^{s_i}u\right)}^{(b+c)t}{R}_i\}}_{i\in I_s}\end{array}$$

(3)

Ultimately, the user’s private key is generated as per Equation (4):

$${{SK}_{id,S}=\left(S, K, K^{\prime }, L, L^{\prime },\{K_i\right\}}_{i\in I_S})$$

(4)

3.2.3. Data Encryption

Data producers perform data encryption, which mainly consists of two parts:

(1) Cloud storage center: Given the blockchain’s storage capacity constraints, it is only suitable for storing basic data information. The BIM collaborative design platform has ample storage and can ensure real-time online capacity. Thus, data file content is symmetrically encrypted and stored on the BIM collaborative design platform.

The data producer utilizes the advanced encryption standard (AES) algorithm to generate a symmetric key, “aeskey”, after selecting the data file. The file is symmetrically encrypted using AES_encrypt(file, aeskey) and then uploaded to the BIM collaborative design platform. Once the file is successfully uploaded, the BIM collaborative design platform returns a unique hash value, “addr”, for subsequent ciphertext retrieval.

(2) Hidden access policy encryption: After symmetrically encrypting the data file, the data producer utilizes attribute-based encryption on the symmetric key “aeskey”, which requires sharing. The symmetric key required to decrypt and obtain the data file can only be obtained by data users who comply with the access policy. The specific algorithm is described below:

Encrypt(PK,M, $\mathbb{A}$) → CT: The input for the algorithm includes common parameters PK, a message M, and an access structure $\mathbb{A}$, where $\mathbb{A}$ = (A,ρ,T), A is a matrix with l rows and n columns, and ρ maps the i-th row of M to the attribute name index ρ(i). T = (t_ρ(1), t_ρ(2),…, t_ρ(l)) represents the collection of attribute values linked to (A, ρ). Vectors v = (s,v₂,…,v_n) and v′ = (s′,$v_2^{\prime }$,…,$v_n^{\prime }$) are chosen, where s, s′ ∈ $\mathbb{Z}$_N are shared secret values, (v₂,…,v_n) ∈ $\mathbb{Z}$_N, and ($v_2^{\prime }$,…,$v_n^{\prime }$) ∈ $\mathbb{Z}$_N. Random values {r_x}_x∈[l] ∈ $\mathbb{Z}$_N, Z₀, Z₁ ∈ $G_{p_4}$, and {Z_0,x,Z_1,x,Z_d,x}_x∈[l] ∈ $G_{p_4}$ are selected, and the calculation in Equation (5) is then performed:

$$\begin{array}{c}{\tilde{C}}_0=Y^{s^{\prime }}, {\widehat{C}}_0=g^{s^{\prime }}{Z}_0,{\widehat{C}}_0^{\prime }=g^{b{s}^{\prime }}{Z}_1,\\ C=M{Y}^{ s},C_1=g^s,C_1^{\prime }=g^{\mathit{bs}}\\ C_{0,x}=g^{a{A}_x·v^{\prime }}(g^{t_{\rho \left(x\right)}}H{)}^{-s^{\prime }}{Z}_{0,x},C_{1,x}=g^{a{A}_{x}v}(g^{t_{\rho \left(x\right)}}H{)}^{-r_x}{Z}_{1,x},D_x=g^{r_x}{Z}_{d,x}\end{array}$$

(5)

The final ciphertext CT with a semi-hidden access policy is generated as in Equation (6):

$$CT=\left(\right(A, \rho ),{\tilde{C}}_0,{\widehat{C}}_0,{\widehat{C}}_0^{\prime },C, C_1,C_1^{\prime },\{C_{0,x},C_{1,x},D_x{\}}_{ x\in \left[l\right]})$$

(6)

(3) Data upload: The BIM collaborative design platform utilizes a blockchain, which is an immutable distributed database, to effectively tackle concerns related to data modification and deletion that may occur during data sharing. Storing the data on the blockchain ensures its immutability, but also adds to the storage burden of the blockchain. Therefore, in this scheme, only the data IndexID, the data producer’s id and addr, the cryptographic CT after symmetric key encryption, and the data producer’s signature “sign” are stored on the blockchain. The data IndexID are generated by hashing the id and timestamp, ensuring uniqueness. Once the data producer completes the attribute encryption of the symmetric key, a transaction is generated via a smart contract, as illustrated in Algorithm 1. First, indexID is derived by hashing the data producer id and timestamp. Subsequently, the message digest MD is obtained by hashing the indexID, data producer id, BIM collaborative design platform address addr, ciphertext CT, and timestamp. The MD is then signed using a private key to generate the signature sign. Finally, a dictionary comprising indexID, the data producer id, the BIM collaborative design platform address addr, the ciphertext CT, timestamp, and signature sign serves as a storage transaction Tx.

Algorithm 1: Generate storage transaction

Input: id of data producer, addr of BIM collaborative design platform, ciphertext CT, timestamp  Output: Storage transaction Tx 1. indexID = H(id || timestamp) // Calculate the data IndexID 2. MD = H(IndexID, id, addr, CT, timestamp) // Calculate the message digest MD 3. sign = Sign(MD) // The digest is signed 4. Tx = {IndexID, id, addr, CT, timestamp, sign} // Create a transaction Tx 5. return Tx

3.2.4. Data Decryption

When data users want to access a data file, they utilize the data-acquisition contract to extract information from the blockchain. This contract is shown in Algorithm 2. The first step involves creating a ChaincodeStub object stub. Utilize the getState method of the stub to retrieve data based on the data IndexID. Subsequently, compute the message digest MD’ for fetched data by employing hash operations with IndexID, id, addr, CT, and timestamp as the input parameters. Verify the data signature by invoking the VerifySign function. If MD’ is equal to MD, return the acquisition transaction Tx; otherwise, if signature authentication fails, return an error message.

Algorithm 2: Generate obtain transaction

Input: the data IndexID, the data user’s id, timestamp Output: obtain transaction Tx 1. ChaincodeStub stub = ctx.getStub(); 2. stub.getState(IndexID); // Obtain data based on data IndexID 3. MD’ = H(IndexID, id, addr, CT, timestamp) // Calculate and obtain data message digest MD′ 4. MD = VerifySign(sign) // Verifying data signatures 5. if MD’ == MD then 6.  return Tx 7. else // Signature verification failure 8.  return Error

The data user decrypts the ciphertext by executing the Decrypt algorithm after obtaining the ciphertext CT encrypted with the symmetric key. The specific algorithm is as follows:

Decrypt (CT,PK,SK_id,S)→M or ⊥: The inputs are the ciphertext CT, the system common parameters PK, and the data user’s private key SK_id,S. Next, the algorithm calculates all the minimal authorization sets I_A,ρ on (A, ρ).

The algorithm comprises of two steps. Initially, a decryption test is performed to check whether there is a minimal authorization set I ∈ I_A,ρ that has {ρ(x)}_x∈I ⊆ I_S and that satisfies Equation (7):

$${\tilde{C}}_0^{-1}=e\left({\prod }_{x\in I}{C}_{0,x}^{w_x},(K^{\prime }{)}^c{L}^{\prime }\right)·e({\widehat{C}}_0,{\prod }_{x\in I}{K}_{\mathsf{\rho }\left(x\right)}^{w_x})·e\left(\right({\widehat{C}}_0{)}^c{\widehat{C}}_0^{\prime },K^{-1})$$

(7)

where c = $\mathcal{H}(K^{\prime },L)$, w_x, x ∈ I, and $\sum _{x\in I}{w}_x{A}_x=(1,0,\dots ,0)$, and there is an equality in S_ρ(x) = t_ρ(x). If this does not hold, the algorithm is terminated. If it does, Equation (8) is then computed:

$$F=e\left(\right(C_1{)}^c{C}_1^{\prime },K)·{\prod }_{x\in I}{\left(e\right(C_{1,x},(K^{\prime }{)}^c{L}^{\prime })·e(D_x,K_{\mathsf{\rho }\left(x\right)}\left)\right)}^{{-w}_x}$$

(8)

The final output is the ciphertext M = F⁻¹∙C, which is the symmetric key “aeskey”. At this point, one only needs to perform symmetric decryption using AES_decrypt(aeskey) to obtain the data file.

3.2.5. Key Tracing

The integrity of the key must be verified by running the KeySanityCheck algorithm before performing key tracing. The specific algorithm is described below:

KeySanityCheck(PK,SK_id,S) → 1 or 0: This algorithm requires the system common parameters PK and the user’s private key SK_id,S as inputs. Initially, it verifies whether the user’s private key conforms to the format of Equation (4). Then, it calculates Equations (9)–(11).

$$e(g^b,K^{\prime })=e(g, L^{\prime })\ne 1$$

(9)

$$e(g^{ b}{g}^{ c},K)=e({g, g)}^{\alpha }·e(g^{ a},{K^{\prime }}^{ c}{L}^{\prime })\ne 1$$

(10)

$$\exists i\in S, e(g^{S_i}H,(K\prime {)}^{c}L\prime )=e(g,{ K}_i) \ne 1$$

(11)

If the key does not have the proper form or does not satisfy the aforementioned equations, the output is 0; otherwise, the output is 1.

If the key integrity check is passed, i.e., the return value is 1, the key-tracing algorithm will proceed. Trace (PK,SK_id,S) → id: The input for the algorithm includes the common parameters PK and the private key SK_id,S that necessitates tracking. It outputs a component of the key L = id, resulting in the traced user’s id.

4. Performance Analysis

4.1. Theoretical Analysis

In this section, we present a theoretical analysis of the proposed scheme by comparing it with the previously mentioned schemes in [20,21,22,23] which have hidden strategies or traceability, mainly focusing on their functionalities and computational time overhead.

The functional aspects of these schemes are primarily analyzed from the following perspectives: access structure, large attribute domain, policy concealment, key tracking, and decryption testing, as well as integration with blockchain technology. The functionalities are presented in

Table 1. Functional comparison.

Scheme	Access Structure	Large Attribute Domain	Policy Hiding	Key Tracking	Decryption Test	Blockchain
Ning et al. [20]	LSSS	×	×	√	×	×
Zhang et al. [21]	LSSS	√	√	×	√	×
Hahn et al. [22]	AND	×	√	√	×	×
Gao et al. [23]	AND	√	√	√	×	√
The TCP-ABE scheme	LSSS	√	√	√	√	√

.

The scheme of Ning et al. [20] is a white-box traceable CP-ABE system for cloud storage services that utilizes non-interactive traceable pairing-friendly commitment with perfectly binding keys to trace users with leaked keys. But, it cannot hide policies or conduct decryption tests. Shortcomings exist in the aspects of both security and efficiency. The scheme of Zhang et al. [21] proposed a large universe CP-ABE scheme with partially hidden access policies denoted as PH-CP-ABE. It allows for the partial hiding of access policies while maintaining the same access structure as the TCP-ABE scheme and supporting decryption tests. However, the key remains untraceable. The scheme of Hahn et al. [22] introduced a general CP-ABE with a hidden policy, constant-sized ciphertext, and traceability. However, unlike the TCP-ABE scheme, it only supports small attribute domains. The system’s attribute set must be determined during the initialization phase, leading to poor scalability. Additionally, the scheme employs an AND-based access structure, limiting its expressive power. The approach of Gao et al. [23] proposed TrustAccess based on blockchain, which can achieve distributed and trusted access control management. It not only supports a large attribute domain but also enables key tracking and access policy hiding. Additionally, similar to the TCP-ABE scheme, it also uses blockchain to ensure data integrity. However, like that of Hahn et al. [22], its access structure uses multivalue wildcards and gates, limiting its expressive capability. It does not support decryption tests, making the decryption efficiency relatively low. Compared with other schemes, the TCP-ABE scheme supports the hiding of access policies and tracing of leaked keys, and uses the more expressive LSSS access structure. Users can customize attribute types and values, enhancing the system’s flexibility and scalability. The scheme achieves adaptive security, leverages blockchain to ensure data integrity, and improves decryption efficiency through decryption testing.

The comparison of computational overhead is primarily analyzed across three aspects: ciphertext encryption, decryption testing, and ciphertext decryption.

Table 2. Compared with the related solution of computational overhead.

Scheme	Ciphertext Encryption	Decryption Testing	Ciphertext Decryption
Ning et al. [20]	$1T_{G_T}^e+(3l+3) T_G^e$	-	(2|I| + 2) $T^p$
Zhang et al. [21]	$2T_{G_T}^e+(6l+2) T_G^e$	2$T^p$	(2|I| + 1) $T^p$
Hahn et al. [22]	$l{T}^p+2T_G^e$	-	(2|I| + 1) $T^p$
Gao et al. [23]	$1T_{G_T}^e+(l+1) T_G^e$	-	(|I| + 1) $T^p$
The TCP-ABE scheme	$2T_{G_T}^e+(6l+4) T_G^e$	3$T^p$	(2|I| + 1) $T^p$

displays the computational overhead comparison of various schemes. Regarding ciphertext encryption, the TCP-ABE scheme has an overhead of $2T_{G_T}^e+(6l+4) T_G^e$. This overhead is relatively large compared to those of other schemes because the encryption phase produces ciphertext for decryption testing, leading to increased overhead. However, only [21] and the TCP-ABE scheme can be tested for decryption. During the decryption phase, the TCP-ABE scheme can perform decryption tests, preventing computational wastage from failed decryption attempts and significantly reducing the computational overhead during full decryption, hence improving decryption efficiency. Compared to the approaches suggested by Ning et al. [20] and Zhang et al. [21], the TCP-ABE scheme achieves a more comprehensive set of functionalities for similar computational costs.

4.2. Experimental Analysis

This section conducts an experimental analysis aimed at evaluating the advantages and disadvantages of the TCP-ABE scheme proposed compared with other algorithms. The experiments were performed on a Windows 10 system with 64-bit architecture and an Intel(R) Core(TM) i7-10875H CPU @ 2.30 GHz, 16 GB RAM, and JPBC-2.0.0 encryption library. The TCP-ABE schemes, as well as those in [20,21,22,23], were implemented, enabling a comparison of system initialization phase calculation time cost, data encryption phase calculation time, and data decryption phase calculation time. The experiment selects a Type A elliptic curve with a 512-bit group order and expression of y² = x³ + x. After testing the algorithm 100 times and taking the average, the average costs of $T_G^e,T_{G_T}^e,T^p$ were obtained, as shown in

Table 3. Average computation time for complex operations.

Operation	${\mathit{T}}^{\mathit{p}}$	${\mathit{T}}_{\mathit{G}}^{\mathit{e}}$	${\mathit{T}}_{{\mathit{G}}_{\mathit{T}}}^{\mathit{e}}$
Time (ms)	14.637	18.769	2.341

.

The time consumptions of different schemes during the system initialization stage are compared and illustrated in Figure 3. The TCP-ABE scheme, as well as the schemes suggested by Zhang et al. [21] and Gao et al. [23], support a large attribute set. The entire system’s attribute domain does not need to be determined during system establishment, and the system initialization time remains unaffected by the number of attributes. From the figure, it is evident that the runtime of the approach proposed in this paper exhibits a slight increase compared to Gao et al. [23], but the time cost of the scheme remains constant and is relatively low. In contrast, as the system’s number of attributes increases, there is an escalation in the time needed for implementing the schemes presented by Ning et al. [20] and Hahn et al. [22].

A comparison of the computational time consumed by different schemes during the data encryption stage is illustrated in Figure 4. The schemes presented by Ning et al. [20], Hahn et al. [22], and Gao et al. [23] require less time compared to our scheme as they do not perform decryption tests. At the same time, the scheme of Ning et al. [20] does not hide the access policy, and that of Zhang et al. [21] does not implement a key tracing function. Our scheme adds additional components to the ciphertext for decryption testing, leading to an increased encryption time.

Figure 5 compares the time costs of different schemes during the data decryption phase. Our scheme reduces the full decryption time by performing decryption tests. In comparison, our scheme performs well in the data decryption phase while achieving more comprehensive functions.

In conclusion, in terms of computational time costs, compared with existing similar schemes, our scheme performs well in all stages and offers the most comprehensive features.

5. Conclusions

The BIM collaborative design platform must not only guarantee data security but also impose restrictions on control permissions for all participants and hold accountable those users who maliciously leak information. Therefore, this paper presents a key-tracking-enabled attribute-based encryption scheme. To address the issue of key leakage by malicious users, user identity information is embedded as a key component in the user’s private key to enable the tracing of the user’s identity in case of private key leakage. To tackle privacy concerns arising from access policies, specific sensitive attribute values are concealed within ciphertexts to achieve policy hiding. In order to mitigate issues such as single-point failure, data modification, and deletion during ciphertext storage, a trusted third party comprising blockchain and the BIM collaborative design platform is employed to ensure data integrity. Ultimately, theoretical analysis and experimental comparisons demonstrate that this paper’s scheme is more comprehensive in functionality than similar schemes while still maintaining good computational efficiency.

In future research, in order to enhance the security and authority management of BIM collaborative design platforms, there are several areas that require further improvement:

(1)

The development of quantum computers poses a significant threat to the security of conventional encryption algorithms. Quantum computers have the potential to break traditional public key cryptosystems, such as bilinear pairing-based attribute-based encryption schemes. Therefore, it is imperative to investigate attribute-based encryption schemes resilient against quantum attacks.

(2)

Currently, there is no effective method for managing the private key associated with the public key in DID documents. If the private key is lost, users must reapply for registration. Hence, it is essential to explore efficient key backup schemes for managing users’ private keys.