[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Photuris.01: signature message
I plan to send several notes commenting on Photuris draft version 01
(draft-karn-photuris-01.txt). Some of the comments were already discussed
with Phil and we reached agreement on part of them. There are many other
comments that we did not have time to discuss. In any case, I believe the
issues need to be presented to the whole WG.
This first note concentrates on the signature message (page 23 of the
draft), whose description seems to me open to different interpretations,
and basically all these interpretations are susceptible to security
vulnerabilities of some kind.
There are several general points that I want to make based on the comments
in this note. I put them here just for the exhausted reader that will
never get to the end.
(1) Design of cryptographic protocols is a very tricky thing. (I know this is
a well-known fact; however, I argue, we tend to underestimate the
meaning of this fact.)
(2) It is very easy to loose the security of a well studied protocol
with seemingly "minor changes". In particular, the security of such
protocols lives or dies by the "minor details".
(3) It is a must to have all these protocols scrutinized as much as possible
by cryptographers and security experts before adoption.
(4) Wherever the protocol allows for generic transforms (which is highly
desirable for generality/upgradability/compatibility/anyotherity)
the security must be analyzed relative to the generic properties of these
transforms and not based on additional properties of particular transforms.
[It is very easy to make the mistake of specifying a generic transform
while, in fact, one has in mind a very particular one: that's dangerous!]
(5) Eventually, the drafts describing the key management mechanisms should
be accompanied by text (or separate drafts) explaining the rationale
behind these mechanisms, and clear implementation notes on the essentiality
of some "details".
After the long comments on what is wrong about the current specifications I
also point out to some possible corrections.
Now to the comments.
Terminology: I use g^x to denote I's Public-Value, and g^y for R's
Public-Value (I and R stand for Initiator and Responder, respectively).
The draft specifies (pages 23/24) that:
1) the signature is computed over the DH key SK (derived from g^xy),
g^x and g^y.
2) *optionally*, the local party's identity can also be signed
3) "the SIGNATURE_MESSAGE ... is required to be authenticated or encrypted"
Although, the draft does not explain the design choices, I believe that
the signing of SK as well as (2) and (3) above are specified to defeat
a special kind of attacks described in:
[STS] Whitfield Diffie, Paul C van Oorshot, Michael J Wiener,
"Authentication and Authenticated Key Exchanges", Designs,
Codes and Cryptography, v 2 pp 107-125, Kluwer Academic
Publishers, 1992.
(this is the paper on which Photuris design is based and I join Phil in
recommending its reading to anybody interested in design of key management
protocols).
This attack consists of the adversary, E, intercepting and
changing messages between I and R such that, after the run of the protocol,
I believes he exchanged a key SK with R, but R believes he exchanged
the same SK with E. Although E does not know SK, it is shown in
[STS] how such an attack can be very harmful to I (and good for E).
Roughly, any piece of information authenticated by I using that
shared key SK is understood by R as authenticated by E. The example
given in the paper consists of R being a bank, and deposits done by I
being credited to E.
Since the issues dealt with in this note are quite involved and there
are several options supported by the draft's protocol, I will start,
for simplicity, with a specific case.
Namely, showing that if one does not include the identity of the
local party in the signed information, and does not encrypt or authenticate
the signature, then the protocol is vulnerable to the above attack.
(Later, I discuss the addition of either encryption or authentication).
For concreteness, let's assume that the signature in use (S-transform)
consists of RSA to sign, and MD5 to hash the information before applying RSA.
The attacker E will intercept I's signature RSA_I(MD5(SK,g^y,g^x)),
will compute from it MD5(SK,g^y,g^x) using the
inverse (verification) function of RSA, and will sign that same string using
her own private key, namely, RSA_E(MD5(SK,g^y,g^x)).
Notice that for this process E does not need to know SK!
If I (the Initiator, not Hugo) would have included the identity inside
the MD5 calculation this (straightforward) attack does not work. (Since
E does not know how to replace this identity by her own inside the MD5).
Notice that at a first glance putting the identity inside the signature
solves the problem, but this is not accurate in general.
Indeed, assume the following.
Before signing apply MD5 to the long information: namely MD5(SK,g^x,g^y).
Concatenate this result to the identity, and then sign (i.e., apply RSA to)
the concatenated information (I am assuming an identifier of no more
than, say, 896=1024-128 bits). In this case the above vulnerability stays,
even if in a strict sense one has signed the identity.
What helps solving the problem is not just signing the identity but
putting the identity inside the MD5 calculation. But who said this is enough?
Moreover, Photuris does not require any specific signature transform,
therefore the security needs to be analyzed on the basis of a generic
transform and not on particular choices (e.g. RSA+MD5). If a generic
transform is not enough to achieve a given requirement, then the necessary
complementary mechanisms must be explicitely required in the draft
specification.