On Thu, Jan 05, 2006 at 04:43:13PM -0800, Thomas Bushnell BSG wrote: > Steve Langasek <vorlon@debian.org> writes: > > AIUI, Ubuntu isn't rotating their archive keys -- something else that their > > centralized model more readily affords them. > I'm a little confused about why we do rotate the keys. I'm not > experienced in thinking through the subtle issues concerned, so I'm > trying to learn, because I know that Debian has plenty of people who > *do* have this experience, and I want to learn/understand. > With a non-expiring key, there is the risk that the key will be > compromised. > However, with the expiring key, there is the risk that a fake key will > be generated at the expected roll-over time. > In other words, I needed to fetch the new key this week, from the web > site, and tell my system "yeah, that's the right key." Of course, the > new key is signed with the old key. It's also signed with some sigs > that I haven't checked, which I assume are the Debian ftpmasters. > However, nothing about the apt-key procedure actually seems to have > *checked* any of these signatures. There are four main attack vectors that I can see: - compromise of the user's local network connection - compromise of the user's local mirror - compromise of the PGP key, together with one of the preceding - compromise of ftp-master itself In the fourth case, either the compromise is detected by the admins, or it isn't. If it isn't, all bets are off: we can only ever have cryptographic assurance that the packages came from ftp-master, not that the packages that came from ftp-master are *good*, so we focus instead on prevention and detection of compromises instead and eliminate this case from consideration. If the compromise *is* detected by the admins, the key is revoked, the server is re-secured, and a new key is issued. So we know that our system has to deal with key revocations: providing means of both broadcasting the key revocation as widely as possible to users, and delivering a replacement key to those same users as securely as possible. In the third case, again the compromise is either detected, or it isn't. If it's detected, we're revoking the key again; if it's *not* detected (and it seems to me that anyone able to compromise the pgp key without also having to compromise ftp-master is likely good enough to go undetected), then this is a case where scheduled key rotations help us. It also shouldn't *hurt* us, since we need to have a sound process in place for dealing with key replacements regardless due to the possibility of compromise. The first two cases provide us with a rationale for wanting cryptographic assurances in the first place, and insight into what that assurance ought to look like. For a user with a compromised local mirror, just having the new key available to grab from http://ftp-master.debian.org is sufficient. (If it isn't, the user falls into one of the other categories.) For a user with a compromised local network, the only safe solution is to validate the new key via some web of trust. This is the feature that's missing today, to give Joe User some reasonable method of checking keys against the web of trust before importing them. > Perhaps then we need to improve apt-key to implement a more careful > model? Yes, I think so. I'm not sure that apt-key itself is what should be doing the checking, or if we should be giving users some sort of recipe for pre-verifying keys using gpg? $ gpg --recv-keys 2D230C5F && gpg --update-trustdb \ && gpg --batch --edit-key 2D230C5F quit 2>&1 | grep -q 'validity: full' \ && gpg --armor --export 2D230C5F | sudo apt-key add - > If the key is compromised, which is the only way the non-expiring key > method can be broken, then the expiring key doesn't seem to be > offering all that much additional security. Indeed it doesn't. Ideally, if the previous key has been compromised, users would be verifying the integrity of the new key using other signatures; but in the worst case, verifying using the signature from the previous key (if they're disconnected from the web of trust) is no worse than not being able to verify it at all. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. vorlon@debian.org http://www.debian.org/
Attachment:
signature.asc
Description: Digital signature