## 4 Threat Model  
We illustrate the threat model as a game between attacker \(\mathcal{A}\) and challenger \(\mathcal{C}\)[39]. The model consists of the following six steps:  
1. **Initialization:** The attacker \(\mathcal{A}\) chooses \(a_{p}=(\mathcal{M}^{*},\rho^{*})\) and the challenge-revocation attribute \(u^{*}\). Here, \(\mathcal{M}^{*}\) is the matrix, i.e., \(\mathcal{M}^{*}=l^{*}\times n^{*},n^{*}\leq q\). The \(a_{p}\) is the access policy. The \(l\) in the matrix \(\mathcal{M}^{*}\) is the number of the attributes contained in the access policy while \(n\) reflects the amount of computation required for secret reconstruction. The \(\rho\) is the function that maps each row of \(m\) to an attribute \(\rho\). 2. **Setup:** The \(\mathcal{C}\) executes the \(GlobalSetup(\lambda)\to GP\) to attain the global parameters (\(GP\)) and offers the \(GP\) to the opponent \(\mathcal{A}\). \(AID\) represent the collection of \(AAs\). 3. **Phase 1:** The opponent \(\mathcal{A}\) wants to corrupt the \(AID_{C}\subset AID\) authorities, so the remaining authorities (\(AID-AID_{C}\)) are not corrupted. The opponent \(\mathcal{A}\) flags the subsequent queries. \(\mathcal{A}\) demands the public keys of its authority \(\{APK_{aid}\}_{aid\in(AID-AID_{C})}\) for noncorrupt authorities from \(\mathcal{C}\). For corrupt authorities \(AID_{C}\), \(\mathcal{A}\) can create the corresponding \(\{APK_{aid}\}_{aid\in AID_{C}}\) by himself. Hence, \(\mathcal{A}\) uses secret key queries by using \((uid,S_{aid,aid})\) against \(\mathcal{C}\) by using a secret key-generation \(SKGen\) algorithm. Here, \(gid\) indicates the end user's identity, and \(Suid,aid\) indicates a set of \(aid\) attributes. \(\mathcal{A}\) transmits messages \(m_{0}\), \(m_{1}\), equal in size and in the range of \(\left\{\left(\mathcal{M}^{*}_{1},\rho^{*}_{1}\right),\ldots,\left(\mathcal{M }^{*}_{q},\rho^{*}_{q}\right)\right\}\), to \(\mathcal{C}\). Thus, \(\mathcal{A}\) provides an updated secret key query by sending \((uid,S_{aid,aid})\) and a revoked attribute \(u\). Therefore, \(\mathcal{A}\) delivers \(UKeyGen\) Query by considering \(m_{0}\), \(m_{1}\) and \(\left(\mathcal{M}^{*}_{i},\rho^{*}_{i}\right)\), \(\left(\mathcal{M}^{*}_{j},\rho^{*}_{j}\right)\)\(\forall i\
eq j\&i,j\in[1,q]\). 4. **Challenge** * \(\mathcal{C}\) chooses random bits, i.e., \(b\in\{0,1\}\), and responds to the attacker's query. * In all authentic authorities \(aid\in(AID-AID_{C})\), \(\mathcal{C}\) executes \(AASetup(aid)\rightarrow(APK_{aid},ASK_{aid})\) to obtain public and secret keys. Therefore, \(\mathcal{C}\) deliver the \(APK_{aid}\) to \(\mathcal{A}\). * For \(x\in S_{aid,aid}\) and \(aid\in(AID-AID_{C})\), \(\mathcal{C}\) executes \(\mathrm{AttrKeyGen}\) and transmits \(SK_{s,aid,aid}\) to \(\mathcal{A}\). Consequently, \(\mathcal{C}\) computes \(Attr-GroupKey-Gen.(aid,x)\rightarrow(KEK_{TREE_{x}},AGK)\) and transmits \(PATH_{uid}\) to the end-user \(uid\), having \(x\in S_{uid,aid}\). Note that \(PATH_{uid}\) is \(KEK_{TREE_{x}}\), as shown in Figure 3.  
Figure 2: Workflow of our proposed scheme. \(\mathcal{C}\) encrypts \(m_{b}\) for \(\left(\mathcal{M}_{1}^{*},p_{1}^{*}\right),\ldots,\left(\mathcal{M}_{q}^{*},p_{q}^ {*}\right)\) and sends ciphertexts \(\left\{\mathcal{CT}_{1}^{\prime},\ldots,\mathcal{CT}_{q}^{\prime}\right\}\) to \(\mathcal{A}\). * For the inputs \(\left(uid,S_{uid,uid},u\right)\), \(\mathcal{C}\) provides the \(SecretKey\) query on \(\left(uid,S_{uid,uid}\right)\) and creates the secret key \(SKs_{uid,aid}\). As a result, \(\mathcal{C}\) calculates the KeyUpdate, i.e., \(SK_{s,uid,aid}^{\prime}\), and transmits it to \(\mathcal{A}\). * For the challenging messages \(m_{0}\), \(m_{1}\) and corresponding access policies \(\left(\mathcal{M}_{i}^{*},p_{i}^{*}\right)\), \(\left(\mathcal{M}_{j}^{*},p_{j}^{*}\right)\), \(\mathcal{C}\) computes \(Encrypt\left(m_{b},\left(\mathcal{M}_{i}^{*},p_{i}^{*}\right),GP,APK_{aid}\right)\).