[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
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
This would protect against the above attack, and some other manipulations,
- 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 , 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 . 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
 sci.crypt thread: Choosing key to verify someone else's sig?