## 3 Proposed Solution
### Proposed Lightweight Accountable Privacy-Preserving (LAPP) Protocol
#### 3.2.1 Key Generation  
Since we have subdivided the data into multiple subchunks, to reassemble the data correctly, we are issuing labels for every subchunk created. The key generation process involves the security parameter '\(\beta\)' that is based on two random numbers \(\gamma_{1}\) and \(\gamma_{2}\); for the secret hash key (for the data) and secret label key (for the labels), respectively. It can be expressed as \(\gamma_{1}\), \(\gamma_{2}\in Z_{\rm p}\). Thus, the secret label key output 'Sk\({}_{0}\)' can be determined as:  
\[Sk_{0}=z_{2}\gamma^{2}\in Z_{2} \tag{8}\]  
Each generated key requires a signature that should be calculated while the end user gets the sent file. File X can be split into m chunks: \(A\rightarrow\{c_{1},c_{2},\,\ldots,\,c_{n-1},c_{n}\}\), \(n\in K^{*}\). The TPA can compute the pair of signatures \(\{S_{k},T_{k}\}\) for every file chunk \(c_{k}\):Calculating two hash values as: \(T_{g}=L_{2}(\mathit{filename})\), \(x_{k}=L_{3}(q_{k},\mathit{uuid},\mathit{filename})\), \(q_{k}\)--is the pointer of the chunk \(c_{k}\) in the file \(X\), \(1\leq k\leq n\).
* Starting an item of [PERSON]'s (\(r\), \(d\)) secret sharing \(\mathcal{JNS}_{(r,\,d)}\) with \(y(x)=T_{\delta}+q_{1}x+\ldots+q_{r-1}x^{r-1}\) and calculates \(r-1\) point \(up=\left\{(e_{1},y(e_{1})),\,(e_{2},y(e_{2})),\,\ldots,\,(e_{r-1},y(e_{r-1})) |e_{l}\in\{0,1\}^{*}\right\}\), \(up\) is a universal parameter. After that algorithm calculates \(e^{\prime}=L_{4}(\mathit{uuid}),\;o=y(e^{\prime}),enc=\frac{e^{\prime}\|y(e^{ \prime})\|}{S_{0}\|S_{1}}\).
* Computing \(n\) random variables as: \(v_{k}\in K_{t},\;1\leq k\leq n\), then calculates \(R_{k}=v_{k}T\).  
The key-generation process is performed by the CSP; And the authentication is initiated by the CC, as described in Algorithm 1.  
```
1.Initialization: (\(CS_{p}\): Cloud service provider; \(S_{k}\): Secret key; \(C_{c}\): Cloud Client; \(Rn\): Random number; \(T_{pa}\): Third-party auditor; \(C_{s}\): Cloud Server; \(K_{req}\): Key Request; \(Vc\): Valid Client)
2.Input: (\(K_{req}\))
3.Output: (\(S_{k}\); \(Rn\))
4. Set \(S_{k}\) & \(Rn\in C_{s}\)
5. \(C_{c}\) makes \(K_{req}\)
6. Check \(CS_{p}\) into \(C_{s}\)
7.If\(C_{c}=V_{c}\) then
8.\(CS_{p}\) releases \(S_{k}\)& \(Rn\) to \(C_{c}\) & \(T_{pa}\)
9.ElseifDenied \(K_{req}\) to \(C_{c}\)
10.endif
11.End-Elseif
```  
**Algorithm 1** Key-Generation and authentication process.  
Algorithm 1 describes the key-generation process when the CC requires an audit. In this algorithm, the CSP is considered as a reliable and trustworthy entity. In step 1, the initialization of variables is given. In steps 2 and 3, the input and the output processes are defined, respectively. In step 4, the secret key and random numbers are stored for each client on the cloud server that is assigned to the CC based on the given request. Step 5 shows the key request process done by the CC when intending to audit. Once the request is received by the CSP; it starts checking the validity of the CC into the cloud server shown in steps 6-7. If the CC is found as a valid client, the CSP releases the secret key and a random number to the CC and the TPA as described in step 8. If the CC is not registered with a given cloud server, then the request for obtaining the keys is denied.