## 3 Proposed Solution
### Proposed Lightweight Accountable Privacy-Preserving (LAPP) Protocol
#### 3.2.2 Key Update  
Each generated key requires updates. Without the key update, there is a chance of a compromise of the generated key.  
**Theorem 1**.: _The proposed agreement is evident for CCs._  
Proof.: During the KeyGen process, CCs can examine the legitimacy of the key updates with the help of open keys and parameters from the CSP. In other words, after the CSP makes the clients' secret keys up to date, using open keys and parameters, the clients can check if the CSP's secured keys have been refreshed. Based on this, the proposed plan supports the key updates' obviousness for customers.  
**Theorem 2**.: _The Proposed agreement is responsible for the period of key updates._  
Proof.: During the key updates, the hash estimation of the encoded key is built by a certain counter estimation Ti. Hence, from the above presentation of key updates, the actual counter is a calculation of the prior encoded key and counter. Therefore, in the process of true key generation, customers can check the present counter against the past counter. If the present counter is equal or less than the prior counter, it can be inferred that the prior key has not been refreshed by the TPA.  
**Hypothesis 1**.: _The proposed convention is correct if all parameters in the proposed convention are created, processed, and transmitted accurately._  
**Proof**. During the key updates, clients can check whether their secret keys have been refreshed by the CSP. As referenced in the KeyGen period, if the condition meets \(\beta(F,\ \lambda)=\beta(rq,\ w)\), then the client can be sure that the secret key has been refreshed. Based on the bilinearity of the bilinear pairing, it is possible to elaborate the right side of the equation as \(\beta(rq,\ w)=\beta\left(F^{t},\ w\right)=\beta\left(F,\ w^{t}\right)=\beta(F,\ \lambda)\). In other words, the outcomes are equivalent on the two sides of the equation.  
In the reviewing procedure of the proposed agreement, we can evaluate the rightness of the data storage in the cloud through registration, whether the produced evidence by the cloud is solid. From the definition of the ProofGen, the verification equation is built by the label confirmation, the data evidence, and the secret key sets. The left side of the mathematical checking statement can be expressed as:  
\[\beta(r_{a},\ rw_{a})=\beta\left(\left(f^{p}.\prod v_{j}^{\mu_{j}}\right)^{ \frac{1}{2}},\ F^{d_{j}}\right)=\beta\left(f^{p}.\prod v_{j}^{\mu_{j}},\ F \right)=\beta\left(f^{p}.\mu_{j}^{\Sigma\,\
u_{j}},\ F\right) \tag{9}\]  
Correspondingly, the right-hand side of the mathematical checking statement can be expounded as follows:  
\[\beta(lw,\ rw)\cdot T_{U}=\beta(f,\ F^{n})\cdot\prod\beta\left(U_{j}^{\mu_{j} },\ F^{\mu_{j}}\right)=\beta(f,\ F^{n})\cdot\prod\beta\left(\
u_{j},\ F^{\mu_{ j}}\right) \tag{10}\]  
\[\beta(lw,\ rw)\cdot T_{U}=\beta(f,\ F^{n})\cdot\beta\left(\
u_{j},\ F\right)^{ \Sigma\,\mu_{j}}=\beta(f,\ F^{n})\cdot\beta\left(\
u_{j}^{\Sigma\,\mu_{j}},\ F \right)=\beta\left(f^{m}.\
u_{j}^{\Sigma\,\mu_{j}},\ F\right)\]  
Subsequently, the accuracy of the evaluating stage can be verified. From the above verification process, it can be considered that key updates and the capacity inspecting are correct. Based on this, the proposed agreement is considered as correct.