On 1/15/26 21:50, Peter Gutmann wrote:
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:
(simple solutions proposed)
Signed malware
An attacker can use a compromised key to sign malware. To deal with this ...
... revocations include a timestamp of the last-known-before-compromise
signature. If legitimate releases were made after the key was
compromised, they MUST be re-signed using the new key.
The timestamp attestation is simply a certification that the artifact
was presented to the timestamping authority at that time. If the signed
timestamp is prior to the first-compromise timestamp in the revocation
certificate, the signature can still be considered valid (although the
user SHOULD be informed that the signature is from a key that was later
found to have been compromised and has therefore been revoked). If the
signed timestamp is *after* the known first-compromise, the signature is
from a revoked compromised key and invalid.
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 ...
... the user is expected to catch the attempted substitution and
packaging tools MUST warn the user before installing an older version
over a newer version. (The version numbers themselves are part of the
signed information, so the attacker cannot alter them.)
-- Jacob
