I am thinking of creating a cloud-based document archive. The intention is to make it impossible for the system to read the users' files, and be more than just a storage provider.

Looking at this question, there are some ways to do this, but effectively this limits the archive system to be just a "dumb" storage provider: Only on your own machine will the data make sense after decryption.

For trusting that the storage provider will not laugh at your embarrassing holiday pictures, this approach is rock solid. But the problem is that you won't have the convenience of a less secure system like dropbox, google drive or neat.com.
These systems (let's call them "smart") index your data for search, have handy in-browser document viewers, etc, which I want for my system.

But providing a web-interface to users' data means that the web server must be able to serve unencrypted files (or thumbnails).

For storage, I was thinking of using asymmetric (RSA) encryption of symmetric encrption (AES?) secrets on the central server. Each file is symmetrically encrypted with a per-file secret. Those secrets are encrypted using the public key. The private key needed for decrypting a file's secret (and thus decrypting the file) is encrypted using a secret based on the user's password.

This means that files can only be read by the server if the decrypted private key is kept in its decrypted form for the duration of a users session. Similary, indexing and generating thumbnails for stored files/documents can only be happen while the private key is "unlocked". This design is easily expandable to accommodate application-specific passwords (create an encrypted private key per password), in case I ever want to develop apps besides the web interface.

My question is: How fundamentally (in)secure is this design?

  1. If the (web) server can decrypt files when users are logged in, this obviously begs a question of "how trustworthy and responsible with users' data and encryption secrets am I?" Is there a way to formally(/by design) answer this question with "very"?
  2. Moreover, how eager are the system administrators at my cloud provider to MITM my running system? (If e.g. pressured by some government.)
  3. And finally: In case of someone seizing my servers, are the users' data/encryption secrets safe from prying eyes?

I'm not sure if I understand your problem. There seems to be a contradiction in your goals vs. solution.

  • You don't trust the server to not evesdrop
  • You're providing the server your decryption keys during login so that it can scan the files and generate metadata
  • You're trusting the server to forget the keys and the plaintext when the user logs out

You'd be better off generating the metadata at the time of encryption on the user's workstation. Then upload the metadata plaintext along with the encrypted data. It's not future-proof, so choose your metadata carefully.

To share the file, encrypt the keyfile with the recipient's public key and upload it.

Never give the plaintext keyfile to the server.

  • I am trusting the software system I am creating, but the question is "will other users trust it to not spy on their data?" The second concern is, "If I'm using some cloud infrastructure, can I as a product provider guarantee that the cloud provider won't be able to read actual data?" Surely it is safest to create metadata during file creation, but that rules out the possibility of creating a web interface. – derabbink Nov 21 '12 at 23:49
  • Is the web interface being used to modify the data? E.g., a Google Docs like environment? – mgjk Nov 22 '12 at 15:08
  • The web interface should mainly serve viewing and searching purposes. Creating (uploading) or deleting files would be nice to have, but modification/editing in the literal sense is not required. – derabbink Nov 22 '12 at 16:06
  • Yeah, then the server would need access to the data and you're right, it comes down to trust. Hushmail uses a similar model for email. See en.wikipedia.org/wiki/… for the story of how they allowed the feds to wiretap. A legitimate business needs to abide by the laws of the land. Your users will know this. – mgjk Nov 22 '12 at 16:53
  • I'll also add that Hushmail has strong names behind it, so they also trust the business not to casually evesdrop. Without that strong name, I wouldn't trust your model. – mgjk Nov 22 '12 at 16:54

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.