The Parsec solution implies numerous cryptography concepts in order to, for example, enable key exchanges between users of the same work-group, or the registration of a new user without implying other private keys than the ones that the new user is creating for himself and the ones of the administrator inviting him.
An user can own one or more devices that he can use transparently, and he is able to add new devices from whichever of his already registered devices as soon as he wants it.
An organization can be bootstrapped without the administrator of the back-end knowing the root key of the organization.
In this section, the mechanisms enabling Parsec to reach that Zero-Trust level of confidentiality will quickly be explained (in that context, Zero-Trust means that no trust has to be placed in the back-end for the solution to be secure).
Creating an Organization¶
First, an administrator of the metadata server register the name of the organization and obtain an initialization token of the organization that he transmits to the person selected to be the first administrator of that organization.
Second, the application creates on the device of that first administrator an organization key (ORG_ROOT_SIG_S_KEY, ORG_ROOT_SIG_P_KEY), a user key (USER_ENC_S_KEY, USER_ENC_P_KEY), and a device key (DEVICE_SIG_S_KEY, DEVICE_SIG_P_KEY). The application certifies public user and device keys with the signature key of the organization and upload them on the back-end. Moreover, only the public part of the organization root key (ORG_ROOT_SIG_P_KEY) is uploaded to the metadata server, the secret part of the key is intentionally discarded, which makes it nonrecoverable.
Adding a new User¶
The creation of a new user can only be done by an existing user, already registered in the organization and having the Administrator profile. Let’s consider the case where Alice is Administrator and wants to register Bob :
Alice signals to the back-end that Bob is invited to the organization and transmits his email adress.
The metadata server sends to Bob an email with an invitation URL containing the organization ID and an unique identifier for the invitation canal.
Alice and Bob proceed to an authenticated Diffie Hellman exchange (DH) :
Alice and Bob create asymmetric ephemeral keys and exchange public parts of that keys using the metadata server as a transmission canal to deduce a secrete key shared in the style of DH.
To prevent a malicious metadata server to modify the DH canal (Man-in-the-middle attack), Alice and Bob authenticate their secrete key using the Short Authentication String (SAS) protocol. Each party share verbally a SAS token that his pair must validate from a set of tokens (accordingly to the recommendations of the scientific community) .
Bob generate his user (USER_ENC_P_KEY, USER_ENC_S_KEY) and device (DEVICE_SIG_P_KEY, DEVICE_SIG_S_KEY) keys and use the authenticated channel to share their public parts with Alice.
Alice signs that two keys with the help of her private key (DEVICE_SIG_S_KEY) and upload those certified keys to the metadata server. As each user key is signed by a device registered in the organization and the one of the first user is signed by the root key (ORG_ROOT_SIG_S_KEY), re-validating the signature trust-chain, a client is able to verify that a key has been added to PARSEC by a legitimate terminal and can be considered as valid. Each user is attributed an email address at its creation in order to reflect his correspondence to a natural person. For a given email address, it exists at least one non-revoked user in the organization (i.e. revocation of the existing user then creation of a new user with the same email address), while enabling other users to find him with the same email address.
Adding a new Device¶
The creation of a new device works in a similar way to the creation of a new user, except that the new device doesn’t have create a user key (USER_ENC_P_KEY, USER_ENC_S_KEY), but it is the role of the inviting device to transmit him that information in a secure way. The same authenticated DH mechanism is used as described in the previous section. The new device key is certified in the same way using the existing device signature key (DEVICE_SIG_S_KEY) before being uploaded to the metadata server.
Management of file reads¶
The PARSEC client tries to prioritize local access to data when reading a file. This isn’t always possible and the consultation of the metadata server can be mandatory.
Reading of a file is described in the following figure :
If the Parsec client doesn’t locally possess the File Manifest, it authenticates itself to the metadata server to ask for it ;
The metadata server ensures that the client has the right to access it and sends it to him in that case ;
The Parsec client decrypts the resulting manifest and verifies its signature (it is noticeable that the recuperation phase of the public key of the device that has signed the manifest is analogous to the mechanism presented in the chapter dedicated to the management of the users/devices) ;
The Parsec client can the find all the blocks necessary to the reading of the file ;
In the case of blocks that aren’t available locally, the Parsec client asks them to the metadata server. Once downloaded, the client decrypts them and check their hashes ;
Finally, the client can recombine the decrypted blocks to form the content of the asked file.
The user interacts with files using his usual regular software. Data are in the first time stored on the local drive, for performance and resilience reasons, as to enable offline functioning of Parsec. In the second time, the Parsec client sends the modifications, if there are, to the metadata server.
The history enables the user to list all versions of a file, and to restore its content at one of those versions.
Management of Workspaces and access control¶
In order to be able to store files, the user has to create a workspace and save the access information (unique identifier WS_ID and symmetric encryption key WS_ENC_KEY) in his User Manifest.
The sharing of a workspace consists in two operations :
Provide access data (WS_ID and WS_ENC_KEY) to the Workspace Manifest. That is done using a mechanism sending encrypted messages between users and handled automatically by the Parsec client. The new user then stores that information in its User Manifest ;
Inform the metadata server that a new user can read (and, where applicable, write) the elements linked to a given workspace.