Steven Bellovin <s...@cs.columbia.edu> 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 updates (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. Peter. --------------------------------------------------------------------- The Cryptography Mailing List Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com