Subject: [MSEC] MIKEY Question

From: "Steffen Fries" <[email-masked]>
Date: Fri, 17 Dec 2004 09:57:42 +0100

Hi,

I've got a question to the usage of the salt and master key (TGK) 
delivered by MIKEY. Does MIKEY offer an option to update the 
salting key alone by keeping the same TGK?

The question behind that is if the master key and the salting key 
are both delivered by MIKEY and used in SRTP to derive the 
session keys, what is to value of the salt, when it is changed 
every time the master key is changed too? I thought the salt 
would provide randomness in the case of using the master key 
multiple times. What would be example offline attacks that 
leverage the absence of the salt?

Regards
	Steffen
_______________________________________________
msec mailing list
[email-masked]
http://six.pairlist.net/mailman/listinfo/msec

---

From: Mark Baugher <[email-masked]>
Date: Fri, 17 Dec 2004 14:30:16 -0800

Steffen,

> salting key alone by keeping the same TGK?

I can't imagine why anyone would want to do that given the purpose of 
the salting key (see 
http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf).
> every time the master key is changed too? I thought the salt

The purpose is to make a precomputation attack infeasible.

> multiple times.

No, it does not do that.  It's a public value.

> What would be example offline attacks that

Specific attacks on additive encryption in the case of RFC 3711.

Mark

---

From: "Steffen Fries" <[email-masked]>
Date: Mon, 20 Dec 2004 16:23:58 +0100

Hi Mark,

thank you for the information, I made some inline comments.

> > delivered by MIKEY. Does MIKEY offer an option to update the salting
> > key alone by keeping the same TGK?
> 
> http://www.mindspring.com/~dmcgrew/dam-srf-sac00.pdf). > > The
> question behind that is if the master key and the salting key > are
> both delivered by MIKEY and used in SRTP to derive the > session keys,
> what is to value of the salt, when it is changed > every time the
> master key is changed too? I thought the salt
> 
stf: aggreed, but this relates to the data encrypted and 
eavesdropped on the network, which would be SRTP data. Since 
SRTP also provides the option to use a salt a similar question 
arises here. (Aehm, we are switching the topic from MIKEY to 
SRTP now ;-))  Isn't in SRTP a "salting effect" already provided 
through the IV?

> No, it does not do that.  It's a public value.
stf: If I understand it right it may be public after usage.

Regards
	Steffen

---

From: Mark Baugher <[email-masked]>
Date: Mon, 20 Dec 2004 08:31:31 -0800

Steffen,

> SRTP now ;-))  Isn't in SRTP a "salting effect" already provided

David and Mats decided to exor the salt in the IV that generates the 
keystream and that's how RFC 3711 does it.  So the salting effect is 
provided in the IV through the salt.  Conceptually, the salt starts the 
counter at a random offset in the counter space.
> stf: If I understand it right it may be public after usage.

Yes, my understanding is that the salt is not known until the SRTP 
session commences.  David is copied on this note and can weigh on this.

Cheers, Mark

---

From: Mats Näslund <[email-masked]>
Date: Mon, 20 Dec 2004 20:15:54 +0100

Hi,

The motivation for using salt in MIKEY is similar, but not
entirely identical, to the reason we have salt in SRTP.

In both cases, the perhaps most important reason is to avoid
pre-computation attacks. In SRTP we here mean an attack against the 
confidentiality, in MIKEY it would be an attack against the key derivation.

So, a pre-computation attack against SRTP encryption would "only"
disclose the session key for confidentiality.

A pre-computation attack against MIKEY would be worse, since it would
be an attack against the TGK, hence *all* keys (TEKs) derived from
that TGK would be disclosed.

In fact, if you use MIKEY with SRTP, there are three "levels" of salt.
One on the MIKEY level, one in the SRTP local key derivation, and
one in the SRTP cipher IV, all of them protecting against attacks on
the respective "level".

Cheers

/Mats

---

From: "Steffen Fries" <[email-masked]>
Date: Tue, 21 Dec 2004 13:00:42 +0100

Hi Maets, 

thanks for the explanation. 

What you wrote is is actually also my view. The only thing is 
that I would like to understand the attack better. The attack 
assumes that somebody pre-computes packets, which he may compare 
afterwards during the communication with eavesdropped packets. I 
made some further inline comments, which show my point.

> confidentiality, in MIKEY it would be an attack against the key
stf: aggreed. Just for my understanding, in case of MIKEY the 
TGK and the salt is delivered as part of the payload. This is 
something one could eavesdrop. But here the pre-computation 
attack may not work as the MIKEY container supplies the TGK and 
the salt. The MIKEY container is protected by other means 
(either (public key) encryption or DH kee agreement)

> that TGK would be disclosed.
stf: aggreed
> One on the MIKEY level, one in the SRTP local key derivation, and one
> in the SRTP cipher IV, all of them protecting against attacks on the
> respective "level".
stf: Yes, I aggree to the key derivation argument, but isn't the 
IV itself not "salt" enough as it is build depending on 
parameters, which belong to the packet (SSRC, packet index) and 
which may be hard to predict?

Regards
	Steffen 
