## 3 Proposed Solution
### System Model  
In this section, we describe our model's security requirements. The proposed protocol is constructed in a cloud computing environment. To describe the actual requirements, we start with discussing the system model that audits for the CC and makes the TPA accountable in front of the CC. As depicted in Figure 1, the system model supports three entities (TPA, CSP, and CC).  
**Cloud Client:** It is the main entity in our proposed approach, which is composed of cloud users, devices, and customers. The privacy of the client is of a paramount significance along with the utilization of the limited storage and computing resources efficiently. The CC can request the TPA to audit its data while having a lack of trust in the TPA. Hence, the CSP issues a secret key and a random number to the CC and the TPA explained in the arrows 1a and 1b, respectively. Thus, the CC sends a key update request to the TPA for auditing process referred in (2). Furthermore, CC wants to confirm whether the TPA possesses a similar secret key and a random number, as CC sends a message to TPA presented as an audit request message as shown in (4). If the similar key and random number are found, then the TPA is considered as reliable; otherwise, the TPA is considered illegitimate and sharing the private information of the CC with someone else for personal gains.
* **Third Party Auditor:** It is considered as a highly trusted party. The TPA has a better capability of storage and computation. The performance of the TPAs is examined to safeguard their impartiality and fairness. Moreover, TPAs use their expertise to audit the data and provide the auditing result as the confirmation or the negation of the deceitful role of the CSP. However, the role of the TPA could be malicious, and the CCs will not have enough trust in him. Thus, the CC wants to ensure that the TPA is not playing a malicious role during the auditing process, as explained in this system model. Once the TPA receives the auditing request from the CC, the TPA establishes the audit initialization process with the CSP referred in message (3) to complete the auditing process. Furthermore, the TPA is also responsible for updating its key with the CC. In response, the TPA sends the key update response message as referred in (5).
* **Cloud Service Provider:** It involves several distributed servers that offer various services to CCs. The CSP has unlimited resources of computation and storage. The CC enjoys cloud services delivered via the Internet. According to our proposed approach, the CSP is assumed as trustworthy and could be considered deceitful. Thus, the CSP has been given the responsibility to issue the secret key and random number for both the TPA and the CC. Besides, this method of issuing the secret key and random number helps the CC to check the role of the TPA. The CSP is  
Figure 1: System model of the lightweight accountable privacy-preserving (LAPP) protocol.  
responsible for forwarding the auditing results to the TPA, as referred in (6). The CSP interacts with the TPA and CCs and initially distributes its identity '\(CSP_{id}^{\prime}\) and the TPA and CCs record this information. In response, the CC and the TPA can use \(CSP_{id}\) to calculate the secret key as follows:  
For \(i\in\{0,1\}\), it calculates two hash values in which \(T_{i}=L_{1}(CSP_{id},\ i),\ T_{i}\in O_{1}\). The output gives a secret key as: \(S_{i}=vT_{i}\).