Re: Back-signatures, part II

At 05:23 PM 10/28/2003 -0500, David Shaw wrote:


> I just checked over my notes about back-signatures, and there was a
> second proposal to solve the same problem.  For completeness, here is
> the other proposal.
>
> To repeat the problem: it is possible for an attacker to take a
> signing subkey from a victim's key and attach this signing subkey to
> the attacker's own key.  The attacker does this by issuing a new
> binding signature on the subkey from his own primary key.  The end
> result is that a signature issued by this signing subkey may be
> claimed to be from either the attacker or the victim.
Does this attack also work if the attacker issues a subkey binding 
signature on the victim's *primary* key, so as to claim signatures issued 
by this primary key?


> Second proposed solution: on all signatures issued by a signing
> subkey, include a copy of the fingerprint of the primary key that
> "owns" this subkey.  An attacker cannot issue signatures from the
> stolen subkey at all, so is foiled.
I don't want to re-confuse an issue you've just clarified, but here's a 
generalization of the second proposal that might be worth considering:
You could include in *every* signature a subpacket that contains a hash of 
*all* enclosing context.  By "enclosing context" I mean the key packet for 
the primary key, along with its self-signatures, and the key packet for the 
subkey as well (if the signing key is a subkey) along with the subkey 
binding signature.
This would protect against the above attack, and some other manipulations, 
such as:
 - A naive user re-uses the same subkey under 2 different primary 
keys.  Signatures performed by the subkey can't be confined to being under 
one or the other primary key.  This problem can be easily avoided: just 
don't re-use keys, but that caveat would be unnecessary if signatures 
committed to their enclosing context.
 - Attacker generates a key that verifies a signature issued by someone 
else [1], then puts this key on a key server where a victim finds it, and 
assumes that since it verifies the signature correctly, it must belong to 
the originator of the message.  There's caveats that make this attack hard, 
and not very useful [1].  Still, it could be avoided entirely if the key 
used to create a signature was hashed as input to the signature.
 - Attacker fiddles the timestamp in someone's primary-key packet, so that 
the key still verifies the signature correctly, but the sender appears to 
have a different fingerprint than he really does.

These aren't a big deal, but it just seems a good principle, in general, 
for signatures to cover as much context as is needed to properly interpret 
them.
Trevor


[1] sci.crypt thread: Choosing key to verify someone else's sig?