[Cryptography] HP accidentally signs malware, will revoke certificate

Jerry Leichter leichter at lrw.com
Sat Oct 11 15:57:54 EDT 2014

On Oct 11, 2014, at 11:18 AM, ianG <iang at iang.org> wrote:
> That's um amazing.  So a 4 year old expired cert is still a critical
> piece of infrastructure, and they are still going to revoke it.  Rather
> finishes the argument of whether revocation means anything different
> than expiry...  More on Krebs.
> http://krebsonsecurity.com/2014/10/signed-malware-is-expensive-oops-for-hp/
> Revocation as a system only works if it is reasonable to roll out a new
> cert, and this works as long as the scale is small.  It looks like
> code-signing can escape that assumption, making one userland cert as
> powerful as .. a root cert!
Yes ... but.  Part of the problem here is that revocation was never meant, and is clearly inappropriate for, this application.  If I sign a software update using an "unleaked" key, that signature, on that update, is logically valid forever.  The fact that the key is later revoked changes nothing.  And, in fact, *allowing* to change "past facts" produces high costs.  Patches - or, really, distributions of software - can have an extremely long lifetime.  Going back and re-creating them with a new key is a big undertaking.  Worse, *the big advantage of a signature is that it eliminates dependence on the distribution channel*.  If things work as they are supposed to, I can safely download a properly signed copy of an updated from Malware-R-US and be quite sure that the bits I got really came from the signer.

But lets consider the failure modes.  Suppose a signing key is leaked.  You obviously can no longer trust anything created after the leak - but stuff signed *before* the leak is still fine.  But you need to determine *when* the signature was done - which brings us back to the recent thread on secure timestamps.  If (a) a software distribution is signed; (b) that same software distribution is time-stamped as "created before time T" in a way that can be checked independently of the signature (i.e., the fact that it says "Made in 2005" inside the signed envelope means nothing); (c) a revocation indicates the last known "secure" date; then you get the most usable possible system:  Artifacts signed before the key was leaked are still verifiably safe; artifacts signed after the key was leaked will be rejected.  (You can argue about how someone can definitely give a "good up to" date, but then any use of an unrevoked key is implicitly an assertion that it hasn't yet leaked....)

In HP's case, we have a completely different issue:  The key, according to HP, was never leaked.  (Their assertion that they were never hacked *is* meaningful, because this is what it's asserting.)  So in fact *all signatures with that key are valid, and will remain invalid indefinitely*.  The problem isn't with the signing; it's with *one particular piece of software that was signed*.  Revocation is *not* the "right" solution here, as there's nothing at all wrong with the key or any signatures.  The *right* solution is something like what Microsoft does to blacklist particular pieces of software.  If HP had something like this, they could blacklist the malware without changing any keys or re-issuing any patches.

The problem of the validity of signed material has been discussed for years, and my comment about the need for timestamping is not new.  (It probably appeared in the papers discussing uses for digital timestamps!)  The only attack against a signing system I've ever seen mentioned is signing key leakage, and as a result, the only solution on offer is revocation.  What we have here is an entirely different attack, which directly contradicts the usual assumptions about signing:  Yes, my signing provides a perfectly correct proof of provenance; but "what I said wasn't want I meant".  In the typical toy examples of digital signatures that get discussed, what's signed is always an assertion or a commitment, and the whole point is to bind it to the signer forever.  Here we're signing something that, if interpreted as an assertion or commitment, loses its whole point:  It's something that actually affects the real world, and it's potentially harmful.  A different attack requiring a different defense.

                                                        -- Jerry

More information about the cryptography mailing list