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

Security problems in Photuris #2



     Summary of this message: I claim that the security of Photuris
     needs to be guaranteed not only based on its default transforms,
     but for any replacement of these transforms by other secure algorithms.
     The current definition of Photuris does not satisfy this criterion.
     As an example, use of plain RSA signature as the signature attribute
     in the protocol discloses the exchanged DH key. [Whoever consider this
     not to be a serious and practical security bug, please let us know.]

Protocol security and Algorithm independence
********************************************

Photuris is intended to be algorithm independent.
To me this means that the protocol with the defined default algorithms is
secure, but also that substituting any default algorithm by another that
has the same required security functionality, e.g., encryption, signature,
would result in a secure implementation of the protocol.

For example, any specifications-conformant implementation of Photuris that
uses a sound digital signature algorithm as its "signature attribute"
(as well as other secure algorithms for the other attributes) must result in
a secure key-exchange protocol. If the use of a particular, secure (i.e.,
computationally unforgeable) signature method results in an insecure
implementation of Photuris then the protocol, as defined, is *insecure*.

In such a case we can either
* change the protocol, or
* explicitly specify the extra requirements from the function (e.g.,
  "a signature-attribute is a signature function that is infeasible to forge
   *and also* protects the secrecy of the signed information.")

The first option is generally preferable if it does not add unnecessary
complexity to the protocol (the second option increases the chances of a
mistaken implementation, and reduces the number of useful algorithms).

Some of my claims about Photuris insecurity fall under the above understanding
of algorithm independence.
Namely, I show that for particular choices of signature or encryption
algorithms the resultant Photuris realization is insecure.
The algorithms used in my examples are well-known and secure, still their
use makes Photuris insecure.
This does not contradict in any way that there exist certain signature
and encryption algorithms for which Photuris is secure.
It is not enough that *there exist* secure conformant implementations of
Photuris, it must be that *all* conformant implementations are secure.

In addition, I warn about accepting the security of a protocol only based on
the fact that all the *known* examples of algorithms that realize a given
attribute happen to have some extra feature. For example, cryptographic hash
functions are designed with the goal of being "collision-resistant", ie. to
guarantee infeasibility of finding collisions. If we need the algorithm to
provide some extra feature, e.g., that the output of the function
does not leak any information on its input, or that the output is
unpredictable (or pseudorandom), then these properties need to
be explicitely specified.

The following  is an example of a security failure in Photuris, related to
the above algorithm-independence issue.

Problems with the signature message
***********************************

Section 5.3 specifies the information on which the signature is verified
(which in turn defines the information on which the signature is computed)

> 5.3.  Verification
>
>    The two parties now verify the signatures received.  The indicated
>    Signature-Choice is calculated over the following concatenated
>    values:
>
>    +  the computed shared-secret,
     +  [other fields]

Clearly, any signature-choice that has the property of *not hiding* the
contents of the signed information will leak information on the
shared-secret (ie., the DH key). And there is *no requirement*
(in the Photuris document, or elsewhere in the literature) that
a signature scheme should hide the information contents. Moreover,
we also have a handy example of such a signature: plain RSA (without hashing).
If you see an RSA signature computed directly on a piece of data D
then the public verification process of that signatures consists of
*recovering D*. In this case, the whole shared-secret has leaked!
(Notice that if one uses a 1024 RSA modulus and works for the DH exchange
over a 155-bit fields then the whole signed information fits in 1024 bits,
as required for such a plain RSA signature).

Bill answered to this security bug by saying that the current default
signature-choice which is MD5-based does not suffer of that problem.
[This is right if we assume that MD5 with an appended secret key
(which is the default signature-choice in Photuris)
does not leak information on its input (a property that is not guaranteed
by cryptographic or collision resistant hash functions).]
However, even if this mechanism is secure it does not guarantee the
security of Photuris when using other signature transforms.
And the above RSA example shows that, indeed, there are natural signatures
that would reveal the whole shared-secret.

How to fix the above "sign the shared-secret" bug?

One solution is to fix the "language": specify that only
signature-attributes that cryptographically hide the signed information
are acceptable.

Or just leave "signatures" to mean what they traditionally mean (ie.,
unforgeability), and add an explicit mechanism that takes care of the
required additional aspects.

I vote for the second way. In the next message I will present the solution
I suggest.

Hugo