2
$\begingroup$

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?

Improve this question
$\endgroup$

1 Answer 1

Reset to default
4
$\begingroup$

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$.

Improve this answer
$\endgroup$
6
  • $\begingroup$ Hi Maarten, pardon me as I am quite new in this field. If I use AES-GCM and disconnect the Bluetooth connection once I got packet which is not authenticated, does it alleviate the problem 1? What if I change the scheme a little bit, once both parties exchange $A$ and $B$, they derive two session keys: $\text{HMAC-SHA256}(K, "A to B"||A||B)$ for packet from mobile app to device $\text{HMAC-SHA256}(K, "B to A"||A||B)$ for packet from device to mobile app The encrypted packet using AES-GCM will be appended with IV using counter. Does it help to overcome 2 & 3? $\endgroup$
    – arahaeldor
    Commented May 31, 2018 at 9:45
  • 1
    $\begingroup$ As for 1, it alleviates your problem when it comes to security. But it will make debugging / logging harder as you cannot distinguish between failed authentication and errors / break in attempts during communication. It's more a technical problem than a security problem. As for 2 / 3, yes, that's fine with the single key AES-GCM. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 31, 2018 at 9:48
  • $\begingroup$ For technical problem, the Bluetooth Low Energy guarantees the integrity of its packet on its link layer up to application layer. I assume that it is quite safe. However per your suggestion, what if I need to add explicit authentication? Lets say the smart lock sends a random/challenge to mobile app in order for mobile app to calculate and send back a hash/response. Device then calculate the hash and compare it with provided hash from mobile app. Is it what you mean by explicit authentication? $\endgroup$
    – arahaeldor
    Commented May 31, 2018 at 10:02
  • 1
    $\begingroup$ Just HMAC any information and send that, if possible with a separate session key. Efficient protocols do this using 3 instead of 4 messages. If you already have both randoms then you can append the HMAC over the random or even sign the randoms themselves. TLS just signs all the data over the previous messages but that may be overly expensive. However, if you have the full concatenations still in memory anyway... Whatever you do, do not encrypt and MAC something in the authentication phase. $\endgroup$
    – Maarten Bodewes ♦
    Commented May 31, 2018 at 10:35
  • $\begingroup$ Marteen let me wrap this up, so instead of deriving 2 session keys just like my previous comment, I could derive 3 session keys. Two of it are used for sending and receiving packet between parties. The other one is used for HMAC any information for example mobile app would send the information along with its MAC (no encrypt & MAC, just plain info & its MAC) and let the device authenticate by doing the MAC calculation & compare. This authentication is performed first before starting to send and receive packet between two parties. Is it in accordance with your advice? $\endgroup$
    – arahaeldor
    Commented May 31, 2018 at 17:17

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.