-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On Tue, Oct 28, 2003 at 08:18:50PM -0800, Trevor Perrin wrote:
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?
You mean take the victim's primary signing key, transform it into a
signing subkey and bind it to the attacker's primary key? Yes, the
attack would still work, but either of the proposed fixes still
prevents it.
The back-signature fix prevents this flavor of the attack since the
attacker still could not use the stolen key (be it primary or subkey),
to issue the back-signature.
The include-the-fingerprint fix prevents this flavor of the attack as
well. Since the key is a primary, existing signatures from the key
would not contain the fingerprint subpacket at all, and would
therefore be suspect.
There are four basic permutations of this attack:
1) Attacker steals a subkey and keeps it as a subkey. Either fix
works here.
2) Attacker steals a primary and makes it into a subkey. Either fix
works here.
3) Attacker steals a subkey and makes it into a primary. Neither fix
is relevant here since the attacker would be unable to bind a user
ID to such a primary key. Without a bound user ID, it would be
difficult at best to get such a key trusted.
4) Attacker steals a primary and keeps it as a primary. Neither fix
is relevant here either, for the same reason as #3.
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.
I don't see this as a problem, actually. So what if a user uses the
same subkey under two different primaries? The user controls the
subkey, and so can issue valid back-signatures (or fingerprint
subpackets). The owner of a subkey can do what they like with it.
- 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.
Hmm. I think I see where you are going with this, but isn't this sort
of the same problem as the "stolen primary that is kept as a primary"
above? I can steal a primary key and add a user ID and bribe someone
to sign it (since I can't sign it myself of course). Just because
I've constructed a key that can verify a signature doesn't mean that I
issued that signature. Or forget computer trickery at all: I can just
get myself a fake ID that says I am "Trevor Perrin" ;)
- 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.
This would break all signatures on the key, including the
self-signatures. I think that would give the attack away.
David
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.3.4-cvs (GNU/Linux)
Comment: Key available at http://www.jabberwocky.com/david/keys.asc
iHEEARECADEFAj+fVwkqGGh0dHA6Ly93d3cuamFiYmVyd29ja3kuY29tL2Rhdmlk
L2tleXMuYXNjAAoJEOJmXIdJ4cvJ0ioAni/Lsc020UT+NVctLArQCiOILEASAJwP
Zag9klK/40ZIkJIpquahISa9Aw==
=5Xdy
-----END PGP SIGNATURE-----