Proxy Re-Encryption through PyUmbral
Adaptation of pyUmbral threshold re-encryption through a C++ interface.Visit GitHub
To use blockchain technology to safely and securely store patient medical data that is completely in control of the patient, as well as provide the means to easily give access to the records between various healthcare providers. The current healthcare system makes transfer of healthcare information difficult, failing to fulfill the needs of patients switching insurance systems or healthcare providers. To bridge this gap, we propose Resilient Records, to allow dynamic transfer of medical data.
In addition to transfer of medical data from a patient to a hospital, ResilientRecords can help you transfer data in an encrypted format for your use case.
Potential use cases include managing the amount of data different people have access to, transferring self employed/gig worker history to a customer(eg. Uber drivers use blockchain to control their own history), and sharing location data logs for travel based occupations.
Alice-Bob Interaction Diagram
Proxy re-encryption (PRE) allows someone to encrypt data using a public key and then give access to that encrypted data to someone else without ever sharing a user’s personal private key. PRE achieves this by using a proxy as a middleman that performs re-encryption on that encrypted data. Re-encryption is the process of taking a conversion key and using it to swap the encrypted file from being encrypted by one public key to being encrypted by a different public key.
To elaborate, the owner of the encrypted data takes their personal private key and the public key of the recipient they’re trying to give access to. They take the private and public key and create a conversion key. The importance of the conversion key is that, if it used to encrypt the already encrypted file, it will remove the owner’s existing encryption and convert the file to being encrypted with the public key of the recipient. The process of re-encryption using the conversion key is relevant and necessary because the proxy that is performing the re-encryption is not capable of un-encrypting the original file: encrypting with the conversion key directly converts the encrypted file from the owner’s encryption to the recipient’s encryption. This is important because it means that none of the proxies have to be trusted, as it’s impossible to decrypt the file with the conversion key.
We are building this system using the ResilientDB architecture which means that we have to fit PRE into the ResilientDB architecture somehow. So, in the scheme of PRE, the proxy will be the ResilientDB nodes/miners. That means that the ResilientDB nodes miners will be responsible for storing the conversion key that is generated when access to an encrypted file is given. Additionally, the ResilientDB nodes/miners will be responsible for the re-encryption of a given file using the conversion key that is stored on the blockchain. The blockchain will be responsible for removing conversion keys when the owner of an encrypted file requests to revoke permission to a recipient.
We will be using ResilientDB as the system that handles consensus as well as the blockchain. We plan to fit ResilientDB to handle the inputs after running PRE and output to a distributed file storage using IPFS. With the multithreaded pipeline that ResilientDB employs using batch, worker, execute, and checkpoint threads, we believe that it should be sufficient for high throughput dynamic access control.
The first thing that we did is learn how the entire ResilientDB network works: how the client creates batch requests and messages, sends them to a primary thread, distributes the messages to the other worker node, and return a result back to the client node.
We created a smart contract that uploads an encrypted message as well as a re-encryption key to ResilientDB to be stored so that others can be given access to a specific person’s files.
We created a smart contract that allows people who have access to a file retrieve the encrypted message as well as retrieve the re-encryption key so that they can decrypt the file to plaintext and read it.
Several weeks were spent researching other platforms, networks and cryptographic engines in order to find a solution model that matches our initial implementation model closely; or could be used tangentially with our design plan for ResilientDB for a stronger development project within the scope of ten weeks.
Worked with ResilientDB and Proxy Re-encryption to implement a way to encrypt messages.
We want to integrate IPFS to store large amounts of data in file format. We also want to integrate the proxy re-encryption code into ResilientDB. The reason that wasn't achieved is because the proxy re-encryption implementation we created relies on pyUmbral which is written in Python. We really struggled to figure out how to get Python running on the ResilientDB docker containers. If Python was installed on the docker containers, integrating the PRE code we created into ResilientDB would be really easy because we already created the smart contracts that would run the PRE code.
We studied and researched different blockchain networks, learned how to set up nodes, work with large codebases, integrating different technologies together. We learned from industry level experts and built teamwork skills.
What we're doing in and out of lecture
|Week||Project Goals||Course Goals|
|Week One||Forming Team||Blockchain At Expolab: Our Resilient Journey, Vision, Bitcoin RadioWhat Is Being Built Today, What Companies Are Looking For?|
|Week Two||Brainstorming Ideas||Introduction To Distributed ConsensusPrinciple Foundations Of BitcoinHow Ethereum Works|
|Week Three||Solidified Team Project Idea: Permissions Based Medical Data Access||Innovating With BitcoinPrinciple Foundations Of Ethereum|
|Week Four||Created Project Proposal Document||Introduction To Decentralized ApplicationsDeveloping Decentralized Applications|
|Week Five||Researched Ethereum, Hyperledger, ResilientDB, NuCypher||Ethereum 2.0: SerenityWhy Only Permissioned Blockchains Matter: A Realist’s Perspective|
|Week Six||Research proxy re-encryption schemes, Hyperledger, NuCypherRun ResilientDB||Principle Foundations Of Hyperledger FabricPrinciple Foundations Of LedgerDBThe History & Philosophy Behind Consensys|
|Week Seven||Teams set up respective tools in proxy re-encryption, ResilientDBResearch IPFSMidpoint Check in||Principle Foundations Of R3 CordaIntro To Zero-knowledge ProofsPrinciple Foundations Of Radix|
|Week Eight||Proxy re-encryption: wrote python and C++ script that works with PyUmbralResilientDB: meeting with Suyash about messagesSet up IPFS||Principle Foundations Of Hedera HashgraphPrinciple Foundations Of Near: Sharding RevisitedEconomics Of Proof Of Stake & Sharding In Polkadot|
|Week Nine||Finished Proxy Re-encryption scriptResilientDB focus on implementing smart contracts||Introduction To Decentralized ApplicationsDeveloping Decentralized Applications/td>|
|Week Ten||Created smart contracts which can send and receive messagesResilientDB: Meeting with Sujjad about smart contractsFinal Project Presentation||Intro To Decentralized FinancePrinciple Foundations Of Libra|