BLE bonding

RE: BLE bonding

Einar Thorsrud — Sun, 15 Mar 2020 10:27:26 GMT

The IRK is Identity Resolving Key, which gives a hint. When a device using a resolvable address changes the address, that is derived from the IRK. And it is also possible to do the reverse: check an address to see if it has been derived from a specific IRK, which is done by the peer that has the IRK after bonding. The exact details of how the resolution works is black magic to me (cryptography), but there is no need to understand the math in order to use it.

RE: BLE bonding

Roei — Fri, 13 Mar 2020 20:52:23 GMT

Thanks, you helped me a lot!

I still don't understand how exactly the IRK works. Can you give me an example, how the first peer can recognize the second peer, using IRK, after the second one changed it's address?

RE: BLE bonding

Einar Thorsrud — Wed, 26 Feb 2020 14:21:31 GMT

Hi,

The device identities list is a list of device IRK's (Identity resolution keys). So that is needed for whitelisting peers that use privacy (which include any modern phone). Whitelisting static MAC addresses only work with devices that do not use privacy. Therefore, you will need code for both to handle both cases, like it is done in the SDK examples.

RE: BLE bonding

Roei — Wed, 26 Feb 2020 13:19:49 GMT

Thanks a lot!

One more question -

I'm still confused about the difference between pm_whitelist_set and pm_device_identities_list_set. Can you please explain what does each of them do?

RE: BLE bonding

Einar Thorsrud — Wed, 26 Feb 2020 13:06:45 GMT

Hi,

I see. You could start advertising normally, and then restart, or slightly adjust the advertising module.

The resone calling ble_advertising_restart_without_whitelistadvertising() did not work is that the module only supports restarting advertising in the same mode, and when advertising is not active the mode is IDLE. If you want to start advertising without whitelist you could expand the library with a ble_advertising_start_without_whitelist() function like this:

uint32_t ble_advertising_start_without_whitelist(ble_advertising_t * const p_advertising,
                                                 ble_adv_mode_t            advertising_mode)
{
    ret_code_t ret;

    p_advertising->whitelist_temporarily_disabled = true;
    p_advertising->whitelist_in_use               = false;
    p_advertising->adv_params.filter_policy       = BLE_GAP_ADV_FP_ANY;
    // Set correct flags.
    ret = flags_set(p_advertising, BLE_GAP_ADV_FLAGS_LE_ONLY_GENERAL_DISC_MODE);
    VERIFY_SUCCESS(ret);

    ret = ble_advertising_start(p_advertising, advertising_mode);
    if ((ret != NRF_SUCCESS) && (p_advertising->error_handler != NULL))
    {
        p_advertising->error_handler(ret);
    }

    return NRF_SUCCESS;
}

The only difference from the restart variant is that it does not stop advertising, and it uses the specified mode instead of the current mode. Calling this function instead of ble_advertising_start() will do the trick.

RE: BLE bonding

Roei — Tue, 25 Feb 2020 13:22:05 GMT

OK, the problem is that the current advertising mode is Idle, and I need to set it to Fast before I restart advertising without whitelist. Or should I do another thing?

Thanks!

RE: BLE bonding

Roei — Tue, 25 Feb 2020 13:00:38 GMT

Yes, I used the example and I test it with my mobile, I can see when I connect or disconnect clearly, and I tested it with more mobiles to validate the whitelist. It was all good, but I need the option to start reqular advertising as well.

I get the idle event right after starting advertising (in the same ms).

RE: BLE bonding

Roei — Tue, 25 Feb 2020 12:40:41 GMT

I will explain again.

I want my application to start advertising with whitelist in some cases, and without whitelist in others.

How can I do that without starting advertising and restart again?

RE: BLE bonding

Einar Thorsrud — Tue, 25 Feb 2020 12:40:23 GMT

Hi,

Please elaborate much more.

Are you using an example?
Which exact changes have you done from the example (preferably show a diff or similar)?
How do you test?
How long time does it take from the call to ble_advertising_restart_without_whitelist() until you get the BLE_ADV_EVT_IDLE?

RE: BLE bonding

Roei — Tue, 25 Feb 2020 12:30:33 GMT

Hi,

I set ble_adv_whitelist_enabled = true when initialized my module.

After that, I just operated ble_advertising_restart_without_whitelist(), and the result was BLE_ADV_EVT_IDLE.

RE: BLE bonding

Einar Thorsrud — Tue, 25 Feb 2020 12:22:04 GMT

Hi,

This works out of the box with the unmodified Current Time Application, and it is not clear to me what you have done. Why do you change whitelist_temporarily_disabled? That is only intended to be used by the module itself, it is not something you should modify.

RE: BLE bonding

Roei — Tue, 25 Feb 2020 11:53:10 GMT

Hi,

