AES-GCM for Securing Bluetooth Low Energy Application

Question

I have a task at hand on designing security on Bluetooth Low Energy application layer. The system is created so that only smartphones with symmetric key (long term) could communicate and control my BLE device. The symmetric key will be stored securely on cloud server and programmed on BLE device with JTAG read protection. The mechanism to distribute this symmetric key to intended smartphone is outside the scope of this thread.

I use AES-GCM on my embedded processor and phone app. It can be summarized like this:

1. Smartphone request connection to BLE device
2. Smartphone read a characteristic which will respond with a challenge $C$:
   $C = \operatorname{AES}(K, S, N)$
   $K$ is the symmetric long term key
   $S$ is 1-byte of secret generated randomly by BLE device
   $N$ is nonce/IV controlled by BLE device and starts from $0$
3. Smartphone prepares the legitimate command $I$ by encrypt and authenticate with incrementing the nonce received by $1$:
   $I = \operatorname{AES}(K, D_{0} \mathbin\Vert S, N+1)$
   $D_{0}$ is the opcode for specific operation for BLE device
4. BLE device then increments its nonce to $N+2$ for future smartphone connect and read the challenge, and so on...

---

At first I though it would be secure but later I found that it might break if someone impersonate BLE device (MAC address clone) and replay the previous legitimate response such as:

1. Smartphone request connection to impersonate device
2. Smartphone read a characteristic and impersonate device replies previous challenge:
   $C = \operatorname{AES}(K, S, N)$
3. Smartphone does not know about previous challenge and proceed with:
   $I = \operatorname{AES}(K, D_{0} \mathbin\Vert S, N+1)$
   I think this would not be a problem if the data is the same $D_{0}$. However if the data is different, lets say the phone would send $D_{1}$ then:
   $I = \operatorname{AES}(K, D_{1} \mathbin\Vert S, N+1)$

It leads into condition where different data is encrypted and authenticated with same nonce. I am worry that adversaries could recover the long term key.

My problem seems similar with these:

• Establish a secure connection between a Bluetooth Low Energy device and an Android App using ECDH
• Encrypting small packets with low data rate

But it uses ECDH while my system does not use public key cryptography

My questions are about:

1. If I use a mechanism to produce symmetric session key before proceeding with above flow. Is it one of solution to mitigate the above problem?

2. What is the good mechanism to securely generate session key when both parties have that same long term symmetric key?

   I have a true random number generator on my BLE hardware and for apps I can use secure random number generator library but my knowledge is limited on key exchange technique.

Answer 1

Using GCM with a long term fixed key is dangerous; if you repeat the nonce, you can leak the authentication piece.

Instead, what I would suggest is that you use AES-SIV instead. It doesn't have the problems with repeating a nonce. It is more complex, and slower, however it is far better suited if you have to use a long term key.

Answer 2

As said by Poncho, nonce reuses with AES GCM leads to compromission of the secret key of the keyed hash function used for authentication, which is not the same as the long term key (so your data is still not at risk of being decrypted).

Using Diffie Hellman key exchange to get a session key as you mention is the best way to do it. If you cannot use public key crypto at all, but fear to expose your long term key, you could rely on a key derivation scheme based on a preshared key.

For example the BLE device could generate a random $r$ and encrypt it using the long term key and a nonce, then the phone could decrypt it and would then use a session key $k_s = \mathrm{KDF}(k,r)$ derived from both the long term key $k$ and the random $r$ to communicate securely with the BLE device which would also be able to derive the session key like the phone did.

What you want to make sure of is that your BLE device actually has a contributory behaviour in the key establishment process.

Finally think twice about your threat model : what if some hacker with too much time cracks a BLE device open and extract its long-term key? To avoid a complete break of your system you might not want to use always the same long-term key on all of your devices.... and you could probably save you a lot of time later on by directly implementing a good public key infrastructure now.