Re: [qubes-users] OpenPGP in QubesOS

Thanks for this abel - I see that figuring out how to sign other people’s keys is on the TODO list :slight_smile:

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?

Alex

I think we're getting closer here -
http://www.macfreek.nl/memory/Convert_GPG_keys_to_subkeys describes a setup
that seems quite usable with a traditional OS and a USB key.

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?

Alex

Alex:
<snip>

I found https://alexcabal.com/**creating-the-perfect-gpg-**keypair/<https://alexcabal.com/creating-the-perfect-gpg-keypair/>which I
think describes the scenario you have in mind. Just treat your

less-trusted

AppVMs as the "laptop" of the blog post. Appears to work ok, not sure

about

keysigning, interaction with keyservers etc. If I ever understand how

this

whole mess works, I might even do a writeup. Just so that I never, ever
have to figure this out again!

I maintain a document that describes how to do this:
https://gist.github.com/**abeluck/3383449<https://gist.github.com/abeluck/3383449>

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 :slight_smile:

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?

I think we're getting closer here -
http://www.macfreek.nl/memory/Convert_GPG_keys_to_subkeys describes a setup
that seems quite usable with a traditional OS and a USB key.

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:

http://wiki.qubes-os.org/trac/ticket/474

joanna.

Alex:

Alex:

What is the canonical usage method for OpenPGP in QubesOS?

Is split PGP ready, or is it WIP and right now the best we can do

is

use

GPG as in any Linux system?

http://wiki.qubes-os.org/trac/ticket/474

j.

I take this to mean

- 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 :slight_smile:

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 http://gnupg.org/documentation/howtos.en.html do not
explicitly cover this scenario - the closest one is the smartcard HOWTO,
but it's convoluted.

I found https://alexcabal.com/creating-the-perfect-gpg-keypair/ which I
think describes the scenario you have in mind. Just treat your

less-trusted

AppVMs as the "laptop" of the blog post. Appears to work ok, not sure

about

keysigning, interaction with keyservers etc. If I ever understand how

this

whole mess works, I might even do a writeup. Just so that I never, ever
have to figure this out again!

'
I maintain a document that describes how to do this:
https://gist.github.com/abeluck/3383449

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 :slight_smile:

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.

~abel

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.

-A

Hi all,

I created a wiki page on using OpenPGP in Qubes. It can be found here:
qubes-os.org/trac/wiki/UserDoc/OpenPGP

Please let me know if you have any corrections.

- -Axon

This has now been fixed:

  • Key generation is done in the vault.
  • A “lesser” keyring is generated in the vault and then exported to networked AppVMs.
  • At no point does the certification key leave the vault.
  • No untrusted input is processed by the vault.
  • The vault is not networked.

I’ve updated the documentation in https://qubes-os.org/trac/wiki/UserDoc/OpenPGP to reflect that.

Please read/debug the writeup at https://apapadop.wordpress.com/2013/08/21/using-gnupg-with-qubesos/ :slight_smile:

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.

Alex