[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: APT public key updates?

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

Reply to: