GPG for ${IDENTITY} is functional with a full backup but it lacks Cabal’s mitigation. I need a tomb-file where I can move some files.

tomb-file creation

I set these variables and I create the tomb-file following the standard procedure.

IDENTITY="joe"
RECIPIENT="joe@foo.bar"
LABEL="cabal"
TOMBID="${IDENTITY}-${LABEL}"
SIZE=15
DIR="/tmp/cabal"

I open it with:

risks open ${LABEL} ${IDENTITY}

which mounts the tomb file in ${HOME}/.tomb/${LABEL}

Cabal’s mitigation

When the tomb-file is ready I move away from ~/.gnupg the files that I want to protect:

  • my primary key-pair private key
  • my revoke certificate for the primary key-pair

Thanks to the “Keygrip” GPG option I can easily identify the file containing it:

echo "$(gpg -K | grep Keygrip | head -n 1 | cut -d= -f 2).key"

50123401D7AA3CBF514F23D5FA98D3D485075B2E.key
cp ~/.gnupg/private-keys-v1.d/50123401D7AA3CBF514F23D5FA98D3D485075B2E.key ${HOME}/.tomb/${LABEL}/
cp ~/.gnupg/openpgp-revocs.d/72052A26269F7552DDED36626596C5FA775EB9AB.rev ${HOME}/.tomb/${LABEL}/

To be sure that the primary private key and the recovery file are erased from the gpg coffin-file:

wipe -f ~/.gnupg/private-keys-v1.d/50123401D7AA3CBF514F23D5FA98D3D485075B2E.key
wipe -f ~/.gnupg/openpgp-revocs.d/72052A26269F7552DDED36626596C5FA775EB9AB.rev
dd if=/dev/random of=~/.gnupg/delme
rm ~/.gnupg/delme

This is what I’m left with in my ~/.gnupg directory:

tree ~/.gnupg
.
├── gpg.conf
├── openpgp-revocs.d
├── private-keys-v1.d
│   ├── 3880DC542784CFC56B5773E50FF00289620071EA.key
│   ├── 4CB933841DCDF831B4CFFBC688B055BE472AC778.key
│   └── 4E37F90BFA7E9A823283F3976C79499A67E0EA03.key
├── pubring.gpg
├── pubring.kbx
├── pubring.kbx~
├── random_seed
├── tofu.db
└── trustdb.gpg

Let’s see what’s different. When I run:

gpg -K

/home/user/.gnupg/pubring.kbx
-----------------------------
sec#  rsa4096/0x6596C5FA775EB9AB 2018-10-08 [SC]
    Key fingerprint = 7205 2A26 269F 7552 DDED  3662 6596 C5FA 775E B9AB
    Keygrip = 50123401D7AA3CBF514F23D5FA98D3D485075B2E
uid                   [ultimate] Joe Tester <joe@foo.bar>
sub   rsa4096/0xFCFB0E137879D519 2018-10-08 [E] [expires: 2019-12-31]
    Key fingerprint = 6598 5A20 E7D5 871E E0EF  5A52 FCFB 0E13 7879 D519
    Keygrip = 4CB933841DCDF831B4CFFBC688B055BE472AC778
sub   rsa4096/0xB7CB9817FF022A44 2018-10-08 [S] [expires: 2019-12-31]
    Key fingerprint = 5FF4 7D3F FD9F 95DB 9C96  1455 B7CB 9817 FF02 2A44
    Keygrip = 4E37F90BFA7E9A823283F3976C79499A67E0EA03
sub   rsa4096/0xB358AAABA8703BD8 2018-10-08 [A] [expires: 2019-12-31]
    Key fingerprint = DB1C 141B 9080 57E0 09AA  3F68 B358 AAAB A870 3BD8
    Keygrip = 3880DC542784CFC56B5773E50FF00289620071EA

I notice that the primary key-pair has a different label: sec# instead of pub

excuse my ignorance: I don’t know what sec# stands for

Publish the public key

If I want to build a “web of trust” for Joe I should publish his public key on some key server which will spread it to other key servers.

By publishing Joe’s public key other people will be able to find it simply by looking for Joe’s email address. They can add it to their key-ring and use it for sending him encrypted files or emails that can be decrypted only by Joe.

This is the least a journalist should have.

If vault had network connection I could use this command for publishing the key:

gpg --send-key ${fingerprint}

but vault is network less so I need another way.

These are the steps:

  • I copy my armored public key to another qube (like joe-devq) which has network accees
  • I open a browser and go to any GPG key server URL (like https://pgp.surfnet.nl/)
  • I open the armored key with a text editor and I copy its content in the clipboard
  • I look for the upload button and I paste in the text-area the content of your public key (now it should be clear why the photo should be small)

Usually the key server, after a successful upload, replies with something like this:

Key block added to key server database. New public keys added: 1 key(s) added successfully.

As a test I search for Joe’s email inside the key server.


GPG-SPLIT setup

Qubes OS offers a fantastic solution called Qubes Split GPG

Split GPG implements a concept similar to having a smart card with your private GPG keys, except that the role of the smart card plays another Qubes AppVM. This way one, not-so-trusted domain, e.g. the one where Thunderbird is running, can delegate all crypto operations, such as encryption/decryption and signing to another, more trusted, network-isolated, domain. This way the compromise of your domain where Thunderbird or another client app is running arguably a not-so-unthinkable scenario does not allow the attacker to automatically also steal all your keys.

I configure vault and joe-devq with GPG Split so that I can use GPG from joe-devq without having any GPG configuration file in it.

joe-devq template configuration

In the template of joe-devq (debian-10-dev)

sudo apt-get install qubes-gpg-split
sudo mv /usr/bin/gpg /usr/bin/gpg-ori
ln -s $(which qubes-gpg-client) /usr/bin/gpg
sudo shutdown -P 0

joe-devq configuration

In joe-devq (not the template)

echo 'export QUBES_GPG_DOMAIN="vault"' >> ~/.bashrc && sudo shutdown -P 0

Qubes configuration

In dom0:

echo '$anyvm $anyvm ask' > /etc/qubes-rpc/policy/qubes.Gpg

Vault configuration

The package qubes-gpg-split should be already installed but in case it’s not:

sudo apt-get install qubes-gpg-split

Optionally I can change for how long vault will grant access to GPG clients. The default is 5 minutes but I can make it an hour in this way.

I tried adding this global var to ~/.profile or ~/.bashrc but it doesn’t work for me. Not sure why.

sudo sh -c 'echo "export QUBES_GPG_AUTOACCEPT=3600" >> /etc/profile.d/qubes-gpg.sh'

Test

In vault:

risks open gpg joe

I restart joe-devq and I run:

gpg -K

I immediately see the Qubes OS interface the authorization.

Cleared the Qubes authorization step, I see in the terminal the same outpet I see by running gpg -K in vault

The same happens if I run:

qubes-gpg-client -K

Skip Qubes authorization step

Optionally, if I trust joe-devq enough, I can disable the Qubes authorization step in this way:

In dom0:

echo 'joe-devq vault allow' > /etc/qubes-rpc/policy/qubes.Gpg
echo '$anyvm $anyvm ask' >> /etc/qubes-rpc/policy/qubes.Gpg