Privacy-First Paradigm for Dynamic Consent Management Systems: Empowering Data Subjects through Decentralized Data Controllers and Privacy-Preserving Techniques

Abstract

This paper explicitly focuses on utilizing blockchain technology in dynamic consent management systems with privacy considerations. While blockchain offers improved security, the potential impact on entities’ privacy must be considered. Through a critical investigation of available contributions to the present state of the art of blockchain-based dynamic consent management systems, we highlight the limitations of plaintext storage and the processing of subject data/consent on the blockchain, which can compromise privacy. We stress the significance of keeping encrypted subject data/consent on the blockchain and sharing it in encrypted form with data controllers and requesters to guarantee privacy and security. Our proposed model demonstrates the usefulness of privacy-preserving techniques, underscoring the decentralization of the abstract entity data controller to enhance subject data/consent privacy. Additionally, we suggest the integration of privacy-enhancing technologies such as secure multi-party computation, homomorphic encryption, and differential privacy with blockchain to accomplish both security and privacy, aligning with the data sharing practices outlined in the General Data Protection Regulation (GDPR) in Europe.

1. Introduction

Consent management in general and dynamic consent management specifically have attained popularity with the emergence of governing bodies and establishments around the globe, e.g., the General Data Protection Regulation (GDPR) in Europe in 2018 [1]. However, besides offering multiple benefits, dynamic consent management system (DCMS) designs also present several risks, generally concerning the privacy of the actors in dynamic consent management systems and specifically the confidentiality of the subject’s data, as stressed by the GDPR. According to the GDPR, while utilizing a subject’s data, explicit consent from the data subject must be obtained, and the subject’s data must be processed to ensure their maximum confidentiality [2].

1.1. GDPR and the Use of a Subject’s Confidential Data

In accordance with the privacy-by-design regulations outlined in the General Data Protection Regulation (GDPR), Wolford et al. extensively examined the five lawful grounds for the utilization of confidential data concerning data subjects as articulated in Recital 40 of the GDPR. These grounds include: (i) when processing is necessary for the execution of a contract involving the data subject or for pre-contractual measures at the data subject’s request; (ii) when applying the confidential data is paramount to rescue lives; (iii) when processing is aimed at executing an obligation related to public interest; (iv) when explicit consent is obtained from the data subjects to process their data; and (v) when information use is required to meet the permitted obligations. As a result, it is clear that in order to use the sensitive details of a data subject, “consent” is regarded as the most explicit grounds. Wolford et al., as discussed in their work [3], delved into the implications of the GDPR within the realm of clinical trials. They underscored the significance of securing valid consent from research participants, emphasizing the critical principles of transparency, clarity, and specificity in the consent-gathering process. Furthermore, their research suggested that a data consent management system (DCMS) can efficiently facilitate this process. The paper not only offered valuable insight into the functional implementation of the GDPR from the perspective of clinical trials but also provided recommendations aimed at assisting investigators and controllers in conforming to the GDPR directives.

1.2. Privacy by Design

Historically, deterrence against and punishment for data protection violations have primarily relied on explicit legal sanctions. However, lately, there has been a concerted effort to establish possession petitioning through design, with the aim of rendering abuses impossible. Belli et al., as discussed in their work [4], underscored the importance of integrating privacy through design principles into the development and management of data-utilizing systems. Their research argued that privacy should not be an afterthought but an integral part of the design process.

The concept of privacy by design seeks to provide both technological and administrative findings to protect the privacy of data subjects. Furthermore, the authors of [4] highlighted the issues faced by designers and regulators when implementing privacy by design. These challenges include finding a balance between addressing privacy concerns and meeting the legitimate needs for data assemblage, usage, and sharing. In [4], the authors advocated for a collaborative effort among designers, developers, and data protection professionals to embed privacy safeguards right from the design phase of systems that will be used for the processing of a subject’s confidential data.

1.3. Dynamic Consent Management Systems (DCMSs)

The existing body of literature has dedicated significant efforts to defining and elucidating the implications and advantages of dynamic consent management systems (DCMSs) in empowering data subjects to manage their consent dynamically [5,6]. In light of this, Budin et al. in [7] illustrated a DCMS as a personalized online communication tool that promotes ongoing two-way interaction between data requesters and controllers and between data controllers and subjects. To provide further clarity, Kaye et al. in [8] proposed that a DCMS allows data subjects to adjust their consent in response to changing circumstances, such as alterations in the purpose of data processing or shifts in the preferences of the data subject. In essence, a DCMS enables individuals to update their consent as their situations evolve, thereby ensuring that their personal data are processed in accordance with their wishes. Spencer et al. in [9] suggested that a well-designed DCMS, through user-friendly interfaces and robust data infrastructures, can improve transparency and foster public trust.

In real-world scenarios, there are various methods to manage consent [10,11]. Hils et al. in [10] outlined a methodology to assess the effectiveness of dynamic consent in research settings, providing an overview of dynamic consent, including the use of electronic consent forms and the implementation of DCMSs. Similarly, Santos et al. in [11] concentrated on the implementation of dynamic consent in the context of health research, covering essential considerations such as designing user-friendly interfaces, ensuring transparency and accountability, and addressing ethical and legal issues. Regarding the currently utilized DCMSs, it is worth mentioning the MyData-Operators [12], which provide a DCMS for healthcare and research settings, along with Onetrust [13] and Ethyca [14], both offering privacy management platforms inclusive of DCMSs. While Onetrust and Ethyca focus on DCMSs with a privacy emphasis, Ethyca, as stated in [14], claims to provide privacy by design. However, in the white papers of [12,13,14], it becomes evident that the data controller stores personal information and the consent of data subjects in a centralized database. Furthermore, these documents lack precise definitions of privacy and security properties, such as how the confidentiality of data involving various parties (e.g., the data subject’s data) is preserved when shared with the data controller and requester. Furthermore, there is no detailed information on how the integrity of outputs is safeguarded for each honest entity is safeguarded in the presence of diverse adversaries. Apart from confidentiality and integrity, no explicit details are provided regarding how the availability and auditability of their respective DCMSs will be ensured, even in the face of various threats. Consequently, the claims made by [14] regarding privacy by design appear overly vague. As discussed in Asghar et al.’s work [15], the creation of a DCMS that guarantees the security and privacy of all parties in the presence of adversaries remains a significant challenge.

