Where to store a key for system wide encryption/decryption?

Question

I have a web application where (among other things) customers can upload files and administrators can then download those files. The uploaded files are stored on ServerA and the web application used to upload/download those files runs on ServerB.

I would like to make it so that while the files are stored on ServerA they are encrypted and that only the web application can encrypt/decrypt, but my concern is that there might not be an effective way to store an encryption key, which would make the file encryption mostly for show.

I came across this question/answer which suggested some good ways to securely store a key, but I think that the most secure ones do not apply since I need different people to be able to decrypt the file.

For example, I cannot create a key based on user credentials, because customers must be able to encrypt all admin users must be able to decrypt (right?).

From what I can tell, my best option is to store the encrypted files on one server and store the encryption key in the code on my web server, but this does not seem particularly secure. It seems likely that if a malicious user gains access to one server they probably gain access to both.

My question - is it even worth implementing "encrypted files on ServerA" and "encryption key on ServerB", or would I just be kidding myself to think this is more secure? Is there an effective way to encrypt files based on the conditions that I laid out above?

Answer 1

The most effective method is to use secure hardware to store the key. You can get SSL accelerators that will securely store and process keys onboard so that they never leave the secure hardware module. Relatively expensive and requires you to have physical access to the hardware (so no VPS or cloud solutions).

Answer 2

You can use public key/asymmetric encryption, for example using the gnupg program. The administrator generates a public/private key pair, and stores the private key somewhere safe (possibly on neither ServerA nor ServerB). You can store the public key anywhere, and in particular on the web server, where it will be used to encrypt uploaded files. Once encrypted, you can store the (encrypted version of the) uploaded files on either ServerA or ServerB; either way, without the private key, it won't be possible to read them. To view the files, the administrator can copy an uploaded file to a trusted computer and then use the private key to decrypt.

Answer 3

A way you can tie user credentials to the key is by having one key for the encrypted file, and encrypting that key multiple times with key based on each user's credentials. You'll have a ton of small key files (one per user), and each user who has access can decrypt the key to use in order to decrypt the final file.

Answer 4

Let's say that users A, B, C and D want to share files with each other on a remote location.

Each user generates a pair of public and private keys (let's say RSA1024/2048 bit).

Each user publishes his public key on the remote server.

Now let's say that A wants to share a file with B and C, but not with D.

A will create a symmetric encryption key (let's say AES-256, symmetric because they're faster). A then continue to encrypt the file with the symmetric key he just created for that purpose. He then encrypts the key 3 separate times: once with his own public key, once with B's public key, and once with C's public key.

A then uploads the encrypted file and and all of the different encryptions of the symmetric key to the remote server.

The remote server doesn't know how to open these files and he doesn't need to.

When B asks for the file, he receives the encrypted file and the symmetric key that was encrypted with B's public key. B can now go on and open the file.

Note that we require a different symmetric key for every file because we want to control the sharing on a per-file basis.

The only problem with this method is that now A,B,C and D need to keep a private key somewhere. If you don't want them to store the private key themselves, you encrypt the private key with a password protected encryption (which is different from their login password) and store the password protected private key on the same (or different) server. Now, whenever a user logs on, he will have to first download his password protected private key and open it with another password prompt.