End-to-end encrypted user data storing and sharing

[stephanemagnenat]

In the context of the mobile version of VPL, it will be useful to store user programs on the cloud, and allow users to share these with friends, as mobile devices do not have an easily accessible generic file-system from an end-user point of view.

However, this needs to be done in a secure way, and compatible with the constraints of schools (possibly own storage, work without Internet connection using a local box, etc.). Based on these requirements, @HannesSommer and I have designed a first high-level draft of how this storage could be implemented.

The storage solution is based on the concept of public-key cryptography. in the envisioned scheme, the user has a secret private key stored on their device. If they change device, the key can be transmitted to another device by NFC or QR Code, or, if too large, by a safe channel whose keys can be verified by NFC communication or the QR Code.

In the proposed public-key cryptography scheme, for every user the following elements are used:

• my_privkey private key, only available on the devices of the user,
• my_pubkey public key generated out of the private key, available to all friends,
• my_pubkey_h hash of public key, to have a smaller key used in file paths.

In addition, for the discussion let us consider your_pubkey the public key of another user, and your_pubkey_h its hash.

On a server, every user will have a private space in a (maybe virtual) file-system, under /my_pubkey_h/. The following folders will be available:

1. /my_pubkey_h/private, containing my private data, encrypted using my_privkey, readable and writeable only by me.
2. /my_pubkey_h/pubkey, containing my public key, clear text but writeable only by me.
3. /my_pubkey_h/shared/data, containing shared data, each element encrypted with its own random private key, readable by anyone, writeable by me.
4. /my_pubkey_h/shared/your_pubkey_h, containing the random private key for data shared by me to you encrypted using your_pubkey and signed using my_privkey. Once the random private key is decoded, you can access my shared data in 3. Writeable by me and readable by you.
5. /my_pubkey_h/incoming/your_pubkey_h, containing the messages from you to me, encrypted using my_pubkey and signed using your_privkey. Writeable by you and readable and deletable by me.

With this scheme, all encryption and decryption is done on the client side. The server is really dumb, has no notion of the content of the data, and only needs to provide a simple secure connection and basic file permissions. To avoid spamming, a small number of authorisation tokens, allowing to create accounts on the server, could be shipped with each robot. The sole operation required by the user is to scan the token with the mobile device's camera, and show a QR Code to a friend to add her. Additional integration such as automatically adding facebook/g+/twitter/... friends is possible as basically adding a friend means registering her public key hash.

Note that this proposal does not address the questions of usage data logging or user registration for newsletter or other.

[HannesSommer]

Great summary, @stephanemagnenat! Some random comments / thoughts:

• The shared data in /my_pubkey_h/shared/data can be symmetrically encrypted and therefor it just has a single key - the one key that gets asymmetrically protected in /my_pubkey_h/shared/your_pubkey_h with a public key
• The entires in /my_pubkey_h/shared/your_pubkey_h would also need to contain a reference to the actual data per key entry (effectively a table of key reference pairs).
• /my_pubkey_h/shared/your_pubkey_h and /my_pubkey_h/incoming/your_pubkey_h could be considered redundant (just an idea): It could be enough for me to send notifications about newly shared data to /your_pubkey_h/incoming/my_pubkey_h because you don't have to clean your inbox. Whatever you are interested in you just don't delete. This way the shared data would basically be a shared attachment to a message. This message might then provide the interesting metadata to you as long as you are interested (=until you delete it). This could be convenient to possible users which are already used to use attachments like cloud storage with history and meta information (I believe those to be rather frequent)
• As soon as one starts thinking about resharing and garbage collection it could be an interesting alternative to store all the shared files centrally (not per user). Per user there would be only references stored. As usual a shared file can be considered garbage as soon as nothing refers to it anymore. Of course this would require the server to be able to read all the references and the reference structure itself would become less protected. Possibly this problem can also be solved by the underlying file system (e.g. hard linking).