The following page is split in two separate sections:

• The 1st section describes the steps from a user perspective. It's a simple example of how RISKS is used on a daily basis.
• The 2nd section comes back on the steps of the first section, but adds some descriptions and explanations on these steps, the components they involve, and some security principles behind.

The following describes the steps needed to unlock an identity, fully ready to be used.

1. I turn on my Qubes OS pc
2. I insert the Qubes OS filesystem passphrase
3. I login as Qubes user
4. I load the vault qube
5. I plug in the sdcard in the socket
6. I connect the sdcard to vault
7. I insert the passphrase to decrypt the sdcard
8. I decrypt Joe's identity-coffin using a script (risks) and no passphrase
9. I access any of Joe's tomb-files using a script (risks + spectre master password)
10. I open Joe's passwords tomb, and use them with pass.

• one passphrase right after boot (step 2)
• one password for the Qubes user (step 3)
• one passphrase for the sdcard (step 7)
• one master password (for all the identities) for spectre (step 9 and 10)

=> if I have 1 identities I need to remember:

• 2 passphrases (Qubes fs, sdcard)
• 2 passwords (Qubes user, spectre master password)

=> if I have 2 identities I need to remember:

• 2 passphrases (Qubes fs, sdcard)
• 2 passwords (Qubes user, spectre master password)

In this case the number doesn't change when the number of identities changes. The annoying part is that it requires one more step when dealing with GPG authorization.

Now we come back on some of the steps described above, and increment them with some comments and explanations. The first 4 steps are omitted since they don't involve the risks tool.

There are 3 ways to attach the SDCard to the vault qube.

• Use the devices GUI in the Qubes systray.
• Use the qvm-block attach <device> command in a dom0 terminal.
• If the risk dom0 CLI is installed, use risk hush attach.

In the vault qube, when the hush device was formatted and prepared with risks hush format /dev/<device>, a UDEV rule has been added to the qubes' udev rules, which automatically maps the device to a "mapper" (hush by default).

Again, there are 2 ways to unlock and mount the SDcard in the vault:

• Use the risks hush mount command in the vault qube, and insert the passphrase.
• If the risk dom0 CLI is installed, use risk hush attach --mount. This will attach the device, and then spawn a terminal in which to enter the passphrase.

This step is the first critical step in unlocking an identity. Many things happen:

• The risks CLI computes a file encryption key for the identity, which is used to resolve the corresponding files and directories of this identity, which are all obfuscated.
• The CLI looks for the coffin-file (containing the GPG files) in the ~/.graveyard directory, looks for its corresponding key-file in the hush device.
• The coffin-file is unlocked (with cryptsetup) and mounted on the ~/.gnupg directory.
• Accessorily, the risks CLI uses the fscrypt tool to unlock the identity's graveyard. While the files in this graveyard are still encrypted (since they are tomb files), they can now be used by the tomb script.

At this point, the GPG keyring can be queried with any gpg command. Any operation involving the use of the GPG subkeys will, however, require the GPG passphrase associated with those keys. Therefore, and even though anyone could unlock and mount the identity GPG keyring without any authentication, it is not possible to do much with the keys at this point.

You might understand, at this point, why the GPG keyring is not itself stored in a tomb file: since the latter require GPG keys to authenticate and perform decryption, we would not be able to unlock the GPG keyring this way.

With the GPG keyring mounted, we can now mount one or more tomb-files. This step involves a new tool, our spectre password manager, along with tomb. The following steps are performed by the risks CLI:

• The user is being asked to enter his master passphrase (which should be the same master passphrase for all identities). From this master passphrase and the identity name is then derived a per-identity GPG passphrase, which is then pasted to the clipboard for a one-time use only. Once used, the clibpoard will be wiped.
• The risks CLI resolves the tomb-file name in the ~/.graveyard directory, and the tomb-key file in the hush device.
• It then uses the tomb tool to try to unlock the tomb-file, asking GPG for the autorized GPG key.
• The GPG software prompts the user to enter its private key passphrase, which is simply pasted from the system clipboard.
• The tomb file is then unlocked and mounted on a directory. Some tomb files have a predefined directory (such as ssh and pass, which both need to be available in some known directory).

In general, the gpg-agent will not ask for the GPG private key passphrase during 5 minutes, so that if you open other tombs successively, you can simply skip the spectre password prompt, which is asked each time.