Scrybe: A Secure Audit Trail for Clinical Trial Data Fusion

One approach is to design a consensus algorithm tailored to the application. These approaches generally address proof-of-work (PoW) efficiency concerns, but many fail to include integrity and security considerations. MediBchain [11, 46] is one such solution. The specifics of the blockchain are very high-level, and concrete details are abstracted. Further, other authors have found security issues with their implementation [81]. BBDS is a PoW-based blockchain designed to facilitate data sharing [80]. Patel designed a blockchain framework for sharing radiology data using a proof-of-stake (PoS) algorithm [59]. Lee and Yang designed a flawed blockchain specific to their work (fingernail microscopy). Peterson et al. designed a blockchain that leverages proof-of-interoperability instead of PoW [62]. While the approach is novel, based on the algorithm description, it appears that two malicious nodes could control the network.

Many EHR blockchain solutions build on either Bitcoin or Ethereum. Bitcoin-based solutions [39, 49, 72] leverage numerous integrations with tools such as sidechains and data anchors. Ethereum-based solutions (such as MedRec [13, 27] and others [16, 17, 54, 56]) use smart contracts to provide impressive functionality that can easily interface with complicated systems. Other solutions (Healthchain [81], MedicalChain¹ [50], and Reference [41]) are based on Hyperledger Fabric—a permissioned blockchain developed by IBM. Hyperledger Fabric incorporates functionality present in Ethereum but does not require a cost or resource overhead. Both Bitcoin and Ethereum currently use PoW as their consensus algorithm. While this is currently one of the more popular consensus algorithms, it does not scale well, and it is cost-prohibitive [67].

While proof-of-concept solutions based on PoW are popular, they are not long-term solutions for securing data provenance. They result in too much overhead and too little throughput [67]. Ethereum has announced a move to a PoS consensus algorithm. While this is a step in the right direction, it still introduces issues, and any application running on the blockchain will have associated costs required to keep running the smart contracts. With the current cryptocurrency volatility, tying a technological solution to any of these blockchains would be a gamble.

Hyperledger is a promising permissioned blockchain architecture that offers pluggable consensus algorithms. There are several mainstream choices, such as Hyperledger Fabric, Hyperledger Indy, Hyperledger Iroha, and Hyperledger Sawtooth [1]. There are several popular pluggable ordering/consensus mechanism for Hyperledger Fabric: practical Byzantine Fault Tolerance (PBFT) [24], BFT-SMaRt [18], SBFT [33], HoneyBadger BFT [51], and Kafka [44]. Kafka stands out on this list, since it is neither crash-tolerant nor fault-tolerant. The other consensus algorithms are all in the family of PBFT algorithms, which suffer from scalability issues (usually greater than 20 nodes) [75]. SBFT improves on this, but it still suffers from the other shortcoming of PBFT algorithms—electing a centralized leader. Similarly, HoneyBadger BFT elects a set of nodes at the beginning of the algorithm that makes it centralized [30]. Hyperledger Indy uses Robust BFT (RBFT), which is in the same PBFT family that suffers from node scalability [75]. Hyperledger Iroha uses the Sumeragi consensus, which is based on BChain [26]. Sumeragi also suffers from node scalability issues [1]. Finally, Hyperledger Sawtooth uses PoET as the consensus algorithm. PoET is based on a Trusted Execution Environment [66]. While TEEs are a huge advancement in the space of efficient consensus algorithms, vulnerabilities such as Plundervolt [53] show there are ways to bypass the trusted environment.

Our EHR blockchain solution leverages Scrybe’s lightweight consensus algorithm [19]. This consensus algorithm is designed for a permissioned blockchain, so it does not require excessively wasteful computations. Scrybe’s complexity is linear as the number of nodes approaches infinity [19], which addresses the scalability concerns many popular consensus algorithms face. While the current embodiment of our design does not leverage Hyperledger Fabric, a future version may be integrated with a pluggable Scrybe consensus algorithm.

REDCap is a software toolset and workflow methodology for electronic clinical trial data collection and management [38]. REDCap provides web-based tools for data entry, aiding correct entry using real-time validation rules with automated data type and range checks at the time of entry. The system allows the research teams to create and design online surveys and allows survey owners to engage respondents using various notification methods. REDCap data dictionaries can be distributed for reuse at multiple institutions. A library of data dictionaries is made available for standard data collection forms and validated collection interfaces [57].

