# AES-GCM for Securing Bluetooth Low Energy Application

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:

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

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.

• It's not clear to me if your system is incapable of using asymmetric crypto, or that it currently doesn't use asymmetric crypto. Nov 7 '17 at 18:03
• my systems is capable for asymmetric because I am using Cortex M4 as the main processor. however due to project schedule, my familiarity on symmetric, and project requirement that connection from phone should be as fast as possible in a manner of: connect-->setup secure session-->send command-->disconnect. So I decided to use symmetric approach with TLS like implementation especially in random exchange. I have to avoid the certificate verification part as I think it will give overhead in setting up the session Nov 12 '17 at 14:49

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.

• thanks poncho, I will read more about this AES-SIV. from initial research, it seems AES-SIV is quite new and not many library already implemented it. I plan to use mbedtls for my embedded processor. Would it be safe and possible if I add a process for deriving session key using random number generator, for example both parties exchange their own generated random and both perform key derivation technique that including the long term fixed key? So each time phone and BLE connects, the session key would be different Nov 4 '17 at 16:06

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.

• yes following your suggestion, I have a plan to prepare the production so that each BLE device would have different long term key and it will be programmed and be locked from JTAG dump/read using the secure feature from the processor that I use. Maybe it still can be cracked by someone with very high expertise but at least it is only that device which is compromised. Regarding the good PKI, I plan to use it for the version 2 of the device because I already have schedule to follow for current version. Nov 9 '17 at 1:20
• Regarding the contributory behavior, I have decided to use more standard setup like TLS handshake which exchange random number from both parties, but in my case there would be no certificate verification. The other thing is when both device derive its session key, I would use the HKDF for deriving the session key using exchanged random from both as salt and long term key as Input Keying Material. Nov 9 '17 at 1:27