BLE data transfer use AES/CCM encryption and unencryption

[JohnCC]

Hi,

      I development a elock device to use nordic 52832 chip. I want to transfer some information between phone app and my device. Like UUID / user account / user password.

for against BLE sniffer, we need use AES method to protect our information.

Can I follow  \examples\crypto\nrf_cc310\aes example to do it? Or any suggest for us? Our data transfer flow as below

 - phone app sent unlock command to our device

 - our device sent a random number to phone app

 - phone app response

- our device check response to unlock

Thank you.

John.

[Hung Bui]

Hi John, 

Yes it's possible to do what described in Daniel's blog for your application. 

But I want to make it clear that the bonding process (with passkey or NFC) only needed on the first time the phone connect to the lock. On the next connection the phone and the lock will use a common LTK to encrypt the link. 
Imagine when a new user setting up his phone as the key, he would need to either read the NFC tag on the log or type the code that show on the log. After that the lock automatically open when the phone is close by (connect - encrypt - unlock command - disconnect)

If you want to have an extra security layer you can also implement what Daniel described, on top of BLE encryption. 

[JohnCC]

Hi Hung,

       Maybe I'll describe as below what I understand, see if that's right.

Step 1: I use MITM function to bonding my device and phone.

Step 2: Use key in passkey on phone to confirm your own.

Step 3: When I will lock device, the device will connect to my phone

Step 4: AES encrypt and unencrypt some information transfer between device and phone

Step 5: If authentication succeeded, device will lock

As I know, if I enable MITM function. The transfer data between device and phone will protected by AES. But AES need a key on device and phone side. When will I get this key? I need burn in this key in my device during production in factory? and transfer this key to phone when user enable lock feature? -  I don't understond.

Do you have any user flow can refer it?

Thank you

John.

[Hung Bui]

Hi John, 

It would work this way: 

Step 1. User turns on the Lock

Step 2. Customer open the app on the phone to connect to the lock for the first time and bonding process starts

Step 3a. If there is keyboard on the lock, the phone can display passkey and user need to type the same passkey on the lock . It's the random passkey the phone generated.

Step 3b. If there is display on the lock, the lock can display the passkey and user type the same passkey on the phone. It's the random passkey the lock generated

Step 4. Two device bonded . They now have generated and stored the same LTK (long term key). This is Bluetooth LTK.

Here the set up process is done. 

Step 5 when the user with the phone come close to the lock, the lock automatically connect to it

Step 6 The phone and the lock encrypt the connection using the previously stored LTK. The lock now know for sure that it connect to the authenticated phone. 

Step 7 The link is now encrypted , and the phone can now send the command to lock or unlock the door. 

Step 8 After the door is locked or unlocked, the phone can disconnect the encrypted connection. 

At step 7 you can implement your extra security protocol if you want. 

[JohnCC]

Hi Hung,

       Thank you for your answer. Very clear.

One more question. If my lock don't have keyboard or display. Only have some hardware buttons. 

The only way I can do what you describe. Is there only a static passkey way?

It would work this way for me:

Step 3a. Lock device have a static passkey "123456". I provided a QR code include my static passkey. phone scan this QR code to get and send passkey "123456" to lock device.

Step 3a-1 Lock device get "123456" from phone to compare passkey in lock device side. If match. then bonded.

Is it right?

Thank you.

John.,

[Hung Bui]

Hi John, 

According to the spec, static passkey is not considered safe. One can just retry bonding 20 times (LESC) to get the correct passkey. 

Please make it very clear that bonding and lock/unlock the doorlock are not the same. 

So the passkey to bond shouldn't be used to lock or unlock the door . Bonding is to encrypt the link for the first time the two device (phone and doorlock) talk to each other. After that they are secured to talk to each other. Then you can send your command to unlock/lock when the link is encrypted.

Note that you can turn off bonding after you bond with the first device. After that, you can switch to the mode that the device doesn't bond with any new device and only can be switch to bond mode when you open it or send a command from the phone.