[145430] in cryptography@c2.net mail archive
Re: A mighty fortress is our PKI, Part II
daemon@ATHENA.MIT.EDU (Jerry Leichter)
Wed Jul 28 08:30:54 2010
From: Jerry Leichter <leichter@lrw.com>
In-Reply-To: <4C4F50E2.4020201@links.org>
Date: Wed, 28 Jul 2010 06:59:46 -0400
Cc: Peter Gutmann <pgut001@cs.auckland.ac.nz>,
cryptography@metzdowd.com
Reply-To: leichter@lrw.com
To: Ben Laurie <ben@links.org>
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?
>=20
> 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" drivers.
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 majordomo@metzdowd.com
