Introduction
The major sites on the internet today represent the modern kingdom. Facebook, Google, Amazon, eachcontrol a massive domain. Each of these companies collects the data of millions of people in a completelyopaque way. With so much information about people flowing through their servers these companiesposses an enormous amount of control over the perception and dissemination of information.This creates one of the major problems with the internet and digital media today. People interactingwith these sites lack control over their own identity as well as information relating to and supporting it.As a person interacts with sites accross the Internet they leave behind bits and pieces of their identity asmedatadata- phone numbers, credit cards, addresses, etc. If any of this information changes it’s almost
impossible to track down all the occurances across the web and update it. Additionally the more sitesthese bits are stored on the more likely they are to be stolen via hacks or other security breaches.A person may have multiple identities, but an identity once formed cannot be changed. An identityis formed through a history of events which together make it unique. The defining parts of this identitycannot be destroyed. As a person’s identity is spread among more data silos on the internet they losethe ability to maintain and control their own identity. That power is transferred to the owners of thedata silos.
Many have spoken to this problem in the past. In fact, some have suggested that a modern solutionto that problem is to use a “blockchain” as the identity registry. A blockchain most generally is adistributed, append-only ledger of information that in at least one instantiation, bitcoin, has defendeditself against all attempts to undermine or take it down. Additionally, it has been able to do this ina completely open, transparent, and distributed manner- the polar opposite from some of the titans ofthe modern Internet. A particularly salient aspect of blockchain technology is it allows every participantto maintain a self-soverign identity. There is no single, central repository which can be taken down orcorrupted. Instead information is stored in a distributed, ownerless system.We propose MedRec as a way to explore this space. Medrec is an access management system formedical records, but at it’s core it is simply an access management system. Its main goal is to givepatients control over the distribution of their private data. Therefore, by building such an identitycontrol system for medical records, we simultaneously solve a social problem and prove a model for otherapplications.
We also note that identity, like retirement plans and medical records themselves are important aspectsof life that most people avoid thinking deeply about. That means that an important aspect of the Medrecwork is making be something that people will want to use.This thesis will create the basic blockchain-based means for identity control: protection against
identity fraud, a means to register contracts through which your information can be used by others, anda secure, distributed system for holding that information.2We also have a primary goal of doing this in a non-commercial, free, and open way, so that it canbecome widely used and developed. This avoids creating a multiplicity of commercial intermediaries thateach have their own proprietary solutions.In the following pages, I will outline the details of the work, but to understand the context of thisproject requires looking at how it fits into much bigger systems.1.1
Bitcoin
Bitcoin is a cryptocurrency and consensus network used by thousands to millions of people around theworld for sending monetary transactions. Unlike traditional fiat currencies it is not backed by a centralbank or government. Instead every user, developer, and participant in the network has to agree to runthe same rules coded into the software. Instead of storing the state of account balances in a centraltrusted entity, the entire network must come to consensus on the current state and every transactionthat changes that state.
The problem that Bitcoin solves is generally called the Byzantine Generals Problem. This is a problemthat plauges distributed systems with unreliable links, such as the Internet and Bitcoin. A ByzantineFault Tolerant system is one that solves the Byzantine Generals Problem. The problem arises whenmultiple parties cannont come to consensus about the state of the world due to untrustworthy commu-nication. The parties involved cannot agree on any plans as those plans as well as their confirmations maybe lost in transit. This problem is easily solved in centralized systems where one party can unilaterallymake decisions, but in distributed systems even the election of a leader is subject to failure.itcoin solves this problem and allows nodes in the network to come to consensus by using a data-stucture called the blockchain. A blockchain is a list of blocks starting at some ”genesis” block and
extending til the present time. Transactions are consolidated into batches called blocks and appendedto the blockchain. The bitcoin blockchain contains all the transactions on the network going back tothe first Bitcoin transaction in 2009. Different blockchains utilize different mechanisms to deter invalidblocks and fradulent transactions. The one which Bitcoin uses, and the easiest to understand is Prof ofWork (PoW). Nodes can opt in to be miners on the network, which have the ability to append blocks tothe blockchain. Miners are allowed to choose which transactions to include and which block in the historyof the blockchain to build off of. The rationale behind the name PoW is that adding a new block requiresfinding the solution to a very hard cryptographic puzzle. The puzzle is regularly updated in difficultyto maintain an approximately fixed generation time of new blocks. The entire Bitcoin network workingtogether to find the solution to Bitcoin’s puzzle targets ten minutes to find a solution, although miningis a poisson point process so this timing is not exact. This takes an enormous amount of computationalresources, current estimates for the amount of engery consumed by the Bitcoin network are between4.12-4.73 TWh/year. This is more than many countries, putting Bitcoin somewhere between Cambodia3and Afghanistan by power usage. In compensation for putting in the resources to solve the problem,the winning miner is paid a fixed amount of Bitcoin. The block with the most work put into makingit, and by extension the blockchain with the greatest sum block difficulty is deemed to be the correctone. Miners are allowed to build on top of any block in the blockchain, but the greatest expectation offinancial reward comes from building on top of the most recent block.1.2
Ethereum
Ethereum is a blockchain based technology that is used in this project. Ethereum provides capabilitiesthat allow for a much greater breadth of applications than those which Bitcoin could provide.1.2.1
SmartContracts
Nick Szabo first proposed the idea of smart contracts in 1996 to bring traditional law and paper contractsinto the digital age. At the time smart contracts were a theoretical construct of codified representationsof agreements between parties that could superceed the functionality of traditional paper based contracts.A smart contract could be a living document, almost an agent in itself that once authorized by its signerscould autonomouly act to uphold the rules within its code. As of now smart contracts are still primitive and can only support basic if-this-then-that statements and are limited by the blockchain to storingsmall amounts of data. Even so, they are still being used for a broad class of applications ranging fromidentity management, provably fair gambling, fundraising, marketplaces, and access control.1.2.2
Proof of Authority
Ethereum also introduced an alternative system of block validation called Proof of Authority (PoA) as
an alternative to Proof of Work. While the main Ethereum public chain runs on PoW, there are multipletestnets and private chains running on PoA. PoA operates by a federated model, only certain nodesare allowed to make additions to the blockchain. This changes the security model, the system is moresusceptible to fradulent transactions by way of one of those authorities getting hacked. At the sametime, it allows faster transaction confirmation times and the ability to remove the cryptocurrency aspectfrom blockchain technology. Private blockchains bridge the gap between public blockchains which aretrustless and psedonymous, and databases which are centralized. In networks where certain entities arealready semitrusted it may be prudent to use a private blockchain instead of public with those entitiesas the custodians.
1.3
Applications
MedRec at its core is an distributed, accessible, reliable, and concistent access management system. Thisis a simple set of features, but enables a diverse range of applications. For example:
4• Emergency Room - A patient with a medical identification tag can expedite the time it takes foran emergency room to identify exactly what is special about their medical condition. With adistributed access management system a patient can selectively grant all emergency rooms accessto certain medical records. They could also create more expressive permissions, such as giving asecond person the right to make decisions on their behalf during times of incapacitation.• Patient Relocation - When a patient swtiches to a new medical provider all of their medical recordsremain digitally acessible.
• Pharmacy - When visiting an out of network pharmacy a patient can give the pharmacy temporaryaccess to their perscription data. This allows the pharmcy to verify the veracity of perscriptionsin real time against the issuing provider’s database.
• Parental Custodians - A minor can be placed under the custodianship of their parents. A smartcontract governing the minor’s access permissions can be set to automatically grant them the abilityto manage their own medical data when they become of age.2
Concept
MedRec ties together disparate health provider networks with blockchain technology to provide patientswith an access management system for their medical data. Healthcare providers are allowed to continueto maintain their patient records in whatever way they see fit. MedRec provides software that sits ontop of a provider’s database and handles external requests for data. Each request is checked against anaccess list to ensure the requester is authorized to read/write the data. Before blockchain technologythis access list would have to be stored in a database managed by a trusted third party. Blockchaintechnology allows MedRec to store these access permissions in a distributed way, among multiple partiesin the system. It also allows MedRec to manage changes to those access permissions in a decentralizedway. Each patient is able to give others fine-grained read/write access to portions of their medicalrecords. Furthermore patients can authorize others to act on their behalf as caretakers and manageaccess to their data for them.
Ethereum advanced the standard for smart contracts on blockchain based systems as a method forrunning Turing Complete code in decentralized systems. MedRec has an open architecture for contracts,users can expressly view the underlying code that governs their contracts. If they are skilled developersthey may also make modifications to their contracts and release them onto the blockchain.Contracts are Open Architechture
Contracts on Distributed BlockchainIdentity and Privacy are built in5Engage the public in personal responsibility of medical dataWe have the following requirements for MedRec:
1. MedRec will not be a proprietary system. In a project designed to facillitate patient centered accessto medical records it would be discordant to design the system in a closed way. To fully allowcomments and feedback to its design MedRec should be designed under a Free (Libre) Software
License. This way agents can know exactly what they are running and ensure for themselves theirsoftware is not mistreating their financial data.2. Patients should have a singular portal to access their data accross various provider databases. Thismeans MedRec has to be interoperable across and agnostic to a range of storage implementationsby providers.
3. Patients should have fast access times to their data. Currently access time is dependent of juris-diction and can take weeks for an accss request to be satisfied.4. MedRec should provide granular access permissions for patients. A patient should be able to specifya specific medical record, such as blood pressure, x-ray results, perscriptions, etc. and who shouldhave access to that data. It should also distinguish between who is allowed to read the data, andwho is allowed to make modifications to it.5. MedRec should provide improved data quality and quantity for medical research. MedRec em-powers users to safely share portions of their medical data with a third party, thus empoweringresearchers with a new dataset.
6. MedRec should incorporate a distributed method of access control data storage and retrieval. Evenif the majority of nodes on the network are offline a user should still be able to view and modifytheir medical record access permissions. Raw data is still stored within provider’s own databases
so if a hospital burns down all of their patient’s medical data will likely still be lost.7. MedRec should obfuscate any association between real world identities and agents in the system.This applies both to patients and to providers.8. There should be a cryptographically secure association between data in the system and real patientdata stored in a medical provider’s database. Patient’s and providers should be able to attest tothe validity of the patient provider relationships stored on the blockchain.9. Bitcoin and most blockchain based systems require the use of cryptocurrency to facillitate interac-tions with the blockchain. MedRec should bypass this and remove cryptocurrency management asa requirement for using a blockchain based protocol.610. Only authorized agents should be able to make changes to a patient’s data. Authorization should
be a cryptographically secure process.11. Patients as well as their caretakers are notified in real time of changes to records12. All agents in the sytem there should have their identity securely authenticated for interactions witheach other.
13. The system should scale to X amount of users per X ¡needs citation¿
14. There should be separation of authority to minimize the impact of security breaches. It maybe allowable for a hacked or otherwise compromised provider to generate false data for all theirpatients, but it should be impossible for them to harm the relationship their patients have withother providers. Similarly actions taken by a patient should not change the data of other patientsnor compromise the relationship between other patients and their providers.15. MedRec should be able to integrate nontraditional data sources. Wearable devices and mobilephones generate a wealth of day to day health data which could be managed by this system.3
Implementation
MedRec comprises three components: The User Client, Ethereum PoA Blockchain, and the DatabaseManager.
3.1
UserClient
This is the user facing component of the application. All of patients, providers, researchers, etc. willinteract with MedRec through this interface.One major design distinction between the former and current implementation of MedRec is to movefrom a web to desktop application. This is necessitated by a change in the way user data is stored inthe system. Our main rationale for this change comes from the security risks posed by MedRec 1.0’s
implementation, which hashed user credentials together and stored them on the blockchain. Though avalid method of storage, recent work has shown that these hashed credentials are crackable as users donot pick sufficiently secure passwords to prevent these hashes from being reverse-engineered.As MedRec is a distributed application, we can not simply store the user credentials on a centralserver, as other WebApps would. Thus, we propose that the user stores their credentials locally, Whilstthe initial load on the user is somewhat greater — requiring the download and installation of an app,rather than a pure web interface, it allows us much greater freedom in the distribution of notifications,and means that the user has a local means of storing and browsing their own, up-to-date records. We7would also propose that, whilst a user might be reluctant to install an app on their computer, they arelikely to have fewer issues with a phone equivalent, and this could provide the more successful platformfor distributing users’ data. This would also provide offline access to data without the user having tohave downloaded the files of their own accord, which could be invaluable in emergency situations, whereinternet access may not be available.We have chosen the Electron API to develop the front-end. Electron is a cross-platform frameworkthat uses web languages (JS, HTML, CSS) to build native applications. The Electron frontend interfaceswith both local and remote servers via web sockets. The local server holds the user’s private keys and
other credentials, while remote servers are hosted by providers that the user has a relationship with.We have written a desktop applicatioon which runs locally and make queries to the other portionsof the system, the Ethereum Blockchain and the Database Manager. MedRec uses a Proof of Authority(PoA) Blockchain to allow participants in the system to come to consensus about the state of the network.Unlike the first version of MedRec which was based on PoW no knowledge of how to transact usingcryptocurrency is required for users to participate in the system. Users will interact with a familiar webinterface while behind the scenes the application logic translates their commands into calls to providerdatabases and smart contracts.
By making a downloadable application instead of a web application we make a tradeoff in userconvenience. Users have to posses more storage space so they can hold the medical records that theyaccess. They also need enough space to house the MedRec application, including the blockchain witheveryone’s access permissions. With these costs come the benefit of the ability to access medical recordsoffline. Even if a patient’s provider becomes unresponsive the patient can still control their own medicaldata. We consider this to be a necessity for any system that claims to be decentralized.MedRec uses a local database to cache some information from the blockchain and store user settings.Users can create an account and then login with a username and password via their MedRec instance.This login mechanism is not necessary, all a person really requires to interact with the system is their64 byte private key. The username password abstraction is to enhance the usability and familiarity ofthe interface. This login will only work on the computer the user account was created on as it’s only
stored in the local database. Multiple users can create accounts on and use one instance of MedRec.Passwords are salted and hashed before storage so that other users on the same system cannot scryothers’ password. We considered three different algorithms for hashing passwords: PBKDF2, bcrypt,
and scrypt. We chose Scrypt even though it’s the newest of the algorithms because it has been designedto be more resistant to brute force attacks. Unlike the other two, Scrypt is memory hard as well ascomputationally hard for an attacker to brute force. Due to this Scrypt is also the hash algorithm ofchoice for multiple popular cryptocurrencies including Dogecoin and Litecoin.Account recovery is done via recovery seeds. When a user creates an account they not only generate8a private key, but a 12 word recovery phrase or seed. This seed should be written down and keptsecret similar to a passport or birth certificate. When a user signs in with this key they can execute allfunctions on their account, including generting a new private key and recovery seed. The recovery seedallows a user to manage their account in the case they forget their password or their primary computer isdamaged. A hash of the recovery seed is stored on the blockchain with a tag associating it with the user’s
account. The seed does not need to be salted since they are verifiably unique to each private key. Whena user logs into a MedRec instance with their recovery seed the software can query the blockchain tocheck which account the seed belongs too. This makes MedRec truly decentralized, even though accessis the easiest from their primary computer, a user can easily move to another device and still securelyaccess their medical data.
This model is completely different from that used in the previous iteration of MedRec. MedRec1.0hashed together the username and password of users and placed them on the blockchain in a registrycontract. This provides universal access to a user’s MedRec account, similar to our use of recovery seeds.The key difference is that the user is effectively setting their own seed. This method of key derivationfrom a user chosen seed is called a brainwallet. Past work ¡cite brainflayer¿ ¡cite myself¿ has shown
brainwallets to be a completely unsafe for practical wallet generation. Inherently humans do not provideenough entropy to create a secure key from a user chosen phrase. The recovery seeds generated byMedRec are 12 words that are simply and alternate encoding and checksum for a private key so we loseno information nor security by using them. We also make a tradeoff, while on a personal device the usercan use their username and password, and if the password is forgotten the recovery seed can be used toback it up. Additionally, the move to local accounts increases the barrier to entry for attacks againstusers. There is no capability for running a general attack against all the users of the entire system, anattacker must run target attacks to obtain the salted and hashed password for each user they want tocompormise and run brute force attacks to decrypt that data.3.2
RPC
Remote Procedure Calls (RPC) are commands issued by one computer to invoke functions on another.The protocol is transport agnostic, and can be applied to TCP, HTTP, Websockets, and other protocolsfor sending data over the internet. MedRec uses RPC in two ways, between the client and a local patientdatabase, and between the client and a remote provider database.3.3
Blockchain
Before choosing to use a private blockchain we looked at many other options. When implementedcorrectly blockchain based systems can provide:
91. Consensus among a globally distributed set of peers so they are in aggreement on what is true andand what is not true
2. Efficient reconcilliation between unharmonious states of reality to the most probable state3. A distributed data storage and computation network4. A system that is secure by design instead of as an afterthought5. A system that runs without the need for a central server or trusted authority to resolve disputesor coordinate participants
6. Transparency to every one involved of the current set of rules agreed upon7. Access for anyone with an internet connection to participate8. Psudonymous identities- users are not inherently linked to their real world identities so deanonym-ization requires targeted attacksDeciding on a blockchain required analyzing what a potential MedRec would look like on each ofthose systems. A few analysis of alternatives used by other systems are below.3.3.1
Bitcoin
Bitcoin is the original use of blockchain technology and it’s still considered the most stable and secureimplementation. It has never been hacked nor stopped running for the past 8 years since its inception.Other systems, similar in aims to MedRec, have been built using it and MedRec itself could operate on it.Although Bitcoin has it’s own version of smart contract, their capabilities are greatly reduced from thoseavailable via the Ethereum Virtual Machine. Most other cryptocurrencies have the same drawbacks asBitcoin.
Bitcoin has a simple scripting language which is uusually used to represent the inputs and outputsof transactions. It allows for arithmetic and comparative operations on bits, signature generation andverification, time locks, and call stack operations. Each transaction is also allowed to include up to 40bytes of data. This is enough space to include a small hash or reference to data living off the blockchainsuch as a land title ¡needs citation¿ or graduation certificate ¡needs citation¿. The data itself has to be
managed by other means, creating more complexity as applications have to keep track of the location ofthe pointers on the blockchain and then query another service to finish fulfilling a request.Additionally every transaction on the Bitcoin networks costs money and takes time. The current feefor a transaction on the network to get confirmed in about 10 minutes is currently $4, but this number can
spike up during periods of heavy usage such as when the bitcoin price varies too fast. Heavy utilizationof the blockchain creates a backlog with transactions with higher fees getting processed first. To mitigate10these costs and delays, applications using Bitcoin for storage tend to batch transactions so they can besubmitted with a higher fee and get confirmed faster. The downside is batching transactions also causesdelays. For some of the usecases we see for MedRec a 10 minute delay is unacceptable, especially whenan alternative exists.
3.3.2
Public Ethereum
The public Ethereum network has some of these same limitations. An Ethereum transaction on averagetakes 15 seconds to confirm and the average transaction fee is $.30. For both parameters this is a markedimprovement over Bitcoin. But an optimal solution would get rid of the cost completely.All transactions on the public Ethereum network are public and must be stored by all the fullnodes on the network and this causes implementation difficulties for a project such as MedRec whichis dealing with sensitive data. Static analysis has been used to deanonymize users of Bitcoin ¡needs
citation, use the mt gox hacker case¿ and I have done research previously ¡needs citation¿ exploring
dynamic deanonymization on the Ethereum network. Since data on the blockchain is persistent, itlacks retroactive identity confidentiality. At some point in the future an algorithm may be developed tocorrelate and deanonymize many users of a public blockchain. By not using a public blockchain MedReccan defend against this attack.
Along with its powerful Turing complete programming language, the public Ethereum blockchainbrings along all it’s programs. A full node on the network must process all the transactions and blocksgenerated on the network. The Ethereum developers have advanced plans to mitigate this, but theoverarching fact remains that for the system to remain operational some nodes must track everythingthat happens on the network. On a private blockchain we can model the growth of the system andexperimentally stress test it. Nodes will not have to store any data that isn’t required for the system to
run.
3.3.3
Alternative EVMs
Other alternatives to and implementations of the Ethereum EVM exist, with different consensus para-meters, target audience, or capabilities. Some of them, such as JP. Morgan’s Quorum ¡needs citation¿
also allow for private transactions. ErisDB has had support for private blockchains well before the Go-Ethereum client MedRec uses. Hyperledger Fabric has not yet reached version 1.0, is being developed asan enterprise grade smart contract platform based on Node.js and Java. We are using a private Ethereumblockchain since the Ethereum ecosystem is the most diverse and has the most public scrutiny and sup-port. The Go-Ethereum client is the most used Ethereum client, developed primarily by the EthereumFoundation. Over time we expect the capabilities offered by this client to approach those offered by otheralternatives. Many of these alternative blockchain solutions use the same Ethereum Virtual Machine,11providing easier portability between systems. As the Ethereum ecosystem further develops we may portour smart contracts to another blockchain if necessary.3.4
Blockchain Choice
MedRec uses a PoA blockchain developed as part of the Go-Ethereum client. PoA is used to createprivate blockchains, where only a federated set of nodes are allowed to make modifications to the sharedledger. The data stored on the blockchain can still be made public outside of the federated set of nodesmaintaining the blockchain. As PoA changes the fundamental game theoretic security model of PoWblockchains from a financial incentive to trust based. The intrinsic cost of trust replaces the extrinsicfinancial cost. The security of such blockchains depends on a choice of federated nodes.We decided to make providers the authorities on the blockchain. These entities already are entrustedwith the safety and security of their patron’s medical data. In many countries they are legally requiredto comply with strict standards around the protection and handling of patient medical records. Thismakes them ideal custodians of the access rights which govern MedRec. In MedRec medical providersare able to be voted in as voting authorities by the current set of authorities. An authority is able toform blocks and add them to the blockchain. Since the identities of all participants is known regulationcan be done external to the blockchain. The penalties for abusing their abilities as an authority wouldbe severe as they would likely be penalized under HIPAA provision.Even as authorities, the attack surface for providers remains low. A provider has the ability tovalidate transactions and add them to the blockchain. Unlike PoW there is no external rate limitingmechanism such as computational power. A properly functioning implementation of a PoA client inhibitsits own rate of block generation so the network isn’t needlessly flooded with data. –sybil attack
Since each transaction is public other providers are able to validate every transaction as well. Aprovider is incentivised not to generate fradulent data because they will be easily identified. Furthermorethe type of attacks on the system by providers is limited since their only duty is to confirm transactions.Providers cannot impersonate other actors in the system or generate false permissions for their patientsas they do not have those private keys.3.5
Bootstrapping
Although they may become decentralized systems, blockchains need to be initially setup by a centralinstitution. The bootstrapping of the PoA blockchain for MedRec was no different. Documentation onthe technical capabilities of PoA and the progress of its implementation in go-ethereum remains scant atthe time of this writing. At this point the go-ethereum blockchain is still considered a work in progressand in practice getting the blockchain to run intially was a finicky process.There is a weakpoint in the decentralized nature of blockchains, which is introducing or bootstrapping12new users into the network. The previous sections discussed various methods of ensuring consistency,availability, and correctness of data on the blockchain, but left open the question of how new usersjoin the network. Even with a decentralized network, blockchains, including MedRec, generally retaina centralized aspect to the network in the form of bootnodes. A bootnode is a node on the networkwith the sole purpose of matchmaking new users with nodes already on the network. They are akin toDNS root authorities and Bittorrent trackers. These nodes are hardcoded into the MedRec client. Ifcompromised they would ¡NEEDS EDIT, MAYBE NOTHING?¿
3.6
Smart Contracts
There are three types of smart contracts in MedRec. These are written in Solidity and run on our PoAblockchain.
3.6.1
Agent
The Agent and it’s derivative the AgentGroup contracts represent actors on MedRec. They are analogousto the SummaryContract in MedRec v1. Indviduals interact with the system using the Agent contractsas a proxy and multiple agents can form an AgentGroup. These contracts hold data about the entitiesthey represent. For patients they store a list of PatientProviderContracts, and for providers they holda list of provided permissions. The AgentGroup is provided as a convenience to give permissions to alarge set of agents at once. For example, a group of emergency rooms from different providers may joininto one AgentGroup allowing a patient to give them all access to basic bloodwork data in one step. Themembers of the AgentGroup can change without any further action on the part of the patient.3.6.2
AgentRegistry
This contract keeps track of the providers in the system which are registered as signers and in charge of maintaining the blockchain. It also provides a mapping between a particular patient ethereum address and its agent contract.
Relationship
This contract represents the union between to Agents or an Agent and Agent Group. The actuall accesspermissions that the entire system of MedRec is designed to protect are stored here. This contract allowsgranular specification of Read/Write permissions and time locks to temporarily grant access. Throughthis interface third parties can gain access to a patients data while the patient maintains the ability torevoke this right at any time.
3.7
Anonymitiy
Patients have some anonymity in the system as their identity is only known to those organizations whomthey share thier identity with. Yet this is still not enough protection, as an inintended side effect ofusing a single smart contract to represent a patient (the Agent contract) allows anyone who discovers a
patient’s Agent contract to decipher all other relationships with providers. One example of a case thiswould be harmful is when a patient shares portions of their medical records with both their employeer13and a gynecologist. The employer could detect this association and find a pretense to discharge theiremployee to avoid paying health insurance.We solve this in two steps. The first step is disassociating each patient identity from provideridentities. The solution to this is simple, each provider makes a new ethereum account for each patientprovider relationship. We call these patient specific accounts delegate accounts. It’s easier for a provider
to manage these extra accounts, in practice it would be an extra column of data stored along with auser’s name in a database. This method also allows a patient to continue interacting with the systemwhile keeping track of only one account.The second step is more complex and it solves the problem with metadata that the first step leavesopen. Even though a patient is not iteracting directly with their provider’s main account, that main
account is still being used to sign blocks containing the patient’s transactions. Over time this correlationcould be used to associate patient with providers. To solve this we do something which could not bedone with public blockchains. Instead of confirming patient transactions themself a provider asks anotherprovider to do it for them. Remember that in MedRec providers also act as authorities and sign blocks.The transaction is shared off the blockchain via other Internet protocols with another provider in around-robin fashion before ultimately being committed to in a new block.The primary advancement of zero-knowledge proofs in the field of cryptocurrency is the ability toexchange coins between two parties without revealing to a third party that the transaction ever happened.This is done using zk-SNARKS. One proposal for an application in MedRec is a form of zero-knowledgeproof, each patient encrypts information about the viewers of their medical relationships so a viewer canprove they have access to data from a medical relationship without knowing who either the patient orprovider are. However, zeroknowledge proofs have their own limitations which we would like to avoid.One implementation in the cryptocurrency ZCash ¡TODO reference¿ utilizes a trusted setup phase.
Although the ZCash team took extreme precautions to insure this phase was not compromised, the factremains that if someone hijacked the secret keys used in this phase they could generate arbitrary amountsof money without anyone knowing. Anologously in MedRec a person could give themself permissionsto read arbitrary patient records. Additionally creating a ZK proof is time and memory consuming,with the latest implementation of of ZCash requiring 7 seconds and 40MB of RAM to prove ¡TODO
citation cultivating zkznarks¿. Again, this does not completely rule out the use of zk-SNARKs, butleaves open the question of is there an alternative. A more recent advancement by Narula et. al is inzkLedger ¡TODO citation¿ which also uses zk-SNARKs for privacy preserving transactions. zkLedgerdoes not require a trusted setup phase. The drawback is transaction creation and verification times aredependent upon the number of nodes in the network. Creation and verification time of transactionsscales linearly with nodes. While zkLedger requires approximately 90ms for 4 participants, it requires400 for 20 participants. zkLedger achieves this by requiring every transaction to encrypt and include14entires for every participant on the network, not just the intended recipient for the transaction. For asystem like MedRec which is designed to scale to millions of nodes, the approach used by zkLedger isclearly infeasible.
3.8
Human Meaningful Names
There are three properties of a naming system which can be difficult to get simultaneously- HumanMeaningful, Secure/Unique, Decentralized. Zooko’s Triangle is a conjecture that it’s impossible to achieve
all three. Although that conjecture has since been proven false, achieving these remains complicated inpractice. In MedRec we balance between the three in two different ways.It’s generally convenient for signers to be able to easily and uniquely identify each other with ahuman readable name. To achieve this new signers are allowed to propose themselves to the list with aname of their choosing. Logic in the smart contract managing the proposals prevents multiple signersfrom choosing the same name. Therefore we have human meaningful and unique names, in a pseudo-decentralized system.
We also allow patients to associate names with the providers and other entities they interact withvia MedRec. These names are human meaningful, but remain linked to the entity’s public account so
they remain unique even if the user chooses to refer to two people by the same name. This naming iscompletely centralized, it’s only meant for one user to keep track of their own relationships.3.9
Handling Sensitive Data
One aspect of the system that we hope to integrate is a fluid handling of sensitive data that is appropriateto the context for which it is required. For example, if you are in receipt of a prescription for methadone,you may well not want all your care providers to access this information, though it will be essential forsome care providers to have access to this data, especially as it would prevent double prescriptions acrossdisparate healthcare providers.
Resolving this issue requires the use of a flexible ‘access rights’ system, where different actors inMedRec are afforded different viewing permissions of a person’s data. For example, a patient shouldmaintain the right to withhold information about their methadone prescription, unless they are in asituation where that is vital knowledge to the actor administering care.A patient can specify on the level of granularity of a single viewer in a particular relationship whatmedical data that viewer is entitled to access. This permission can be specified to start on a particular dayand last for a specified number of days. This information is stored publicly accessible on the blockchaininside Relationship contracts. As described in an earlier section, a patient has one Relationship contractper provider, with multiple viewers listed inside. This contract also contains information about whichpermissions each viewer possesses. This information is public so there is minimal cost to read it. When15a viewer makes a request to read information from a provider the provider can easily compare thepermissions on the data that the viewer is requesting to the list of permissions afforded on the blockchain.Scalably managing custom-defined permissions may be an issue on the blockchain. Providers maypotentially be using an unbounded set... ¡TODO what do we do about this section¿
3.10
Message Authentication
The same signing mechanism used for transactions in MedRec can similarly be utilized for signingarbitrary messages. In MedRec all messages to providers requesting data must be signed.4
Patient-System Interaction
TODO
we are creating some standard permissionsTODO Potential Standard Permissions:
GP — May view your prescribed medication, referrals and medical history.ER — May view vital information that could affect emergency treatment: blood type, allergies, Does
not require explicit permission from the patient to view, but permissions expire after a certain amountof time.
Pharmacist — Before prescribing over-the-counter drugs, access to allergy-type information is invalu-able in a pharmacy setting. In addition, there may be additional flags for medicines already prescribedthat would clash with possible prescriptions. This could be optional, but might help a great deal in caseswhere a patient would otherwise be given wrong medication, or possibly prescribed the same thing twice.5
Acknowledgements
I thank my supervisor, the venerable Dr. Andrew Lippman. I also thank the other people directlyworking with me on this project in the Media Lab Viral Communications group, Kallirroi Retzepi andAgnes Fury Cameron. I would also like to thank the elusive yet revered inventor(s) of Bitcoin, Satoshi
Nakamoto for it is with their invention that I am able to put myself through graduate school.16References
[1] https://bitcoin.org/bitcoin.pdf
[2] https://en.wikipedia.orgm/wiki/List of countries by electricity consumption[3] http://blog.zorinaq.com/bitcoin-electricity-consumption/
[4] https://en.wikipedia.org/wiki/Byzantine fault tolerance
[5] https://bitcointalk.org/oldSiteFiles/byzantine.html
[6] https://nakedsecurity.sophos.com/2013/11/20/serious-security-how-to-store-your-users-passwords-safely/
[7] ttps://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki
[8] ttps://github.com/ryancdotorg/brainflayer
[9] ttps://github.com/bitpay/bitcore-lib/pull/187
[10] ttps://github.com/bitpay/bitcore-mnemonic/pull/61
[11] ttps://github.com/trufflesuite/ganache-core/pull/48
[12] ttps://github.com/ethereumjs/ethereumjs-vm/pull/248
[13] ttps://blog.z.cash/cultivating-sapling-faster-zksnarks/
Creative Commons Attribution 4.0 International License (CC-BY 4.0)