# A Blockchain-Based Framework to Enhance Anonymous Services with Accountability Guarantees
## 5 The Proposed Approach
### Interaction between \(U\) and \(La\)  
Through this interaction, \(LA\) links \(Add^{U}_{1}\) and \(Add^{U}_{2}\) without knowing the real identity of \(U\).  
First, \(U\) (anonymously) contacts \(LA\) and provides it with \(Add^{U}_{1}\). \(LA\) needs to verify two conditions. The first is that \(Add^{U}_{1}\) is an Ethereum address associated with a real identity. However, \(LA\) does not need to know such a real identity. This condition can be easily verified by checking that \(Add^{U}_{1}\) is in state \"Confirmed\" on \(C^{IG}\). The second condition is that \(Add^{U}_{1}\) really belongs to the user contacting \(LA\). This is carried out to avoid a user trying to impersonate another user already authenticated with \(IG\).  
Even though the challenge-response mechanism used in the previous section allows this task, we should not use it. Indeed, it requires some interactions through the blockchain that would disclose the linkage \(Add^{U}_{1}-Add^{U}_{2}\) to anyone.  
Therefore, to verify the second condition, \(LA\) generates a random \(R^{\prime}\) and provides \(U\) with it. \(U\) signs \(R^{\prime}\) with the private key associated with \(Add^{U}_{1}\), obtaining a signature \(\sigma\). Finally, \(U\) replies to \(LA\) with the pair \((\sigma,Add^{U}_{2})\).  
Starting from \(\sigma\) and \(R^{\prime}\), \(LA\) verifies the signature and retrieves the public key associated with \(Add^{U}_{1}\). Then, as explained in Section 2, \(LA\) computes the hash function Keccak256 on this public key and takes the last 20 bytes to obtain the address \(\overline{Add^{U}_{1}}\). If \(\overline{Add^{U}_{1}}=Add^{U}_{1}\), then \(LA\) is sure that the user contacting it owns \(Add^{U}_{1}\).  
At this point, \(LA\) needs to verify that \(U\) owns \(Add^{U}_{2}\). The same challenge-response mechanism used with \(IG\) is adopted. This way, \(Add^{U}_{2}\) will move to the state \"Confirmed\" on the instance \(C^{LA}\) and will be used by \(SP\) in the next interaction with \(U\).  
In detail, \(LA\) picks a random \(\bar{R}\) and generates a challenge \(ch=Keccak256(Keccak256(\bar{R}\|Add^{U}_{1}\|Add^{U}_{2}\|\sigma))\).  
Then, \(LA\) generates a transaction \(T_{3}=(Add^{LA},\ Add^{CLA},setChallenge(Add^{U}_{2},ch))\). This transaction invokes the function setChallenge that associates the challenge \(ch\) with the address \(Add^{U}_{2}\) and sets \(Add^{U}_{2}\) in state \"To Confirm\". The random \(\bar{R}\) is provided to \(U\).  
\(U\) computes the solution of the challenge as \(sol=Keccak256(\bar{R}\|Add^{U}_{1}\|Add^{U}_{2}\|\sigma)\) and generates the transaction \(T_{4}=\langle Add^{U}_{2},Add^{CLA},solveChallenge(sol)\rangle\). This proves to \(LA\) that \(U\) is the owner of \(Add^{U}_{2}\), which will be set in state \"Confirmed\" by the function solveChallenge.  
Finally, \(LA\) verifies the state \"Confirmed\" of the address \(Add^{U}_{2}\) and locally stores the tuple \(\langle Add^{U}_{1},Add^{U}_{2},\bar{R},\sigma\rangle\).  
The above steps are summarized in the sequence diagram of Figure 2.  
Figure 1: Sequence diagram of the interaction between \(U\) and \(IG\).