1.4. Blockchain Technology

Blockchain is a type of distributed ledger technology originally presented as the technology underpinning Bitcoin [16]. Blockchain is a dispersed shared register with a consecutively increasing index of transactions in a chain of blocks. Blockchain promotes data sharing without depending on the compute nodes of a network, and a significant node does not control it. Blockchain guarantees the effectiveness of networks and methods through information quality. To realise the potential of blockchain technology, Ethereum, an open-source general-purpose blockchain platform, features smart contracts [17]. Smart contracts are self-sufficient computer programs that run automatically, and the conditions are already set mandatorily (i.e., the contract agreement) [17]. Smart contracts run effectively as they are programmed without interruption, censorship, forgery, or third-party interference. Based on its nature and applications, blockchain can be divided into two main categories:

• Private and public blockchains: Private blockchains like Hyperledger Fabric need prior approval, whereas public blockchains like Ethereum allow anyone to join and participate in the network procedures [18]. Based on the governance methods, blockchain networks can be classified into three classes—public, private, and consortium networks [18].
• Public blockchain networks are permissionless, allowing players to transact securely in trustless settings. In public blockchains, anyone can enter the network anonymously in Bitcoin [16] and Ethereum [17], and all parties retaining a replica of the ledger can create, verify, and validate transactions.
• Private blockchains are essentially permissioned networks limited to well-known registered participants of an organization granted approval to access and use the network. Permissioned blockchains are more scalable than public blockchains and take less time to reach a consensus, resulting in quicker transactions. However, it is claimed that private blockchains require decentralization.
• Hybrid or federated blockchain networks are semi-decentralized networks that connect public and private blockchain elements. A hybrid blockchain network is available exclusively to set organizations or people who have chosen to share the ledger for transactions. Some common examples are R3 Corda and Quorum.

1.5. Motivation and Contributions

Blockchain has been extensively used for DCMS security and privacy. Unfortunately, studies on the privacy of these blockchain applications reveal that using blockchain to decentralize all the actors in a DCMS is highly unjustified. After reviewing recent works on blockchain-based DCMSs, we devised an idea for ensuring security and privacy with blockchain using a few essential privacy-preserving techniques. We summarize this paper as follows:

• We introduce a model that delves into the vulnerabilities inherent to DCMSs. Within our proposed model, we underscore the prospective advantages of incorporating blockchain technology to decentralize the abstract concept of the data controller. Furthermore, we endorse the adoption of cryptographic techniques, such as differential privacy, homomorphic encryption, and secure multi-party computation, as a means to enhance the security of the subject’s data when shared with both the data controller and requester.
• We provide precise guidelines and recommendations, backed by formal proofs, algorithms, and definitions, for employing privacy-preserving techniques to encrypt the data of subjects. These guidelines promote secure encrypted data sharing between decentralized data controllers and requesters.
• Finally, we present a holistic overview of the current work on blockchain-based DCMSs and point out the flaws in the privacy of data subjects.

The rest of the paper is organized as follows: The issues in the current dynamic consent management systems are described in Section 2. A detailed critical analysis of the available DCMSs is illustrated in Section 3. The proposed model of a privacy-first paradigm for DCMSs is described in Section 4. A discussion of the entire work is placed in Section 5. Finally, Section 6 presents the conclusions and future work.

2. Background of Blockchain-based Dynamic Consent Management Systems (DCMSs)

There are typically three entities in a DCMS, i.e., the data subject, data controller, and data requester.

• Data subject (DS): A person who submits their data to a data controller. A DS is an identified person who can be directly or indirectly identified by name or an identification number.
• Data controller (DC): The entity in charge who obtains and stores the data of a DS. A data controller is a lawful person or general management/authority accountable for keeping the subject’s consent/data. The DC is also responsible for establishing the purposes and standards of the personal processing of the DS’s data.
• Data requester (DR): A natural or permitted individual, a general administrator, who processes the private data of the DS on behalf of the DC. The DR could be a researcher who would like to employ the DS’s data for research-associated tasks. From Figure 1, it is clear that a DS is submitting their data/consent to a DC. The DC stores the data/consent granted by the DS regarding their data utility when the DS’s data are shared with the DR. Likewise, the DR wants to use the DS’s data for research-related tasks.
• Excluding the direct connection between the DS and DR: We remark that in our model elaborated in Section 4, we deliberately omit direct communication between the data subject (DS) and data requester (DR). The rationale behind this decision is rooted in the potential challenges associated with a dynamic consent management system (DCMS) where the DS and DR interact directly. In such a system, various issues can arise. Generally, the DS prefers to share their data passively, avoiding time-consuming interactions with all potential DRs, including both legitimate and non-legitimate parties interested in accessing their data. The DS typically seeks to grant consent to a data controller (DC) specialized in managing interactions with DRs. This consent might even be of a general nature, specifying categories of DRs authorized to access the data. From Figure 1 above, it is also clear that the “DC” is the central entity liable for collecting, managing, and sharing the sensitive data/consent of the DS. After carefully examining the work carried out in previously deployed DCMSs using blockchain, as explained in Section 3, we believe that this centralized DC is a weak point for the whole system. The DC stores the DS’s data/consent in a centralized server, and if the server is hacked or damaged due to any issues, then the data/consent of the DS is at stake. Keeping the truth in mind and exploring previously developed DCMSs using blockchain for various use cases, we designed a strategy according to the notion that in a DCMS, instead of decentralizing all the actors, only this DC should be made decentralized, and the DS’s data/consent must be kept over the blockchain in an encrypted form and transmitted to the DR in an encrypted form.

Use Case Description for DCMS

As a practical scenario, in the wake of the GDPR reforms [1,19] and the establishment of European Health Data Spaces in 2022 [20], we consider as the data subject a patient whose information is recorded during hospital checkups. Similarly, the hospital is viewed as a data controller—a centralized entity responsible for obtaining, storing, and processing the patient’s sensitive data, subject to explicit and unambiguous consent. Additionally, we identify the data requester/processor as a researcher or group of researchers affiliated with a specific university who require access to patient data for research purposes. The general structure of DCMS entities, as depicted in Figure 2, is now applied to the management of patient data within a hospital, including their subsequent sharing with researchers.

