Static Passkey, using and testing

RE: Static Passkey, using and testing

Ron — Thu, 02 Jan 2020 10:26:10 GMT

Thank you!

RE: Static Passkey, using and testing

Vidar Berg — Mon, 23 Dec 2019 07:31:12 GMT

Hi,

The slow advertiser will not start because you have disabled the advertiser timeout while using the "limited discovery mode". The max. advertisement duration for this mode is 180 seconds (BLE_GAP_ADV_TIMEOUT_LIMITED_MAX).

It should work if you change the BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE flag to BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE.

RE: Static Passkey, using and testing

Ron — Fri, 20 Dec 2019 17:09:58 GMT

Hi Vidar,

do you mean that

        case BLE_ADV_EVT_IDLE:
            sleep_mode_enter();
            break; // BLE_ADV_EVT_IDLE

I changed the entire routine to

static void on_adv_evt(ble_adv_evt_t ble_adv_evt)
{
    switch (ble_adv_evt)
    {
        case BLE_ADV_EVT_FAST:

            break;
        case BLE_ADV_EVT_SLOW:

            break;                
        default:
            break;
    }
}

as for the advertising_init() I think I added a slow advertisement configuraiton

static void advertising_init(void)
{
    uint32_t               err_code;
    ble_advdata_t          advdata;
    ble_adv_modes_config_t options;

    // Build and set advertising data.
    memset(&advdata, 0, sizeof(advdata));

    advdata.name_type               = BLE_ADVDATA_FULL_NAME;
    advdata.include_appearance      = true;
    advdata.flags                   = BLE_GAP_ADV_FLAGS_LE_ONLY_LIMITED_DISC_MODE;;
    advdata.uuids_complete.uuid_cnt = sizeof(m_adv_uuids) / sizeof(m_adv_uuids[0]);
    advdata.uuids_complete.p_uuids  = m_adv_uuids;

    memset(&options, 0, sizeof(options));
    options.ble_adv_fast_enabled  = true;
    options.ble_adv_fast_interval = APP_ADV_INTERVAL;
    options.ble_adv_fast_timeout  = APP_ADV_TIMEOUT_IN_SECONDS;

    options.ble_adv_slow_enabled = true; //BLE_ADV_SLOW_ENABLED; 
    options.ble_adv_slow_interval = MSEC_TO_UNITS(1475, UNIT_0_625_MS);
    options.ble_adv_slow_timeout = 0;	
	
    err_code = ble_advertising_init(&advdata, NULL, &options, on_adv_evt, NULL);
    APP_ERROR_CHECK(err_code);
}

Still the effect is the same, after timeout advertisement stops.

Any more directions?

Thanks again

RE: Static Passkey, using and testing

Vidar Berg — Fri, 20 Dec 2019 14:08:38 GMT

Hi,

This example does not implement slow advertising. Instead, it attempts to enter System OFF mode (deep sleep) when the fast advertising times out, see BLE_ADV_EVT_IDLE event in on_adv_evt(). I say attempt because it can't enter deep sleep if you are debugging the app while it times out.

RE: Static Passkey, using and testing

Ron — Fri, 20 Dec 2019 13:26:01 GMT

Thanks Vidar

Do you have any idea why would advertising stop after the fast advertising timeout, it never goes into slow advertising in the GLS example, it just stops.

Thanks again for your help

RE: Static Passkey, using and testing

Vidar Berg — Wed, 18 Dec 2019 09:29:34 GMT

Hi,

Yes, it's used to protect against man in the middle attacks. However, legacy passkey pairing does not protect against passive eavesdropping as opposed to the LE secure pairing procedure, which was discussed in the other thread. A high-end BT sniffer will easily brute force the passkey on the fly and retrieve the encryption keys. Also, note that LE secure pairing is not fully supported on the nRF51 series.

RE: Static Passkey, using and testing

Ron — Mon, 16 Dec 2019 19:35:57 GMT

Hey

Isn't the passkey (including static passkey) used to protect encryption key exchange as well?

in this thread - Questions about LESC, MITM and passkey it states that "In LESC passkey pairing, the pairing is safe from MITM attacks, as long as the MITM doesn't know the passkey"

I understand that using a static passkey the MITM eventually will guess the correct key, the author there suggest using a password, and says that "(they won't be able to decrypt the data and they will not learn the password)", I did not understand why wouldn't a eavesdropper attacker be able to able to learn this password if it can learn my passkey.

I would appreciate if you would share what to you opinion will be the best way to protect my data given

Thanks again!

RE: Static Passkey, using and testing

Vidar Berg — Mon, 16 Dec 2019 17:33:21 GMT

Hi,

the devices agree on a common encryption key during the pairing/bonding procedure, but that key is not derived or based on the passkey in any way. If you just need encryption you can use the "just works" procedure.

Relevant message sequence charts:

Bonding: Just Works

Bonding: Passkey Entry with static passkey

