Keeping user files secure while allowing a web-application to use the files

Question

Short background

I am currently in the process of designing a web-application where the user uploads some files to the server and then asks the server to do some calculations based on these files (task may be queued if the current workload is high). Then the server stores the result and makes it available for the user to view.

These files may contain private and/or sensitive data and therefore I decided to look into ways to keep these files secure on the server side.

I have done some research into this topic but not found the solution that I am looking for. I do have a general idea for the design, but I feel it is flawed and that I might be reinventing the wheel (lacking experience in this field).

I will start with the basic requirements, then present my idea and end with the questions i have.

Security requirements

• System must encrypt the files before storing on the file system
• System administrators etc must not be able to decrypt the files on their own (next requirement takes priority over this requirement)
• System must be able to decrypt the files only if user provides authentication
• System must support multiple simultaneous users with each user able to only authenticate decryption the files uploaded by that user.

Current idea

Storing the files in a way that decryption is possible only for the user seems quite straight forward. Currently I am thinking of the following workflow:

1. User creates a public/private key pair (with some 3rd party tools)
2. User uploads the public key to the system
3. User uploads file (file stays in memory for now)
4. System generates shared key for encrypting the file
5. System encrypts the file with the shared key
6. System stores the file
7. System encrypts the shared key with the public key
8. System stores the encrypted shared key

I believe this approach is quite common and does not have any serious draw-backs.

Now the problematic part. Since I want the user to be able to allow the system to decrypt the file in some situations then this is the only workflow I came up with:

1. User starts a task that requires an encrypted file
2. User uploads the private key (stays only in memory)
3. System decrypts the shared key (stays only in memory)
4. System deletes the private key from memory
5. System decrypts the file into memory
6. System deletes the decrypted shared key from memory
7. System completes the task
8. System deletes the decrypted file from memory
9. System stores the task result

Questions

While I do believe that this approach would be functional, I am still worried about a couple of things:

• I am not sure if uploading a private key as a regular file can even be considered as a viable option? - If i'm not mistaken, then this at least goes against the usual norms.
• Can the private key be transferred securely over the internet? - I am inclined to believe that it can, however I have not jet looked into how exactly.
• Even if the encrypted file (or the private key) is only held in memory for the minimum time needed, would it still be a security risk? - I feel that it is still a risk, but not a serious one.
• Is this already a solved problem? - If so than I was unable to find the solutions

As a final remark I would like to add that I am fully aware that any such system would require trust from the users. Mainly I would like to know if this is achievable at all, is my idea viable and is there a better/alternative way?

Answer 1

For part two, you can do sensibly better:

1. (The session between User and System is encrypted)
2. User starts a task that requires an encrypted file
3. System sends tne encrypted shared key
4. User locally decrypts the shared key
5. User sends the decrypted shared key (stays only in memory)
6. System decrypts the file into memory
7. System deletes the decrypted shared key from memory
8. System completes the task
9. System deletes the decrypted file from memory
10. System stores the task result

You should ensure the memory of the routine that performs the task is not accessible by other threads on the system's service, if you happen to serve multiple clients on the same system, using compartmentalisation techniques like COWL (not sure about its implementation status) or maybe Capsicum.

I'm thinking strongly of secure multi-party computation and homomorphic encryption when reading your problem. I'm not expert so won't dwell on this, though. There might be ways, depending on what you need to compute, to perform the computation without actually having to decrypt the files. This might also be achieved by having clients compute and upload encrypted properties about the files rather than the files themselves.

There are quite possibly tons of other designs, and hopefully someone will point out a better approach.

Answer 2

Don't upload the private key to the server.

Instead, send the encrypted shared key to the user. The user can then decrypt with the private key, which stays on the user's system.

Then, the user sends the decrypted shared key to the server.