[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: change in isakmp/oakley
Steve and Dan both have a similar question
> Maybe I'm missing something, but in this case the attacker is the other
> party to the conversation -- who by definition will know the full key.
Here is an example scenario:
1) an excellent block cipher with security of (at least) 128 bits and keys
of length 256 is used as a prf. The only "weakness" known for the cipher
is that keys with the last half bits fixed to zero act as the identity
function (or any other insecure transformation of the data).
[As said in my previous message this is NO real weakness for a block
cipher, keyed-hash or prf.]
2) encryption mode of isakmp/oakley is used with this prf. Nonces are
defined to be 128 bits each in this case. The key SKEYID to the prf as
currently defined is Ni|Nr (concatenation of the nonces)
3) I is willing to initiate a key exchange with R using the legitimate
public key of R denoted pk_R. (For simplicity we can assume aggressive
mode but it is not essential for the example; also notice that I describe
below only the minimal information relevant to the attack)
I chooses a random 128-bit Ni and cookie CKY-I and sends to R:
<Ni>pk_R and CKY-I (as well as g^xi, etc).
The message is intercepted by Eve who responds to I (claiming to be R)
in the following way: Eve chooses Nr=0...0 and a random value CKY-R.
Sends <Nr>pk_I and CKY-R to I. Even if she DOES NOT KNOW Ni
she can compute
SKEYID = prf(Ni|Nr, CKY-I | CKY-R) = prf(Ni|0, CKY-I | CKY-R) = CKY-I | CKY-R
(notice that here we use that Nr=0 and that this results in the identity
function, and that the values of the cookies are public!)
Knowing SKEYID Eve succeeds in impersonating R without having any idea on
the value of R's public key. She just needs to reply with
HASH_R =prf(SKEYID, g^xr | g^xi | CKY-R | CKY-I | SAp | IDir)
which depends on SKEYID, that she knows, and the other public information.
Makes sense now?
I hope this help clarifying some of the issues.
In the above attack the attacker does not need to learn anything
about Ni. As I hinted to in a previous message, more sophisticated attacks
can be though of where the attacker learns some information about Ni
(even without knowing pk_R) by replying an encryption of Ni produced by I
and getting back information on some value Ni|Nr'.
As my philosophical remark of the day, let me stress that
it is a big mistake to design cryptography solely based on the *absence*
of a "practical enough" attack today. The only way to design good
cryptography for the years to come is to have a good analytical basis
on which to claim the security. Since I need the mixing of Ni and Nr
to provide that analysis, then the mixing should be there.
The examples of attacks that I give are for illustration only, not intended
as the *exhaustive* listing of all the possible attacks. (A list which
I do not know myself!)
And, yes, I know, it breaks a couple of implementations of the
encryption mode. So repair them. No big deal.
(Do not forget that security-wise the encryption mode provides the best
advantages. Especially, the *combined* hardness of DH and of PK encryption.
So we better do it right.)
Hugo
PS: 1) If anyone wants an even better solution than mixing at a higher
editorial/implementation cost, I can offer that to you:
do not mix; just use unidirectional SKEYID keys: SKEYID-I
and SKEYID-R (using Nr and Ni respectively).
Now all the derivatives _e _a _d are unidirectional too.
And that can only help security. But I know it is too late
now to do that, as it was too late 2 years ago too...
2) it just occured to me that the attack described above would be much harder
with the revised encryption mode, since there Eve will need knowledge of
pk_R to learn the value g^xi involved in the computation of HASH-R.
Just another example on the benefits of this mode.
3) Dan: I notice that the draft uses the symbol g^xy to denote the DH key.
But it uses g^xi and g^xr to denote the individual exponents. Some
clarification (or change of notation) is needed.