1
$\begingroup$

I have a system made of 2 or more parties, already sharing a master key MK, who want to agree on a session key SK (both 128-bit AES keys).

One of the parties (the master) starts the protocol by sending a random nonce authenticated by a MAC computed from a shared secret (derived from MK). The request is also protected against replay by means of a counter.

The parties verify the request and compute a salt by concatening nonce, counter and MAC. Then, they use HKDF (rfc5869) based on SHA256 to derive SK:

PRK = HMAC-SHA256(salt, MK)          // HKDF-Extract
T = HMAC-SHA256(PRK, info | 0x01)    // HKDF-Expand
SK = first 16 octets of T

Now, by protocol, each party has to prove that the derivation of SK from MK was successful, by authenticating fresh data with SK. Assuming each party has a well-known fixed identifier, I build proof of possession as follows:

data = party_ID || salt
proof = AES-CMAC(SK, data)

My question is: is it safe re-use the above salt as a "challenge" for proof of possession, or I have to force the master to send a new random nonce as challenge? With "safe" I mean: assuming that the rest of the scheme is secure, does the fact of re-using the salt as a challenge leak some information about SK?

$\endgroup$
  • $\begingroup$ Is the counter publicly known? $\endgroup$ – mat Oct 31 '17 at 11:13
  • $\begingroup$ Yes, the only secret is MK (and SK of course). $\endgroup$ – andrey Oct 31 '17 at 13:54
  • $\begingroup$ If you have multiple parties, which have to proof the possession of SK, then you cannot just use salt as a challenge for all of them, since any party could just copy the MAC from another one. The challenge needs to be unique per user. $\endgroup$ – mat Oct 31 '17 at 14:51
  • $\begingroup$ I am sorry, I missed to specify that the salt is not the only piece of data on which the proof is computed. You're right, question updated. $\endgroup$ – andrey Oct 31 '17 at 15:48

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Browse other questions tagged or ask your own question.