1

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.

4 Answers 4

2

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...

4
  • I understand your point, however most of the data would remain encrypted most of the time (think 1 request/year/user). If someone were to get access to the system, they would have to be there for a very long time until they can amass any amount of data. Also if they are looking for someone's data in particular the chance would be small that their's is currently being processed. Also I would like to keep the data safe from law enforcement for which the highest security practices you talk about don't help. I think my key problem is, that the data undergoes expensive server-side processing.
    – Moritz_st
    Nov 29, 2023 at 13:42
  • The answer lies in the acceptable risk. If you can accept that an attacker access some sensitive data at random and leak it, then your design if fine. If you cannot... Nov 29, 2023 at 14:11
  • @Moritz_st: The rule is that whenever a threat is identified, the risk shall be eliminated, transfered (think about insurances) or accepted. Mitigation is a way of reducing the volume of residual risks. Nothing is bad in accepting a risk provided the decision is explicit and taken at the proper level. Nov 29, 2023 at 14:19
  • I appreciate your thoughts on this. Unfortunately I cannot change the requirement that sometimes the data needs to be processed on the server. Also consider that the data is the output of some lab machine and needs to be transferred from that machine to my server - so a zero-trust approach cannot work.
    – Moritz_st
    Nov 29, 2023 at 17:34
1

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.

0

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.

1
  • Right, I'm looking for some key exchange mechanism. The only problem is, that the data needs to be decrypted and processed on the server. I've edited my question in that regard.
    – Moritz_st
    Nov 28, 2023 at 11:02
0

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

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .