[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: comments on Photuris

	Consider the case whereby, e.g., through OS deficiencies one 
	can steal a signature on a quantity from a smart card or token
	device, even though there is no possibility of stealing the
	private key from the device. With Photuris, stealing a single 
	signature on a quantity whose discrete log is known is equivalent 
	to stealing the long term private key (in the sense that it allows
	unlimited impersonation thereafter). This is the real problem.

What do you mean by "steal a signature"? Trick the device to sign an
arbitrary value of your own choosing, such as the hash on a g^x
for which you know x?

If this is the case, then of *course* you can impersonate the user.
This just underscores the importance of being careful about what you
sign. The problem is really one of engineering, not protocol design.

But I see an addition to the protocol to at least limit the damage if
this were to happen. Simply append an expiration time to the
precomputed DH public part before you sign it.

Choosing an expiration time is easy - just set it to when you plan to
precompute a new x,g^x pair. Note that this doesn't really require
everyone to have synchronized clocks. You're free to ignore expiration
times at your own risk.

	Then there is also the scenario that Hugo mentioned about
	the intruder simply stealing the fatal triple {x,g^x,Sig(g^x)}
	from the precompute table. This is also fatal, even if the
	triple was never used and the private key is perfectly protected.

This is just a superset of the previous attack. It's not really fair
to posit that x is compromised since DH has always assumed it to be
secret. But the timestamp feature could again limit the duration of
the breach if it were to occur.

I would suspect that in many practical implementations, any particular
x is better protected than the secret key used to sign g^x for the
simple reason that x is ephemeral and never leaves the system where it
is automatically generated.  On the other hand, the signature key is a
long-lived item that will probably be generated offline and backed up
in places beyond the control of the IPSP implementation.

Now I have been assuming that the entire IPSP is software running on
general purpose computers, i.e., there is no special tamper resistant
hardware for the signing operation.  If you do assume such hardware,
especially if the rest of the protocol remains on hackable general
purpose computers, then your point starts to carry some real weight.

Phil
References: