How to design a cryptographically secure file hosting service

Question

How would one go about designing something like Google Drive/Dropbox providing the following features:

1. files are encrypted and decrypted on the client
2. files can be synced between devices
3. the service provider shouldn't be store private keys/passwords on servers
4. if the user can have only one password to remember that'd be great (we want to design something user friendly)
5. ideally one could share files with other users

So I thought about a couple of things which don't quite solve the problems.

Using AES to encrypt files

So the first idea is that each user has one password. Now to encrypt a file we derive a long enough AES key from this password (by hashing it and taking the first N bits of the hash) and we encrypt the file. Decryption can only be done if we have the original password.

This fulfills requirements #1, #2, #3, #4.

But I see several potential drawbacks: first files cannot be shared (unless we decrypt them...). Also how bad would that be to derive the AES key from a hashed password? And how bad would that be to reuse the same AES key again and again?

Using a public/private key encryption scheme

To encrypt a file: generate a key pair, encrypt with the public key, save this to the servers. To decrypt use the private key.

This fulfills requirements #1, #2*, #3.

[*] while files can be synced between devices we don't have a user friendly way to pass private keys around (because the user would have to store them 'offline' and carry them with him 24/7)

Sharing is also an issue. Let's consider that Alice stores a file foo.bar and wants to share it with Bob. The only way to do that would be for Alice to decrypt the file locally and reencrypt it with Bob's public key and then send this to Bob. This is cumbersome because it means that sharing takes time and needs Alice to be 'online' to be able to send the new encrypted file.

tl;dr

Is there a way to design such a system without any of the aforementioned drawbacks/flaws?

Answer 1

• Generate key-pair
• Generate random salt, hash password with proper password hash (scrypt or PBKDF2) to derive a master key.
• Use HKDF to derive one login key and one encryption key from master key
• Encrypt private key with encryption key from previous step
• Upload it to server, download only possible by proving possession of login key (either send over SSL, or use SRP)
• Encrypt files with random AES key, encrypt AES key to public key of a user

Answer 2

Here is a possible solution using a symmetric scheme, which supports more than one device for each user.

To begin, consider a user who wants to use the service for the first time with the first device. The device client randomly generates a new AES master key $\mathit{MK}$. $\mathit{MK}$ is then encrypted by using another key $\mathit{PK}$ derived (e.g. by PBKDF2) from a user password, a salt $S$ and an iteration count $c$ (see RFC 2898). The encrypted $\mathit{MK}$, together with $S$ and $c$ in plaintext, can be sent to the hosting server (via authenticated TLS session or whatever, out of scope). Thus, the server stores $E_\mathit{PK}(\mathit{MK}),S,c$ for each user.

With this scheme, the master key can be obtained from any device the user wants to connect to the service, by using only one password. The strength of the scheme is highly based on the strength of the password (but this is quite often the case).

Then, each file $F_i$ can be associated with a file key $K_i$, randomly generated by the client before the first upload. For each file, the pair $E_\mathit{MK}(K_i)$, $E_{K_i}(F_i)$ can be stored on the server (i.e. the server maintains the file $F_i$ encrypted with the key $K_i$, and the key $K_i$ encrypted with the master key $M_K$).

With the above scheme, your requirements are fulfilled:

1. files are encrypted and decrypted on the client by using the chain of keys (starting from the user password);
2. files can be synced between devices, because any device can decrypt and access to any file (hashes may be used to optimize sync);
3. the service provider does not store private keys/passwords on servers, because the only 'private' key $\mathit{PK}$ is managed by the client, and it could also be not stored at all (upon user decision);
4. the user only has to remember just one password;
5. one could share files with other users by simply sharing a pointer to the file $F_i$ into the server and the file key $K_i$. Note that $K_i$ shall be protected, e.g. by using TLS session between users.