Over-Optimizing Security? Storing Encrypted Data on a Server While Private Key Remains With User

Question

Assume that I have a server storing sensitive user information (think medical records). I want this data to be encrypted on my server at almost all times. Only when a doctor needs to access the data of a particular person, it should be decrypted, processed and encrypted again.

I want to give the user as much control over their data as possible, while minimizing risks for my application. If 99% of the data is encrypted without keys on the server, only 1% of the data (the one ephemeraly processed) is at stake.

I've come up with the following approach:

1. The user's private key is stored on their smartphones.
2. If a doctor needs to access a user's files, the doctor can make a request from the software, which sends a push notification to the user.
3. The user opens the app, clicks and on release.
4. The private key is sent to the server to decrypt the data and deleted afterwards. (this is the part that's giving me a headache)
5. The data is processed and then encrypted again using the user's public key.

Here's my question:

Is there some better/standardized approach to this? I was thinking of using the private key to generate some sort of temporary key which is only valid for a given duration but don't know if that's possible.

Does it even make sense to improve upon this process? The users need to trust me and the doctor that we don't keep an unencrypted copy of their data anyway - why should I bother increasing the security at a point which is not the most vulnerable (processing step with data ephemeraly analyzed).

Important: It is necessary that the data is decrypted on the server. The data could be something like biomedical records which are many Gigabytes in size and need to be analyzed, so doing the decryption on the doctor's machine is not an option.

Answer 1

I am afraid that whatever you do to pretend that you have no access to that data, it will be close to snake oil security. The central problem, is that as the data has to be encrypted and decrypted on your server, the server has knowledge of the plain text data. That is enough. Whatever your application can do, if your system were to be compromissed the attacker could access this information at the moment when the legitimate application can.

So you will have to take the full responsability of having that highly sensitive information on your system, and handle it accordingly. That means respecting the highest security practices (including physical security and staff control) or at least the legal requirements for your country and your clients countries. Of course encryption at rest is a minimal requirement, but it may not be enough...

Answer 2

One option is to deploy this as a 'zero-trust' application, where all encryption and decryption of medical records takes place on the users' and the doctors' devices; and your server only sees encrypted medical records of the users, and never sees the decrypted records, or the keys needed to decrypt the records. This requires a key exchange protocol between the users and the doctors, but there are standardized methods for this. The users and the doctors do not need to trust you or the server (or trust that your server doesn't get hacked), because your server has 'zero-access' to the plaintext medical records (hence the name 'zero-trust').

However, you state at the end of your question that decryption (and presumably encryption as well) must take place on your server. In that case, your server must have access to the encryption keys, and this turns into a problem of how best to secure data at rest. Conventional wisdom for securing data at rest is to use a hardware security module (HSM) or trusted platform module (TPM). See Is at-rest encryption worth it if the key has to be kept accessible for decryption? for some interesting reading on this subject.

Answer 3

The system as proposed does not do what you want it to do, as soon as you send the private key, it is no longer private.

In essence what you would like to do, is have a key exchange mechanism that uses a encrypted secret and a Public / Private key system such as PGP which would use the public key of the doctor to send him/her a the shared secret that is only decrypted on the clients system.

Answer 4

You can avoid transmitting the private key by using a Session key, a single-use symmetric key, to encrypt each file or set of records.

Steps to encrypt

1. Generate a session key S
2. Encrypt the file using S
3. Encrypt S using public key, and store it alongside the file. We'll call the encrypted version SE

Steps to decrypt

1. Send SE to user device
2. Decrypt SE using private key
3. Send S to server
4. Decrypt file using S