Show HN: ETSD – Transmit sensitive data encrypted across your organization

spapas82 2021-08-18 10:59:27 +0000 UTC [ - ]

Hello friends, this is a Django project that we are going to use to submit sensitive data across the departments of our (public sector) organization. It uses Openpgp.js to encrypt/decrypt all files locally to the users's browsers and tries to make the PGP experience as flawless as possible for non-techical people.

I'm submitting it in case anybody finds it useful for his organization but also if somebody would like to take a peek and give me any security related feedback.

Thank you!

unixhero 2021-08-19 09:54:29 +0000 UTC [ - ]

Hi, it would be useful if you can document the end user journey and the administrator user journey in the form of screenshots in your github repo.

Cheers

spapas82 2021-08-19 10:00:20 +0000 UTC [ - ]

Thank you for the suggestion, I'll get to it ASAP.

henryackerman 2021-08-19 09:46:41 +0000 UTC [ - ]

Why did you opt for PGP? If I understand correctly, your system inherits the lack of PFS.

upofadown 2021-08-19 12:15:37 +0000 UTC [ - ]

This seems to be primarily for forwarding files. It is unlikely that the users would want to get rid of the files after transfer. Any attack intense enough to get access to the passphrase for the secret key (keylogger) will pretty much for sure give access to the files on the system involved at the time of attack (including insecurely deleted files) and any files that exist on the system going forward.

The whole thing is generally more secure then many of these file transfer things due to the use of the passphrase. The idea of strongly protecting the secret key against local attacks is a PGPism that tends to be forgotten these days.

spapas82 2021-08-19 12:17:43 +0000 UTC [ - ]

Yes, this will be used in our organization to transfer various documents (mainly pdf/word files) that contain sensitive data (i.e medical conditions of colleagues).

spapas82 2021-08-19 09:59:44 +0000 UTC [ - ]

Yes there's no PFS in ETSD. The data is encrypted with the recipient's public key as normally in PGP so if the private key is compromised then the malicious user can decrypt all messages that were encrypted with that key (if he also gets access to the server holding the ciphers of course).

We wanted to use PGP because it's a well known and heavily tested solution. Also, the openpgp.js library is great and makes it really easy to encrypt/decrypt the messages to the client side without the need to really mess with security stuff. Finally, the users would want to have access to their old messages in the future so using ephemeral keys for each transmission wasn't really possible.

adontz 2021-08-19 11:39:33 +0000 UTC [ - ]

I am confused, is private key actually uploaded to server or just imported into client java script?

spapas82 2021-08-19 12:13:18 +0000 UTC [ - ]

The private key is not uploaded to the server, only the public key. It is loaded to the client javascript (localStorage) as you say. Also both the encryption and decryption are performed client side.

The result is that if the server is compromised no data should be leaked.

c22 2021-08-19 13:07:17 +0000 UTC [ - ]

If the server is compromised what's to stop an attacker from replacing the end-user javascript with a malicious payload and quietly waiting for it to steal the keys?

spapas82 2021-08-19 13:21:54 +0000 UTC [ - ]

Yes you are right, nothing. However that is a different and much more difficult kind of attack than the common one where an attacker retrieves all the files stored on the server and goes away.

Also I'm really not sure if such a determined attacker could be stopped somehow... Any suggestions?

c22 2021-08-19 14:10:35 +0000 UTC [ - ]

Whether or not an active attack is much more difficult than a passive one depends on the specific security profile of the entire service. Often a passive data-exfiltrating attack will become possible due to an innocent mis-configuration on the server, but mis-configuration can open the door to active attacks as well. There is no guarantee that any mistake in configuration will only allow passive attacks or that an attacker will choose to just "go away" after retrieving all of your files.

With this system, specifically, active attacks will be quite rewarding to any potential attacker because secrets are saved indefinitely and every user-key they steal will allow the recovery of multiple secrets. Since the rewards are high you should expect the chances of active attack to be heightened.

In order to mitigate against this you need the enduser to be able to verify the proper functioning of the encryption/decryption apparatus. Usually this is accomplished with separate binaries, checksums, reproducible builds, and etc. Of course any solution will be vulnerable during updates of the encryption/decryption endpoints, often an out-of-band channel is used to transfer the update or the verification checksum.

These challenges are particularly fraught when attempting to implement a secure system using in-browser javascript. Not only is the entire encryption/decryption algorithm redistributed frequently, regardless of whether or not it has changed, but the tooling around authentication and validation of browser-resident javascript is currently very weak. In addition to compromise of the server, the system is still vulnerable to local attacks as well as a whole host of in-transit attacks that more static e2e systems don't have to worry about (e.g. someone forgets to enable https, or happens to connect through a suss proxy).

Perhaps some sort of javascript pinning could help to alleviate some of the threat-surface, but to my knowledge no major browsers support anything like that.

spapas82 2021-08-19 14:43:28 +0000 UTC [ - ]

Thank you for this great explanation! I understand that the prolem is inherent in in web-ased security systems and not much can be done.

However, let's suppose that I packed the client functionality to an electron app (i.e executable with some signature) so the .js files doing the encryption/decryption would not be downloaded from the server each time but they would reside inside the electron app. Would that be better from a security standpoint against the attacks you mention or I'm missing something?

c22 2021-08-19 14:52:19 +0000 UTC [ - ]

Yes, this would be better. You would just have to be careful about how you distribute the app.

spapas82 2021-08-19 14:57:11 +0000 UTC [ - ]

Excellent thank you so much!

upofadown 2021-08-19 12:29:12 +0000 UTC [ - ]

Then that brings up the question; how is the private key backed up and does it need to be backed up? Or does the loss of the data on a system mean you start over for that system?

spapas82 2021-08-19 12:40:52 +0000 UTC [ - ]

Yes that's right. The backing up of the private key and its passphrase is done out of this application.

So if an authority loses access to its private key then they need to generate a new key pair and start over. Of course they will lose access to all the files that are stored in the server and have been encrypted with that key's pair (unless they have already downloaded them and saved then in a different place).