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.

[Vidar Berg]

Hello,

You should also increase the security level on your service characteristics to make pairing/bonding required. The NUS service characteristics are set to "SEC_OPEN" by default, which means the client can access them without securing the connecting first.

The security level can be set to 'SEC_MITM' when passkey pairing is supported.

For protection against passive eavesdropping (from a BT sniffer) you should also consider enabling the LESC bit. This require that you integrate the neccessary crypto libraries as in the ble_app_gls example and call the nrf_ble_lesc_request_handler() function from your main loop.

Best regards,

Vidar

[Ben]

Hi,

Thank you for your reply.

There are still few questions about your tips.

1.  I changed access to SEC_MITM in your yellow remark. After using nRF connect, it can't access these characteristics directly. Because it doesn't display passkey entry window. Does it not work in passkey?

   void gap_params_init(uint8_t *dev_name, uint8_t len)
   {
       uint32_t                err_code;
       ble_gap_conn_params_t   gap_conn_params;
       ble_gap_conn_sec_mode_t sec_mode;
   
       BLE_GAP_CONN_SEC_MODE_SET_OPEN(&sec_mode);
   
       err_code = sd_ble_gap_device_name_set(&sec_mode,
                                             dev_name,
                                             len);
       APP_ERROR_CHECK(err_code);
   
       memset(&gap_conn_params, 0, sizeof(gap_conn_params));
   
       gap_conn_params.min_conn_interval = MIN_CONN_INTERVAL;
       gap_conn_params.max_conn_interval = MAX_CONN_INTERVAL;
       gap_conn_params.slave_latency     = SLAVE_LATENCY;
       gap_conn_params.conn_sup_timeout  = CONN_SUP_TIMEOUT;
   
       err_code = sd_ble_gap_ppcp_set(&gap_conn_params);
       APP_ERROR_CHECK(err_code);
       
       // static passkey
       ble_opt_t ble_opt;
       uint8_t passkey[] = "123456";
   
       ble_opt.gap_opt.passkey.p_passkey = passkey;
       err_code = sd_ble_opt_set(BLE_GAP_OPT_PASSKEY, &ble_opt);
       APP_ERROR_CHECK(err_code);
   }

2. Do you mean when device enables MITM which should also enable crypto function to get full protection?
3. I try to import below file to project which source is reference glucose example.

         add nrf_rng.c

            

         

        But, IDE displays two errors. Does it mean I import wrong file to cause RAM size not enough?

      

[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.

[Vidar Berg]

Hi,

I sent you my modified version of your project to your email. Hope it helps.

[Ben]

Thank you for your provide that project. After I import my project, it solves my problem.