ble_advertising_restart_without_whitelist() doesn't work, it cause BLE_ADV_EVT_IDLE event, instead of BLE_ADV_EVT_FAST. Only when I set whitelist_temporarily_disabled = false, it works.

Thanks!

RE: BLE bonding

Einar Thorsrud — Tue, 25 Feb 2020 11:32:54 GMT

Hi,

The advertising module handles this for you, If you refer to the Current Time Application, you can see that it calls ble_advertising_restart_without_whitelist() in a few places, particularly when there is a BSP_EVENT_WHITELIST_OFF event. So basically all you have to do is call this function if you want any central to be allowed to connect.

RE: BLE bonding

Roei — Tue, 25 Feb 2020 09:53:41 GMT

OK, thanks, you helped me a lot!

Just one more question regarding whitelisting -

When I don't want to advertise with whitelist, I just don't use pm_whitelist_set and pm_device_identities_list_set functions. Is that the right way? Or should I set a disabled flag to be sure that the advertising will be clean from whitelist?

RE: BLE bonding

Einar Thorsrud — Tue, 25 Feb 2020 08:40:32 GMT

Hi,

[quote user="Roei"]I will be more specific. My use case is that I want to connect and bond my NRF device with my mobile. After turning off and on the device and mobile, I want them to connect again.[/quote]

That makes sense.

[quote user="Roei"]Until now, I did it with direct advertising. I saved the mobile's address after bonding when they first connected, so I will use it for direct advertising when my NRF device is turned on again.[/quote]

You should not use directed advertising against mobile phones. Apple explicitly states that it should not be used. Since you use directed advertising I assume you only want the bonded pone to be allowed to connect. The normal way of achieving this is by using whitelisting. With that concept, you will advertise normally, but connections from non-whitelisted devices will be ignored. You can refer to for instance the Current Time Application to see an example of whitelisting.

[quote user="Roei"]The problem is that my mobile changes it's address. I read some articles about that privacy feature. Do you know that?[/quote]

All modern smartphones changes address regularly to avoid being tracked. This is done by deriving the MAC address form an identity resolving key (IRK), and the address is then called a Resolvable Private Address (RPA). As long as you have bonded your peripheral device also has this IRK and can use it for whitelisting. This is all implemented for you in the nRF5 SDK (and in HW which does the address resolution for you), so you do not need to think much about it other than knowing the concepts.

[quote user="Roei"]What can I do about that? How can I reconnect to a mobile which changed it's address?[/quote]

Use bonding and whitelisting as I have suggested above.

I notice that all of these questions are general BLE questions, so it might be worth spending some hours reading up on BLE before proceeding. I suspect that could save you some work in the long run. If you like to get such information from books, then I could recomend Getting Started with Bluetooth Low Energy. It does not cover all the recent additions to the Bluetooth specification, but all the basics are explained in a good and simple way.

RE: BLE bonding

Roei — Tue, 25 Feb 2020 08:26:53 GMT

Thanks for your answer!

I will be more specific. My use case is that I want to connect and bond my NRF device with my mobile. After turning off and on the device and mobile, I want them to connect again.

Until now, I did it with direct advertising. I saved the mobile's address after bonding when they first connected, so I will use it for direct advertising when my NRF device is turned on again.

The problem is that my mobile changes it's address. I read some articles about that privacy feature. Do you know that?

What can I do about that? How can I reconnect to a mobile which changed it's address?

Thanks!

RE: BLE bonding

Einar Thorsrud — Tue, 25 Feb 2020 08:04:09 GMT

Hi,

[quote user=""]As far as I understand, every connection establishment has to start with advertising.[/quote]

Yes, that is correct. This is a key concept of the BLE protocol. The peripheral advertises regularly, and in case of connected advertising, it will switch the radio to Rx and listen for connection requests from a central in a short window after transmitting the advertising packet. This is how BLE connections are established.

[quote user=""][/quote]

Event if I have already connected and bonded to a peer, after disconnection I have to start advertising in order to connect to this peer again.

Am I right?

Yes pairing and bonding is independent of the connection mechanism.

[quote user=""]In that case - what is the meaning of bonding here? Shouldn't the peers connect automatically again without advertising/direct advertising?[/quote]

No, that would not be possible. When the peripheral is not advertising or in a connection it is typically in sleep, with the radio completely turned off. So there would be no way to connect to it. Pairing is a completely different concept, which is how devices exchange encryption keys (used both for encrypting the link and optionally randomizing the address to that it cannot be tracked even though it advertises). Bonding is the same thing, the only difference is that when bonding, the peers agree to store the keys to be used for later.

[quote user=""]Do I have another option?[/quote]

Not really. Dependign on your use case you may not need to bond, but there is no way around advertising to initiate a connection, regardless of if bonded or not.