aes symmetric authenticated-encryption aes-gcm
Updated Fri, 17 Jun 2022 03:26:37 GMT

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

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.


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.

Comments (1)

  • +0 – 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 04, 2017 at 16:06