Re: Re: Best practices for signature verifcation

[Peter Gutmann <pgut001 () cs auckland ac nz>]

Demi Marie Obenour writes:

> To answer your last question: I believe that it is sufficient for the TSA to
> sign the public key, hash algorithm, and signature algorithm used to make the
> signature, as well as the signature itself.

That's more or less what a TSA does anyway, but it doesn't address any of the
other issues.  I think the required approach would be to start with a threat
model and work from there, not with a given technology and say "the threat is
whatever this tech counters" (which is admittedly the standard "threat model"
used in 99% of all crypto designs).

So you'd have:

Signed malware

An attacker can use a compromised key to sign malware.  To deal with this ...

Rollback attacks

Once a binary is signed, it's universally trusted.  An attacker can feed in an
older signed binary (with an vulnerability) in place of a newer one that has
the vulnerability fixed.  To deal with this ...

> I'm fine with CMS *if* there is an implementation that is permissively
> licensed and *obviously* correct.  I don't want a CMS equivalent of <https://
> gpg.fail>.  I don't think this is possible, though, because CMS is such a
> complex standard.

Of all the protocols I've implemented, I'd put my CMS implementation as having
the least likelihood of being compromised because the TLV encoding means it
can be statically checked before you ever process or act on it.  And before
anyone asks, the one I have the least confidence in is SSH because of its wild
mix of binary data and comma-delimited text strings, and the incredibly
complex exchange and potentially protracted ongoing negotiations it carries
out in the handshake phase, there's huge scope there for state confusion
attacks.

Peter.