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