For our security proof, we utilize the q-type assumption over prime-order bilinear groups, specifically referring to the q-DPBDHE2 [20], which is a variant of the q-decisional parallel bilinear Diffie-Hellman exponent assumption presented in [21].

Definition 1

(q-DPBDHE2 Assumption) Select a bilinear group G of prime order p, associated with a non-degenerate bilinear map e:G×G→GT, based on the security parameter λ. Let s,a,b1,b2,…,bq be chosen uniformly at random from Zp and let R be chosen uniformly at random from GT. Let D=(G,p,e,g,gs,𝒦,𝒟,ℋ,ℳ), where 𝒦={gs/bi∣i∈[1,q]}ℋ={gbjai∣i∈[1,2q]∖{q+1},j∈[1,q]}𝒟={gai∣i∈[1,2q]∖{q+1}}ℳ={gsaibj/bj′∣i∈[1,q+1],j∈[1,q],j′∈[1,q],j≠j′}and this assumption states that no polynomial-time distinguisher can differentiate between the distributions (D,e(g,g)saq+1) and (D,R) with non-negligible advantage.

Business Process Modeling and Notation (BPMN) and Decision Model and Notation (DMN) are the most widely used process and decision modeling languages [22]. BPMN defines the symbols and semantics for collaboration diagrams, flowcharts, and processes. It is intended for direct use by stakeholders involved in designing, managing, and implementing business processes, while also being precise enough to allow BPMN diagrams to be converted into software process components. It features easy-to-use, flowchart-like symbols that are independent of any specific implementation environment. In Fig. 1, it shows a BPMN collaboration diagram that illustrates the customs clearance process based on a single window system.

Caterpillar is designed to combine the convenience of Business Process Management System (BPMS) with the security and transparency features of blockchain platforms [23]. Similar to the traditional BPMS, it supports the instantiation of process models and allows users to monitor the status of process instances and perform tasks within them. What sets it apart is the preservation of each process instance’s state on the Ethereum, where workflow management is facilitated by smart contracts produced via a BPMN-to-Solidity compiler. It is particularly suited for cross-organizational processes and is often referred to as “process-centric decentralized applications”. The applications operate among untrusted participants and require ensuring that all parties adhere to predefined process model rules. Caterpillar aims to ensure design compliance, meaning that no party can execute a transaction that violates the collaborative process model.

For decryption users with limited computational resources, proxy Decryption is an option. This phase comprises three algorithms: GenTR, PartDec, and FinalDec.

GenTR(uid,UAKS,uid)→(TKuid,RKuid): User uid selects t∈Zp∗ and calculates Kuid,x1=(Kuid,x)1/t,KPuid,x2=(KPuid,x)1/t, where x∈Suid. The algorithm outputs TKuid={Kuid,x1,KPuid,x2}x∈Suid and RKuid=t. Finally, the user sends TKuid to the proxy server and retains RKuid.

PartDec(TKuid,CT,GP)→CT′/⊥: The partial decryption algorithm is executed by the proxy server. If Suid∉A, the algorithm outputs stops. Otherwise, it calculates CT1′=∏i∈I(C1,i⋅e(H(uid),C3,i))ciandCT2′=∏i∈I(e(Kuid,δ(i)1,C2,i)⋅e(KPuid,δ(i)2,C4,i))ci

Finally, it generates the partially decrypted ciphertext CT′={A,C0,CT1′,CT2′} to be sent to the user.

FinalDec(CT′,RKuid)→m/⊥: The final decryption algorithm is run by the user. If Suid∉A, this algorithm outputs stops. Otherwise, compute: C0CT1′∗CT2′RKuid=me(g,g)se(g,g)s=m

When the attribute authority revokes the user’s attribute x, the authority should update the membership of AUGx and generate a new attribute group key GKx′. The authority then computes the revocation update key RUKx=gdx(GKx′−GKx). The authority sends RUKx to users and generates the update ciphertext key UCKx=GKx/GKx′.

KeyUpdate(uid,UAKS,uid,x,RUKx)→UAKuid,x′: The user executes the revocation attribute key update algorithm. x is the revoked attribute. For non-revoked attribute sets, the corresponding attribute keys remain unchanged. Otherwise, the algorithm updates KPuid,x′=KPuid,x⋅gdx(GKx′−GKx). The revocation attribute key updated by the user is UAKuid,x′={Kuid,x,KPuid,x′}.

CTUpdate(CT,x,UCKx)→CT∗: This algorithm is executed by AA to update the ciphertext. The algorithm updates C4,i′=C4,iGKδ(i)/GKδ(i)′ Finally, it generates the new re-encryption ciphertext CT∗=(A,C0,C), where C={C1,i,C2,i,C3,i,C4,i′}i∈L.

