On Jul 27, 2010, at 5:34 PM, Ben Laurie wrote:

> 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.
There is, of course, the problem of knowing when a signature was stolen!  You 
can know that it was definitely stolen *by* a particular date, but never that 
it wasn't stolen earlier.  Given that it was stolen, what evidence could you 
produce that it wasn't stolen - and simply kept around for later use - at the 
moment it was created?

Beyond that, you it's often hard to know when you received a file.  Perhaps the 
actual attack was to stick it on your system and backdate it!  A forensic 
examination could look at backups, but we're talking about how to decide 
whether to accept a signature in an operational setting.  You can't, of course, 
rely on any dates within the file itself, as they are protected from fakery 
only by the signature that you can't trust.  You could rely on a digital 
time-stamping service ... but that just brings into sharper focus the absurdity 
that actually began the moment you needed to check an on-line CRL.  The only 
conceivable purpose for using a signature is that you can check it *offline*.  
If you assume you can connect to the network, and that you can trust what you 
get from the network - why bother with a signature?  Simply check a 
cryptographic hash of the driver against an on-line database of "known good" 

This is right in line with Lynn Wheeler's frequent mention here that the use 
case for offline verification of certs for commerce basically doesn't exist.  
It was a nice theory to develop 30 years ago, but today the rest of the 
framework assumes connectivity, and you buy nothing but additional problems by 
focusing on making just one piece work off-line.

                                                        -- Jerry

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to