Tails

#2 Updated by intrigeri 2018-07-04 17:44:13

> It sounds weird that the cryptographic content embeded in a Tails image is not trusted, while we have extensive verification mechanism for the image itself.
> And actually, our OpenPGP verification documentation (wrongly) takes this for granted as seen in Bug #15697.

IIRC there are two kinds of trust that GnuPG manages on a keyring:

• how well the owner of the keyring has verified that the key is indeed controlled by its UIDs → for this one, I think it would probably be reasonable to mark all the Tails public keys we include in the ISO as “trusted”
• how much the owner of the keyring trusts the key to certify other keys → for this one, it’s a personal decision, has nothing to do with how carefully we craft our ISO, and I don’t think we can legitimately decide this for the user

I think the message seen on Bug #15697 is about the first kind of trust but I’m not 100% sure. Sorry all this is so confusing!
I would suggest asking dkg what his take on this is. And if he can’t or does not want to, I can act as a fallback but it’ll take me quite some time to understand this correctly and research our options.

#5 Updated by taowa 2018-08-10 16:00:11

In my understanding, the second one affects the first but not vice versa.

Here’s the output of `gpg —list-key` if I just have the Tails key in my keyring and haven’t marked it trusted:
> user@disp2158:~$ gpg —list-key
> pub rsa4096 2015-01-18 [C] [expires: 2019-01-11]
> A490D0F4D311A4153E2BB7CADBB802B258ACD84F
> uid [ unknown] Tails developers <tails@boum.org>
> uid [ unknown] Tails developers (offline long-term identity key) <tails@boum.org>

Here’s the output if I have both the Tails key and my key, and haven’t marked either as trusted:
> user@disp2158:~$ gpg —list-key
> pub rsa4096 2015-01-18 [C] [expires: 2019-01-11]
> A490D0F4D311A4153E2BB7CADBB802B258ACD84F
> uid [ unknown] Tails developers <tails@boum.org>
> uid [ unknown] Tails developers (offline long-term identity key) <tails@boum.org>
>
> pub rsa4096 2018-07-10 [C] [expires: 2022-07-09]
> 8FB9C5D6AE7BA82B7BB1D887C51EA7006E6BDC0D
> uid [ unknown] Taowa Munene-Tardif <taowa@taowa.ca>

Here’s the output if I set my key (which has signed the Tails key) as trusted:
> user@disp2158:~$ gpg —edit-key Taowa
> gpg> trust
> Your decision? 5
> Do you really want to set this key to ultimate trust? (y/N) y
> gpg> save
> user@disp2158:~$ gpg —list-key
> gpg: checking the trustdb
> gpg: marginals needed: 3 completes needed: 1 trust model: pgp
> gpg: depth: 0 valid: 1 signed: 1 trust: 0-, 0q, 0n, 0m, 0f, 1u
> gpg: depth: 1 valid: 1 signed: 0 trust: 1-, 0q, 0n, 0m, 0f, 0u
> gpg: next trustdb check due at 2019-01-11
> pub rsa4096 2015-01-18 [C] [expires: 2019-01-11]
> A490D0F4D311A4153E2BB7CADBB802B258ACD84F
> uid [ full ] Tails developers <tails@boum.org>
> uid [ full ] Tails developers (offline long-term identity key) <tails@boum.org>
>
> pub rsa4096 2018-07-10 [C] [expires: 2022-07-09]
> 8FB9C5D6AE7BA82B7BB1D887C51EA7006E6BDC0D
> uid [ultimate] Taowa Munene-Tardif <taowa@taowa.ca>

So, GPG looks at the trust set manually, and uses this to determine the trust of other keys. So Bug #15697 is based on the “trust” that the key has, and this is determined based on both trust manually assigned to individual keys and whether a given key has been signed by a trusted key.

#6 Updated by Anonymous 2018-08-16 10:42:02

Thanks Taowa! I’m leaving this assigned to dkg just in case he has more comments on the issue.

#10 Updated by dkg 2019-01-08 16:48:21

What context are you asking about? is this for the standard user’s GnuPG keyring in a running instance of tails? If it’s just about verifying signatures during a well-defined software verification process against a known key, then you don’t need anything like ownertrust. What you need is a curated keyring (e.g. in a well-known location in the filesystem) and then to do the verification with:

gpgv —keyring /path/to/curated/keyring.gpg cd.iso.sig cd.iso

That’s it.

---