In this section, we extend the security model of RW15 by defining a security game between the challenger 𝒞 and adversary 𝒜 [20]. The game requires that all key-query requests from 𝒜 are instantly forwarded to 𝒞 after observing the global public parameters. Additionally, 𝒜 is allowed to corrupt (or manipulate) a fixed number of attribute authorities, with these corrupted entities remaining constant throughout the duration of the game.

The security attribute revocation in ABE should have two security requirements: forward security and backward security. Forward security means that if one or more attributes are revoked and a user’s remaining attributes no longer satisfy the access policy, that user will not be able to access data that was previously accessible using the revoked attributes. Backward security means that if one or more attributes are revoked, then the user will not be able to access subsequent data using the revoked attributes.

Ciphertext rollback attack refers to a scenario where, when updating a ciphertext, a malicious user obtains ciphertext update items from the relevant AA. For example, attribute revocation or policy update. The user rolls back the updated ciphertext to a previous version by using the ciphertext update item. Finally, the malicious user can decrypt the rolled-back ciphertext using the private key of the older version.

The security game proceeds as follows:

GlobalSetup: 𝒞 execute GlobalSetup algorithm obtains the GP and then forwards them to 𝒜.

Adversary's   Queries: 𝒜 establishes a set of corrupt permissions 𝒰C⊂𝒰Θ and the remaining uncorrupted permissions 𝒰N⊂(𝒰Θ−𝒰C). Our query and reply is similar to RW15 regarding Authority  Public  Keys and Secret  Keys. 𝒜 statically issues the following queries:

Transform   Key   query: 𝒜 requests a key transformation by submitting a sequence of (uid,Suid) tuples to 𝒞, also under the condition that T(Suid)∩𝒰C=⧸0. Note that it is meaningless to query the transform key for a user uid who has already had their secret key queried.

Challenger's   Replies: Upon receiving a query, the challenger 𝒞 selects a random bit b∈{0,1} and responds accordingly.

Transform   Keys : 𝒞 runs the GenTR algorithm to get the transformed key set TKuid and send them to 𝒜.

Guess. 𝒜 outputs a guess bit b′∈{0,1}. If b′=b, 𝒜 win the game.

Definition 2. We say that an attacker statically breaks the scheme if it has a non negligible advantage in correctly guessing the bit b in the above security game. The advantage of 𝒜 in this game is defined as Adv𝒜=|Pr[b′=b]−12|.

As shown in Fig. 2, our architecture’s main components consist of the following seven entities:

Certifier Central: It is responsible for deploying smart contracts, assigning user roles, and generating unique global identifiers for each user and authority within the system.

In this section, a detailed introduction to the specific processes of system startup, authority initialization, key management, data sharing, proxy decryption, attribute revolution, and policy update is provided. First, it is assumed that all participants agree on the smart contract code and user roles. The Certifier Central deploys all smart contracts on the blockchain. The Certifier Central assigns participant roles to specific users identified by their blockchain accounts. Each Authority assigned the attributes to the appropriate user. Data users generate RSA key pairs and upload their public keys to the RSA smart contract, which Authorities use to verify identities and transmit attribute keys.

As shown in Algorithm 1, the Initialization phase involves constructing the Authorities network and establishing encryption parameters. To ensure complete decentralization, the public parameter generation procedure for MA-ABE has been redesigned as a Multi-Party Computation protocol. Specifically, a commit-then-open coin-tossing protocol is used to produce a random generator. Each Authority publishes the hash of the locally generated random pairing elements on the blockchain, then reveals these elements themselves, completing the commit-then-open protocol. Each Authority verifies that the hash of the pairing elements matches their revealed values and then processes all revealed values to compute the public parameters, which become part of the public parameters. Each Authority uses the AAKeyGen algorithm to create its own public/private key.

Key management securely distributes and assembles attribute keys, enabling authorized data users to access encrypted information. As shown in Fig. 3a, it represents the steps of the key management phase, this phase involves the Certifier Central storing user attributes and records of their process participation. For instance, the manufacturer holds the address 0 × 07e…A6, associated with process 45,896,228. To access message data, users request keys from Authorities using their uid. Each Authority retrieves relevant user information from the Attribute Certifier Contract and generates an attribute key using this information, public parameters, and its own key. The Authorities then send these keys to the user for decryption. Only after collecting keys from all Authorities can a user combine them into the complete attribute key. No single authority is capable of generating the complete attribute key independently.

The process of data sharing is divided into encryption and decryption phases, with Algorithm 2 illustrating the data owner’s encryption procedure. Based on MA-ABE, the data owner establishes an access control policy. Considering that business processes may require encryption of plaintext data of arbitrary size, we employ a two-stage hybrid encryption strategy. The data owner encrypts a randomly generated symmetric key using the Encrypt algorithm. The symmetric key is used to encrypt the actual business information using a symmetric key encryption algorithm. The encrypted symmetric key and data are stored in a formatted file (message). Decryption mirrors this process. Access to the original information requires the symmetric key, ensuring only policy-compliant users can decrypt the data, thus enforcing fine-grained access control.

