DDSSEC_ — Use standard Key Derivation functions from the SharedSecret

It appears that using the HMAC() by itself is not recommended in the case the shared secret Z comes from a diffie-hellman exchange because the DH-generated secrets are not random enough. It would be OK with the RSA approach if the secret was generated using a cryptographically-strong random number.

The accepted way to derive keys from a "shared secret" is called a HMAC-based Key Derivation Function. As it turns out there is a great paper on this (http://eprint.iacr.org/2010/264.pdf) which was the basis for a recent IETF (informational) standard:
https://tools.ietf.org/html/rfc5869

This paper describes the pitfalls of using just a hash-function to generate keys from with DH shared secrets. It also criticizes some of the NIST recommendations because they are also "weak".

The recommendation is to follow what https://tools.ietf.org/html/rfc5869 as it is a well stablished approach used by IKE and it is better than the simple HMAC the specification is using.

Their recommended approach is along the lines of HMACsha256(Challenge_A # Challenge_B # Cookie, SharedSecret). However there is a twist. Rather than repeat this approach using different Cookies they recommend using the result of the above just as a first step, and then "expand on it" as in:

Note: First argument to HMAC-sha256() function is the key material.

PRK = HMAC-sha256(NonSecretSalt, SharedSecret)
T(0) = "" (empty-zero length string)
Cookie = "
T(1) = HMAC-sha256(PRK, T(0) | Cookie | 0x01)
T(2) = HMAC-sha256(PRK, T(1) | Cookie | 0x02)
T(3) = HMAC-sha256(PRK, T(2) | Cookie | 0x03)

The resulting material T = T(1) | T(2) | T(3) | T(4)
is then used to get the needed keys and salts.
In our case we would need: KxKey, KxSalt

We could use, following RFC 5869:

NonSecretSalt = Sha256(Challenge_A # Challenge_B # "key exchange")
PRK = HMAC-sha256(NonSecretSalt, SharedSecret)

KxKey = HMAC-sha256(PRK, KxKeyCookie | 0x01)
KxSalt = HMAC-sha256(PRK, KxSaltCookie | 0x02)

In addition it seems like our SessionKeys, SessionSalt, and SessionHMacKey may suffer from the same problem. they are using the secret (MasterKey) as the key to the HMAC instead of as the "payload".
Perhaps we should also modify this to align it with RFC 5869

This change would be limited to:

Table 50 ( KeyMaterial_AES_GCM_GMAC for BuiltinParticipantVolatileMessageSecureWriter and BuiltinParticipantVolatileMessageSecureReader )

And Section 9.5.3.3.3 (Computation of SessionSenderKey and SessionReceiverSpecificKey)

Use a HKDF to obtain the key material from the DH shared secret

Follow the approach recommended in IETF RFC 5869https://tools.ietf.org/html/rfc5869