# Secure and Privacy-Aware Blockchain Design: Requirements, Challenges and Solutions
## 3 Privacy and Security Requirements for Blockchain
However, ring signature involves a TTP to manage user identities and the cost of both generation and verification of ring signature increases due to digital certificates [37]. Identity-based ring signature overcomes these issues and enhances users' privacy. It also prevents against full key exposure attack [65]. **Zero knowledge proof (ZKP)** allows one entity (the prover) to prove to another entity (the verifier), that a given value is true, without disclosing any information apart from that the proof itself is correct. Zk-SNARKs (Zero-Knowledge Succinct Non-Interactive Argument of Knowledge) is a ZKP that allows proving correct computation of information without any interaction between both parties (prover and verifier). ZKP-based solutions are particularly interesting for data integrity and authentication without revealing anything as they provide proof of a statement without revealing that particular statement. They also preserve anonymity for sensitive data and do not rely on TTP. However, they are computationally quite intensive as compared to other solutions to validate and generate proofs [5]. **Mix networks** take input data from multiple users and forward them to the next destination according to a different time frame. They basically randomize the order of the transaction data, so that it is harder for an attacker to trace end-to-end communication. However, the mix network becomes a TTP and has latency issues as compared to other mechanisms. One example of blockchain implementation is coinJoin [66]. On the other hand, onion routing and tor routing enable anonymous communication to provide protection on user's data without any TTPs. **K-anonymity** concept was introduced in 1998 to prevent identity disclosure [67]. It preserves the privacy of sensitive information by hiding a user's identity in a given data set [68]. It enforces integrity on data without any TTPs. However, it is insufficient to protect attribute privacy in transactional data due to lack of diversity in the data. **L-diversity** complements k-anonymity. It augments the diversity of users' sensitive information in the data set to achieve higher privacy. It effectively protects the user's identity and guarantees the confidentiality of the data [50,51]. **T-closeness** ensures better protection of identity privacy and transaction data privacy than existing data anonymization techniques [52]. It enforces privacy without the involvement of TTPs [52]. The principle of t-closeness is simple and easy to understand as it enforces a maximum distance between sensitive attributes in a data set to ensure data protection. **Identity-based encryption** is a technique of public-key encryption that allows a user to generate a public key from its unique identity (e.g., IP address or email address) [69]. This scheme may involve a TTP such as a private key generation algorithm to derive corresponding private keys. It protects user's identity and guarantees the integrity of the message. It entails a longer public key, message size, and memory overhead than attribute-based encryption. **Attribute-based encryption** derives from identity-based encryption [70] in which only a user can decrypt the ciphertext if the user attributes (e.g., hometown) satisfy the access rules defined by the owner of the system. It enforces confidentiality on data and fulfills transaction data requirements. **Symmetric key cryptography** is efficient to enforce integrity, confidentiality, and non-repudiation on data without TTPs. Symmetric key cryptography refers to use the same key for encryption and decryption of messages to guarantee that only authorized users do so. Key should be shared through a key exchange protocol to protect further communications. There are several symmetric key algorithms such as DES, Blowfish, and AES [71]. In our context, the main drawbacks of symmetric cryptography are communication overhead and the required key exchange protocol [58, 59].