These features make REDCap an ideal clinical trial collection tool. We use REDCap as our data management system, intending to secure the data provenance. The existing REDCap system already has some valuable security features. The underlying database is typically hosted in secure data centers at the host institutions with layers of redundancy, failover capability, backups, and extensive security checks. The system is inherently compliant with the Health Insurance Portability and Accountability Act (HIPAA) of 1996. It has several layers of protection including, user/group account management, “Data Access Groups,”⁴ audit trails for all changes, queries, reports, and Secure Sockets Layer (SSL) encryption. In addition to HIPAA, it can be set up to support other regulatory requirements including Title 21 Part 11 of CFR [7] and FISMA-compliant [28] environments as needed.

Users can export data in native format for several statistical packages, including SPSS, SAS, SATA, R, and comma-separated values files. REDCap has an Application Programming Interface (API), which allows interoperability with external tools, plugins, and mobile apps. REDCap provides an interface for database and case report form creation, either online via a web-based designer or offline using a “data dictionary” spreadsheet template that can be uploaded later into REDCap. This generalized method for quickly creating clinical trial infrastructure has led to REDCap being used in over 3,000 institutions [8].

REDCap is written in PHP, and it depends on other software, such as MySQL and the underlying HTTP server [74]. The developers note that REDCap’s security depends on this underlying infrastructure, which is known to be vulnerable if improperly configured or not maintained [74]. However, even if the underlying infrastructure is updated, REDCap itself still has documented vulnerabilities. According to the latest REDCap changelog, [64], version 9.5.0 (released 12/05/2019) fixed an SQL injection vulnerability that would allow “tech-savvy” users to view any sensitive data they wished. REDCap is an invaluable tool for researchers, but it is not a secure provenance tool. A malicious user could exploit any of these vulnerabilities to falsify REDCap records.

In 2008, Satoshi Nakamoto proposed Bitcoin, the first cryptocurrency [55]. Nakamoto’s work extended the ideas presented by Haber and Stornetta [34], who presented the first cryptographically secured timestamp audit trail. Bitcoin allowed the digital currency to be exchanged between participants without trusting a central authority (e.g., a bank or wire service). Bitcoin has two categories of participants—miners and users. Each miner maintains a local copy of a decentralized ledger tracking the balances in all accounts, and any user transferring Bitcoin broadcasts a signed message that causes all miners to update their local ledgers.

The blockchain is the data structure each miner uses to store all of the transactions making up the local ledger. Transactions are grouped together in blocks, and each block contains a cryptographic link to the previous block (hence a “chain” of blocks). This cryptographic link is a hash—a one-way function that takes an arbitrary blob of data and returns a random value between 0 and \(2^{256} - 1\) with uniform probability. Since the hash is a one-way function, it is computationally hard to determine the original input given the random value. Further, each block is cryptographically signed—ensuring its authenticity and integrity.

In Bitcoin, creating a valid block requires a computationally expensive proof-of-work (PoW). This process is called mining. All miners try to guess a random value (nonce) that causes the block’s hash to have specific properties. The first miner to guess this random value broadcasts the solution. The process begins again, and the next block contains a hash of the latest solution. The group’s consensus is the longest blockchain.

An attacker must create a valid chain that is longer than the current consensus chain to change the consensus. The probability of successfully performing this attack decreases exponentially with each block added to the chain.⁵ Mining ensures that the blockchain is an immutable consensus among all participants, even in the presence of attackers. One caveat is that the PoW mining process is highly inefficient (computationally and economically), limiting the scalability of the PoW-based systems.

While the most popular use-case is currency transactions, blockchains can be generalized to any use-case where a distributed data store requires consensus and immutability. There are many applications and supporting technologies [77] following this trend. Blockchains have also been used to store provenance metadata [36]. The immutability property provides strong guarantees of data integrity. The requirement that each block is signed and contains the hash of the previous block ensures signatures are interleaved throughout the blockchain, and each miner’s signature validates the signatures of every previous block.