3. State of the Art (Analysis of Existing Blockchain-Based DCMSs)

The present research on DCMSs utilizes the case of patient consent management while following the rules of a governing body, e.g., the GDPR in Europe. Keeping these facts in mind, when surveying the state of the art, we found that patient consent management using blockchain technologies is one of the primary instantiations of DCMSs.

3.1. Blockchain-Based DCMSs

While multiple solutions are available for DCMS implementation, this section provides a concise overview of the most relevant ones. Our primary emphasis will be on highlighting the key vulnerabilities of current DCMS solutions, particularly in relation to the security and privacy of the subject’s data. It is worth noting that DCMSs have a wide range of potential applications, but existing research predominantly centers around their implementation within the healthcare sector. The papers highlighted in

Table 1. Comparison of the proposed model with related works.

Referenced Paper	DS is on Blockchain	DC is on Blockchain	DR is on Blockchain	Blockchain Platform Used	Use of Privacy-Preserving Techniques
[5]	🗸	🗸	🗸	Quorum	×
[21]	🗸	🗸	🗸	Hyperledger Fabric	×
[22]	🗸	🗸	🗸	Ethereum	×
[23]	🗸	🗸	🗸	Hyperledger Fabric	×
[6]	🗸	🗸	🗸	Hyperledger Fabric	×
[24]	🗸	×	🗸	Ethereum	×
[25]	🗸	🗸	🗸	Hyperledger Fabric	×
[26]	🗸	🗸	🗸	Hyperledger Fabric	×
[27]	🗸	🗸	🗸	Hyperledger Besu	×
[28]	🗸	🗸	🗸	Hyperledger Fabric	×

employed blockchain technology poorly, as they did not resolve the necessary problems.

Legend for Table 1:

• DS—data subject.
• DC—data controller.
• DR—data requester.
• 🗸 indicates that the actor (DS, DC, or DR) is decentralized.
• × indicates that the actor (DS, DC, or DR) is not decentralized.

Regarding Table 1, we specify that in all the previous work, the strategies made the situation worse by generating multiple points of failure instead of resolving a single point of failure. In the abovementioned papers, the method of decentralizing the data controller was erroneous. Because the DCMS did not resolve a single point of failure, it multiplied the points of failure. Furthermore, of the previous studies that developed blockchain-based DCMSs, none utilized privacy-preserving techniques to ensure the confidentiality and integrity of the DS’s data.

3.2. Explanation of the Related Works Reported in Table 1

Reference [5]: The authors proposed a smart-contract-based DCMS backed by blockchain technology, targeting personal data usage under the General Data Protection Regulation. They developed a prototype of the proposed DCMS and implemented it to demonstrate its feasibility. In this work, the authors decentralized all three actors, i.e., the DS, DC, and DR. Using blockchain, the DS shares their data in a plaintext format to the DC, and, finally, the DC also shares the DS’s data/consent in a plaintext format, underlining the privacy concerns regarding the DS’s data/consent. The DS essentially trusts the DC by giving them plaintext data, and the DS trusts that the DC will honestly store and process their data/consent. In contrast, in our proposed model presented in Section 4, we do not trust the DC. Instead, the DS encrypts their data/consent before sharing them with the DC, and the DC then transfers the encrypted data/consent to the DR.

Reference [21]: In this work, the authors proposed a proof-of-concept system developed using Hyperledger Fabric. The authors used a private blockchain to identify the benefits and challenges of a blockchain-based consent manager for GDPR compliance. In this work, three actors, i.e., the data subject, data controller, and data processor, were mentioned, and all were decentralized by defining them as three nodes in the Hyperledger Fabric blockchain. As we discuss for our model, all entities of consent management lie on the blockchain, so the situation for achieving privacy and security is risky.

Reference [22]: Here, the authors proposed a cloud-based data management and sharing platform to enable data subjects to control who can access their data and consent to their collection and usage based on smart contracts. In this work, the authors implemented a DCMS prototype on the Ethereum blockchain to demonstrate the feasibility of the proposed approach. The authors presented a cloud-based data management dynamic consent system wherein all three entities, i.e., the data subject, data controller, and data user, were decentralized. In contrast to our proposed model presented in Section 4, this work achieved security at the cost of privacy, as any actors could reveal the subject’s confidential data.

Reference [23]: In this work, the authors demonstrated a use of the Hyperledger Fabric blockchain wherein known entities exist and interact with each other. Known nodes in the blockchain can communicate to acquire patient data. Essentially, in the proposed prototype, the three entities of the DS (a patient), DC (hospital), and DR (a doctor or researcher) are on the blockchain. In our proposed model, we stress using privacy-preserving techniques to encrypt the DS’s data/consent before sharing them with the data controller and requester. We only decentralize the data controller so that there are multiple points of failure regarding the leakage of the DS’s data, thus maintaining privacy and security. Hence, this work does not fulfill our model explained in Section 4.

Reference [6]: This was the PhD thesis of a student from Monash University. In this work, the author implemented a blockchain-enabled DCMS that allowed a researcher to ask for the personal information of a data subject from the data controller. The suggested method had all the components that should satisfy the possible constraints set by data governance authorities like the GDPR. The author tried to create a few design goals for this DCMS. In this work, the proposed DCMS only consisted of a prototype implemented using the Hyperledger Fabric blockchain. Here, all three typical entities (the DS, DC, and DR) were placed on the blockchain as nodes. From the perspective of our model, elaborated in Section 4, this work used blockchain technology erroneously, though the privacy assurance for the DS was sufficiently severe.

Reference [24]: The authors proposed an Ethereum blockchain-based data sharing dynamic consent scheme to control access to individuals’ health data, wherein smart contracts provided separate consent and allowed the requester to seek and access health data from the data provider. The consent model proposed in this work consisted of a data provider, a data sharing agreement-based smart contract, and a data requester (who wants to acquire the subject’s data). The data provider and requester were designated as two nodes in the Ethereum blockchain. Each time a data requester needs the provider’s data, they query the data sharing smart contract, and after taking the necessary steps, the provider’s data are shared with the requester. In contrast to our model depicted in Section 4, where the data are added onto the blockchain in plaintext format, both entities are still on the blockchain. There is no guarantee that the provider’s data will be used according to the consent release from the provider or that the requester will not leak the sensitive data of the data provider. Hence, the use of blockchain technology in this work was misguided.

