Skip to main content

Advanced functions

Quorum recovery​

We are now going to use a quorum group of secret administrators to make a third party recovery.

Setting up a Quorum​

First of all, we add a quorum group sharing a vault. To do this, the administrator must add the quorum group via the administration menu (Administration > Quorums).

Setting up a quorum

The administrator must indicate the name of the group, possibly a description, the quorum threshold, and the members of the quorum. In order to finalize the quorum group, each member of the group must log in twice. In our case, we add Alice, Bob and Charlie to a quorum group with a threshold of 2.

Once the quorum group has been created, we need to indicate in the configuration of the relevant vault folder that we want to use this quorum. To do this, in the settings of the vault folder (root for example), add the quorum group as the recovering friends to the desired group (All groups for example).

Quorum group configuration

Once this configuration is done, all vaults that will be created in the root vault folder or its sub-vault folders will benefit from the quorum recovery mechanism.

Creation of a vault with a quorum recovery mechanism​

Now that we've configured the Quorum group overlay consisting of Alice, Bob and Charlie, a normal user can create a vault that will benefit from the Quorum recovery. The Delta user creates a vault and places a file in it. In the vault shares, we can see the quorum group.

Quorum is in shares

Note that Quorum members, if they haven't been shared the vault, can see it grayed out on their interface, but can't decipher it.

Vault view by a quorum

Recovery procedure​

A member of the quorum may invite a user to access the vault. To do so, he can access the shares of the vault (he still can't decipher it), and add the user of his choice.

Vault sharing

Awaiting recovery

A notification shall then inform the members of the quorum that a request for recovery has been made.

They may then accept or refuse. When the number of members of the quorum who have accepted the recovery is greater than or equal to the quorum threshold, then the recovery is effective and the user has access to the vault.

Access ask to a vault

It must be understood that this mechanism is cryptographic. The quorum group has a public key, but no private key. When c@a.net requested access to the vault, the AES256 key of the repository encrypted by the public key of the quorum group was over-encrypted by the public key of c@a.net.

When the quorum member last partially decrypted, the repository AES256 key remained encrypted by the c@a.net public key. c@a.net retrieved this value and then decrypted it with its private key. He then had access to the repository key AES256 and thus to the repository.

The separation between access authorization by the quorum group and access to the repository is cryptographic. This is a very valuable property of our system. It allows a group of non-experts to carry out the recovery operations that are usually entrusted to technical experts, who may not necessarily be the best suited to carry out these operations.

Vault folder rights and validations​

The mechanism of vault folders allows a more refined management of the users' possibilities. Each vault folder can be configured to fit as closely as possible to the needs.

Changing the rights of vault folders​

Directory permissions editing can be particularly tricky, so we advise you not to give all users the possibility to change the permissions of vault directories. Rather, delegate this task to a group of experienced and aware users.

The assignment of rights to folders is based on the combination of group membership and the folder to which the permissions are changed. It is not possible, for example, to change the permissions of one and only one user.

To do so, enter a vault folder and go to its properties ().
You are now in front of the configuration window of this vault folder.

.

In order to change the rights of this folder, let's look at the last two elements of the properties.

Visibility allows you to define if this directory is visible for :

  • The groups for which you are going to apply a configuration.
  • No one if this one is empty and everyone who shares a vault contained in this directory.

Adding a configuration for a new group allows you to apply rules for specific groups.

There is at least one group that exists without modification on your part, the group (all groups) which therefore groups all groups together. The way rights work is this: you have the highest right. If you are part of a group , only the configuration of the group does not give you the right to create vaults and that the configuration of this group gives you this possibility, then you have the right to create vaults. This is an important notion to understand in order to get out of it when assigning rights. This allows you to apply very restrictive rights for the group and refine for each group afterwards.

The assignment of rights is quite simple, just click in the "Add a configuration for a new group" area and select the group for which you want to apply a configuration from the list of available groups.

you will then see the group appear in the configuration list.

Click on the deployment button of the section and you will see the group configuration window appears.

You can, in order:

  • Give or deny the right to create vaults,
  • give or deny the right to create vault folders,
  • give or deny the right to modify the rights of subfolders.
  • define a group or groups exempt from share validation,
  • define the group responsible for the share validation,
  • define the group in charge of content validation,
  • define the group in charge of recovery.

Once your configuration is done, just click on the "Update" button.

Validations​

There are therefore, in Crypt n Drive, two validation systems:

  • Content validation
    • Each file shared by a member of a group subject to file validation must be validated by a pre-determined group of third parties before being made available in a vault.
  • Shares validation
    • Each guest external to the application will have his or her identity validated, no longer by the guest, but by a group of third parties decided in advance.

To ensure the smooth running of these systems we advise you to create at least two groups, different from the quorum group seen above. One group for the validation of files and one group for the validation of new shares.

Content validation​

Let's take the next case: There’s :

  • The content validation group
    • In this group is
  • The share validation group
    • In this group is
  • The accounting group
    • In this group is
  • The Trusty group
    • In this group is
  • And finally

With the admin account, we create a "test validation" vault folder. I will add a configuration in this folder for the group
So let's go to the folder properties, then to the field to add a new configuration and select the group .

Let's first give the right to create vaults, then the right to create subfolders. In order not to risk breaking the configuration, let's forbid the group to modify the rights of subfolders. Then, the group will avoid sharing validations. We will set the group to share validators, then to content validators.

We now have this configuration :

.

We update the properties and connect with and see the appearance of the new folder . We then create in this folder the testV vault. Let's now drop some files. The files are in an « not validated" state as we can see on this screen :

These files need to be validated by the content validation group, i.e. .

connects (as a member of the content validation group), enters the "testV" vault and notices that 3 files are waiting for validation. A right click on a file offers a new option to , validate the file.

She can therefore view and/or download the file, check the content and validate or not the file. Let's validate the first two but not the last one to see that the status of the two validated files has changed to the validated status represented by this icon :

can now ask to modify or delete its not validated file.

Demo now wishes to share this vault with a third party, let's try to invite , using the shares tab. (note the presence of and in the shares list as "content validator" and "validator" respectively). Let's add and let's connect with him.

can see the folder and can enter the vault. View and download the files. Nothing more normal since is part of the group which avoids the share validation. If we repeat the operation with a third party outside this group, let's see what happens, so let's invite .

Once connected with by clicking on the link received by mail, arrives directly in the vault and sees this screen :

.

It is therefore up to who is part of the group to validate the share. He connects, sees the alert in the top bar

.

Now sees the vault, with only two files validated.

A subtlety remains for the configuration. If you specify only a group that "avoids validation" without adding a share commit group or content commit group, the only members to whom the vaults in that folder can be shared will be the users in that group. This is another way to allow the administrator to control sharing.