Our Mission

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.

Our Work

Our focus was researching different avenues to enable the user to dynamically and securely give access to files or data to multiple users in a public blockchain network; and to integrate such mechanisms within ResilientDB.

Use Cases

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.

Deliverables

What our team learned and built during Fall2020

Proxy Re-Encryption through PyUmbral

Adaptation of pyUmbral threshold re-encryption through a C++ interface.

Visit GitHub

Smart Contracts through ResilientDB

Introduction of two smart contracts that send/receive information to/from worker nodes.

Visit GitHub

Initial Model Plan

Alice-Bob Interaction Diagram

What is Proxy Re-Encryption?

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.

How does Proxy Re-Encryption Fit into Our Model?

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.

ResilientDB

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.

What we modified on ResilientDB

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.

Avenues Explored

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.

NuCypher

What
Cryptographic Infrastructure for Privacy-Preserving Applications. Uses pyUmbral PRE under the hood to dynamically give or revoke access from multiple users.

Pros
Fits our initial Alice-Bob model very well.
Has its own engine for PRE.

Cons
Limited Documentation for integrating to networks other than Ethereum.

HyperLedger

What
Suite of stable frameworks, tools and libraries for blockchain deployments. Focus: HyperLedger Fabric distributed ledger software.

Pros
Many capabilities similar to dynamic access control.

Cons
Setting up personal private channels is a huge barrier to entry for individuals.
The intent of the private channels is so that large corporations can manage them whisch is against our mission.

IPFS

What
Flexible framework that provides reliable and secure, decentralized solutions to storing and accessing sensitive information.

Pros
Easy to implement.
Robust control over the data uploaded.
Added layer of encyption.

Cons
Written in python, while our work is primarily in C++.
Complexity to integrate with ResilientDB fell out of scope.

PRE schemes

What
Performing proxy re-encryption uses an incredibly complex and specific hashing algorithm, one that uses elliptical curves. We explored several other PREs before settling on pyUmbral.

Pros
If found, can be used to create C++ program to manually re-encrypt files as needed.
Will require a deep dive into ResilientDB's architecure to implement, which enriches learning experience.

Cons
Difficult to find a cryptographic algorithm that uses elliptical curves AND can be easily integrated with a C++ program.

Key Takeaways and Next Steps

Project Impact

Worked with ResilientDB and Proxy Re-encryption to implement a way to encrypt messages.

Future

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.

What we learned

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.

Development Timeline

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 Radio
What Is Being Built Today, What Companies Are Looking For?
Week Two Brainstorming Ideas Introduction To Distributed Consensus
Principle Foundations Of Bitcoin
How Ethereum Works
Week Three Solidified Team Project Idea: Permissions Based Medical Data Access Innovating With Bitcoin
Principle Foundations Of Ethereum
Week Four Created Project Proposal Document Introduction To Decentralized Applications
Developing Decentralized Applications
Week Five Researched Ethereum, Hyperledger, ResilientDB, NuCypher Ethereum 2.0: Serenity
Why Only Permissioned Blockchains Matter: A Realist’s Perspective
Week Six Research proxy re-encryption schemes, Hyperledger, NuCypher
Run ResilientDB		 Principle Foundations Of Hyperledger Fabric
Principle Foundations Of LedgerDB
The History & Philosophy Behind Consensys
Week Seven Teams set up respective tools in proxy re-encryption, ResilientDB
Research IPFS
Midpoint Check in		 Principle Foundations Of R3 Corda
Intro To Zero-knowledge Proofs
Principle Foundations Of Radix
Week Eight Proxy re-encryption: wrote python and C++ script that works with PyUmbral
ResilientDB: meeting with Suyash about messages
Set up IPFS		 Principle Foundations Of Hedera Hashgraph
Principle Foundations Of Near: Sharding Revisited
Economics Of Proof Of Stake & Sharding In Polkadot
Week Nine Finished Proxy Re-encryption script
ResilientDB focus on implementing smart contracts		 Introduction To Decentralized Applications
Developing Decentralized Applications/td>
Week Ten Created smart contracts which can send and receive messages
ResilientDB: Meeting with Sujjad about smart contracts
Final Project Presentation		 Intro To Decentralized Finance
Principle Foundations Of Libra