# A Blockchain-Based Framework to Enhance Anonymous Services with Accountability Guarantees
## 5 The Proposed Approach
### Interaction between \(U\) and \(Ig\)  
Through this interaction, the Ethereum address \(Add^{U}_{1}\) is associated with the real identity \(ID_{U}\) of \(U\). This is performed without \(IG\) learning anything about \(ID_{U}\). At the end of this phase, \(Add^{U}_{1}\) will result in state \"Confirmed\" and will be used by \(LA\) in the next interaction. This phase proceeds as follows.  
At the start, we assume that \(U\) is registered with an identity provider that knows their real identity \(ID_{U}\).  
In our solution, \(IG\) offers a federated-based authentication scheme [36] possibly relying on different identity providers.  
First, \(U\) authenticates with \(IG\) through the federated scheme by selecting the identity provider that \(U\) is registered to. We denote by \(IP\) such an identity provider.  
As a standard federated authentication, when \(IP\) identifies \(U\), it provides \(IG\) with a signed assertion not containing information associated with \(ID_{U}\). In this assertion, \(IP\) includes \(Keccak256(R||ID_{U})\), where \(R\) is a random value. \(R\) is then associated with \(ID_{U}\) and stored along with \(Keccak256(R||ID_{U})\) by \(IP\).  
Once the authentication is performed, \(U\) provides \(IG\) with \(Add^{U}_{1}\).  
Then, \(IG\) computes a challenge \(ch=Keccak256(Keccak256(R||ID_{U})))\) and generates a transaction \(T_{1}=\langle Add^{IG},Add^{C^{IG}},setChallenge(Add^{U}_{1},ch)\rangle\) intended for the instance \(C^{IG}\) of the smart contract. This transaction invokes the function setChallenge that associates the challenge \(ch\) with the address \(Add^{U}_{1}\) and sets \(Add^{U}_{1}\) in state \"To Confirm\". Finally, \(IG\) sends \(U\) the digest \(Keccak256(R||ID_{U})\).  
After receiving this value, \(U\) uses it as solution to the challenge \(ch\), i.e., \(sol=Keccak256(R||ID_{U})\), and generates the transaction \(T_{2}=\langle Add^{U}_{1},Add^{C^{IG}},solveChallenge(sol)\rangle\).  
This proves to \(IG\) that \(U\) is the owner of \(Add^{U}_{1}\). The function solveChallenge sets \(Add^{U}_{1}\) in state \"Confirmed\".  
Observe that the random \(R\) acts as a salt for the hash function \(Keccak256\). This way, \(ID_{U}\) cannot be reversed by \(sol\), even when performing dictionary attacks by testing all of the possible real identities. On the other hand, if the identity provider discloses \(R\) to \(LA\), the association \(ID_{U}-Add^{U}_{1}\) can be verified through the instance \(C^{IG}\) of the smart contract.  
Finally, \(IG\) verifies the state \"Confirmed\" of the address \(Add^{U}_{1}\) and locally stores the tuple \(\langle Add^{U}_{1},Keccak256(R||ID_{U})\rangle\) to provide \(LA\) if needed.  
The above steps are summarized in the sequence diagram of Figure 1.  
The next two interactions are between \(U\) and \(LA\) and between \(U\) and \(SP\), respectively. They have to be performed in anonymous form without any authentication of \(U\). Clearly, to avoid IP geolocation, anonymous communication protocols such as Tor [37] and VPNs [38] can be adopted. We do not treat this aspect in detail since it is out of the scope of this paper.