Re: Back-signatures, part II

At 03:13 PM 10/29/2003 -0500, David Shaw wrote:

> On Tue, Oct 28, 2003 at 10:59:31PM -0800, Trevor Perrin wrote:
>
> > >>  - 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.
> >
> > The problem arises when the user signs a document with the subkey, and
> > wants this signature to be under one of his particular primaries.  Say he
> > has Work and Personal primary keys.  He signs something and wants to
> > indicate that it's under his Work primary key.
>
> A user can "legally" use the same subkey under two different
> primaries.
yeah, but if he does this, a verifier might assume that the signature was 
intended under one primary key, when it was really intended under another.

>   I think this is more of a feature request than an attack.
It's only an attack if a bad guy can choose which primary key the signature 
appears to be under, in a way that tricks the verifier into treating the 
signature incorrectly.
I believe signing subkeys are rare, re-use of signing subkeys is rarer, and 
re-using them in such a way that an attacker
can do this trick, and accomplish something, is pretty unlikely.

I'm just trying to point out ways in which signatures can be placed in 
different contexts than what the signer intended.  I view that as the 
commonality that links these things together - if every signature had a 
subpacket that contained a hash of:
 - the key used to perform the signature
 - the primary key (if the signing key is a subkey)
 - any self-signatures on the primary key, and the binding signature on 
the subkey,
then I'd feel re-assured that every signature was bound to all relevant 
context, and no manipulations such as
 - splicing someone else's key under your primary key, to claim their 
signatures
 - fiddling with which primary key a signature appears to be under
 - presenting a different key that happens to verify a signature
would be possible.

The one manipulation that *would* still be possible is presenting someone 
else's key under your primary key, when there's no signature by the 
victimized key present to give the lie to this.  For that, some sort of 
additional back-signature is unavoidable.
But these approaches could be combined - if the back-signature contains the 
sort of subpacket I'm talking about, that's enough to make it a back-signature.
So I guess I'm saying *every* signature should be a back-signature, in that 
it covers the relevant primary key and sub-keys.  But you could also add an 
extra back-signature just when sub-keys are present.



> The include-the-primary-fingerprint fix for the original attack has a
> side effect that gives the information you want here, but I still
> don't think this is an attack on the system.
>
> > I.e.: a user who receives a signed message through some secure channel 
> (say
> > someone hands them a message on a floppy disk), might then retrieve a key
> > through an *un*secure channel, and attempt to validate the key by 
> verifying
> > the message with it.
> >
> > You can say: the user screwed up, we can't help him.  But if the signature
> > covered the public key that produced it, then the user's naive assumption
> > would be correct, and his behavior would be safe.
> >
> > The issuer key ID subpacket makes an attack hard, though, because the
> > attacker would have to try ~ 2^64 trial keys that verify the signature,
> > before discovering one that *also* has the right issuer key ID.  But if 
> the
> > signature covered the public key with a full hash, an attack would be even
> > harder.
>
> Note that most implementations do not store the issuer key ID in the
> hashed portion of the signature.  The issuer ID is thus not part of
> the signature.
In the odd case I'm considering, the verifier gets the signed message 
through some secure channel - someone hands him a signed message on a 
floppy disk, for example.  So even though the issuer key ID isn't part of 
the signature, an attacker who's trying to make a fake key that verifies 
the message, still has to match the issuer key ID.
So that provides some measure of protection, but if the signing key was 
hashed as an input to the signature, that would provide even more.
Trevor