NRF51822 Beacon with Secure Connection

[silex]

Hello, I have enough experience for ARM MCUs but I am newbie to BLE technology. I am thinking of a project about using NRF51822 beacon to unlock door when in range. I am using Keil v5 and PCA10028 devkit. I tried beacon example in SDK, which use indirect advertisement. It works, but not secure. Firstly, i want beacon and my gateway get paired first with 6digit password. After that, beacon must go to sleep mode , then wake up and send its ID for every 4seconds. Because battery life is important. I want your help on this. How can i do this? Which protocol should i use? Are there any example for such application?

Thank you so much.

[Petter Myhre]

So currently you have a nRF51 DK (PCA10028), which is the lock (observer/central device), and a nRF51822 Bluetooth Smart Beacon kit which is a key/beacon (broadcaster/peripheral) device. In your current implementation the central device unlocks when it receives an advertising packet from the peripheral, maybe with a certain RSSI. Now you want to add security, so that unauthenticated devices can't unlock the lock. Is this correct?

[silex]

Thats correct. I am thinking of 2 ways; 1- After being powered up, central device want to connect to beacon (peripheral) with password. After they got paired, beacon sleeps for 4 seconds, then sends its UUID, RSSI etc, and then again sleep for 4 seconds again. In this way, a low level security can be established via 6 digit password. 2- AES encryption. Beacon sends the data using indirected advertisement, but this data must be AES encrypted. Central device knows AES passkey, and decrypts the data.

Are these possible, and how? Which one is quicker solution? Thanks

[Petter Myhre]

To use the security features of BLE you need to be connected, so if you want to have a broadcaster/observer setup the security has to be implemented in the application layer. If this is something you want to do, this may be helpful. Then you can also use another protocol, like ANT or Gazell.

If I was you, I would strongly consider using connections instead, in a peripheral/central setup:

On the central device you have a GATT server with a "lock" service that has a characteristic with a characteristic value that requires MITM protection and encryption to be written to. The value represent an open or locked lock. You set this by using:

BLE_GAP_CONN_SEC_MODE_SET_ENC_WITH_MITM(&attr_md.write_perm);

To get MITM protection, authentication with a 6-digit passkey entry or OOB is required in the pairing process. It is very important that the pairing with Passkey Entry is done in a safe environment, if not an attacker can follow the pairing process and get the encryption keys. Bonding should also be performed, which means that devices remembers the encryption keys, and use them for following connections. In our SDK bonding and MITM are enabled by the following defines:

#define SEC_PARAM_BOND         1     /**< Perform bonding. */
#define SEC_PARAM_MITM         1     /**< Man In The Middle protection required. */

To authenticate with passkey entry IO capabilities are required. The possible combinations are:

The central has a display which can display the passkey, and the peripheral has a keyboard that can input the passkey. The peripheral has a display which can display the passkey, and the central has a keyboard that can input the passkey. Both the central and the peripheral has a keyboard, and both type the same passkey.

In our SDK IO capability is set by the following define:

#define SEC_PARAM_IO_CAPABILITIES           BLE_GAP_IO_CAPS_DISPLAY_ONLY

It is also possible to use a static passkey, see this MSC. For more information, search DevZone.

The operation would be something like this after the devices are paired, authenticated with passkey entry, and bonded:

1. The central scans with a whitelist, with the device address or IRK of the peripheral in the list.
2. The peripheral advertises with a whitelist, with the device address or IRK of the central in the list. Every 4th second?
3. When the peripheral comes in range of the central the central connects to it, and then the link is encrypted with the shared encrypting keys.
4. A short or long connection interval can be used to obtain short latency or low power consumption, while the devices are connection. The connection interval must be between 7.5 ms and 4 s. Slave latency can also be used to low the power consumption in the slave.
5. The peripheral is then able to write "open" to the "lock" characteristic to open the lock. RSSI can be used in addition.

PS. A whitelist is a list of devices addresses and IRKs of devices that you want to communicate with, all other are filtered out.