Thanks for this abel - I see that figuring out how to sign other people’s keys is on the TODO list
I have a setup that works for me now, but it seems that signing other people’s keys and uploading to the keyserver will be a long and tricky process… Is anyone using this setup on a day to day basis and can advise on how to make signing other people’s keys reasonably usable?
But, that method requires
(a) networking from "vault"
(b) mounting "vault"'s filesystem from an untrusted day-to-day AppVM
Both of these are no-no's in QubesOS
closer to a QubesOS setup, as it talks about a properly isolated
environment (similar to the QubesOS vault), but does not explain what to do
after you've signed someone else's key. How do you update your regular
day-to-day keyring so that it knows the public key you signed is now
trusted?
It is not Qubes OS specific, and in fact assumes you want to use a
smartcard, which might not be the case, so skip those bits.
Also, use your vault vm instead of booting into an offline livecd as
described.
~abel
Thanks for this abel - I see that figuring out how to sign other people's
keys is on the TODO list
I have a setup that works for me now, but it seems that signing other
people's keys and uploading to the keyserver will be a long and tricky
process... Is anyone using this setup on a day to day basis and can advise
on how to make signing other people's keys reasonably usable?
But, that method requires
(a) networking from "vault"
(b) mounting "vault"'s filesystem from an untrusted day-to-day AppVM
Both of these are no-no's in QubesOS
I think such assumptions are no-no's in any reasonable environment
(including air-gapped). A vault that is network-connected is... not a
vault really. A vault whose filesystem is accessible by untrusted
entities... come on, is it a joke, or something?
https://wiki.fsfe.org/Card_howtos/Card_with_subkeys_using_backups/#Paying_the_Orks_a_visitcomes
closer to a QubesOS setup, as it talks about a properly isolated
environment (similar to the QubesOS vault), but does not explain what to do
after you've signed someone else's key. How do you update your regular
day-to-day keyring so that it knows the public key you signed is now
trusted?
The problem is that the gpg in the vault should not be forced to process
any external (so untrusted) input. Copying somebody's else key there is
just breaking of all the security model that a air-gapped gpg can
provide to you.
So, generally not only you should not try to sign other keys in your
vault, you should not even import them there. More thoughts on this in
the ticket description and the thread linked from there:
- Split GPG is work in progress - aiming to be part of QubesOS
Release
3
- As of now (Aug 2013) the best QubesOS users can do is use GPG as
they
would on any GNU/Linux system.
Actually, the best a Qubes user might do, is to... submit some
patches
to make real Split GPG working as described in the ticket
But generally, even if you don't use split GPG, Qubes OS still offers
some advantages, such as e.g. you can generate and keep the master
key
in your "vault" AppVM (e.g. network disconnected) and use it to sign
your short-term keys that are to be kept in normal AppVMs. The key
export could be then done easily via qvm-copy-to-vm (but *never*
import
keys to your super-secret vault AppVM, only export from it!).
joanna.
That sounds like reasonably secure and not too unusable. Can you point
me
to any decent HOWTO online on the steps required to achieve this
offline-long-term-key and exposed-short-term-keys setup?
Take a look at the regular GnuPG docs, they talk there about a scenario
with using a separate machine for your long-term keys, IIRC.
j.
So the docs under GnuPG - HOWTOs do not
explicitly cover this scenario - the closest one is the smartcard HOWTO,
but it's convoluted.
It is not Qubes OS specific, and in fact assumes you want to use a
smartcard, which might not be the case, so skip those bits.
Also, use your vault vm instead of booting into an offline livecd as
described.
~abel
Thanks for this abel - I see that figuring out how to sign other people's
keys is on the TODO list
I have a setup that works for me now, but it seems that signing other
people's keys and uploading to the keyserver will be a long and tricky
process... Is anyone using this setup on a day to day basis and can advise
on how to make signing other people's keys reasonably usable?
For now, as Joanna stated, I don't sign other people's keys. I don't
like to use the public WOT (keyservers) anyways.
In the one or two cases where I really did need to sign another key, I
made a duplicate of my USB key, using dd, that contains my "clean room"
OS and an encrypted partition with my master key. Then I booted, signed
the key in question, exported it via another usb stick or sd card, and
finally, destroyed the duplicate USB key.
The computer that I was booting on had it's networking hardware removed.
Please review & let me know for any holes in this QubesOS-specific writeup:
The one bug of this approach I'm aware of is that initial key generation
should happen in the vault, with the less-trusted keyring transferred to
the less trusted networked AppVM. I realised that after doing most of the
work and now haven't got time to fix it until September.
The other bug I'm well aware of is that this setup doesn't offer any
anonymity, since the spooks primarily care about relationships between
people, which PGP doesn't protect, but hey, let's focus on doing the best
we can with the tools we have here.
One minor bug is that key IDs are not consistent throughout the writeup because I did this with two sets of keys, but I doubt anyone will notice - may do some sed’ing to fix it next time I have some time to work on this.