Skip to content

Latest commit

 

History

History
191 lines (128 loc) · 8.63 KB

05_under-the-hood.md

File metadata and controls

191 lines (128 loc) · 8.63 KB
Raw
title permalink
Under the hood
/under-the-hood

R.I.S.K.S. architecture

Implementing R.I.S.K.S. provides:

  • one qube for managing secrets, called vault
  • one qube for storing files, called joe-fsq
  • one qube for software development or writing, called joe-devq
  • a mechanism, based on sdcard, for managing key-files
  • disaster recovery and backup procedures

joe-fsq and joe-devq are the tool-set for a virtual identity called Joe.

With R.I.S.K.S. GPG, SSH and pass-files are encrypted and isolated but pretty easy to retrieve and use.

The attempt is to obtain a reasonable workflow for for daily use.

From the operational standpoint I implement the R.I.S.K.S. workflow with two bash scripts risks and risq provided in the RISKS-SCRIPTS repository

Why an sdcard?

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 which handles secrets, passwords and GPG. Nothing else.

It's a minimal Debian with no network connection.

vault hosts an its filesystem a directory named graveyard (~/.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.

I connect the sdcard to the vault via a script (part of the risks-script repository).

The partition containing the key-files, called hush-partition, is encrypted with LUKS and protected by a passphrase (no binary-key).

Secrets: 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. The two types differ in:

  • the management: tomb-files are managed by Tomb, a very comfortable wrapper for cryptsetup, while coffin-file are managed by cryptsetup
  • the passphrase: tomb-files require a key-file plus a mnemonic passphrase to be opened. Coffin-files need just a key-file.

In the coffin-file I store just the GPG-files of the identity (Joe). One coffin-file for a each identity.

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 script (risq). When a coffin-file is open, vault is able to provide GPG functionality to any other qube.

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 in the vault qube and 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 risks while, inside any other authorized qube I can manage just tomb-files with risq.

Note1: Using passphrase-less coffin-files means that who can open the hush-partition can also access my coffins. This is indeed a weak point not so weak as it seems because GPG is also protected by its passphrase. This is why GPG passphrases must be strong and well done.

Note2: When the number of identities is big enough, the required mnemonic effort could become dangerously high (one passphrase per identity). Optionally, although advised, I can decide to store the GPG passphrases inside the hush-partition in a file encrypted via SSL and AES-256. Then I can retrieve them with risks by providing the mpw password (or any other password I want to use).

Credentials and passphrases

I manage the pass-files for each identity with pass. In most of the cases I use mpw seamlessly within pass.

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

RISKS workflow without SSL & MPW password

This is what I do when I need to work with identity Joe:

  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 Joe's GPG passphrase
  10. I access Joe's passwords using pass and eventually mpw (which requires a password)

How much mnemonic effort is that?

Let's measure it:

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

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

  • 3 passphrases (Qubes fs, sdcard, GPG)
  • 2 passwords (Qubes user, mpw master password)

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

  • 4 passphrases (Qubes fs, sdcard, 2 x GPG)
  • 2 passwords (Qubes user, mwp master password)

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

  • 5 passphrases (Qubes fs, sdcard, 3 x GPG)
  • 2 passwords (Qubes user, mpw master password)

This is the formula:

2 passwords + (#number_of_identities + 2) passphrases

The annoying part is that the total number of GPG passphrases required increases with the number of identities.

RISKS workflow with SSL & MPW password

This is what I do when I need to work with identity Joe:

  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 + mpw master password)
  10. I access Joe's passwords using pass and eventually mpw (which requires a password)

How much mnemonic effort is that?

  • 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 mpw (step 9 and 10)

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

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

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

  • 2 passphrases (Qubes fs, sdcard)
  • 2 passwords (Qubes user, mpw 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.