A mighty fortress is our PKI, Part II

[Peter Gutmann]

Ben Laurie <ben at links.org> writes:
>On 24/07/2010 18:55, Peter Gutmann wrote:
>> - PKI dogma doesn't even consider availability issues but expects the
>>   straightforward execution of the condition "problem -> revoke cert".  For a
>>   situation like this, particularly if the cert was used to sign 64-bit
>>   drivers, I wouldn't have revoked because the global damage caused by that is
>>   potentially much larger than the relatively small-scale damage caused by the
>>   malware.  So alongside "too big to fail" we now have "too widely-used to
>>   revoke".  Is anyone running x64 Windows with revocation checking enabled and
>>   drivers signed by the Realtek or JMicron certs?
>
>One way to mitigate this would be to revoke a cert on a date, and only reject 
>signatures on files you received after that date.

This wouldn't make any difference, except for the special case of x64, 
signatures are only verified on install, so existing installed code isn't 
affected and anything new that's being installed is, with either form of 
sig-checking.

In any case though the whole thing is really a moot point given the sucking 
void that is revocation-handling, the Realtek certificate was revoked on the 
16th but one of my spies has informed me that as of yesterday it was still 
regarded as valid by Windows.  Previous experience with revoked certs has been 
that they remain valid more or less indefinitely (which would be really great 
if CAs offered something like domain-tasting for certs, you could get as many 
free certs as you wanted).

The way to revoke a cert for signed malware is to wait 0-12 hours for the 
malware signature to be added to AV databases, not to actually expect PKI to 
work.

Peter.

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com