Security of /etc/pacman.d/gnupg etc

jernst · 2014-08-31 00:29:59

I'm confused about the security design related to gpg and pacman. Is there some post that describes this? Would appreciate pointers.

Here is my understanding (which very well could be incorrect). Could somebody more knowledgeable than me correct me?

A new Arch system has no key material related to pacman
Before pacman can be used, keys need to initialized with
```
pacman-key --init
pacman-key --populate archlinux
```
That will:
1. Generate a new GPG key pair
2. Pull the package signer keys from a key server
3. Sign those package signer keys with the locally generated private key, thereby starting a local web of trust.
Now, pacman can validate package signatures against the web of trust as understood by gpg with homedir /etc/pacman.d/gnupg

The thing that I'm confused about is why each Arch system needs a different GPG key pair for that purpose. Couldn't this entire list of steps be pre-generated? It does not seem to matter, security-wise, if all Arch systems had the same GPG key pair. (Because for Alice to attack Bob by slipping a hostile package signer key into Bob's web of trust, Alice could sign the hostile key as she has the same private key as Bob, but could not write that to Bob's trust db unless she was root, and if they can be root, all bets are off anyway as she could simply add the hostile key directly using Bob's private key. If the web of trust was part of some package, upgrades could occur immediately.)

Or is there something about this approach being more secure that I'm not seeing?

I'm also asking because this process for new systems takes a significant amount of time. I'm attempting to script some tests that involve repeatedly setting up new virtual systems in VirtualBox, and tearing them back down, and generating a new key pair every time takes a lot of entropy, which is not necessarily available. So my tests take foreeeveeeer.

(There's also a downside to security:

pacman-key --init

can only run while the system is on the network, and it needs to complete before I can do a systems upgrade from the image that was used to initially boot and before I can install new packages (such as a firewall), during which the latest patches by definition, aren't applied.)

[minor corrections made an hour later]

Last edited by jernst (2014-08-31 01:30:28)

ewaller · 2014-08-31 05:54:10

Part of any key exchange involves the decision by the person joining as to whether they trust the keys or not. These keys are asymmetrical public/private keys. To ensure that the keys have not been compromised, it is up to the user to verify the signatures against something they trust, and acquired independently of the distribution, If they keys were distributed along with the distribution, what keeps them from having been altered? How would you know? Yes, you could check the signatures by hand. It is easier to obtain them from a public key server. If you trust the key server that is. Since most people don't check each key, at least this way they keys arrive by a different path than does the distribution. All one must really check at install time is the hash of the iso. If it is okay, then it is likely the key servers it contacts are real. If the key servers are real, the packages they sign (which are not part of the iso) can probably be trusted. In the mean time, keys expire. Keys are revoked, and new keys are generated. If the keys were burned into the iso, the iso would need to be updated any time anyone's key changed. Rambling answer -- sorry about that

Allan · 2014-08-31 08:19:13

If everyone has the same key at the root of their keychain, then anyone can sign a package with it and the distribute it on a bad mirror. See https://pierre-schmitz.com/random-but-important/ for a story about this...

Pierre · 2014-08-31 10:16:00

Manjaro did this for some time :-) https://pierre-schmitz.com/random-but-important/

jernst · 2014-08-31 19:41:02

I missed that this key pair can also be used to sign packages. Then, indeed, it opens up a gigantic security hole. Thanks for pointing this out.

I'm noting in the referenced post that the live CD has the same performance problem that I have: they create artificial entropy using haveged "to not slow down the boot process".

But I agree with this comment: https://pierre-schmitz.com/random-but-i … omment-130:

Why even sign the master keys locally? It just opens up possible attack vectors. Why not just save the master keys somewhere in /etc/pacman.d/… in a keyring without signing them? What benefit does an archlinux installation obtain from having its own private key?

ewaller · 2014-08-31 20:37:39

Because it is a matter of trust. If you use your private key to sign someone else's key, it means that you trust that person and the key that is their proxy.
If the iso has keys that are signed by whoever made that iso, it means the person who made the iso trusts that key. Do you know who made the iso? How? Do you trust them?

Leonid.I · 2014-08-31 22:06:24

ewaller wrote:

Because it is a matter of trust. If you use your private key to sign someone else's key, it means that you trust that person and the key that is their proxy.
If the iso has keys that are signed by whoever made that iso, it means the person who made the iso trusts that key. Do you know who made the iso? How? Do you trust them?

Um, what's your point? So, you always trust the master keys, as well as the signature of the iso image.... From a security perspective, locally signing the master keys adds nothing.

However, this process serves an important maintainability goal (and this is why GPG web of trust is crucial): if only packages signed with a trusted key are allowed, and the trust is computed using the GPG web-of-trust concept, then it is easy to disable a developer/TU key but simply revoking certain number of master sigs from his key. The trustpath from your local key to that dev's key will be disrupted and no packages signed by that dev. are allowed.

To see this, run "pacman-key -l" and look for the "[ unknown ]" entries. Those are keys with revoked master sigs which are on your keyring but insufficient to allow a package on your system.

Leonid.I · 2014-08-31 22:32:01

jernst wrote:

I'm also asking because this process for new systems takes a significant amount of time. I'm attempting to script some tests that involve repeatedly setting up new virtual systems in VirtualBox, and tearing them back down, and generating a new key pair every time takes a lot of entropy, which is not necessarily available. So my tests take foreeeveeeer.

Do what Arch ISO is doing: use haveged. This way, generating a 2048 bit key is almost instantaneous.

jernst wrote:

(There's also a downside to security:
pacman-key --init
can only run while the system is on the network, and it needs to complete before I can do a systems upgrade from the image that was used to initially boot and before I can install new packages (such as a firewall), during which the latest patches by definition, aren't applied.)

This is wrong, where did you take it from? Indeed, Arch ISO runs this every boot, and there is no network available. Moreover, I think this is a good practice even for a permanent installation (provided haveged is running of course).

ewaller · 2014-08-31 23:48:09

Leonid.I wrote:

Um, what's your point? So, you always trust the master keys, as well as the signature of the iso image....

No, I don't.

From a security perspective, locally signing the master keys adds nothing.

Yes, it does. It means that the administrator of a system has verified that the key for a given developer and trusts packages from that developer. At least they have had the opportunity to verify it. Without a local signing by a key under my control, how do I know if there is a man in the middle? Of course, it is possible to be duped at the outset -- but unless you can actually talk to the person, and know for certain who they are, you need to trust something. In my case, I trust certain key servers.

To see this, run "pacman-key -l" and look for the "[ unknown ]" entries. Those are keys with revoked master sigs which are on your keyring but insufficient to allow a package on your system.

Okay, now it is my turn to ask, what is your point? At issue is, who controls whether they are legitimate? And how do I know that person is who they claim to be?

Allan · 2014-09-01 00:17:49

Locally signing the master keys with your individual key is important. It provides a root to your local web of trust. That means at any stage you can easily disable one of our master keys (and thus all its signatures on developer keys) if it is compromised.

jernst · 2014-09-01 03:26:41

Leonid.I wrote:

jernst wrote:
(There's also a downside to security:
pacman-key --init
can only run while the system is on the network, and it needs to complete before I can do a systems upgrade from the image that was used to initially boot and before I can install new packages (such as a firewall), during which the latest patches by definition, aren't applied.)
This is wrong, where did you take it from? Indeed, Arch ISO runs this every boot, and there is no network available. Moreover, I think this is a good practice even for a permanent installation (provided haveged is running of course).

I stand corrected. The public keys seem to come from package archlinux-keyring and not a key server. I think.

jernst · 2014-09-01 03:29:06

I have attempted to summarize this very helpful discussion on the wiki: https://wiki.archlinux.org/index.php/PacmanWoT

I hope I got it right. If not, please do correct that page. Thanks, everybody!

Leonid.I · 2014-09-01 18:38:36

ewaller wrote:

Leonid.I wrote:
Um, what's your point? So, you always trust the master keys, as well as the signature of the iso image....
No, I don't.
From a security perspective, locally signing the master keys adds nothing.
Yes, it does. It means that the administrator of a system has verified that the key for a given developer and trusts packages from that developer. At least they have had the opportunity to verify it. Without a local signing by a key under my control, how do I know if there is a man in the middle? Of course, it is possible to be duped at the outset -- but unless you can actually talk to the person, and know for certain who they are, you need to trust something. In my case, I trust certain key servers.

My understanding of the original question was essentially "why do we need to have TrustedOnly= entry". Indeed, if there is no local master key, then all public keys on the keyring will have "unknown" trust. So, why is it bad? Of course, you can meet with every developer and _personally_ verify his/her key, but this never happens. So, you (or rather pacman-key) _automatically_ trusts (locally signs) master keys. Sure, you can check their fingerprints, but provided those are "authentic" what is the _security_ benefit of locally signing those master keys?

By itself, none. However, as Allan said, it provides a trust path from your local key to any dev's key via the Arch master keys. If pacman depends on this path and the latter is disrupted, then a malicious package can be kept off the system. This is why having a _installation-specific_ local key is important -- it's a maintenance and control thing, not a magic protection against a man-in-the-middle attack.

Sadly, this subtlety leads to lots of confusion even among the experts: https://www.schneier.com/blog/archives/ … _wi_4.html

ewaller wrote:

To see this, run "pacman-key -l" and look for the "[ unknown ]" entries. Those are keys with revoked master sigs which are on your keyring but insufficient to allow a package on your system.
Okay, now it is my turn to ask, what is your point? At issue is, who controls whether they are legitimate? And how do I know that person is who they claim to be?

You don't. You trust signatures from master keys. Legitimate = key has >= 3 sigs from master keys.

Leonid.I · 2014-09-01 18:50:33

jernst wrote:

I have attempted to summarize this very helpful discussion on the wiki: https://wiki.archlinux.org/index.php/PacmanWoT
I hope I got it right. If not, please do correct that page. Thanks, everybody!

Thanks for taking the time to write the wiki entry... Hopefully, it'll keep people from making stupid mistakes, especially when deploying chroots and containers using pacstrap (which usually copies host master key to container).

BTW, do you know whether other distros (specifically debian and fedora) have an analog of the master key? I couldn't find it, but perhaps I missed something...

Last edited by Leonid.I (2014-09-01 18:50:46)

Arch Linux

#1 2014-08-31 00:29:59

Security of /etc/pacman.d/gnupg etc

#2 2014-08-31 05:54:10

Re: Security of /etc/pacman.d/gnupg etc

#3 2014-08-31 08:19:13

Re: Security of /etc/pacman.d/gnupg etc

#4 2014-08-31 10:16:00

Re: Security of /etc/pacman.d/gnupg etc

#5 2014-08-31 19:41:02

Re: Security of /etc/pacman.d/gnupg etc

#6 2014-08-31 20:37:39

Re: Security of /etc/pacman.d/gnupg etc

#7 2014-08-31 22:06:24

Re: Security of /etc/pacman.d/gnupg etc

#8 2014-08-31 22:32:01

Re: Security of /etc/pacman.d/gnupg etc

#9 2014-08-31 23:48:09

Re: Security of /etc/pacman.d/gnupg etc

#10 2014-09-01 00:17:49

Re: Security of /etc/pacman.d/gnupg etc

#11 2014-09-01 03:26:41

Re: Security of /etc/pacman.d/gnupg etc

#12 2014-09-01 03:29:06

Re: Security of /etc/pacman.d/gnupg etc

#13 2014-09-01 18:38:36

Re: Security of /etc/pacman.d/gnupg etc

#14 2014-09-01 18:50:33

Re: Security of /etc/pacman.d/gnupg etc

Board footer