I am currently working on a web application with sensitive data to store (personal medical data). The app is on the very first stages of conception and I am to quickly produce a beta version that would be used, while on a very narrowed scale, in production, with real people's data. Following a few month of beta testing and refining, the app will hit production on a larger scale.

My goal, once the beta is ended, is to hire a professional to review the security of the app, and performs some pentests. But unfortunately this is out of the way right now, for business and financial reasons. I'm primarily a web developer and even though I know more or less advanced basics in security, I am in no way a security professional, so the situation is far from ideal but I don't have any other options right now. Even if those data are medical, they are not extremely sensitive, but I would like to secure them the best I can.

For the beta, the global project is as following : My back end consists of a node.js server serving the static files to access the webapp on desktop, and of an api accessing and serving the data. My front end will primarily be an android app on tablet. The whole thing is setup on-premises on a local network with, in the worst case scenario, no access at all to external ressources, which prevents me of using any cloud-based key management system or anything alike.

I have one database for the customer, accessed by several users trough their tablets or desktops computers.

As the tablets may end up being offline and the whole database will be relatively small, the goal is to download the whole database on the tablet, and sync back every modified data later on. I would like that the most sensitive data stay most of the time encrypted on the tablet, and be decrypted only when necessary. If a modification is made, the data would then be encrypted back on the tablet, before sending it back to the server.

Currently what I'm planning to do is to have every sensitive data encrypted in database (with a key "K1"). To avoid storing both the encrypted data and the encryption key on the server, that key would be itself encrypted with a key "K2". That way, the encrypted K1 could be stored on the tablet (hardcoded in the app sources), while the other key would be stored on the server and sent to the tablet when necessary. The main goal being that an attacker gaining access to the server would not have access to both the encrypted data and the encryption key, and that if a tablet were to be stolen, the encryption key K1 would not be as easily divulged.

This solution in itself may still be weak, I'm working on it as much as I can, but it has anyway one major drawback : I can't have an hardcoded client-side key when accessing the webapp trough a browser, unless I have a specific desktop app installed (which I could have, but it would add a lot more complexity and time consuming tasks to the project). Every solution I think of end-up with having both the encrypted data and the encryption key on the same server, which as far as I know is a major flaw that I would like to avoid.

So here is my question : would there be a - if not perfectly secure, at least not totally flawed - way to have this encryption key sent from the server to any web client, alongside the encrypted data ? Or would there be a way to decrypt the data on the front-side, and still avoid the server to ever have access to the encryption key ?

Any comments on the solution I described would also be appreciated, especially if it is to tell me that it is absolutely terrible. Thanks !

1 Answer 1


First of all: stop developing until you can really understand encryption, privacy, and the laws regarding medical data. If because of financial reasons you cannot have an expert to inspect and certify your solution, for financial reasons you should not develop it. The money spent on having a specialist helping you design and test is a few orders of magnitude less than the fines and image damage from an data leak event.

Second: don't store the entire database on the client. It won't scale, and you must design with scale on mind since day-0. If you design things that by design don't scale, that will bite you later. Hard.

If you want to continue this (for Science, or to learn), you will use Envelope Encryption (this IBM link have a nice explanation). It basically means that your client generates some data, encrypts it with a symmetric key, encrypts this key with his own key, and sends along the encrypted data plus encrypted key. The server stores the blob and does not have any knowledge of its contents.

When the client needs the data, it will receive the blob, extract the encrypted symmetric key, decrypts the key and uses it to decrypt the data.

How you create the user's secret key? You need a Key Derivation Function (KDF). The KDF will take the user's password, some other parameters, and generate a key. Every time you run the KDF with the same parameters, it will output the same key. It can be seen as a very specialized hash function: you always enter the same value, it always returns the same hash.

But what if the user wants to change his password? All data is lost? No, it's not. You must create an intermediary key, encrypt all DEKs with it, and encrypt this intermediary key with the user key. Store the encrypted intermediate key on the server. If the user wants to change its password, he will retrieve the encrypted intermediate key, decrypt it with his current key, change its password (and by consequence his secret key), re-encrypt the intermediate key with his new secret key, and store it back.

And what if the user forgets the key? Using Envelope Encryption, he is doomed. There's no way to recover it, unless you somehow store an unencrypted intermediate key (or encrypted by your own key), and break the entire security chain.

Yes, I know it's complicated. And my explanation was not the best, and there's a lot of possible gotchas on the implementation, but is a secure way. Read the Envelope Encryption implementation from IBM, from Google Cloud, from AWS, and so on.

And let your boss know that developing a secure service managing medical data without proper experience is asking for big trouble down the road.

  • Thank you for the thorough answer ! No boss here, only me, but I should specify that the key management is really the major part where I'm out of my skills on this project, aside from that, I'm having comprehensives counsel from specialized lawyers and am myself specialized in GDPR compliance. I do realize that a lot comes down to the quality of the security implemented, this is why I'm seeking advice from more knowledgeable people on the subject and that I will continue to do so for some time. Commented Jan 16, 2020 at 23:25

You must log in to answer this question.

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