HMAC SHA256 for deriving session keys using random nonce

Question

I need to derive session key in order to create an application layer secure channel between mobile app and a bluetooth device. My scheme is similar to this scheme that uses a HMAC and counter.

Provided that between mobile app and BLE device have already share a same key $K$ (256-bits) through provisioning process, I plan to derive session key with these steps:

1. Let $A$ be 16-bytes of generated random number from mobile app and $B$ be 16-bytes of generated random number from BLE device. Both are treated as nonce or IV.

2. Mobile app sends random $R_A$ to BLE device $A$ and BLE device sends its random $R_B$ to mobile app $B$ on unsecure communication channel.

3. Both mobile app and BLE device derive session key using:

   Session Key = $\text{HMAC-SHA256}(K, R_A||R_B)$

   The random $R_A$ and $R_B$ are both concatenated.

Now both parties will share the same session key for upcoming communication using AES. I use this scheme because my BLE device is limited on its processing power for asymmetric method.

Is it safe to implement this scheme for deriving session key?

Answer 1

Yes, it is secure, as the KDF is secure, as the answers to the question you linked to indicates.

However, there are some things that you should keep in mind:

1. The result of the KDF is not validated; if the initial shared key is incorrect you will only find out once the session keys are used. This is tricky to implement if you want to use the session key for authentication (you may want to use explicit authentication rather than implicit authentication during the session).
2. Both parties now share a single session key, so you may need to be careful when using encrypt-then-MAC.
3. Both parties use share a single session key, possibly for communication in both directions, which means you can have messages replayed not just from $A$ to $B$, but also from $A$ to $B$ and then replayed back to $A$.
4. The scheme will not provide any forward secrecy that ephemeral Diffie-Hellman could provide.

You can e.g. use a single byte tag in addition to calculate both an encryption key and a MAC key, possibly a third one to create a value that can be exchanged to authenticate the entities.

You could include the identities $ID_A$ and $ID_B$ in the MAC calculation, e.g. $ID_A || ID_B || R_A || R_B$ for sending from $A$ to $B$.