Steven Bellovin <> writes:

>For the last issue, I'd note that using pki instead of PKI (i.e., many 
>different per-realm roots, authorization certificates rather than identity 
>certificates, etc.) doesn't help: Realtek et al. still have no better way or 
>better incentive to revoke their own widely-used keys.

I think the problems go a bit further than just Realtek's motivation, if you 
look at the way it's supposed to work in all the PKI textbooks it's:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Realtek requests that the issuing CA revoke the cert.
  Shortly after t': CA revokes the cert.
  Shortly after t'': Signature is no longer regarded as valid.

What actually happened was:

  Time t: Malware appears signed with a stolen key.
  Shortly after t: Widespread (well, relatively) news coverage of the issue.

  Time t + 2-3 days: The issuing CA reads about the cert problem in the news.
  Time t + 4-5 days: The certificate is revoked by the CA.
  Time t + 2 weeks and counting: The certificate is regarded as still valid by
    the sig-checking software.

That's pretty much what you'd expect if you're familiar with the realities of 
PKI, but definitely not PKI's finest hour.  In addition you have:

  Time t - lots: Stuxnet malware appears (i.e. is noticed by people other than
    the victims)
  Shortly after t - lots: AV vendors add it to their AV databases and push out

(I don't know what "lots" is here, it seems to be anything from weeks to
months depending on which news reports you go with).

So if I'm looking for a defence against signed malware, it's not going to be 
PKI.  That was the point of my previous exchange with Ben, assume that PKI 
doesn't work and you won't be disappointed, and more importantly, you now have 
the freedom to design around it to try and find mechanisms that do work.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to