Reference [25]: This paper presented SCoDES, an approach based on blockchain technology for the trusted and decentralized control of dynamic consent in clinical trials. This work utilized the Hyperledger Fabric blockchain to remove the trust of third parties while managing consent dynamically in clinical trials. This work focused on creating a web-based platform using a permission blockchain network wherein entities, e.g., patients, could control their consent and data. In this work, patients (the DSs), doctors (DCs), and data requesters (DRs) were designated as nodes in the Fabric blockchain. Furthermore, data were uploaded to the blockchain in a plaintext format, thereby enabling data misuse by any other actor in the system. Hence, in comparison to our model described in Section 4, this work misused blockchain technology.

Reference [26]: In this work, a DCMS was designed for use in the bio-banking sector. This work presented a web portal backed by Hyperledger Composer blockchain technology and a hub connecting various Maltese bio-banking stakeholders. In this work, the DS, DC, and DR were designated as nodes in the Hyperledger Fabric blockchain, and all entities were placed on the blockchain. Hence, there was a strong chance that the DC or DR would misuse the DS’s data. In our model presented in Section 4, we determined that DS’s data should be sent to the DC in encrypted form, and only the required information should be revealed to the DC. Ultimately, upon receiving a request from the DR, the DC should retrieve the data from the blockchain and share these encrypted data with the DR.

Reference [27]: In this work, the authors used the Hyperledger Besu InterPlanetary File System framework for implementing a controlled blockchain network. The authors developed an ontology model to represent patient consent elements as machine-readable codes in order to automate the consent and data access processes. Here, the DS (the patient), DC (storing the data and consent of the DS), and DR were decentralized. The DS’s data were sent and held on the blockchain in plaintext format, and hence there was a risk of DS data abuse. Thus, this paper did not follow our proposed model presented in Section 4.

Reference [28]: In this work, the authors proposed the development of a dynamic-consent medical blockchain system called DynamiChain based on a rule-set management algorithm for handling health examination data. The proposed approach was implemented for a scenario wherein an exercise management healthcare company provided health management services based on data from the data provider’s hospital. For the implementation, this work utilized the Hyperledger Fabric blockchain, which essentially reflected the private system. Here, data providers (DSs) and data utilizers (DRs) were designated as two nodes on the Fabric blockchain. Though the DC entity was missing here, the DS’s personal information was still stored on the blockchain in plaintext format, and the DR invoked a query in the blockchain to access the DS’s data. In contrast to our proposed model presented in Section 4, the DR could leak the DS’s data, highlighting the severe privacy and security risks of having all entities on the blockchain.

4. Proposed Model

There are numerous scenarios where DCMSs can be applied. However, in the existing literature, the leading research has been carried out on DCMSs for the healthcare sector to manage the sharing of a patient’s (DS) data/consent by the hospital (DC) when a university or a researcher from a university (DR) asks for that DS’s data. As we pointed out in Table 1, it is well established that the use of blockchain to attain security and privacy in DCMSs needs to be justified. All the abovementioned works used blockchain to achieve security in the proposed DCMS, while privacy remains to be addressed. In our suggested model’s guidelines, we recommend that the data from the DS should reach a DC in a form that is not directly accessible to/readable by the DC. When deciding to share data with a DC, the DS should generate data that can only be understood by the DR, and not the DC. The idea is that the DR can use those unique data by decrypting and accessing the DS data saved onto the blockchain by the DC. The DS uses cryptographic software to encrypt the data shared with the DC. Upon acquiring data from the DS, the DC executed certain data aggregation processes to assemble the data originating from many DSs. In our model, we only consider a case in which a single DS shares data/consent with the DC, but in real-time DCMSs, many DSs share their data/consent with the DC, so the DC has to aggregate all the data to remove any active links between a data attribute and a particular DS. Then, the DC keeps these encrypted data in the Hyperledger Fabric blockchain instead of in a centralized database. When a DR requires the DS’s data for research-related tasks, they ask for the DS’s data/consent from the DC. The DC transmits the necessary data to the DR. Thus, the DR applies cryptographic software to decrypt the DS’s encrypted data and uses them for research-related tasks. The proposed model can be viewed in Figure 3.

4.1. Use of Privacy-Preserving Techniques along with Blockchains in DCMSs

If we only decentralize the DC by having governance of a blockchain instead of just one player, then we do not improve anything about the privacy of the DS’s data. This decentralization of the DC only works for the unforgeability, but for the privacy, we are making the situation worse. Because a single DC is decentralized, only one actor in the DCMS manages the data storing and processing tasks. Likewise, we must trust that the DC does not leak the DS’s data. Also, if we have governance of more than one actor, e.g., with three actors running on a Hyperledger Fabric blockchain, we build a private network comprising these three actors. Hence, we must now trust all three actors rather than trusting a single actor (the DC), because all or any of them might use the DS’s data, which would be an even worse situation theoretically as well as practically. Thus, we believe that blockchain is valuable for unforgeability but takes away from privacy or, even worse, from the privacy of the DS’s data. Therefore, using privacy-preserving techniques with blockchain technology is highly important to achieving security and privacy for the DS’s data when processed in a DCMS.

4.2. Assumptions in the Model

In the proposed model, we assume that the DS (referring to a patient) and DR (representing a university or a researcher from a university) are identified entities. This means that the DC (referring to a hospital) has verified the legitimacy of the DS (the patient), who willingly provides their data/consent to the DC. Therefore, the DC does not need to verify the authenticity of the DS. Additionally, we assume that the DR is a registered organization known to the DC (the hospital) and is genuinely interested in acquiring the DS’s data for research purposes.

4.3. Model Definitions

• Sharing of DS’s data with DC: The DS uses cryptographic software that applies cryptographic techniques like differential privacy, homomorphic encryption, and secure multi-party computation. The DS uses this software to transform their plaintext data into encrypted data so that the DC cannot learn sensitive information related to the DS (e.g., name and gender) but the level of detail is sufficient for the data to be shared and processed as needed by the DR.
• DC’s reception of data from DS: We assume that the DC receives data from multiple DSs. After acquiring the data in encrypted form, the DC applies aggregation to them. Various studies in the literature have demonstrated the aggregation of encrypted data [29,30,31]. In our model, we assume that the DC aggregates the received data using cryptographic techniques like homomorphic encryption and differential privacy mechanisms, i.e., Laplacian and Gaussian. In the work of Castelluccia et al. [29], the encrypted data were aggregated using homomorphic encryption in wireless sensor networks. Moreover, aggregation operations like randomization and generalization are performed. Randomization techniques alter the quality of any DS’s data in a DCMS to evade the dynamic link between the entity’s data and the entity. The generalization approach generalizes the characteristics of a DS’s data in a DCMS by adjusting the individual hierarchy. After consulting with various studies in the literature on differential privacy and data anonymization techniques, differential privacy was selected as an excellent approach to achieve a balance between the privacy and utility of the subject’s data [32].
• Decentralization of DC:Figure 3 shows the DC node lying on the blockchain service. This demonstrates that to achieve unforgeability and avoid a single point of failure, the DC is the only entity that is decentralized.
• Use of InterPlanetary File System (IPFS) for DS data storage: The InterPlanetary File System (IPFS) is a decentralized file system that utilizes distributed hash table (DHT) technology [33]. In the proposed model presented in Figure 3, we explicitly overcome one of the significant overheads highlighted in the blockchain implementations and the IPFS. It is not recommended to burden the blockchain with sensible data since, due to the immutable nature of the blockchain, no data can be removed from it once stored there. This is an apparent violation of one of the significant clauses of the GDPR [1], which states that the data subject has the right to erase their data anytime they want. Due to this reason and to overcome this severe overhead in our proposed model (Figure 3), we suggest the use of a distributed IPFS [34,35,36] to store the patient’s sensitive data while the hash of the subject’s data is held in the blockchain. Keeping only hashes on the blockchain will improve the scalability and limit the transaction time and cost [37] when this DCMS is set up in real time.
• DR requesting DS’s data: Now, when a DR asks for the DS’s data for a research assignment, instead of sharing the data in plaintext format, the DC shares aggregated encrypted data to preserve the confidentiality of the DS’s data. Upon receiving those encrypted and aggregated data, the DR again utilizes the cryptographic software running homomorphic encryption and other cryptographic modules to examine the encrypted DS data. In this way, the DR obtains a reasonable response to their request for the DS’s data, and the confidentiality of the DS’s data is ensured effectively.
• Cryptographic software: By cryptographic software, we refer to software applications in which many operations for encryption and decryption concerning privacy-preserving technologies like homomorphic encryption, secure multi-party computation, and differential privacy are run, and the state of each of these operations (s) is only triggered when the specified entity, i.e., DS, DC, or DR, is using the software. For instance, if a DS is using the software, then the encryption procedures and anonymization of the DS’s data are implemented, and all the data entered by the subject are converted into a cyphertext. Also, when a DC uses the software, it allows them to analyze and pollute/aggregate the received DS data via the available differential privacy techniques like randomization, generalization, diversity, and T-closeness. The data controller employs these techniques to remove the active link between the data and a particular DS.
  Similarly, when a DR asks for the DS’s data, the DC does not share the DS’s data in plaintext format. Instead, the data polluted and aggregated using the cryptographic software are transmitted to the DR. Upon obtaining those data, the DR uses the same cryptographic software to obtain the required outcomes from the encrypted data for their research-related assignments. Throughout this entire procedure, there is no possibility of DS data leakage. Hence, in our proposed model shown in Figure 3, we demonstrate that the confidentiality of the DS in the DCMS can be protected using cryptographic techniques and blockchains. Indeed, by having a decentralized DC in the DCMS, we confirm the unforgeability of the entire DCMS, as now there is no single point of failure; instead, the entity that has access to abundant data is decentralized, and privacy is ensured with the utilization of privacy-preserving technologies.

4.4. Guidelines for Using Blockchain and Privacy-Preserving Techniques in a DCMS

Here are some suggestions and guidelines regarding the use of privacy-preserving technologies in the form of the definitions, formal proofs, and algorithms applied by each actor in a DCMS: Our model states that when a subject’s data/consent have to be shared with the data controller and requester, privacy and security must be guaranteed by employing robust privacy-preserving techniques. The following is based on the model illustrated earlier in Figure 2:

• DS Sharing Data/Consent with the DC.
  Definition: A DS is an individual whose personal data are collected and processed by a DC.
  Formal Description: The DS must use techniques like differential privacy, secure multi-party computation, and homomorphic encryption while sending data/consent to the DC. Using privacy-preserving techniques will ensure that the data/consent are protected and secure while being transmitted.
  The DS should implement the following steps while sending data/consent to the DC:
  • The DS should use differential privacy to add random noise to the sensitive information in order to protect the privacy of the data being transited to the DC.
  • To guarantee that the DS’s data/consent are not modified when transmitting them to the DC, the DS can employ secure multi-party computation.
  • Correspondingly, the DS can also employ homomorphic encryption to safeguard the data/consent when disseminating them to the DC.
  • Eventually, to convert the plaintext data into ciphertext form after using cryptographic software operating secure multi-party computation homomorphic encryptions, the DS sends their data/consent to the DC in the DCMS.
  Precise Algorithm

  (a)

  Data subject generates a public-private key pair:

  pub_DS, priv_DS ← KeyGen()

  (b)

  Data subject encrypts the data and consent with their public key:

  (D’, C’) ← Enc(pub_DS, D, C)

  (c)

  Data subject sends the encrypted data and consent to data controller:

  Send(D’, C’) to DC

  (d)

  Data controller receives the encrypted data and consent:

  Receive(D’, C’) from DS

  (e)

  Data controller verifies the authenticity of the message by checking the public key used for encryption:

  Verify(pub_DS)

  (f)

  Data controller decrypts the message using their private key:

  (D, C) ← Dec(priv_DC, D’, C’)

  (g)

  Data controller stores the decrypted data and consent securely and associates it with the data subject’s identity:

  Store(D, C) with the identifier ID_DS

  (h)

  Data controller sends a confirmation message to the data subject:

  SendConfirmation(ID_DS)