If you’re asking about how to pre-configure a user’s GnuPG installation so that it “knows” that the Tails key is valid, then read on:

in the standard GnuPG trust model (`—trust-model=pgp`, the default), setting the ownertrust in a key means that you are willing to rely on this key to identify other parties.

So if you set the ownertrust on key X to “ultimate”, then you’re making key X capable of forging believable OpenPGP certificates for anyone else. To use a comparison from the X.509 world, it’s like setting it up as an unlimited root CA. Do the people who control that key expect it to have that kind of authority? If they’re OK with that, then go ahead.

But do note that some users might resent the key that controls operating system upgrades (which are noticable) from being given extra online powers. in particular, the Tails signing key can now be used to inject fake OpenPGP certificates for Tails users who use GnuPG with the given setting already applied.

There are two other routes you can take if what you want is for this key in particular to be considered valid, but you don’t want to grant it root-CA powers:

1. Dynamically set up a local, private key that does have ultimate trust (call it “key Z”). key Z won’t be used anywhere else, and will effectively be private, the equivalent of having local control over this instance of the operating system. Then make a local certification of the OpenPGP certificate in question with key Z. you could even delete the secret key after creating it and assigning this trustlevel, so that it cannot be further abused. `monkeysphere-authentication` uses a custom local key like this (along with some even fancier tricks involving trust signatures to manage its set of identity certifiers, which aren’t necessary for Tails) for managing its internal keyring. One problem with this approach is that users might wonder what this special local key is.
2. Use a different trust model. For example, if you use `—trust-model=direct` then GnuPG collapses the distinction between `ownertrust` and `validity`, while ignoring all third-party certifications. in that case, placing `trust-model direct` in the relevant `gpg.conf` and marking the key you care about with `full` trust will grant it full validity. (note that the `ownertrust` field disappears from GnuPG’s UI in this case). The problem with this approach if it is applied to keyrings that the user sees

#11 Updated by sajolida 2019-01-09 12:57:19

Thanks for chiming in!

> What context are you asking about?

When verifying a Tails download from inside Tails, people get an
“untrusted” notification from Seahorse Nautilus. See Bug #15697.

So yeah, that’s using the user’s GnuPG keyring in a running instance of
Tails.

> If you’re asking about how to pre-configure a user’s GnuPG installation so that it “knows” that the Tails key is valid, then read on:
>
> in the standard GnuPG trust model (`—trust-model=pgp`, the default), setting the ownertrust in a key means that you are willing to rely on this key to identify other parties.

That’s what I thought already. I guess that’s why only the “ultimate”
level changes the signature from “untrusted” to “trusted”.

> Do the people who control that key expect it to have that kind of authority?

The people who control that key are a small subset of the people who
decide what gets in Tails. So as long as this “ultimate” trust only
affects how Tails behaves, I think we’re fine.

Can you confirm that this “ultimate” trust wouldn’t be exported outside
of Tails?

> If they’re OK with that, then go ahead.

But I’ll ask them anyway :)

> But do note that some users might resent the key that controls operating system upgrades (which are noticable) from being given extra online powers. in particular, the Tails signing key can now be used to inject fake OpenPGP certificates for Tails users who use GnuPG with the given setting already applied.

Understood.

> # Dynamically set up a local, private key that does have ultimate trust (call it “key Z”). key Z won’t be used anywhere else, and will effectively be private, the equivalent of having local control over this instance of the operating system. Then make a local certification of the OpenPGP certificate in question with key Z. you could even delete the secret key after creating it and assigning this trustlevel, so that it cannot be further abused. `monkeysphere-authentication` uses a custom local key like this (along with some even fancier tricks involving trust signatures to manage its set of identity certifiers, which aren’t necessary for Tails) for managing its internal keyring. One problem with this approach is that users might wonder what this special local key is.
>
> # Use a different trust model. For example, if you use `—trust-model=direct` then GnuPG collapses the distinction between `ownertrust` and `validity`, while ignoring all third-party certifications. in that case, placing `trust-model direct` in the relevant `gpg.conf` and marking the key you care about with `full` trust will grant it full validity. (note that the `ownertrust` field disappears from GnuPG’s UI in this case). The problem with this approach if it is applied to keyrings that the user sees

Both approaches seem to be more complex for us to put in place and with
usability drawbacks for users… I might prefer sticking with the
original “untrusted” notification and don’t spend any more time on this.

I’m marking this as “Discuss” now since I think we’re ready for a
discussion during a monthly meeting.

Thanks dkg!