[cryptography] How are expired code-signing certs revoked?

ianG iang at iang.org
Wed Dec 7 07:32:32 EST 2011


On 7/12/11 23:01 PM, Peter Gutmann wrote:
> Consider the following scenario:
>
> 1. Attackers steal a code-signing key and use it to sign malware.
> 2. The certificate for the stolen key expires.
> 3. Malware signed with the key turns up.
>
> Since the signature is timestamped to allow it to still validate after the
> original cert expires, it'll be regarded as valid.  Since the cert has now
> expired, it won't be present in the CRL, or if it was present it'll be removed
> (this is standard practice to manage CRL sizes).
>
> How do you invalidate such a signature?
>

This is what might be called the fallacy of digital signatures.  In 
brief, it runs like this:  because signatures are something that are 
expected to have long lasting validity, it is required that any 
signature also be time-stamped reliably.  Which means, externally to the 
interested parties, c.f. legal convention.

However, if one is relying on an external TTP to time-stamp the digital 
signature, one can also rely on the TTP to evidence the hash of the 
document.  In which case, the digital signature is not performing any 
signing task (although it may form a local authentication role, or may 
not, as the case may be).  In this case the act of presenting the hash 
for external time-stamp is the act of signing, not the act of affixing a 
digital signature.

Therefore, so-called digital signatures aren't.  QED.

(That's all before you get to the tactical question of what a revocation 
over a key that produces so-called digital signatures actually means in 
semantic or legal terms.  It's turtles all the way down.)



iang



More information about the cryptography mailing list