## 3 Proposed Solution
### Proposed Lightweight Accountable Privacy-Preserving (LAPP) Protocol  
There are several security threats to the cloud computing realm that cause damage to the privacy and confidentiality of data. Hence, complete satisfaction of CC is of a paramount significance. In this section, we present our proposed LAPP model, which provides the mechanisms for preserving the data privacy of the CC. This mechanism aims to ensure that the TPA should not expose or steal the CC's private data. Our proposed solution ensures that the TPA does not expose the CC's data contents while auditing the out-sourced data on the cloud servers. This concept is significant as it prevents issues resulting from involving the TPA in the process, whether they are intentional (TPA bribed by other sources) or unintentional (TPA compromised by attackers). Cloud storage is an easy and flexible platform that allows the CC to store their confidential data from their local computers to the servers on the cloud. Nowadays, many CC's store their confidential data in the cloud. However, this platform introduces new concerns and security trials. To overcome these concerns, the TPA is introduced to safeguard the confidential data and restore the confidence of the CC's, but it is also expected that the TPA could be dishonest. The TPA could share confidential information to illegitimate parties for the sake of gaining financial benefits. Therefore, after a comprehensive survey on cloud computing, based on a TPA homogeneity, dynamicity, and privacy-preserving, we concluded the need for a lightweight (in terms of processing and communication cost) solution, that allows the CC to have more control on the auditing process when a TPA is involved. We assume that the CC transmits the data file '\(D_{\text{f}}\)' with data contents '\(D_{\text{c}}\)' given by:  
\[D_{\text{f}}=\{D_{\text{c1}},D_{\text{c2}},D_{\text{c3}},\ldots,D_{\text{cn}}\} \tag{1}\]  
Each data content has physical significance and can be updated by the CC anytime. The CC can decrypt the private data contents. The CC encrypts the data using its private key:  
\[D_{\text{f}}=P_{R}{<}D_{\text{c1}},D_{\text{c2}},D_{\text{c3}},\ldots,D_{\text{ cn}}{>} \tag{2}\]  
Therefore, private data contents are encrypted by  
\[D_{f}=\sum_{i=0}^{T_{pr}}E_{key}[P_{R}(D_{ci})] \tag{3}\]  
where, \(E_{key}\): Encryption key; \(P_{R}(Dci)\): Private data; \(T_{pr}\): complete testing process. In Equation (4), the CC uses its private key to encrypt the data contents. The data contents are further divided into subdata contents '\(\text{Sd}_{\text{c}}\)' which are denoted as:  
\[D_{\text{c}}=\{\text{Sd}_{\text{c1}},\text{Sd}_{\text{c2}},\ldots,\text{Sd}_ {\text{cn}}\} \tag{4}\]  
By adopting the same concept and for the sake of making the data more secure, the subdata contents \(\text{Sd}_{\text{c}}\) are further fragmented into smaller chunks \(\text{C}(\text{Sd}_{\text{c}})\), explained as:  
\[(\text{Sd}_{\text{c}})=\text{C}(\text{Sd}_{\text{c1}}),\text{C}(\text{Sd}_{ \text{c2}}),\ldots,\text{C}(\text{Sd}_{\text{cn}}) \tag{5}\]  
For simplicity, we only focus on single data content in our construct, and a constant number of small chunks for each subdata content. We chose the maximum number of chunks 'M[C(\(\text{Sd}_{\text{c}}\))]'from the list of small chunks as 'C(\(\text{Sd}_{\text{c}}\))n.'Thus, C(Sd\({}_{c}\))n \(<\) M[C(Sd\({}_{c}\))]. Therefore, each subdata content Sd\({}_{c}\) has a maximum of M[C(Sd\({}_{c}\))] data chunks, by setting (Sd\({}_{c}\))k = 0 for (Sd\({}_{c}\)) \(<\) k \(<\) M[C(Sd\({}_{c}\))]. In our case, we are assuming that the size of each data chunk is persistent and equivalent to the security metric '\(\gamma\).' Therefore, the total of subdata contents 'T(Sd\({}_{c}\))' can be calculated by Equation (6):  
\[T(Sd_{c})=S^{*}D_{c}/\{(Sd_{c})\log\gamma\} \tag{6}\]  
where k: compatible data chunks and S: data content size.