oss-sec mailing list archives
Re: Re: Best practices for signature verifcation
From: Jacob Bachmeyer <jcb62281 () gmail com>
Date: Fri, 16 Jan 2026 19:44:28 -0600
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
Current thread:
- Re: Best practices for signature verifcation Simon Josefsson (Jan 01)
- Re: Re: Best practices for signature verifcation Peter Gutmann (Jan 02)
- Re: Re: Best practices for signature verifcation Demi Marie Obenour (Jan 03)
- Re: Re: Best practices for signature verifcation Peter Gutmann (Jan 05)
- Re: Re: Best practices for signature verifcation Valtteri Vuorikoski (Jan 05)
- Re: Re: Best practices for signature verifcation Jeffrey Walton (Jan 05)
- Re: Re: Best practices for signature verifcation Morten Linderud (Jan 05)
- Re: Re: Best practices for signature verifcation Peter Gutmann (Jan 05)
- Re: Re: Best practices for signature verifcation Demi Marie Obenour (Jan 03)
- Re: Re: Best practices for signature verifcation Demi Marie Obenour (Jan 05)
- Re: Re: Best practices for signature verifcation Peter Gutmann (Jan 15)
- Re: Re: Best practices for signature verifcation Jacob Bachmeyer (Jan 16)
- Re: Re: Best practices for signature verifcation Peter Gutmann (Jan 02)
- Re: Re: Best practices for signature verifcation Taavi Eomäe (Jan 06)
- <Possible follow-ups>
- Re: Re: Best practices for signature verifcation Ali Polatel (Jan 01)
- Re: Best practices for signature verifcation Clemens Lang (Jan 01)
- Re: Best practices for signature verifcation Soatok Dreamseeker (Jan 02)
- Re: Best practices for signature verifcation Demi Marie Obenour (Jan 03)
- Re: Best practices for signature verifcation Clemens Lang (Jan 05)
- Re: Best practices for signature verifcation Demi Marie Obenour (Jan 05)
