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

comments on Photuris

Here are some comments on the key-management aspects of
Photuris. Phil and I have already discussed, but it's
probably useful to present these comments to the list.

Although it is possible to easily deal with some of the issues
that are raised, section B is probably the greatest concern.

Regards,
Ashar.


----------------------------------------------------------------

Photuris uses the "sign your own exponential only" version of 
authenticated DH exchange. Presumably this was done in order to 
allow the signatures to be precomputed, thereby speeding up the
realtime aspects of the protocol. This message is focused on
the potential vulnerabilities of such a scheme.

These are as follows.

A - Insecure combination of signature and hash algorithm

If the signature scheme is RSA, and the signature hash function is 
the identity function then an intruder can mount an impersonation
attack as follows;

The intruder chooses as her secret DH exponent the value 0, therefore
the intruder's public DH value is g^0 = 1. The exchanged key is
g^(0*y), which is 1, independent of y. 

In order to pass the authentication phase the intruder needs the 
signed value of the sender's public DH exponent, encrypted in
the current session key, call it Ks. We represent this as,

	{Sender_Signed(Sender's DH exponent)}Ks

where Ks is g^xy

If the signing function is the primitive RSA signature (P^d mod n), 
then the intruder can calculate this encrypted signature without 
knowing the impersonated party's secret RSA exponent d as follows;

	{Sender_Signed(Sender's DH exponent)}Ks
	= {Sender_Signed(1)}1
	= {1^d mod n}1
	= {1}1

Since (1^d mod n) is 1 independent of d, then all the intruder
needs to do is compute the encryption of 1 using the key 1
to pass the authentication phase, which she can do.

Note that since the size of the signed quantity is approximately the 
same as the size of an RSA signature block, it's not obvious
that non-identity hashing is required.

Choosing a non-indentity hash function or non RSA signature for 
signing can defeat this attack.

B - Knowing combination of {x, g^x, Signed(g^x)} allows impersonation

This illustrates a general weakness of the "sign only your own
exponential" approach. If the intruder can compute (or obtain)
a valid signature of a quantity whose discrete log it can compute
(or obtain) in advance, then she can mount an impersonation 
attack.

A seemingly inocuous way of doing this might be: Intruder asks
the party she wants to impersonate to sign the value g (the generator
of GF(p)) so that she can be sure of what the generator is.

This might seem harmless enough that a party may actually sign
g. However, by obtaining signed g the intruder has now obtained the
following tuple {1, g^1, Signed(g^1)}. The intruder can now
impersonate the party who signed g by choosing 1 as her 
secret exponent when participating in a key-exchange.

There may also be other (harder to detect) ways of obtaining 
signatures in advance over quantities whose discrete logs are known.

Once a signature is obtained, it can used and reused (forever) to 
impersonate the party whose signature was obtained.

This attack is independent of the signature algorithm used.
Also, this does not require obtaining a signature on some
unpredictable quantity in real time, which is much harder. 
This can all be done in advance.

C - Known key attacks

Should a party ever learn the other side's secret DH exponent
after a successful key exchange, she can then impersonate that party
because she now knows {x, g^x, Signed(g^x)}. 

It's not immediately obvious that one should never reveal the
secret DH exponent in an exchange even to an authorized party,
because it may appear that all the secret exponent allows one to
do is compute g^xy which the connecting party already knows. 

However, in this case, knowing x and the other information one 
learns in a succesful run of the protocol allows an intruder to 
later impersonate who she connected to.

The above vulnerability is described in "Authentication and
Authenticated Key Exchanges", by Diffie, Van Oorschot and Wiener,
in "Designs, Codes and Cryptography", 1992, Kluwer Academic Publishers.

The STS protocol described in this paper shows how to remove this 
vulnerability by including in the signature the other party's public 
DH value, which makes all these attacks infeasible. This is because
now an adversary has to produce in realtime a signature over an 
unpredictable quantity (because the other party's public DH value is 
unpredictable).

Unfortunately, this modification to the protocol also makes signature 
precomputation infeasible.

D - Requirement for Authentication-Only version of protocol

If one is not performing encryption, but instead is doing authentication
only, then it is a requirement to check the authenticity of the IP
packet that contains the signed DH public value. Checking the signature
of the signed DH value alone is not enough, as both the public DH value 
and its signed version may be played back from an earlier run with
the real party.

Assuming that the intruder did not learn the other side's secret
exponent in the earlier run would mean that the intruder cannot actually 
compute the session key, and therefore would not be able to authenticate 
the IP packets, even though she can provide a properly signed public DH 
value.

Failing to check the authenticity of the packet would mean that
the authentication phase would pass with the intruder. (Although the 
intruder would not be able to produce authenticated IP packets).