To formally prove the fundamental properties of the Scrybe Provenance framework, we provide formal definitions for the cryptographic primitives. An SHA 256 hash function is defined in Equation (1) for message M, and it has the following relevant properties [12]:

For perspective, the current Bitcoin network hash rate⁶ is \(8.5 \times 10^{19}\) hashes per second [10]. At the current rate, it would take \(3.42 \times 10^{49}\) years before the Bitcoin network found a collision for a given hash.

Public key encryption assumes two keys: \(K_{private}\) and \(K_{public}\). The private key is known only to the owner, while the public key is known to everyone. The formal definition for the public key encryption function is provided in Equation (4).

The encryption and decryption functions are asymmetric, as shown in Equation (5). \(C_{public}\) is the ciphertext when the message is encrypted with the public key, and \(C_{private}\) is the ciphertext when the message is encrypted with the private key.

From this definition, we can see that anything encrypted using a private key can be decrypted using the public key. Until recently, RSA has been the standard for public-key cryptography [65]. Elliptic curve cryptography leverages different mathematical principles to reduce the overall key size (significantly) at a slight performance cost [37]. Both of these approaches are susceptible to quantum attacks [4], but those are distant concerns.

Scrybe uses cryptographic signatures to ensure the integrity of data provenance. The formal definition for a cryptographic signature, shown in Equation (6).

The signature, \(S(M)\), is appended to the message, M, so anyone can verify the message’s integrity. Since the assumption is that only the signatory knows the private key, it is assumed that if the decrypted signature, \(H_{256}(M)^{\prime }\), is the same as the hash of the message, \(H_{256}(M)\), then the message originated from the owner of \(K_{private}\) and the message has not been modified. The transaction containing the hash of the changelog entry is timestamped and cryptographically signed by the researcher, and the block is timestamped and cryptographically signed by the miner. Together, these layers of cryptographic signatures satisfy the integrity property. Using the digital signature standard as documented by the National Institute of Standards and Technology [14] guarantees security and portability.

A changelog entry describes a single change made to the secure REDCap database. These entries are not a part of Scrybe—they are an entirely separate primitive used to extend REDCap (or any secure database) with additional provenance functionality. Whenever a user performs any addition, deletion, or modification, an entry is created and stored in a changelog server. The changelog server is a sequence of these entries. Each entry has an associated ID that increases sequentially with each new entry added to the log. The entry contains a modification field describing the change made to the database. The entry is signed to guarantee non-repudiation. Changelog entries can be applied sequentially (up to the most recent changelog entry) to an empty database to construct the current database. The changelog is stored locally by the institution and is not a part of Scrybe. Keeping the changelog server behind an institutional firewall and access control list alongside the REDCap database used for the clinical trial will ensure HIPAA compliance, since only authorized personnel can view the data. When a changelog event occurs, the changelog server submits a transaction to the Scrybe blockchain containing a hash of the changelog entry and non-identifying metadata, such as date, time, and trial ID.

Scrybe transactions contain whole pieces of provenance metadata. Any correlations to other pieces of metadata must be performed at a higher level outside the system. In the case of clinical trials that are performed with an institutional database, the changelog entries are secured by transactions. Whenever a change is made to a record, an entry is stored in the changelog server. Then, a transaction with the changelog hash is broadcast to the blockchain miners. This transaction contains a hash of the created entry, the time, and the entry’s ID. The hash is used instead of the actual entry to ensure HIPAA compliance.

When a transaction is created, it is cryptographically signed by its creator, the changelog server. The signature guarantees that if a transaction exists with a particular timestamp, entry hash, and valid signature, the signatory modified the database in the manner described by that particular entry. The transaction is the foundational building block of secure provenance.

A block contains a group of transactions, the hash of the previous block, and a record of the mining process. Since each block contains a previous block’s hash, an attacker must modify all previous blocks to modify the current block. Since the probability of producing a forged block is almost surely zero (i.e., probability of 0), the blockchain can be considered immutable. The block size is determined by the volume of transactions and the time required to mine a block. The time between blocks is adjusted to maintain a reasonable interval for transactions to accumulate. Each block contains a signature of the miner that generated the block. The signature provides an added layer of security for transactions on the blockchain—the block itself contains a signed timestamp, and each transaction also contains a signed timestamp. Both of these attributes provide interleaved trust, allowing us to trust the timestamp on the changelog entry. Authorized participants can view the transaction, but no one can change it or deny its existence.

