# Blockchain for Doping Control Applications in Sports: A Conceptual Approach
## 3 Blockchain-Based Approach for the AD Domain
### Design of a Decentralized Anti-Doping Ecosystem
#### 3.3.5 Security and Privacy Aspects  
HLF is a platform designed to enable secure collaboration between organizations [87]. In the AD scenario, all participating organizations have social responsibilities towards the community [32]; therefore, it is unlikely that participants would engage in malicious behavior and put their reputations in risk. Nevertheless, threats can potentially occur, which makes important a work for identification and definition of mitigation strategies [87]. The following aspects are listed:  
Consensus and Endorsements of Transactions: The most common consensus threat for public platforms, 51% of attacks, is not a considerable issue for permissioned platforms [1; 9; 10]. In the context of HLF, the current consensus process only utilizes Crash Fault Tolerant (CFT) algorithms, where zero tolerance against malicious actors is established [87]. Nevertheless, monitoring key indicators, such as the latency of transactions and leadership elections of transactions' endorsers [14; 74], can be a strategy for the early detection of malicious behavior [87]. If only authorized participants access the ledger, the adversary model considers the attacker is a member of the channel [87; 88]. When a user proposes a transaction, preferred endorsers can be chosen; therefore, the identities of the chosen endorsers are disclosed to participants of the channel, which is because in the current HLF version, Idemix cannot yet be used for endorsement of a SC transaction or for approval of SC definitions [86]. Assuming the existence of an adversary, a selective denial of service (DoS) attack can be executed by the adversary, in an attempt to modify the content of transactions, which can be a treat for any distributed system [87; 89]. A motivator for the adversary would be to defeat the endorsement policy requirement embedded in the SC [87; 89]. As an example, consider an adversary attacks a certain number of endorsement responses to the user. If a user proposes a transaction and sends it to N endorsers and the policy within the SC requires at least (N-4) endorsements, if the attacker dumps or modifies five responses, only (N-5) endorsed responses are sent back to the user, causing the transaction proposal to fail. Repeated DoS attacks can also degrade the overall network efficiency [87]. A risk mitigation strategy for DoS attacks is the proactive collection of performance metrics [87]. The wormhole attack is another threat to transaction's endorsements [89]. Within a channel, a group of identities can be separated from the rest and every member has access to the ledger. If a single member acts maliciously, colluding with an adversary outside the channel, the attack can be executed. In this case, a virtual private network (VPN) with the outer adversary leaks internal information from the consortium without any knowledge of honest members [89]. Two strategies for mitigation are proposed. The first strategy focuses on anonymizing the endorsers to protect against DoS attacks. This is achievable by two different techniques. The first considers the randomization of endorsers by use of Verifiable Random Functions (VRF) implemented in the SCs. The second proposes the pseudonymization of endorsers to protect against wormhole attacks. To achieve this, the anonymization of transactions within a channel is needed. The sender is anonymized in a first step and the receiver in a second step [89]. Overall, test results suggest that immunity against DoS and wormhole attacks were achieved, with a tradeoff on the network efficiency [89]. Smart Contracts: SCs must be designed with precise logic that encapsulate the defined business process and mitigate common bugs and errors in handling nondeterminism and concurrency [87]. Additionally, best practices of software lifecycle management must be embedded in the governance policies for the platform, as proposed in Section 3.3.1, where SCs can only be deployed after approval by all SC executors.