Components And Roles - wizardofhoms/risks GitHub Wiki
This page describes with a general overview how components and tools interact together to implement the RISKS workflow.
I choose a Secure Digital Card for storing key-files because:
- it's a cheap and common device
- sdcard readers are available out of the box in a good number of laptops
- USB sdcard readers are common and cheap
- it's small factor, light and comfortable
- in microsd format, it can be easily swallowed (in case of need!)
- forgotten inside the slot, it doesn't break when the pc is pushed inside the hand bag
- it's a raw container with few electronic parts: robust and hard to tamper with
- it can be replaced with a common usb pen-drive or usb hard-drive
- easy to clone
- a clone can be easily hidden in some secure place
- it can be hidden among other photo-camera sdcard and can pass checkpoints undetected
- it can be easily sent via regular mail
- it can be used read-only mode but it can be written any time
Vault and secrets
vault handles secrets, passwords and GPG credentials. It hosts an its filesystem a directory
(~/.graveyard) which contains secret-files where data is encrypted and stored.
Sdcard and keys
I use a partitioned sdcard to store the key-files required to open the secret-files laying in the graveyard. The partition containing the key-files, called hush-partition, is encrypted with LUKS and protected by a passphrase (no binary-key). In short, the sdcard does not contain data, it only stores the private keys needed to unlock secret-files (tombs, and LUKS coffin)
Coffins and Tombs
I classify the secret-files contained in the graveyard as coffin-files and tomb-files.
Both are LUKS filesystem with the same security level, so there is essentially no difference in their functioning, and in the tools they use to encrypt/lock/unlock/store data.
The differences between an identity's coffin-file and its tomb-files are the following:
- the management: tomb-files are managed by Tomb, a very comfortable wrapper for
cryptsetup, while coffin-file are managed by
- the passphrase: tomb-files require a key-file plus a mnemonic passphrase to be opened. Coffin-files need just a key-file on the hush device.
There are good reasons why we don't store all data, including the GPG files, in tombs. This is going to be briefly explained below, however it is possible that it will still be unclear to some readers. To get a good grasp, check the Components-Workflow page.
In the coffin-file I store just the GPG-files of the identity (Joe). Each identity has only one coffin-file, in which all GPG files (except GPG private keys) are stored.
The coffin-file uses a binary key-file without passphrase (passphrase-less) stored inside the
hush-partition. Opening a coffin-file requires no mnemonic effort and it's done with a passphrase-less
risq). When a coffin-file is open, vault is able to provide GPG functionality to any other qube.
Note1: Using passphrase-less coffin-files means that anyone who can open the hush-partition can also access my coffins. This is indeed a weak point, but not so weak as it seems because GPG is also protected by its passphrase. This is why GPG passphrases must be strong and well devised.
In tomb-files I usually store generic secret files and directories of files. Each one is protected by a different GPG encrypted binary key stored in the hush-partition.
Opening a tomb-file requires both the binary key and the GPG decryption, which requires to provide a passphrase.
This means that no tomb-file can be opened until:
- The right coffin-file is opened, e.g that the identity GPG keyring is configured is mounted.
- As a prerequisite, that the hush device is available to deliver the coffin-file decryption key.
- GPG is fully configured.
Basically the vault qube is configured with the GPG-split technique (and other split-techniques) which lets other qubes to access the vault GPG agent after the Qubes OS authorization step is cleared (it asks for the GPG-passphrase).
I can manage both the coffin-file and the tomb-file inside the vault qube using
while inside any other authorized qube I can manage just tomb-files with
Credentials and passphrases
I manage the pass-files for each identity with
This grants R.I.S.K.S. credentials management to match these features:
- each identity has its own tomb-file for credentials
- I need just one master password for all the identities but each pass-tomb-file is protected by a different GPG
- password-files follow a lean scheme with very few rules. This allows to store any kind of text and offers maximum freedom