# Anonymous Access System with Limited Number of Uses in a Trustless Environment
## 5 Security Analysis
### Design Decisions  
I confirm that starting with step 0 indicates that this step is taken only once at the beginning and not repeated in subsequent iterations.  
Three different choices to modify Formula (3) are presented in order to introduce \(n\) and \(i\), denoting the maximum number of uses and the increment value, respectively, in the calculation of the NI-Sconrrr ZKP.  
The first option to introduce \(i\) in the computation of \(t_{i}\) is to take \(t\) and use it to compute each \(t_{i}\) by multiplying it by \(i\). Formula (3) becomes \(t_{i}=i\cdot t=i\cdot(H(id_{\mathcal{U}})\cdot sk^{\prime}_{\mathcal{U}}+r^{ \prime}),\forall i\in[0\ldots n]\). The problem in this case is that when \(t_{1}\) is known, it is easy to force \(t_{2}\) by calculating \(t_{1}+t_{1}\), and so on with \(t_{3},\cdots,t_{n}\).  
The second option to introduce \(i\) in the computation of \(t_{i}\) is to take \(t\) and multiply by \(i\) the term of \(t\) where \(r^{\prime}\) appears. Formula (3) becomes \(t_{i}=h^{\prime}_{i}\cdot sk^{\prime}_{\mathcal{U}}+i\cdot r^{\prime},\forall i \in[0\ldots n]\). Note that, in this case  
\[t_{i+1} =(i+2)\cdot R^{\prime}+pk^{\prime}_{\mathcal{U}}\cdot H(id_{ \mathcal{U}})\] \[=R^{\prime}+(i+1)\cdot R^{\prime}+pk^{\prime}_{\mathcal{U}}\cdot H (id_{\mathcal{U}})\] \[=R^{\prime}+t_{i},\forall i\in[0\ldots n]\]  
the problem is knowing \(R^{\prime}\) and adding it to \(t_{i}\), anyone can then force \(t_{i+1}\) and so on.  
The third and final choice involves multiplying the term that contains the private key, Formula (3) becomes \(t_{i}=R^{\prime}+i\cdot pk^{\prime}_{\mathcal{U}}\cdot H(id_{\mathcal{U}})\). Nobody can force \(t_{i}\) without knowing the private key. This is the method chosen for this study.  
Once the option has been chosen on how to introduce \(n\) and \(i\) into the ZKP, a problem appears when this value is equal to zero. The private key would be multiplied by zero and be rendered null. Therefore, in the computation of \(t_{i}\), the multiplication factor becomes \(i+1\) to avoid multiplication by 0.  
All threats to the current protocol are based on the robustness of \(ZKP\); therefore, this robustness has to be proved. From Formula (8), the proof is \((R^{\prime},t_{i})\) with public values \(i\), \(id_{\mathcal{U}}\), and private \(sk^{\prime}_{\mathcal{U}}\) is calculated as:  
\[R^{\prime} =r^{\prime}\cdot P\] \[t_{i} =(i+1)\cdot H(id_{\mathcal{U}})\cdot sk^{\prime}_{\mathcal{U}}+r^ {\prime}\]  
As long as \(sk^{\prime}_{\mathcal{U}}\), and \(r^{\prime}\) are private to \(\mathcal{U}\), nobody except \(\mathcal{U}\), can forge a ZKP. Because of the discrete logarithm problem (DLP) in additive groups, it is not feasible to compute \(sk^{\prime}_{\mathcal{U}}\) nor \(r^{\prime}\) from \(pk^{\prime}_{\mathcal{U}}\) and \(R^{\prime}\), respectively.  
With these results, the robustness of the protocol is proven in the presence of threats found. The main threats are described as:  
* The use of an arbitrary \(id_{\mathcal{U}}\) where a malicious \(\mathcal{U}\) tries to forge a counter without the authentication creation phase.
* A misbehaviour of \(\mathcal{SP}\) in the counter creation phase that attempts to create a counter with an incorrect maximum usage value.
* A replay attack performed by \(\mathcal{SP}\).
* A misbehaviour of \(\mathcal{SP}\) trying to forge an invalid \(t_{i}\).