# A Blockchain-Based Framework to Enhance Anonymous Services with Accountability Guarantees
## 7 Security Analysis
\(Keccak256(R\|ID_{U})\) is the only information received by \(IG\) from \(IP\), since the assertion does not contain any information linked to \(ID_{U}\). Finally, consider the adversary composed of the collaboration of \(IP\), \(IG\), and \(SP\). \(IP\), through \(IG\), knows the mapping \(Add^{U}_{1}-ID_{U}\), whereas \(SP\) maintains the mapping \(Add^{U}_{2}-user_{U}\). However, without the mapping \(Add^{U}_{1}-Add^{U}_{2}\) (maintained by \(LA\)), they are not able to link \(ID_{U}\) with \(user_{U}\). The only public information containing this mapping (in obfuscated form) is the transaction \(T_{4}\) generated by \(U\). This contains the solution to the challenge \(sol=Keccak256(R\|Add^{U}_{1}\|Add^{U}_{2}\|\sigma)\). Again, without \(\bar{R}\) and \(\sigma\) (maintained by \(LA\)), it is not possible to reverse the hash function Keccak256. Compromise C2. This compromise occurs when an adversary forges a valid link (publicly verifiable on the blockchain) between the real identity \(ID_{U}\) of a user \(\bar{U}\) and a username \(user_{U}\) of a different user \(U\). To forge a valid link, \(ID_{Q}\) has to be present (in obfuscated form) in a transaction intended for the instance \(C^{IG}\). By Assumption A, \(IP\) legally performs the steps of the protocol and does not provide a tampered digest \(Keccak256(R\|\bar{U})\) associated with the real identity of a user \(\bar{U}\) not requiring the anonymous service. Therefore, we consider \(\bar{U}\) as a user with Ethereum address \(Add^{\Omega}_{1}\) such that the link between \(ID_{\bar{U}}\) and \(Add^{\Omega}_{1}\) can be verified through the instance \(C^{IG}\) and the random \(R\) provided by \(IP\). To perform the compromise C2, the attacker has two possibilities. The first possibility is to forge a fake link between \(Add^{\Omega}_{1}\) and \(Add^{U}_{2}\) verifiable through the instance \(C^{LA}\) such that \(Add^{U}_{2}\) is associated with \(user_{U}\) by \(SP\). To achieve this, the blockchain would have a transaction originated by \(Add^{LA}\) including the challenge \(ch=Keccak256(Keccak256(R\|Add^{\Omega}_{1}\|\)  
\(Add^{U}_{1}\|\sigma))\), where \(\sigma\) is a signature obtained from the private key associated with the address \(Add^{\Omega}_{1}\). Moreover, another transaction originated by \(Add^{U}_{2}\), including the solution to the challenge, would be present on the blockchain. Even though the attacker coincides with the collaboration of \(LA\) and \(U\) (the only parties that can generate these two transactions), it is not able to forge the signature \(\sigma\) without the collaboration of \(\bar{U}\). Therefore, this first case cannot occur. The second possibility is that a valid link between \(Add^{\Omega}_{1}\) and \(Add^{\Omega}_{2}\) (both belonging to \(\Omega\)) exists and the attacker attempts to forge a fake link between \(Add^{\Omega}_{2}\) and \(user_{U}\). However, similar to the previous case, in order to accomplish this, the blockchain would have a transaction originated by \(Add^{SP}\), including the challenge \(ch=Keccak256(Keccak256(\hat{R}\|user_{U}))\), and a transaction originated by \(Add^{\Omega}_{2}\), including the solution to the challenge. Even though the attacker coincides with the collaboration of \(SP\) and \(U\), it is able to forge the first transaction but not the second. Therefore, this possibility also cannot occur. This concludes the security analysis.