Miners generate the blocks in a blockchain and broadcast them to the rest of the miners. Traditionally, PoW mining is too resource-intensive, requiring the constant generation of hashes until the miner solves a cryptographic puzzle. Proof-of-Stake (PoS) systems require that miners stake a sizable amount of currency that will be forfeit if malfeasance is found. While PoS scales better and provides a more economical approach, it requires a native currency and poses centralization risks if a particular miner controls a majority of the currency.

Scrybe is a permissioned blockchain—only authorized miners can generate blocks. Each block is signed, and any block signed by an unauthorized miner is immediately discarded. This lightweight mining approach differs from traditional PoW and PoS consensus algorithms [20]. A miner is randomly selected from the pool of authorized miners, and that miner is delegated to produce the next block. In practice, miners consist of various companies, research institutions, and regulatory agencies. A detailed description and rigorous proof of Scrybe’s consensus algorithm is given in References [19, 78]. Since Scrybe is a dedicated provenance blockchain, no underlying currency can introduce volatility or cause the underlying technology to become obsolete. Scrybe is not based on PoW or PoS, so there are no concerns with environmental impact or greedy nodes. No leader or initial group of nodes is elected like in PBFT-based algorithms, ensuring the process is truly decentralized. Scrybe leverages the advantages of a permissioned blockchain with a secure and scalable algorithm. The complexity is \(O(n)\) as the number of nodes approaches infinity [19].

Consider the standard use-case, shown in Figure 2. A researcher uploads data to REDCap using the Scrybe provenance framework. The Scrybe provenance framework breaks the data into a series of incremental changes that can be applied to the REDCap database. The metadata for each change is used to create a transaction, and this transaction is signed using the researcher’s private key (TXN Signature). This transaction only contains publicly available metadata and the hash of the changelog entry. Simultaneously, each incremental change is also signed using the researcher’s private key (REDCap Signature). The Scrybe framework stores the signed changes in a changelog,⁷ allowing the current state of the database to be reconstructed. Then, the Scrybe transaction is submitted to the miners, where it is incorporated into the blockchain. Finally, the data is uploaded to REDCap.

When an auditor verifies the data stored in REDCap, the first step is to download a copy of the REDCap data and the corresponding Scrybe transactions. The transaction signature is used to verify the integrity of the metadata in the transaction. Next, the REDCap signature is compared to the REDCap signature stored in the Scrybe transaction. Once this signature is verified, it is used to verify the integrity of the REDCap entry. With this verification complete, the auditor can reconstruct the complete history using the changelog. Auditors may elect to use software tools to identify anomalies, such as conflicting changes, which may indicate intentional malfeasance on the researcher’s part.

Consider a malicious user modifying data in the REDCap database without the proper approval. This is shown in Figure 3. The attacker modifies the blood type of a patient. There are two cases, (1) the attacker does not attempt to forge the REDCap signature, and (2) the attacker is a researcher and maliciously updates the database to include false information using the Scrybe framework. The latter case can be addressed by software that scans the changelog and identifies conflicting anomalous behavior. In the former case (shown in Figure 2), the auditor downloads a copy of the REDCap data and verifies the signature. The signature is calculated using all of the fields stored in REDCap. Section 3.5 provided a proof showing that if any of the data changes, then it is detected with the signature. In this scenario, the auditor cannot verify the REDCap signature, showing the data in REDCap was altered.

The final scenario, shown in Figure 4, addresses malicious changes made to the Scrybe blockchain. The prerequisite is that an attacker compromises every Scrybe node. This compromise would include Scrybe nodes hosted at private, public, and federal institutions (e.g., the FDA, DHEC, and CDC). By compromising these institutions, the attacker gains access to the private keys the Scrybe nodes use to sign blocks. The attacker must also compromise the researcher who signed the transaction they wish to modify, allowing the attacker to forge the REDCap signature and the transaction signature. With the forged transaction signature, the attacker can reconstruct the entire blockchain using forged signatures. To our knowledge, there are no security countermeasures that can handle all of the nodes being compromised.

The general provenance requirements were distilled from Table 1. Scrybe satisfies each of these requirements to provide a secure framework for data provenance.