• DC Obtaining, Storing, and Processing DS Data/Consent.
  Definition: A DC is an individual who collects and processes personal data on behalf of the DS.
  Formal Proof: The DC should receive the encrypted data/consent and, after performing the necessary aggregation to remove any dynamic links between a data attribute and a particular DS, store them on the blockchain, e.g., a Hyperledger Fabric blockchain. This process takes care of the privacy of the DS’s data/consent by aggregating the encrypted data while implementing a private blockchain, i.e., Hyperledger Fabric, that will ensure the security and privacy of DS’s data/consent. This guarantees that the data are secure and tamper-proof.
  Description: To obtain both data and consent from the DS, the DC could utilize the following approaches:
  • Acquire encrypted data/consent from the DS.
  • Ascertain the genuineness and integrity of the data/consent received from the DS.
  • Apply an aggregation process to the collected data to avoid any active link between the data and a particular DS.
  • Keep the encrypted data/consent on a Hyperledger Fabric blockchain.
  Precise Algorithm

  (a)

  Data subject generates a public-private key pair:

  pub_DS, priv_DS ← KeyGen()

  (b)

  Data subject encrypts the data and consent with their public key:

  (D’, C’) ← Enc(pub_DS, D, C)

  (c)

  Data subject sends the encrypted data and consent to data controller:

  Send(D’, C’) to DC

  (d)

  Data controller receives the encrypted data and consent:

  Receive(D’, C’) from DS

  (e)

  Data controller verifies the authenticity of the message by checking the public key used for encryption:

  Verify(pub_DS)

  (f)

  Data controller decrypts the message using their private key:

  (D, C) ← Dec(priv_DC, D’, C’)

  (g)

  Data controller stores the decrypted data and consent securely and associates it with the data subject’s identity:

  Store(D, C) with the identifier ID_DS

  (h)

  StoreOnBlockchain(hash_D’, hash_C’)

  (hash_D’, hash_C’) ← Hash(D’, C’)

  (i)

  DC saves the plain text data (D, C) of DS onto IPFS:

  SaveOnIPFS(D, C)

  (j)

  Data controller sends a confirmation message to the data subject:

  SendConfirmation(ID_DS)

• DR Requesting DS Data/Consent.
  Definition: A DR is an individual who requests access to a DS’s data from the DC.
  Formal Proof: The DR should ask the DC for the encrypted data of the DS, and the DC should retrieve the data from the blockchain and then transfer them to the DR. The above procedure guarantees that the data of the DS are only transmitted to official and legitimate DRs in the DCMS.
  Description: The DR should use the following measures to request access to the data/consent of the DS.
  • The DR asks for the DS’s data/consent from the DC, which are essentially encrypted.
  • Once the DC has received the request, they ask the DR to supply credentials demonstrating that they are a legitimate entity asking for the DS’s data/consent.
  • Upon receiving a response from the DR, the DC then checks the authenticity of the credentials provided by the DR, i.e., by cross-checking the public key of the DR given to the DC.
  • If the DR’s credentials are legal, the DC initiates another process to obtain data and corresponding consent from the Hyperledger blockchain and share the encrypted data/consent with the authenticated DR.
  Precise Algorithm

  (a)

  Data requester generates a public-private key pair:

  pub_DR, priv_DR ← KeyGen()

  (b)

  Data requester sends a request for data and consent to data controller for data subject

  DS: SendRequest(DS) to DC

  (c)

  data controller receives the request and verifies the authenticity of the message by checking the requester’s public key:

  ReceiveRequest(DS, pub_DR) from DR

  Verify(pub_DR)

  (d)

  Data controller encrypts the data and consent associated with data subject DS with the requester’s public key:

  (D’, C’) ← Enc(pub_DR, D, C)

  (e)

  Data controller sends the encrypted data and consent to the data requester:

  Send(D’, C’) to DR

  (f)

  Data requester receives the encrypted data and consent:

  Receive(D’, C’) from DC

  (g)

  Data requester decrypts the message using their private key:

  (D, C) ← Dec(priv_DR, D’, C’)

  (h)

  Data requester can access and use the data and consent of data subject DS as needed.

4.5. Breakdown of the Proposed Model at Each Actor’s Level

We elaborate on the suggested techniques and how each actor makes use of them while following the proposed model shown in Figure 3.

• Techniques used by the DS when disseminating data/consent to the DC.
  Below are the cryptographic proofs, along with the algorithms that should be performed by the DS while transmitting their data/consent to the DC:

  (a)

  Differential Privacy, ($\delta$, $ϵ$). According to [38], differential privacy assures the DS (whose data will be utilized for research-related tasks by the DR) that they must provide consent authorizing their healthcare data to be employed by any researcher. DP adds random noise to the data before they are released, making it difficult for an attacker to identify any specific individual in the dataset [38]. The algorithm for differential privacy involves the following steps:

  Input: Dataset D, which essentially comprises the data/consent of a DS.

  Operation: Add random noise to dataset D using a probability distribution, i.e., Laplacian or Gaussian mechanism, that satisfies the privacy guarantee and manages the trade-off between the privacy and utility of the DS’s data, since the DR would like to use DS’s data. If there is too much noise in the DS’s data, then the DR will not be able to use the data for their research-related tasks.

  Output: A new dataset $D^{\prime }$ that is differentially private concerning the input that was D.

  Formal Definition: A randomized algorithm A satisfies $ϵ$-differential privacy if for any two datasets D and D’ that differ in a single individual and any output O of the algorithm A, the following inequality holds:

  $$Pr[A\left(D\right)=O]\le \widehat{e}\left(ϵ\right)\ast Pr[A\left(D^{\prime }\right)=O]$$

  (1)

  where $ϵ$ is a non-negative privacy parameter that specifies the level of privacy guaranteed.

  (b)

  Secure Multi-party Computation (SMPC). Secure multi-party computation is a technique that allows multiple parties to jointly compute a function using their private inputs without revealing their inputs to each other [39]. In a DCMS, SMPC enables the DS to share their data with the DC securely. Here, we elaborate on the general applicability of SMPC among DS, DC and DC, and DR. The algorithm for SMPC involves the following steps:

  Input: Private inputs from multiple parties, i.e., between the DS and DC or DC and DR.

  Operation: In line with the intrinsic features of SMPC, the involved entities (e.g., the DS and DC or the DC and DR) implement a secure computation protocol that allows interacting actors to concurrently compute a function using their private inputs without revealing their inputs to each other.

  Output: The function output is computed using the private inputs from each of the communication entities in the DCMS.

  Definition: An SMPC protocol is a protocol that allows the DS and DC or the DC and DR to apply a function $f(x_1,x_2,\cdots ,x_n)$ to their private inputs $x_1,x_2,\cdots ,x_n,$ without exposing their inputs to each other and without any party knowing anything other than the output of the function.

  (c)

  Homomorphic Encryption (HE). Homomorphic encryption is a technique used to analyze encrypted data without first decrypting them [40]. This enables the DS to encrypt their data/consent before transmitting them to the DC. The algorithm for HE in a DCMS may involve the following steps:

  Input: A plaintext message m and a public key $pk$. For instance, if the DS shares their data/consent with the DC, the DS provides their data/consent and the related $pk$ as input for the procedure.

  Operation: Encrypt the plaintext message by employing the public key $pk$ to obtain the ciphertext c.

  Output: The ciphertext c.

  Definition: A public-key encryption technique is homomorphic if for any two plaintext messages $m_1$ and $m_2$, and their affiliated ciphertexts $c_1$ and $c_2$, it is likely to compute a ciphertext $c_3$ that decodes to the sum of $m_1$ and $m_2$.

  Discussion Summing up, we believe and suggest that if a DS uses the cryptographic techniques and algorithms mentioned above, they may expect that both the security and privacy of their shared data/consent are effectively ensured, as the required data/consent are encrypted before being shared with the DC in the DCMS.