> >  >>> I've got a question to the usage of the salt and master key
> >  >>> (TGK) delivered by MIKEY. Does MIKEY offer an option to update
> >  >>> the salting key alone by keeping the same TGK?
> >  >>
> >  >> I can't imagine why anyone would want to do that given the
> >  >> purpose of the salting key (see
> >  >> question behind that is if the master key and the salting key >
> >  >> are both delivered by MIKEY and used in SRTP to derive the >
> >  >> session keys, what is to value of the salt, when it is changed >
> >  > eavesdropped on the network, which would be SRTP data. Since SRTP
> >  > also provides the option to use a salt a similar question arises
> >  > here. (Aehm, we are switching the topic from MIKEY to SRTP now
> >  > ;-))  Isn't in SRTP a "salting effect" already provided through
> >  > the IV?
> > 
> > provided in the IV through the salt.  Conceptually, the salt starts
> > the counter at a random offset in the counter space.
> >  >
> >  >>

-----------------------------------------------------------
    Steffen Fries,     Siemens AG, CT IC 3	
    Otto-Hahn-Ring 6,  D-81730 Munich, Germany 
    Phone:  (+49) 89 / 636-53403,    
    Fax  :  (+49) 89 / 636-48000
    Email:  [email-masked]
-----------------------------------------------------------

---

From: Mats Näslund <[email-masked]>
Date: Tue, 21 Dec 2004 13:50:36 +0100

Hello Steffen,

> made some further inline comments, which show my point.

Here is a sketch on how a pre-comp attack on MIKEYs key derivation
(KDF) could work (assuming no salt/RAND is used):

1. Generate randomly and independently 2^t TGKs.

2. Run each TGK through the KDF to obtain, say, an integrity key,
    k = KDF(TGK).

    (Assumption: somewhere in the session that follows there will be some
    predictable message, m, occurring that is to be integrity protected.)

3. Integrity protect said predictable message with each candidate key,
    k, producing MAC tag T_m(k) = T_m(KDF(TGK)).

4. Store all (T_m(KDF(TGK)), TGK) pairs indexed by T_m(k) value.

This concludes the off-line precomputation phase, which is done once
and for all.

In the on-line phase, we observe about 2^s "sessions", we assume all (or
almost all) contain the predictable message m. If in one of these,
we see the tag T_m(k) occurring, there's a reasonable chance (depending
on the size of the tag) that we have the right TGK value in our
database.

Roughly, if s + t > size(TGK), we can hope with some reasonable prob.
that we have the right TGK, from which we can then deduce *all* derived 
keys. E.g. if size(TGK) = 128, s = t = 64 would work.

There are perhaps more clever attacks, the one above is a bit naive
but I think it shows the principle. In practice, other things may be
in place to protect against this attack, but it *could* be this simple,
and we should take countermeasures using a salt/RAND, since it really
doesn't cost much.

> (either (public key) encryption or DH kee agreement)

The pre-computation attack breaks down even if the salt was in the
clear, since the salt would need to be known already in the
off-line phase. Of course, you could "loop" over possible salts
too, but if size(salt) >= size(TGK), the attack has
complexity at least 2^size(TGK), and it becomes a "trivial" attack.

> which may be hard to predict?

In the case that MIKEY is used with SRTP, yes, there are requirements
in the RTP spec on SSRC and sequence number starting from "random"
values. However, we chose not to trust these quantities to provide
"cryptographic quality" randomness, and so we added out own salt, though
in practice you are right, the SSRC etc would serve similar purposes
assuming they are unpredictable enough.

Cheers

/Mats

---

From: "Steffen Fries" <[email-masked]>
Date: Wed, 22 Dec 2004 09:21:55 +0100

Hi Maets,

I now see the reasonning for salting. I made some inline 
comments.

--- snipp ---
>     (Assumption: somewhere in the session that follows there will be
>     some predictable message, m, occurring that is to be integrity
>     protected.)
> 
> In the on-line phase, we observe about 2^s "sessions", we assume all
> (or almost all) contain the predictable message m. If in one of these,
> we see the tag T_m(k) occurring, there's a reasonable chance
> (depending on the size of the tag) that we have the right TGK value in
> our database.
stf:
Your explanation of the attack reflects my assumptions. Not 
using the salt by the security protocol utilizing MIKEY would 
enable these attacks.

--- snipp --- 
> clear, since the salt would need to be known already in the off-line
> phase. Of course, you could "loop" over possible salts too, but if
> size(salt) >= size(TGK), the attack has complexity at least
> 2^size(TGK), and it becomes a "trivial" attack.
stf: okay
--- snipp ---
> "cryptographic quality" randomness, and so we added out own salt,
> though in practice you are right, the SSRC etc would serve similar
> purposes assuming they are unpredictable enough.
stf: okay, I now understand the reasoning.

Maets, thanks for your detailed answer. Have a Merry Christmas 
and a Happy New Year!

Ciao
	Steffen

> >>>David and Mats decided to exor the salt in the IV that generates
> >>>the keystream and that's how RFC 3711 does it.  So the salting
> >>>effect is provided in the IV through the salt.  Conceptually, the
> >>>salt starts the counter at a random offset in the counter space.
> >>> >
> >>> >>