As illustrated in Fig. 3b, the process of proxy encryption involves several key steps. Firstly, the data user generates transformation key and a retrieval key from the attribute key, then transmits the transformation key along with the message ID to the Proxy Server. The Proxy Server retrieves the corresponding message from the Message Contract and Data Store using the message ID and applies the transformation key for partial decryption. It forwards the partially decrypted message to the data user, who completes the decryption process using the retrieval key to obtain the symmetric key, thereby gaining access to the information.

In Algorithm 3, it describes the process of attribute revocation in MADEXA. The policy update process in MADEXA can be obtained through the Algorithm 4. In their algorithm, “link” refers to the content identifier (CID) used for rebinding in IPNS.

In Table 2, it presents the format of messages that are encrypted and stored in the Data Store. Each storage entry is composed of one or more slices, designed to meet the access needs of different participants. Each file consists of metadata and a body. The metadata contains the sender, process id, and unique message id, while the body contains encrypted key-value pair data for easy indexing and retrieval, with each slice identified by a unique slice id. The sender corresponds to the user’s ethereum address and is used to identify the sender of the message. The process id and message id are fixed-length random numbers generated by the entity to uniquely identify each process and message instance. Key corresponds to the symmetric key that has been encrypted using MA-ABE, and Fields indicates the JSON-formatted data encrypted by the above symmetric key. We achieve finer-grained access control management by setting access policies on message slices. The messages are stored in the Data Store, retrievable via resource locators, and their integrity and authenticity are verified through hashing.

In Table 3, we compare our scheme with various MA-CP-ABE schemes. The GLGL23 [25] employs an access tree structure, while the proposed scheme and others use LSSS structures. The GLGL23 and ZLWR24 support user-level attribute revocation, while our scheme and others implement attribute-level revocation. The schemes [24–27] are susceptible to collusion attacks. The LJ18 [24] direct transmission of attribute group keys from AA to users can lead to adversaries obtaining revoked keys. Additionally, the scheme [24–28] are vulnerable to ciphertext rollback attacks, where adversary may exploit cloud-obtained update items to compromise backward security. In contrast, our scheme and ZHZL22 [29] conduct all ciphertext updates independently by AA without delegating update items to the cloud. Furthermore, CBZ22 [26], GLGL23 [25], and GWZ23 [27] exhibit significant security flaws, potentially allowing malicious entities to obtain plaintext.

In the CBZ22 scheme, a critical security flaw occurs during the Online.Enc phase, where parameters C4,j and C5,j exposes λ, closely associated with the secret value s. This exposure allows an adversary with access to these ciphertext components to deduce s, thereby decrypting the ciphertext and recovering the plaintext. In the GLGL23 scheme, due to the desire to achieve user Escrow Free, random numbers related to attributes are generated by users. This design allows an adversary to forge random numbers for attributes they do not possess, thereby generating false attribute keys. Once an adversary acquires sufficient valid attribute keys, they can decrypt the ciphertext. Algorithm 2 of the GWZ23 scheme also contains potential security risks. Here, εξi is part of the transformation key (TKuid), while the retrieval key (RKuid) equals ε. According to the scheme description, TKuid is directly provided by the authoritative sending server. It is noteworthy that εξi is the result of multiplying two random numbers, and this operation is not based on any widely recognized hard mathematical problem. Consequently, it is feasible for an adversary to find ε through brute force or exhaustive search. Once the adversary determines RKuid, they could gain access to the plaintext, threatening the confidentiality and integrity of the system.

In Table 4, we present a comparative analysis of computational complexities between our scheme and other studies. Here, P and E denote bilinear pairing and exponentiation operations in group G, while H and M represent hash and multiplication operations, respectively. We use nk, nc, and nd to indicate the number of attributes for key generation, policy setting, and decryption, respectively. For the proxy decryption phase, the complexity of the GenTR algorithm in our scheme and those from [24,26–29] scales linearly with the number of user attributes. GWZ23 [27] incorporates symmetric decryption and hash verification in the final decryption step, due to its encryption mechanism. Preprocessing for proxy decryption in CBZ22 [26] and GWZ23 occurs during key generation, not proxy decryption. Although ZHZL22 [29] and CBZ22 [26] have reduced preprocessing operations, this leads to increased P operations in ciphertext updates for attribute revocation. Our scheme and HKQ21 maintain identical computational complexity for the final decryption operation, adding only one extra multiplication compared to LJ18. When discussing attribute revocation, our scheme aligns with [28,29] when users update their attribute keys. The CTUpdate in other schemes modifies the revoked attribute’s associated ciphertext portion but incurs additional operations compared to ours. Overall, our attribute revocation and proxy decryption have low computational complexity.