There are two aspects of availability: the original data’s availability and the audit trail’s availability. Scrybe only stores the audit trail, and storing the actual clinical trial data is outside the scope of Scrybe. Since Scrybe is a distributed ledger, there are redundant copies stored at various sites. The Scrybe use-case recommends that each institution and regulatory oversight entity host a Scrybe node. Each of these nodes contains a copy of the blockchain. Further, it is recommended that the Scrybe miners be hosted on a server with modern storage redundancy features, such as RAID, which allows data to be recovered in the event of multiple hard drive failures. With these considerations, the bare minimum availability provided by Scrybe matches the current level of availability. However, these features ensure that a valid version of the provenance proof will be available in almost every failure or tampering event.

Scrybe is a distributed blockchain and has no central database to control. Instead, the distributed mining process determines what information is added to the blockchain. There is no need to assign privileges to modify on-chain data. Instead, each researcher has a public-private keypair that is publicly registered with the blockchain. Each researcher can only submit transactions when they are signed with a valid key, and these transactions are incorporated into the blockchain by a miner with a valid key. This signature ensures that only authorized researchers create transactions on the blockchain.

Assigning rights to modify off-chain data is handled by the institutional database itself. This access control is not affected by our approach and can be done using existing methods. Care must be taken to ensure that all off-chain data modification is linked with an on-chain record. Since only hashes of the changelog entry are stored on the blockchain, there is no need to restrict read access to the transactions. In addition to simplifying the system, this guarantees HIPAA compliance.

Section 2 discusses the several approaches solutions in this space employ. Most popular blockchains, such as Ethereum and Bitcoin, use a PoW mining algorithm. Even permissioned Ethereum blockchains still currently use PoW. Many provenance blockchains leverage existing technology, such as Bitcoin and Ethereum. These mining algorithms are designed to consume all available resources wherever it is running. Using Bitcoin or Ethereum as the basis of a provenance blockchain is economically inefficient and morally irresponsible. Despite this limitation, there are still issues with scalability and volatility. Other solutions, such as Hyperledger’s built-in consensus algorithms, face challenges with scalability and decentralization. There is also a set of solutions that employ novel blockchain solutions. As discussed in Section 2, many of these solutions have scalability and security issues.

Scrybe uses a permissioned blockchain that is built with a novel lightweight mining algorithm [20]. Each miner only expends energy communicating and mining when selected through a non-deterministic algorithm [20]. By exchanging signed messages containing all the received transactions, nodes can validate the block published by the selected node. As part of the message exchange, a new node is chosen to produce the next block. The algorithm is described in detail in References [19, 78]. This algorithm was proven to have complexity \(O(n)\) as n approaches infinity [19]. Scrybe is an efficient alternative consensus algorithm that is capable of registering provenance for multiple clinical trials.

For experimental purposes, the public-use National Longitudinal Mortality Study (NLMS) dataset was acquired from the National Institute of Health’s Biologic Specimen and Data Repository Information Coordinating Center [3]. This large-scale dataset relates mortality to many lifestyle factors, such as age, location, or substance use. A REDCap instance at the Medical University of South Carolina was used to store the data. REDCap instruments were created for this dataset, allowing the data to be input and processed. An example REDCap input interface is shown in Figure 5.

The interface script was used to submit the NLMS data in CSV format to REDCap and the changelog server. The data can be viewed by exporting individual entries in the Scrybe command-line interface. The changelog server’s pull option can be used to download the entire changelog and the entire blockchain to conduct an item-by-item comparison to audit integrity. If there is an entry in the changelog with no corresponding transaction in Scrybe, then a warning is given. An error is raised if an entry’s value does not match the hash in the corresponding transaction. Similarly, if a transaction is modified on the local blockchain database, then anyone can verify that the transaction is invalid due to the invalid “previous block” hash in the following block. If a recent transaction or set of transactions is missing, then synchronization with the rest of the miners resolves the issue.

Figure 6 shows an example of a successful comparison between the blockchain and the changelog. Every changelog entry hash was stored in a block transaction. The blockchain was manually corrupted, so the hash of an entry would no longer match a valid changelog entry. This corruption was identified, as shown in Figure 7, validating the integrity of the changelog.