Hippocrates and Self-Sovereign Data
Hippocrates was an ancient Greek physician and is considered a father of modern day medicine. His document, the Hippocratic Oath, widely held sacred by physicians, requires the practitioner (among many things) to treat the ill to the best of one’s ability, to teach the secrets to the next generation, and most relevantly: to preserve patient privacy.
We are proud to present complete data self-sovereignty for users of Hippocrates: the first tele-dermatology application running on the Ethereum blockchain. We’ve been working hard to encrypt the data end-to-end and provide complete control to the end user over their data. Cases will only be accessible by the patients, and only the patient may grant case-by-case access to doctors.
The Hippocrates Beta will be released soon, and we wish to talk about the encryption protocol. In this article I will detail the inspiration to our design and how we went about implementing it. We encourage any feedback or criticism so that we can improve the service.
The Design
The main user flow for our application is quite simple:
- The patient creates a new case by taking photos and answering a few questions.
- A doctor reviews the case and submits a diagnosis.
- The patient can view and accept the diagnosis, or request another.
This flow informs us of our core design requirements:
- Cases must be viewable only by the patient
- Patients must be able to share cases with a specific doctor on a per-case basis
- Doctors must be able to share diagnoses with patients on a per-case basis
Let’s add some additional constraints:
- The user must be able to lock the app and unlock it with a password
To prevent unauthorised access to a user’s account we should allow them to lock the app and unlock it using a password. - The user must be able to change their unlock password
Eventually the user may reveal or share their password, so they must be able to change it. - Changing the password must be fast
Regularly changing passwords is good for security; it should be fast and free in order to encourage good practices. - Sharing a case with a doctor must be fast
Given that our app will run in web browsers, re-encrypting megabytes of photos and metadata may slow down the browser and will not yield a good user experience.
Our application will be storing medical records, so let’s now take note of Health Insurance Portability and Accountability Act. This is a piece of legislation in the United States that provides data privacy and security provisions for medical information. HIPAA requires stored data to be encrypted, and defers to the Federal Information Processing Standard and National Security Agency for approved encryption algorithms.
- Our encryption algorithms must be FIPS validated and NSA approved.
Most standard algorithms are approved, such as AES, Triple-DES, and RSA. Elliptic Curve Diffie-Hellman is approved with caveats; the chosen curve must be selected from FIPS-defined set of ‘safe curves’. Unfortunately the cryptocurrency favourite secp256k1 is not among the approved curves.
The Implementation
Our application strives to be as decentralised as possible, so our infrastructure consists of an IPFS server, a static front-end, and smart contracts deployed to Ethereum. Case information is stored encrypted in IPFS, and all secrets are stored in each user’s browser.
You may notice that the language and patterns we use take much inspiration from a password manager called 1Password. You can read about their approach in their excellent whitepaper.
On sign up we generate a 256 bit AES Secret Key for the user.
The user then chooses a Master Password which is combined with a salt and passed through pbkdf2 to derive a key that is used to encrypt the Secret Key locally in the browser. The Master Password can be changed quickly and for free; it is only used to encrypt and decrypt the Secret Key locally.
When a case is created we generate a 256 bit AES Case Key. This key is used to encrypt and decrypt the case’s photos and data stored in IPFS. The Secret Key is combined with a non-secret salt and passed through pbkdf2 to encrypt the Case Key. The encrypted Case Key is then stored in the case contract.
Encrypted case storage and retrieval for patients is complete!
To share a case with a doctor, the patient effectively needs to send the doctor an encrypted ‘message’ whose contents is the case key. This is a perfect use case for the elliptic curve Diffie-Hellman key exchange.
Using the secret key we derive a public and private elliptic curve key pair using curve P-521. The user’s public key is stored in the blockchain. The private key is stored ephemerally in the user’s browser. Patients and doctors are able to derive a secret Shared Key using their private key and the other’s public key. This Shared Key is secret and unique to each pair of users, so it serves as an excellent encryption key.
When a patient shares a case with the doctor, they ‘authorize’ the doctor by re-encrypting the Case Key using the above mentioned Shared Key. Let’s call the re-encrypted key the Doctor Case Key. The doctor is able to decrypt the Doctor Case Key using the Shared Key and extract the Case Key, which is then used to decrypt the case files.
Finally, when the doctor submits their diagnosis it is encrypted using the Case Key. The patient is able to view the diagnosis with the same key as with the case.
Sharing complete!
Conclusion
This is our first iteration of the MedCredits encryption protocol. We’re excited to offer beta testers complete privacy even if the cases are just test data. The beta testing will be an opportunity to ensure a smooth user experience around key management, so there will likely be further iterations to our design.
We hope this article was useful to those seeking insight in how to build self-sovereign data. Once again, if anyone has feedback we’re all ears. We’re keen to provide the smoothest and most secure experience possible.
To find out more about the MedCredits healthcare ecosystem, please join the discussion on our Telegram or join our mailing list!
