nRF52810 passkey entry

RE: nRF52810 passkey entry

Ben — Thu, 16 Dec 2021 01:43:57 GMT

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

RE: nRF52810 passkey entry

Vidar Berg — Fri, 10 Dec 2021 12:52:58 GMT

Hi,

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

RE: nRF52810 passkey entry

Ben — Fri, 10 Dec 2021 03:04:34 GMT

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

RE: nRF52810 passkey entry

Emil Lenngren — Thu, 09 Dec 2021 11:48:30 GMT

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

RE: nRF52810 passkey entry

Ben — Thu, 09 Dec 2021 11:27:44 GMT

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.

RE: nRF52810 passkey entry

Emil Lenngren — Thu, 09 Dec 2021 08:48:29 GMT

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

RE: nRF52810 passkey entry

Ben — Thu, 09 Dec 2021 01:48:51 GMT

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

RE: nRF52810 passkey entry

Vidar Berg — Wed, 08 Dec 2021 12:29:16 GMT

Hi,

Are you able to share the full project so I can try to debug it here?

RE: nRF52810 passkey entry

Ben — Wed, 08 Dec 2021 08:15:26 GMT

Hi,

1. In my project, I add #if !PEER_MANAGER_ENABLED and #endif between BLE_GAP_EVT_SEC_PARAMS_REQUEST and BLE_GATTS_EVT_SYS_ATTR_MISSING in main.c. The nRF connect still can't pop up passkey entry window. I also import these files and modify on ble_app_uart example (PCA10040e). The result is same. Please help to solve it. Thank you.

devzone.nordicsemi.com/.../71206.main.c devzone.nordicsemi.com/.../23271.sdk_5F00_config.h devzone.nordicsemi.com/.../7115.ble_5F00_nus.c

RE: nRF52810 passkey entry

Vidar Berg — Tue, 07 Dec 2021 13:06:10 GMT

Hi,

1. Please make sure you are not handling the following events in main.c::ble_event_handler():

- BLE_GAP_EVT_SEC_PARAMS_REQUEST

- BLE_GATTS_EVT_SYS_ATTR_MISSING

static void ble_evt_handler(ble_evt_t const * p_ble_evt, void * p_context)
{
    uint32_t err_code;

    switch (p_ble_evt->header.evt_id)
    {
        case BLE_GAP_EVT_CONNECTED:
            NRF_LOG_INFO("Connected");
            err_code = bsp_indication_set(BSP_INDICATE_CONNECTED);
            APP_ERROR_CHECK(err_code);
            m_conn_handle = p_ble_evt->evt.gap_evt.conn_handle;
            err_code = nrf_ble_qwr_conn_handle_assign(&m_qwr, m_conn_handle);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GAP_EVT_DISCONNECTED:
            NRF_LOG_INFO("Disconnected");
            // LED indication will be changed when advertising starts.
            m_conn_handle = BLE_CONN_HANDLE_INVALID;
            break;

        case BLE_GAP_EVT_PHY_UPDATE_REQUEST:
        {
            NRF_LOG_DEBUG("PHY update request.");
            ble_gap_phys_t const phys =
            {
                .rx_phys = BLE_GAP_PHY_AUTO,
                .tx_phys = BLE_GAP_PHY_AUTO,
            };
            err_code = sd_ble_gap_phy_update(p_ble_evt->evt.gap_evt.conn_handle, &phys);
            APP_ERROR_CHECK(err_code);
        } break;
#if !PEER_MANAGER_ENABLED
        case BLE_GAP_EVT_SEC_PARAMS_REQUEST:
            // Pairing not supported
            err_code = sd_ble_gap_sec_params_reply(m_conn_handle, BLE_GAP_SEC_STATUS_PAIRING_NOT_SUPP, NULL, NULL);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GATTS_EVT_SYS_ATTR_MISSING:
            // No system attributes have been stored.
            err_code = sd_ble_gatts_sys_attr_set(m_conn_handle, NULL, 0, 0);
            APP_ERROR_CHECK(err_code);
            break;
#endif // !PEER_MANAGER_ENABLED
        case BLE_GATTC_EVT_TIMEOUT:
            // Disconnect on GATT Client timeout event.
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gattc_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;

        case BLE_GATTS_EVT_TIMEOUT:
            // Disconnect on GATT Server timeout event.
            err_code = sd_ble_gap_disconnect(p_ble_evt->evt.gatts_evt.conn_handle,
                                             BLE_HCI_REMOTE_USER_TERMINATED_CONNECTION);
            APP_ERROR_CHECK(err_code);
            break;

        default:
            // No implementation needed.
            break;
    }
}

The peer manager is responsible for handling these events when enabled.

2. Yes. The encryption keys are sent on-air in cleartext when you use legacy pairing. This means that a BT sniffer can fetch the encryption key if it's listening during key exchange.

3. Yes, it looks like you have run out of RAM. Maybe you are including the wrong crypto libraries. I suggest you use the ble_app_hrs/pca10040e project as a reference for which crypto related configuration settings and source files to use for this chip variant.

Best regards,

Vidar

RE: nRF52810 passkey entry

Ben — Tue, 07 Dec 2021 08:57:00 GMT

Hi,

Thank you for your reply.

There are still few questions about your tips.

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);
}

Do you mean when device enables MITM which should also enable crypto function to get full protection?
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?

RE: nRF52810 passkey entry

Vidar Berg — Mon, 06 Dec 2021 12:42:11 GMT

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