Edit: it may be helpful to take a look at other forum threads that discuss the security aspects of pairing and bonding. This one for instance: https://devzone.nordicsemi.com/f/nordic-q-a/35856/questions-about-lesc-mitm-and-passkey/138175

RE: Static Passkey, using and testing

Ron — Mon, 16 Dec 2019 17:27:10 GMT

Hey Vidar

you said

[quote userid="4240" url="~/f/nordic-q-a/55422/static-passkey-using-and-testing/224927"]The passkey is not used for encryption, but to protect against man-in-the-middle (MITM) attacks[/quote]

Is implementing encryption conditioned by pairing and bonding? Does that not requiring passing keys earlier? what key does the encryption use? is there an additional key?

Thanks!

RE: Static Passkey, using and testing

Vidar Berg — Mon, 16 Dec 2019 13:36:00 GMT

Hi,

I suggest we continue the discussion in the other thread you posted here: https://devzone.nordicsemi.com/f/nordic-q-a/55668/sd_ble_gap_authenticate-causes-hardfault. When you get a hardfault on a SD call it usually means that you're using the wrong interrupt priority levels.

RE: Static Passkey, using and testing

Ron — Fri, 13 Dec 2019 18:05:03 GMT

Thank you Vidar

So far I have change the GLS to static passkey and connected successfully.

Since than I have tried to migrate that code into a thin version of my existing application and encountered a hardfault after the sd_ble_gap_authenticate command

static ret_code_t link_secure_peripheral(uint16_t conn_handle, ble_gap_sec_params_t * p_sec_params)
{
    // This should never happen for a peripheral.
    NRF_PM_DEBUG_CHECK(p_sec_params != NULL);

    // VERIFY_PARAM_NOT_NULL(p_sec_params);

    ret_code_t err_code = sd_ble_gap_authenticate(conn_handle, p_sec_params);

    return err_code;
}

Have no idea what causes this and how to fix it.

Would appreciate your help on that issue as well

Thanks!

RE: Static Passkey, using and testing

Vidar Berg — Wed, 11 Dec 2019 13:16:25 GMT

I should have pointed out that the glucose app uses a dynamic passkey, not a static one. That is why the BLE_GAP_OPT_PASSKEY isn't used. But the configuration should be similar apart from that.

[quote user="EranR"]I don't have display capabilities or keyboard on the peripheral I am developing for, I am connecting a peripheral to a mobile device (first as I said will try to use nRF Connect).[/quote]

The device must either have a display or a keyboard option to support passkey pairing. The central will not initiate passkey pairing otherwise. But since you're using static passkey the key could be displayed in other ways. It could be printed on a sticker for instance.

[quote user="EranR"]Will a static passkey not ensure encryption for all characteristics?[/quote]

You need to change the security level in your service initialization to limit access to characteristics. Code snippet below show how the gls measurement characteristic is set to require encryption for write access.

static uint32_t glucose_measurement_char_add(ble_gls_t * p_gls)
{
    ble_gatts_char_md_t char_md;
    ble_gatts_attr_md_t cccd_md;
    ble_gatts_attr_t    attr_char_value;
    ble_uuid_t          ble_uuid;
    ble_gatts_attr_md_t attr_md;
    ble_gls_rec_t       initial_gls_rec_value;
    uint8_t             encoded_gls_meas[MAX_GLM_LEN];
    uint8_t             num_recs;
    memset(&cccd_md, 0, sizeof(cccd_md));

    BLE_GAP_CONN_SEC_MODE_SET_OPEN(&cccd_md.read_perm);
    BLE_GAP_CONN_SEC_MODE_SET_ENC_NO_MITM(&cccd_md.write_perm); <---- Notifications can't be enabled unless the link is secured

The passkey is not used for encryption, but to protect against man-in-the-middle (MITM) attacks while performing the pairing procedure. And the MITM protection isn't particularly effective when you use a static key and legacy pairing, unfortunately.

These message sequence charts may help illustrate the different security procedures. It's from the Application's point of view

Peripheral Security Procedures

RE: Static Passkey, using and testing

Ron — Tue, 10 Dec 2019 16:16:30 GMT

Thank you Vidar for your answer

As far as I understood from the code, Glucose Application uses BLE_GAP_OPT_PRIVACY, not BLE_GAP_OPT_PASSKEY, Is that example relevant to using static passkey?

I don't have display capabilities or keyboard on the peripheral I am developing for, I am connecting a peripheral to a mobile device (first as I said will try to use nRF Connect).

Will a static passkey not ensure encryption for all characteristics?

Thanks !

RE: Static Passkey, using and testing

Vidar Berg — Tue, 10 Dec 2019 13:37:25 GMT

Hi,

I suggest that you try with this with the Glucose Application example first, then use that as a reference on what settings to use. SEC_PARAM_MITM must be set to '1' and SEC_PARAM_IO_CAPABILITIES must say you have display capabilities.

Note that these security parameters define the security capabilities of the device and not the security requirements/level which is set individually for each characteristic.