nRF52810 passkey entry

[Ben]

Hi Sir/Miss,

I try to implement static passkey in my project. Which is using nRF52810.

The SDK version is 17.0.2.

Softdevice is S112.

My project is based to develop on NUS.

I want to use central device to enter passkey to do pairing and bonding.

It's just like ble_app_gls example.

I refer ble_app_template example to add peer_manager and fds in project.

Reference this to do it. 

#define SEC_PARAM_BOND                  1                                           /**< Perform bonding. */
#define SEC_PARAM_MITM                  1                                           /**< Man In The Middle protection required (applicable when display module is detected). */
#define SEC_PARAM_LESC                  0//1                                           /**< LE Secure Connections enabled. */
#define SEC_PARAM_KEYPRESS              0                                           /**< Keypress notifications not enabled. */
#define SEC_PARAM_IO_CAPABILITIES       BLE_GAP_IO_CAPS_DISPLAY_ONLY                /**< Display I/O capabilities. */
#define SEC_PARAM_OOB                   0                                           /**< Out Of Band data not available. */
#define SEC_PARAM_MIN_KEY_SIZE          7                                           /**< Minimum encryption key size. */
#define SEC_PARAM_MAX_KEY_SIZE          16                                          /**< Maximum encryption key size. */

And, add setup static passkey code between ble_stack_init() and advertising_start()

When I use dongle to connect nrf52810 in nRF connect, it doesn't pop up passkey entry window on it. It's connected directly.

It's different with glucose example.

How do I set it up?

Thank you.

[Ben]

Hi,

Please download this file.

IDE: IAR 8.50.9

Path: examples -> ble_peripheral -> ble_app_uart (pca10040e)

HW: PCA10040 V1.2.4 2018.44

Thank you

[Emil Lenngren]

Static passkey with LESC is highly discouraged ("should not be used") in the Bluetooth Specification. The reason is that the security model is only valid for a new random passkey on every attempt. A passive eavesdropper learns the passkey after a successful attempt (just like legacy pairing). But an active attacker trying to brute force the passkey learns what first bit was wrong and can hence on average crack the passkey in only ten attempts. This is not possible with legacy pairing, which requires up to a million attempts, so if the security goal is to make it possible for only people knowing the passkey to connect, then the legacy model is stronger than LESC. As you can see, static passkey with current BLE security has very bad security compared to real PAKE algorithms. Even for legacy pairing, the Bluetooth standard says static passkeys "should not be used".

[Ben]

Hi,

After your suggestion, I see the content is in 7.2.3 and 2.3.5.6.3 of Core Spec 5.3.
Because our product don't have screen and display. There is only two color LED. I don't know whether has other method to let our user to enter dynamic passkey? I don't know if my idea is correct. Maybe, I can add another open security service to show dynamic passkey in APP. Then, user can have authority to access main service. Or, are there another suggestion?
Thank you for your information.

[Emil Lenngren]

"Maybe, I can add another open security service to show dynamic passkey in APP"

Do you mean that you over a non-secured characteristic send the passkey to later be used? That will not give you any higher security than the "Just Works" association model.

Unfortunately, what the Bluetooth standard can offer is not good enough for use cases when devices have no displays nor keypads, to establish all the security properties expected by modern security (secure against passive eavesdroppers, man-in-the-middle attacks and unauthorized bond attempts (i.e. being able to pair without knowing the passkey)).

This is a wide issue among BLE device manufacturers and is in my opinion a design mistake in the spec. If the spec developers had just chosen a PAKE (password authenticated key exchange) algorithm instead, static passkeys would have been possible and could have all the security properties mentioned above.

What people instead tend to do, that really want a static passkey, is to either accept the lower security and go with Legacy Pairing (which is still pretty good protecting from users only knowing the correct passkey to "log in" to the device, assuming no attacker is nearby at the pair attempt), or implement their own PAKE protocol and security on top of unencrypted BLE and then skip BLE pairing. The later approach is way more advanced but is chosen when the higher security is really needed, so this approach is chosen by for example Homekit. So you should really try to list down the different security properties you need, compare with the implementation efforts you would like to put into the project, and then choose the method that suits you best.

If you would like to read more about why LESC with static passkey is not secure, I wrote a post some time ago here: github.com/.../36005.

[Ben]

"Do you mean that you over a non-secured characteristic send the passkey to later be used? " Yes. But, it looks like useless.

That's good suggestion to me in method of Apple Homekit. We can refer it.

Thanks your suggestion and github link.