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 = 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 = AES(K, D_{0}||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 = AES(K, S, N)$
3. Smartphone does not know about previous challenge and proceed with:
   $I = AES(K, D_{0}||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 = AES(K, D_{1}||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.

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.

Hello

I am still new to cryptography world and I am still learning much about it, please pardon me for my limited knowledge.

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 = 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 = AES(K, D_{0}||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 = AES(K, S, N)$
3. Smartphone does not know about previous challenge and proceed with:
   $I = AES(K, D_{0}||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 = AES(K, D_{1}||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.

Any suggestions is much appreciated, thanks

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 = 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 = AES(K, D_{0}||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 = AES(K, S, N)$
3. Smartphone does not know about previous challenge and proceed with:
   $I = AES(K, D_{0}||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 = AES(K, D_{1}||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.