Maintaining the kernel's web of trust

Posted Sep 5, 2019 13:16 UTC (Thu) by corbet (editor, #1)
In reply to: Maintaining the kernel's web of trust by weberm
Parent article: Maintaining the kernel's web of trust

You don't need to trust that repo, you just need to trust Linus's key; everything else leads back to that.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 13:52 UTC (Thu) by weberm (guest, #131630) [Link] (6 responses)

AFAIUI the chain which leads back to Linus' key is stored within that repository. The chain is embodied by the signatures on the keys. The keys and these signatures are stored in the repository. Which is stored on kernel.org. Which we don't trust.

I still must be missing something so brutally obvious to you folks. Probably ... knowledge. Thanks for bearing with me.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 14:17 UTC (Thu) by weberm (guest, #131630) [Link] (3 responses)

I guess the thing I don't grok is how I establish a new local root of trust if my source of trust is something that is potentially forged. In theory, I could, if I took over kernel.org, forge a new universe in which I own all private keys of all authors (freshly generated), reproduce the whole signature chain, and have my copies sign things in the other git repo(s) on kernel.org because I can.
Now if another user wants to verify the integrity of their fresh clone of linux from kernel.org, and if their source of the keys and the chains is also kernel.org, and they did not have a local trust anchor ... I guess I have to RTFM :shrug:
Developers, of course, will have their local cache, but even developers lose machines, and backups, and there may be points in time where they have to re-establish their own anchors.
It just seems fishy to me to store the thing you're securing and the thing you're securing it with on the same, potentially hostile infrastructure.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 14:32 UTC (Thu) by farnz (subscriber, #17727) [Link]

This is the gotcha built-in to all trust systems - you need some form of external verification to ensure that you have a valid root of trust. In a web-of-trust system, that means that you need external validation of one of the keys in the web which you can then use to get to a point where you're confident that you trust all the people in the web. In a trusted third party system (like X.509), you need root CAs that you implicitly trust.

For this system, the goal is that you get a key for Linus, or Dave Miller, or AKPM, or Corbet, or someone else in the kernel WoT from them via another route (perhaps a page on lwn.net?). You can then use that to validate the keys for the entire repo, and can raise the alarm if a forged WoT repo contains the "wrong" key for your root of trust. Similar can happen if (e.g.) Linus discovers that he can't find a path from his key to the publicly known key for (say) Alan Cox - he knows that path should exist, but "Linus Torvalds" in the WoT repo is not the same key as his own key, and he can raise the alarm instead.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 18:35 UTC (Thu) by naptastic (guest, #60139) [Link] (1 responses)

I think I see the distinction you're looking for that hasn't been made clear yet.

It's not that the keys are being stored somewhere else, it's that they're being stored differently. Instead of being files on a key server, they are part of the repository itself. In order to successfully replace a legitimate key with a malicious one, you would have to compromise and alter every copy of the Linux git repository checked out anywhere. If the "canonical" git tree hosted on kernel.org gets tampered with, there are thousands of developers with pristine git histories who would immediately know something was wrong, and what to do about it.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 19:10 UTC (Thu) by naptastic (guest, #60139) [Link]

Disregard; I should have read the rest of the thread.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 14:27 UTC (Thu) by corbet (editor, #1) [Link] (1 responses)

Linus's public key is pretty well known at this point and, as far as we know, only he controls it. That is the key that you mark as trusted in your own keyring; it need not come from the pgpkeys.git repo. Any keys that are in that repo that are signed by Linus's key should be trustable, since only he could have done that. We know that he trusts those keys, anyway. And so continues the chain.

The situation is no different than the public keyservers we had before, where anybody could upload a key claiming to belong to anybody. But those keys lacked the requisite signatures and would not be trusted.

Maintaining the kernel's web of trust

Posted Sep 5, 2019 14:43 UTC (Thu) by weberm (guest, #131630) [Link]

Thank you (and farnz) for shedding light on my blind spot.