The performance of the proposed scheme was assessed by the Charm¹ 1

https://github.com/JHUISI/charm (accessed on 27 January 2025)

As shown in Fig. 4a–c, the efficiency of proxy decryption is primarily explored. For this experiment, the system included 4 AAs, and the number of attributes per AA was increased according to the encryption policy. In Fig. 4a, our GenTR algorithm incurs less time than LJ18, with a slower increase as the number of attributes grows. The LJ18 scheme includes an extra ciphertext processing step that increases linearly with the number of attributes. In Fig. 4b, our FinalDec decryption times are slightly longer but generally remaining stable compared to LJ18. After increasing the number of experiments, LJ18 still occasionally has a little more than us, which may be an experimental inaccuracy due to the short decryption time. As shown in Fig. 4c, the decryption phase time cost for users is presented. The proxy decryption time of user is the sum of the GenTR and FinalDec algorithms’ times. When the number of attributes is 20, the LJ18 scheme’s proxy decryption requires 88.016 ms compared to 123.414 ms without it; our scheme demands 52.564 ms with proxy decryption vs. 98.278 ms without. Through proxy decryption, our scheme reduces the overall computational workload for users by approximately 50%, despite the added overhead. Overall, these figures demonstrate that our scheme performs better in handling a large number of attributes during proxy decryption.

For proxy decryption, the handled key and ciphertext constitute the main communication overhead. In Table 5, it shows the communication overhead comparison of GenTR algorithm under different numbers of attributes. Compared to the LJ18 scheme, our scheme only needs to transmit the key during processing, instead of having to transmit both the ciphertext and the key for processing as in LJ18. In addition, due to this algorithm are based on attributes. Therefore, when the number of attributes increases, the communication overhead of the LJ18 scheme will be significantly higher than our proposed scheme. As shown in Table 6, the communication overhead of the ciphertext is compared. In the PartDec algorithm, our scheme requires the transmission of two attribute-independent ciphertext parameters, in contrast to the LJ18 scheme which requires the transmission of only one similar parameter. So for messages of the same length, the costs in our scheme and the LJ18 scheme are essentially fixed, with slight fluctuations. Our scheme incurs slightly higher costs than the LJ18 scheme, which is consistent with the PartDec algorithm. In practice, our scheme reduces network bandwidth usage and improves communication efficiency.

In Fig. 5, it shows the time consumption under different numbers of revoked attributes. As shown in Fig. 5b, the execution time of the LJ18 scheme’s CTUpdate algorithm is basically constant, about 198 ms. The LJ18 scheme’s CTUpdate algorithm involves re-randomizing the entire ciphertext, this process is not affected by the number of revocation attributes [24]. As shown in Fig. 5c, it represents the overall attribute revocation time. The execution time of our scheme’s KeyUpdate and CTUpdate algorithm increases linearly with the number of revoked attributes. Our execution time is significantly lower than that the LJ18 scheme. In Fig. 5, it indicates that our scheme performs better when handling the revocation of a large number of attributes.

In the Ethereum protocol, the cost of executing or deploying a smart contract is measured in gas, reflecting the number of opcodes invoked [31]. We use ganache to simulate the merged version of Ethereum. The version used for Smart Contract is Solitidy^{\wedge}0.8.0. To estimate mainnet expenses, we adopted an average gas price of 6.50 Gwei and an ETH to USD exchange rate of 3192.15 as of 09 July 2024. Contract 1 is primarily designed to manage and record users’ RSA public keys as well as establish user identities. Through this contract, each user can register their public key and associate it with a unique identity. This process ensures the verifiability of all participants’ identities while providing the necessary public key infrastructure for subsequent encryption and decryption. Authority Contract invokes a decentralised public parameter generation mechanism that allows multiple authorities or nodes to jointly participate in the public parameter creation process. Message Contract focuses on implementing the information-sharing functionality.

As illustrated in Table 7, four stages were evaluated: smart contract deployment, system startup, authority initialization, and data sharing. Specifically, smart contract deployment consumes the most gas at 2,357,360 units, approximately $49. In the long run, this cost will be amortized, as the smart contract will continue to be used for future similar scenarios. System startup and authority initialization consume 299,231 gas units ($6.2) and 473,516 gas units ($9.8), respectively, with both being one-time costs. Data sharing incurs a cost of 89,420 gas units ($1.80) per file, also a one-time expense. The results indicate that the average gas consumption across these stages is relatively low.

We integrated MADEXA with Caterpillar v1.0² 2

https://github.com/orlenyslp/Caterpillar (accessed on 27 January 2025)