Project

General

Profile

Bug #15710

The Tails signing key is not trusted from within Tails

Added by sajolida about 1 year ago. Updated 7 months ago.

Status:
Confirmed
Priority:
Normal
Assignee:
-
Category:
Installation
Target version:
-
Start date:
07/04/2018
Due date:
% Done:

0%

Feature Branch:
Type of work:
Discuss
Blueprint:
Starter:
Affected tool:

Description

See #15697.

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 #15697.

Am I missing something?


Related issues

Related to Tails - Bug #15697: Downloading ISO and verifying signature not giving result shown in instructions Confirmed 07/01/2018
Related to Tails - Bug #11785: Users get confused by the particularities of the Tails signing key Rejected 09/08/2016
Related to Tails - Bug #16327: Sign the key of tails-{fundraising,mirrors,sysadmins}@boum.org with the signing key Confirmed 01/08/2019

History

#1 Updated by sajolida about 1 year ago

  • Related to Bug #15697: Downloading ISO and verifying signature not giving result shown in instructions added

#2 Updated by intrigeri about 1 year ago

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 #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 #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.

#3 Updated by mercedes508 about 1 year ago

  • Status changed from New to Confirmed

#4 Updated by sajolida about 1 year ago

  • Assignee set to dkg
  • QA Check set to Info Needed

dkg: Any quick opinion or advice on this? Otherwise I'm fine doing more tests.

#5 Updated by taowa about 1 year ago

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 <>
uid [ unknown] Tails developers (offline long-term identity key) <>

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 <>
uid [ unknown] Tails developers (offline long-term identity key) <>

pub rsa4096 2018-07-10 [C] [expires: 2022-07-09]
8FB9C5D6AE7BA82B7BB1D887C51EA7006E6BDC0D
uid [ unknown] Taowa Munene-Tardif <>

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 <>
uid [ full ] Tails developers (offline long-term identity key) <>

pub rsa4096 2018-07-10 [C] [expires: 2022-07-09]
8FB9C5D6AE7BA82B7BB1D887C51EA7006E6BDC0D
uid [ultimate] Taowa Munene-Tardif <>

So, GPG looks at the trust set manually, and uses this to determine the trust of other keys. So #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 u about 1 year ago

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

#7 Updated by u about 1 year ago

  • Related to Bug #11785: Users get confused by the particularities of the Tails signing key added

#8 Updated by sajolida 7 months ago

  • Assignee changed from dkg to intrigeri

I did more tests.

Setting the trust to "Ultimate" fixes the notification when verifying an image. See #15697. Setting the trust to "Full" does not.

Setting the trust to "Ultimate" also moves the trust of the other Tails keys included in the image to "Full". All but tails-mirrors@ and tails-sysadmins@. See #16327.

intrigeri: I think I can write a patch that gives ultimate trust to the signing key in our images. Shall I do that?

#9 Updated by sajolida 7 months ago

  • Related to Bug #16327: Sign the key of tails-{fundraising,mirrors,sysadmins}@boum.org with the signing key added

#10 Updated by dkg 7 months ago

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 7 months ago

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 #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.

  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.
  1. 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!

#12 Updated by sajolida 7 months ago

  • Assignee deleted (intrigeri)
  • QA Check deleted (Info Needed)

Also available in: Atom PDF