# A Blockchain-Based Framework to Enhance Anonymous Services with Accountability Guarantees
## 7 Security Analysis  
In this section, we discuss the security guarantees offered by our solution. We analyze the following two _compromises_ possibly affecting our protocol. * C1: an adversary, not including the collaboration of \(IP\), \(SP\), and \(LA\) simultaneously, is able to discover the link between the username and the real identity of a user. * C2: an adversary is able to forge a fake link, publicly verifiable on the blockchain, between the username and the real identity of a user. Regarding C1, it represents a privacy compromise. As already discussed, our protocol allows for the de-anonymization of a username only when \(IP\), \(SP\), and \(LA\) collaborate. In the other cases, the real identity-username link should not be disclosed to anyone. Concerning C2, we refer to attacks in which the adversary attempts to associate a username \(user_{U}\) of a user \(U\) with an identity \(ID_{\Omega}\) of another user \(\vec{U}\) to falsely accuse the latter of an illegal behavior performed by \(U\). Regarding the trust required to the involved actors, we only make the following _assumption_. * A: \(IP\) is _honest but curious_, in the sense that it legally performs the steps of the protocols but attempts to cause the two compromises C1 and C2. In other words, A requires that \(IP\) does not swap the real identities of two users. This is a standard assumption of all of the identity management systems. Indeed, the role of an identity provider is just to certify the real identity of users. However, in our threat model, we allow \(IP\) to disclose the identities that it knows and show that this does not affect the privacy of the users. No assumption is made on \(IG\), \(LA\), and \(SP\). They can be considered fully malicious with respect to the considered compromises. Now, we discuss in detail the two compromises and show how our protocol prevents them. Compromise C1. This compromise occurs when the adversary identifies the real identity \(ID_{U}\) of a user \(U\) associated with a given username \(user_{U}\). Since external users just see the transactions originating from some Ethereum addresses on the blockchain, we consider \(SP\), \(IG\), \(IP\), and \(LA\) as adversaries. They can access the blockchain too; then, they have at least the knowledge of all external users. By excluding the collaboration of \(IP\), \(SP\), and \(LA\) (by hypothesis), we consider the collaboration of the three tuples \((IP,IG,LA)\), \((IG,LA,SP)\), and \((IP,IG,SP)\) as an adversary and show that C1 does not occur. We start by considering the collaboration of \(IP\), \(IG\), and \(LA\). Given the user \(U\), \(IP\) knows the real identity \(ID_{U}\) of \(U\). Through the collaboration with \(IG\), \(IP\) links \(ID_{U}\) with the Ethereum address \(Add_{2}^{U}\). Then, through the collaboration with \(LA\), \(IP\) can discover the Ethereum address \(Add_{2}^{U}\) linked with \(Add_{1}^{U}\). However, no information about the username \(user_{U}\) of \(U\) is available to \(IP\), \(IG\), and \(LA\). Indeed, the only public information containing \(user_{U}\) (in obfuscated form) is the transaction \(T_{6}\) generated by \(U\) with the address \(Add_{2}^{U}\). This transaction contains the solution to the challenge \(sol=Keccak256(R\|user_{U})\). Without\(\hat{R}\) (maintained by \(SP\)), it is not possible to also reverse the hash function Keccak256 through dictionary attacks on all of the possible usernames. A similar reasoning applies when considering the collaboration of \(IG\), \(LA\), and \(SP\) as an adversary. Their collaboration just allows for the linkage of \(Add^{U}_{1}\), \(Add^{U}_{2}\), and \(user_{U}\), but no information is available to \(IG\), \(LA\), and \(SP\) about \(ID_{U}\). Indeed, the only public information containing \(ID_{U}\) (in obfuscated form) is the transaction \(T_{2}\) generated by \(U\) with the address \(Add^{U}_{1}\). This transaction contains the solution to the challenge \(sol=Keccak256(R\|ID_{U})\). Without \(R\) (maintained by \(IP\)), it is not possible to reverse the hash function Keccak256.