Over-Optimizing Security? Storing Encrypted Data on a Server While Private Key Remains With User
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:
- The user's private key is stored on their smartphones.
- 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.
- The user opens the app, clicks and on release.
- 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)
- 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.
