Best practice for periodic key change?
Doug Barton
dougb at dougbarton.us
Fri May 6 09:47:57 CEST 2011
On 05/05/2011 23:22, Andreas Heinlein wrote:
> Like Werner said, many people never refresh their keys, so
> expiring is indeed a way to force them to do that. ( I admit that, in
> our case, even this will not help, since gpg will happily verify a
> signature made by an expired key. It will tell you that it's expired,
> but verify anyway. The 'hard' way would be to just refuse to do anything
> with an expired key or even delete it automatically, but that's another
> discussion).
Obviously you've thought through one side of the problem of key
compromise (which I've snipped), but I'm not sure you've thought through
the ramifications of what's going to happen after the bad guys get your
key.
You create a key with an expiration date.
You sign stuff with it.
Users download your stuff, the signature, and your key, and verify the
signature on your stuff. All good.
Now the bad guys get your key (oops!).
They sign malicious versions of your code, and upload it.
Users who still have your (now compromised) key will still be able to
verify the signatures (as you pointed out). The tiny percentage of users
who periodically refresh their keys, and care that the key has expired,
_may_ notice something is wrong, probably not.
Even if the user doesn't already have the key, most keyservers don't
hesitate to serve up keys that are expired, or even revoked.
There's also another element, the expiration date is irrelevant if the
key is actually compromised. If Eve has your secret key she can simply
update or remove the expiration date, and upload the new version of the
public key to the public keyservers. So, I remain confused as to what
purpose expiration dates on the keys will serve.
One could make an argument for creating new keys (or subkeys) on an
annual basis with a comment to the effect of "This key is only valid for
signatures created during calendar year 2011." However, asking users to
parse that is likely to be more than they are able or willing to do. And
even that can be trivially compromised if Eve changes the clock on her
computer before generating the signature.
In short, rotating keys, with or without an expiration date _may_ add
single-digit percentage points of security to your intended use, but
you'd be far better off with a good management policy for your secret
key (you've been given some good suggestions already) to reduce as much
as possible the potential for having it compromised.
Good luck,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
More information about the Gnupg-users
mailing list