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

comments on Photuris

Ref:  Your note of Tue, 07 Feb 1995 13:40:16 -0500 (attached)

Perry, Phil, Ashar and others:

I completely support the concerns expressed by Ashar about the
potential vulnerabilities of "replayable signatures" as appear in the current
Photuris draft. I hope Phil agrees with this and will reflect it in the next
version.  Indeed, freshness of authentication is a basic principle for
sound cryptographic protocols and its absence a great invitation to trouble.

Beyond the scenarios presented by Ashar, Photuris itself
indirectly presents a similar concern when saying that:

      A background process can periodically destroy the old values,
      generate a new random secret, and recalculate the public DH part
      and the RSA signature.  This limits the exposure of the secret, as
      past secrets are not kept for possible discovery by a future
      intrusion, protecting earlier communications.  Also, the secret
      currently in use is less likely to be anticipated, as the element
      of random timing is introduced.

Phil here is concerned about secrecy and then is careful enough to destroy
values that live for too long by fear of intrusion.
However, for replaying a signature the intruder does not care if the
triple (x,g^x,sig(g^x)) is used or not by the legal guy. Once she found
these values the adversary can use them as much as she wants to impersonate
the attacked party.  (Even if the private key is perfectly protected!).

As for Perry's comment:
 >
 > I think I've solved this problem. Here is my strawman:
 >
 > In Phil's algorithm, instead of signing the D-H components g^x'es
 > directly, all that is needed is to sign a hash of the g^x concatenated
 > with the "name" (to be defined in a moment) of the entity that I
 > intend to authenticate with.
 >
 > The "name" should be a unique identifier of the party I anticipate
 > communicating with. By hashing the two together, I prevent the replay
 > of the signed g^x with another counterparty -- at most I can
 > impersonate the signer in communicating with myself, which is useless.
 >
 > Perry

This is a step in the right direction. Now the exposure of this signature
will only allow the intruder to impersonate that particular party whose name
appears in the signature. But not a good enough solution.

The right way to guarantee freshness is by nonces (challenge/response).
In the case of Photuris the challenges could be exchanged with the cookies.
Unfortunately, this prevents pre-computation. Nonetheless, notice that
when you communicate to somebody with whom you already have communicated
before and can keep a state for this party, then the nonces can be exchanged
at the end of the previous key exchange round. This is especially suitable
when the parties periodically exchange a new key. This approach is used in
MKMP and very applicable here. In this way the parties have the time between
two exchanges to prepare their exponentiations and signatures.

BTW, the solution suggested by Perry has another problem. You shouldn't be
signing the identity of the party you talk to. This could be used later
to *prove* that you talked to that party. This unintentonal (or enforced)
use of non-repudiation is a severe privacy concern (in some cases even more
significant that anonymity protection a la Photuris).

The last remark needs to be considered in Photuris and any other design that
uses (non-repudable) signatures.

Hugo