• Techniques used by the DC while storing/sharing the DS’s data/consent:

  (a)

  Hyperledger Fabric Blockchain. Hyperledger Fabric is a permissioned blockchain platform that allows for secure, private, and tamper-proof data storage [41]. The DC uses Hyperledger Fabric to store the encrypted data/consent received from the DS. The DC might use a blockchain query protocol like Chain-code or the Fabric query language to retrieve the encrypted data/consent from the Hyperledger Fabric blockchain. The algorithm for storing data/consent on the Hyperledger Fabric blockchain involves the following steps:

  Input: Encrypted data/consent from the DS.

  Operation: Storing the encrypted data/consent on the Hyperledger Fabric blockchain using a smart contract invocation.

  Output: Confirmation of successful data/consent storage on the blockchain.

  Assumption: A network of nodes comprises the Hyperledger Fabric blockchain, with each node having a copy of the ledger. Here, we assume that there can be many DS nodes, but for the algorithm’s description, we assume a single DC.

  Step 1: A client (the DC) proposes a transaction, including the encrypted data/ consent of the DS.

  Step 2: The transaction is validated by the endorsing peers (other DCs), who execute the smart contract code to ensure it meets the necessary criteria.

  Step 3: The validated transaction is then broadcast to the ordering service, which orders the transactions and creates blocks. Here, we assume that some DC nodes are selected as ordering peers to render transactions on the shared ledger of the Hyperledger blockchain.

  Step 4: The blocks are then distributed to the peers, who validate them and add them to their copy of the ledger.

  (b)

  DC Retrieving DS’s data from the Blockchain and Sharing Them with the DR. The DC implements the process that essentially involves obtaining the data/consent from the private blockchain, where the data/consent are in an encrypted form; then, the data/consent are transmitted to the authenticated DR.

  Input: The credentials of the DR proving their right to access the DS’s data/consent and the encrypted data/consent kept on the Fabric blockchain.

  Operation: The DC retrieves the required DS data/consent from the blockchain and shares these encrypted data/consent with the authenticated DR.

  Expected Output: Encrypted data/consent shared securely with the DR.

  Discussion The detailed step-by-step procedures described above demonstrate how privacy-preserving techniques can help to ensure the privacy of the DS’s data/consent while sharing them with the DC and DR when only the DC is placed on the blockchain. We comprehensively discussed the possible tools and techniques that could be vital in the practical realization of such cases to ensure the security of the entire system by using blockchain technology to decentralize only the abstract entity of the DC and achieve privacy with the help of privacy-preserving techniques like differential privacy, secure multi-party computation, and homomorphic encryption.

• Techniques used by the DR while requesting the DS’s data/consent.
  After receiving the encrypted data and corresponding consent from the DC, several cryptographic techniques and tools can be used by the DR to perform research tasks with the DS’s data while maintaining their security and privacy. The DS encrypts their data/consent using cryptographic software that essentially runs homomorphic encryption. We elaborate below precisely how both encryption and decryption can be conducted using homomorphic encryption, protecting the privacy and security of the DS’s data/consent in a DCMS. Here, we discuss only the use of HE for precision. The use of differential privacy is also relevant to this entity in a DCMS.

  (a)

  Differential Privacy Mechanism. The differential privacy mechanism can be used by the data requester to protect the privacy of the subject’s data. The algorithm for the differential privacy mechanism is as follows:

  Input: Dataset D, privacy parameter $ϵ$.

  Output: Dataset $D^{\prime }$.

  Assumption: The data are discrete and numerical.

  Algorithm:

  • Set the sensitivity of the dataset as d.
  • Calculate the noise to be added to the data as $\lambda$, where $\lambda$ = d∖$ϵ$.
  • Add random noise to each data point in the dataset.
  • Return the dataset $D^{\prime }$ with the added noise.

  Expected Output: The dataset $D^{\prime }$ with added random noise maintaining the subject’s data privacy.

  (b)

  Secure Multi-Party Computation. Secure multi-party computation (SMPC) can compute functions over encrypted data without revealing the data themselves [39]. The algorithm for secure multi-party computation is as follows:

  Input: Two parties A and B with inputs x and y, respectively, and the function $f(x,y)$ to be computed.

  Output: The result of the function $f(x,y)$.

  Assumptions: The parties must have encrypted inputs and a secure communication channel.

  Algorithm:

  • Both parties encrypt their input data.
  • The parties then perform a secure computation of the function $f(x,y)$ without revealing their input data.
  • The parties decrypt the result of the function $f(x,y)$ to obtain the final output.

  Expected Output: The result of the function $f(x,y)$ computed over the encrypted input data without revealing the input data themselves.

  (c)

  Homomorphic Encryption (HE). Homomorphic encryption can be used to perform computations on encrypted data without decrypting them [40]. We assume that the DR obtains the encrypted data of the DS from the DC, which were encrypted using the homomorphic encryption operation running in the cryptographic software explained in the model. The algorithm for homomorphic encryption is as follows:

  Input: Encrypted data D of the DS, homomorphic encryption key K, function $f\left(x\right)$ to be computed.

  Output: The result of the function $f\left(D\right)$ computed on encrypted data D of the DS.

  Assumptions:

  The DS data are encrypted using a homomorphic encryption scheme with the help of cryptographic software, and the function is compatible with the homomorphic encryption scheme.

  Algorithm:

  • The data D are encrypted using the homomorphic encryption key K.
  • The function $f\left(x\right)$ is applied to the encrypted data D.
  • The resulting encrypted output is decrypted by the DR using the homomorphic encryption key K with the help of the cryptographic software explained in the model.

  Output: The result of the function $f\left(D\right)$ computed on encrypted data D of the DS without decrypting them.

  (d)

  Differential Privacy. If the DS pollutes their data/consent using any of the differential privacy mechanisms of noise addition, then they are able to hide sensitive details in their data and would be happy to share these data with the DR. At the same time, there is concern regarding the privacy parameter of the differential privacy $ϵ$. If the value of $ϵ$ is set higher, then a substantial amount of noise is added to the DS’s data, and the DR would be unable to use these highly polluted data. At the same time, if $ϵ$ is smaller, then significantly less noise is introduced to the DS’s data, and as a result, the DR may have access to sensitive attributes of the DS’s data, which is again a big issue. To address this, researchers have suggested that there should be a significant focus on choosing an appropriate value of $ϵ$ so that the trade-off between the privacy and utility of the DS’s data is balanced and well managed. Hence, choosing a concrete epsilon value is a complex task. It requires careful considerations, depending on the data one intends to pollute using the DP framework.

  (e)

  Secure Multi-Party Computation using Homomorphic Encryption.

  Secure multi-party computation can also be performed using homomorphic encryption. The algorithm for secure multi-party computation using homomorphic encryption is as follows:

  Input: Two parties A and B with inputs x and y, respectively, and function $f(x,y)$ to be computed.

  Output: The result of the function $f(x,y)$ computed using the encrypted input data.

  Assumptions: The parties must have encrypted inputs and a secure communication channel. The function $f(x,y)$ is compatible with the homomorphic encryption scheme.

  Algorithm:

  • Both parties encrypt their input data using the homomorphic encryption key K.
  • The parties then perform a secure computation of the function $f(x,y)$ using the encrypted data without revealing their input data.
  • The resulting encrypted output is decrypted using the homomorphic encryption key K.

  Expected Output: The result of the function $f(x,y)$ computed on encrypted input data without revealing the input data themselves.
  Discussion. Summing up, we stated that with the help of homomorphic encryption schemes running on cryptographic software, the DR can obtain the data needed to perform their research-related tasks. Through the use of privacy-preserving homomorphic encryption, the DS’s data/consent remain confidential, while the DR can perform the necessary operations on the basis of the data. Likewise, in addition to homomorphic encryption, the use of differential privacy by the DS to add random noise to the data could also be helpful. In this way, the DR obtains polluted data that can still be analyzed, as the trade-off between the privacy and utility of the data is managed by choosing an appropriate noise addition mechanism (e.g., Laplacian and Gaussian).

Using these cryptographic tools and techniques, the DR can securely retrieve the encrypted data/consent of the DS from the DC, perform the necessary computations on the encrypted data via SMPC and homomorphic encryption, and maintain the privacy of the data subject while employing their data for research-related tasks.

Definition of Cryptographic Protocols Used

Encryption: A reversible procedure of converting the DS’s plaintext data/consent into ciphertext using a key.

Decryption: A reversible process of transforming the DS’s ciphertext data/consent into plaintext using a key.

Private key: A secret key kept by the DC to decrypt the encrypted DS data.

Public key: A key that is made public and used to encrypt the DS’s data.

Key exchange: A protocol used to securely exchange keys between two parties, e.g., the DC and DR.

Signature: A digital signature is a mathematical technique used to verify the authenticity of a digital message exchanged between the DC and DR.

5. Discussion

In this work, we studied the requirements for both the integrity and confidentiality of the DS’s data while being shared with the DC and DR. After considering the substantial amount of previous work on blockchain-based DCMSs, and we pointed out the poor application of blockchains to increase security but considerably decrease privacy for a subject’s data/consent. We proposed a model demonstrating the use of privacy-preserving techniques to ensure the confidentiality of the DS’s data/consent. To achieve security and privacy by design for a DCMS, we suggested using permissioned blockchain platforms to decentralize only the DC and ensure confidentiality and security for future blockchain-enabled DCMSs. Our findings in this work highlight the need to carefully consider security and privacy requirements whenever a DCMS is being developed. Indeed, the security and privacy of these DCMSs must be considered right from the design phase and should not be an afterthought. We stress that the software engineering for a DCMS should be conducted such that the end product exhibits security and privacy by design, not by law. Future systems must provide both security and privacy by design while obtaining, storing, and sharing the sensitive information of data subjects.

6. Conclusions and Future Work

This work explored the decentralization of data controllers and the use of privacy-preserving techniques in a DCMS to enhance the security of the entire DCMS and the privacy related to the data subject’s data, as required by the GDPR in Europe. Our proposed model focuses on achieving security through decentralizing data controllers using the Hyperledger Fabric blockchain, while the privacy of data subject’s data/consent is ensured by applying privacy-preserving techniques. Additionally, we offered a practical approach in the form of constructive guidelines and suggestions to demonstrate the security of the DCMS and the confidentiality of the subject’s data within the DCMS. As part of ongoing research, we developed a model incorporating state-of-the-art tools and techniques. In the future, we plan to conduct experiments using the Hyperledger Fabric blockchain to decentralize the data controller and employ techniques like secure multi-party computation, differential privacy, and homomorphic encryption for real-world results. This study explicitly addressed the confidentiality and integrity of the subject’s data/consent while sharing them with various other entities in a DCMS.