Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Thu, 01 Jun 2023 17:24:03 GMT

You can disregard the last question...I have figured out the issue.

You can consider this question closed.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Thu, 01 Jun 2023 16:32:35 GMT

I have everything working now...thanks for the assistance.

I am running into an issue whenever an initial bonding operation occurs unrelated to the central connection with the heart rate service peripheral. My implementation also supports a single peripheral connection which is interacts with the central connection in the following way:

1. Peripheral advertising is enabled by default

a. Initiating advertising first sets the Tx power (sd_ble_gap_tx_power_set), updates the advertising message (sd_ble_gap_adv_set_configure) and finally starts the advertising (ble_advertising_start)

2. Upon starting to scan for heart rate service peripherals, the peripheral advertising is stopped (sd_ble_gap_adv_stop)

3. After connecting, bonding and enabling the heart rate service notification, the peripheral advertising is enabled again.

The above sequence worked perfectly prior to adding the bonding functionality. It works when connecting to an already bonded heart rate peripheral. However, it now fails reliably after step 3 above as follows:

...when calling sd_ble_gap_adv_set_configure() it returns NRF_ERROR_INVALID_STATE (see code snippet below). It doesn't matter whether the third parameter is NULL or not. I have confirmed that advertising is definitely being stopped and that I am calling the below function once prior to re-starting adverstising.

ble_gap_adv_data_t adv_data;
memcpy(&adv_data, p_profile->padvertising->p_adv_data, sizeof(ble_gap_adv_data_t));
if (p_profile->padvertising->adv_mode_current == BLE_ADV_MODE_IDLE)
{
result = sd_ble_gap_adv_set_configure(&p_profile->padvertising->adv_handle, &adv_data, &p_profile->padvertising->adv_params);
if (result != NRF_SUCCESS)
asm("nop");
}
else
{
result = sd_ble_gap_adv_set_configure(&p_profile->padvertising->adv_handle, &adv_data, NULL);
if (result != NRF_SUCCESS)
asm("nop");
}

I am willing to create a separate support question if that is desired.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Wed, 31 May 2023 08:00:50 GMT

No, it is not like that. If the central initiate pairing/bonding of the link, and the peripheral already have a bond with this central, you will get the PM_EVT_CONN_SEC_CONFIG_REQ event on the peripheral side. If you allow re-pairing by calling pm_conn_sec_config_reply() as shown in the mentioned post, a new pairing procedure will start. If not, the peripheral will send LL_REJECT_IND. If the device that initiated bonding (central in this case) is an nRF, you will get a PM_EVT_CONN_SEC_FAILED event at this point (when it has received the LL_REJECT_IND).

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Tue, 30 May 2023 15:04:55 GMT

As described in the "post" you cite...will the LL_REJECT_IND sent by the peripheral trigger the PM_EVT_CONN_SEC_CONFIG_REQ, or more specifically, how is the central informed the the LL_REJECT_IND has been sent (this is received by the soft device, but I don't see how it bubbles up)?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Tue, 30 May 2023 14:58:36 GMT

Hi,

Sorry, forgot the context over the weekend. The default behavior of the nRF5 SDK as well is to reject re-pairing attempts for the reasons I explained in my previous points. You can allow re-pairing on that device too though, by doing as described in this post.

[quote user="mlyonupdesigns"]What can I do from the central side if I have lost the bonding information but the peripheral has not? I'm just trying to understand what the spec says should occur in these instances.[/quote]

The spec does not describe how this should be handled, it is up to the product designer. Generally, it is not a good idea to allow re-pairing. But for many small embedded devices it is needed. In the case you describe here, where the bonding information is lost on the central, the only way to recover is if the peripheral either has some mechanism to delete bonding data (for instance with a button press or similar), or if you allow re-pairing. It is commonly done, but as it is a potential security issue, it is prohibited by default in both the nRF5 SDK and nRF Connect SDK.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Tue, 30 May 2023 14:09:36 GMT

The BT_SMP_ALLOW_UNAUTH_OVERWRITE doesn't pertain to SDK 15.3 I don't believe (at least I don't see any reference to that type of functionality).

Specifically, I purposely deleted the bonding information from the peripheral to see the behavior so I'm trying to understand what the correct procedure is for forcing a re-bonding if either the central or peripheral loses the non-volatile storage holding the bonding information. Obviously, in our app on the central side I can delete the peer information (e.g., pm_peers_delete) which should force a re-bonding. What can I do from the central side if I have lost the bonding information but the peripheral has not? I'm just trying to understand what the spec says should occur in these instances.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Tue, 30 May 2023 13:47:19 GMT

The default behavior is to reject pairing attempts from peers where there already exists a bond. This is for security reasons, as if you allow that, it means that an attacker can spoof the address of the peer you are bonded with, and replace that bond. It is however possible to allow re-pairing by BT_SMP_ALLOW_UNAUTH_OVERWRITE if you want to. Sometimes this may be required from a usability perspective, but it is important to be aware of the security implications.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Emil Lenngren — Sat, 27 May 2023 08:22:18 GMT

Why not require mode 1 level 4 instead? The difference to level 3 is that level 4 requires LE Secure Connections, which is much more secure than Legacy Pairing.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Fri, 26 May 2023 15:28:19 GMT

I did have a follow up question related to central and peripheral bonding data becoming of "lost". If the central has it's bonding information, but the peripheral no longer does.

From my BT capture I see that the central sends a LL_ENC_REQ and the peripheral responds with LL_ENC_RSP (which must have something in it that doesn't match. The peripheral then responds with LL_REJECT_IND. I don't see this handled in the SDK and wonder what is the correct action?

Similarly, if the central no longer has the bonding information, but the peripheral does what is the expected behavior?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Fri, 26 May 2023 15:02:44 GMT

Once I fixed the behavior of the ble_app_hrs example so it doesn't start the application timers (application_timers_start) at start-up, but rather waits for BLE_GAP_EVT_AUTH_STATUS event on the initial bonding or NRF_BLE_GATT_EVT_ATT_MTU_UPDATED event on reconnection, then all worked as expected.

Also stopping the application timers on a disconnect was necessary so that repeated connect/disconnect operations would work.

So I think I'm all set. Thanks for your attention.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Fri, 26 May 2023 12:48:50 GMT

Can you share code also? Regarding the more data bit in the last screenshot from the previous post I am not able to see much from the screenshot. Can you upload the actual trace file? Generally though, if there are empty packets with MD set, that seems odd.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Fri, 26 May 2023 12:24:21 GMT

Here are two example logs (and call stack screen shots) from the peripheral.

devzone.nordicsemi.com/.../ble_5F00_app_5F00_hrs_5F00_1.log devzone.nordicsemi.com/.../ble_5F00_app_5F00_hrs_5F00_2.log

The error being returned from heart_rate_meas_timeout_handler() is NRF_ERROR_FORBIDDEN.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Fri, 26 May 2023 11:35:31 GMT

The third screen shot (which I added after the original reply) shows the initial bonding capture. The first screen shot is nRF connect and the second screen shot is my application.

Can you comment on the "More Data" flag being set in the second screen shot?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Fri, 26 May 2023 10:59:36 GMT

Hi,

I see from the second screenshot that the central is re transmitting the LL_ENC_REQ packet, so it seems that something happened to the peripheral when you are using your central and not nRF Connect. Do you have logs from the peripheral that can tell us what happened there?

Other than that, the peripheral sent the LL_LENGTH_REQ right before the central sent LL_ENC_REQ, but that should be OK. There are few limitations on the order of procedures other than that only one procedure can be initiated from each side at a single time, and as I see LL_ENC_REQ here right away, so a bond already exist. A feature exchange is normally needed for using any feature that is not mandatory, but up to this point the only non-mandatory feature is encrypting the link, but if a bond already existed that should be no problem. Do you have a sniffer trace from the first connection when the bond was established? (Or if this is the first connection, then there is something fundamentally wrong with the handling of the security as the central at least acts as if it has an existing bond).

I am not able to say much more based on these screenshots. Can you share logs from both the peripheral and central side, and your central implementation?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Thu, 25 May 2023 14:07:33 GMT

OK....thanks.

This is the BT capture when I used nRF Connect (Android) to first bond to ble_app_hrs app (with mode 1, level 2 security required for the measurement data) and then reconnect after bonding.

and this is my application (instead of nRF Connect) trying to reconnect to the ble_app_hrs app...obviously I have something wrong in my app, but not sure what. Any ideas?

I note that there is no "feature exchange" from my app...is this necessary?

Also, the "More Data" flag is set in the example from my app (see Empty PDUs) which looks incorrect and may be keeping the peripheral from behaving properly. After 6 seconds the peripherals disconnects and begins advertising again.

Above is the initial bonding capture

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Thu, 25 May 2023 13:54:38 GMT

Hi,

[quote user="mlyonupdesigns"]I assume there is nothing that precludes repeated discovery if you choose not to implement the "remote_db" functionality.[/quote]

No, that is right. If you don't store the remote database, you have to do discovery every time.

[quote user="mlyonupdesigns"]If repeated discovery is used, is the link encrypted first before discovery or is discovery in the clear and when encryption is enabled doesn't matter?[/quote]

It should not matter if you do service discovery before or after the link is encrypted.

[quote user="mlyonupdesigns"]Also, is there a peripheral example that supports mode 1, level 2 security (no MITM) out-of-the-box...preferably heart rate?[/quote]

Not out of the box, but you only need to change the security level for the parameter(s) you don't want to be accessible without mode 1 level 2 or higher, as I suggested in my initial post.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Thu, 25 May 2023 12:18:08 GMT

I assume there is nothing that precludes repeated discovery if you choose not to implement the "remote_db" functionality. If repeated discovery is used, is the link encrypted first before discovery or is discovery in the clear and when encryption is enabled doesn't matter?

Also, is there a peripheral example that supports mode 1, level 2 security (no MITM) out-of-the-box...preferably heart rate?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Thu, 25 May 2023 12:00:24 GMT

Regarding database caching, that is supported in the SDK, and makes it so that repeated discovery is not needed. There are two examples in the SDK that demonstrate it: Apple Notification Center Service (ANCS) Client Application and GATT Service Client Example Application. Search for "remote_db" in the main.c to see most of the relevant code. (These happen to be peripheral and not centrals, but they key point here is that they are GATT clients).

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Thu, 25 May 2023 11:50:56 GMT

I will investigate further and come back to you.

I was also curious whether the bonding operation also stores the discovered services/characteristics for the peer? If so, does this mean repeated discovery is not necessary? Can you reference which sdk element manages storing and retrieving the discovery results?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Thu, 25 May 2023 10:53:49 GMT

Hi,

I see. I am not able to find any other reasons for getting NRF_ERROR_INVALID_STATE in this case (other than there not being any pending request or the connection handle not being for an active connection). Can you double check that this is the error you get, and that it is from sd_ble_gatts_exchange_mtu_reply? And which event to you get before calling it? (I am not sure, as the sniffer trace screenshot also shows a LL_LENGTH_REQ, which is not the same as a GATT length update, and for that you reply with sd_ble_gap_data_length_update() - perhaps that is mixed up somehow in your code)?

There is no obvious link between this and encrypting the link though, and even though I see in the sniffer trace that the link is about to be encrypted, this could happen in parallel (the main limitation is that there can only be one LL procedure initiated by each side at a single time, but at least form the screenshot that does not seem to be a problem). Does it help if you delay encrypting the link, just as a test? If not, perhaps you can share your code, and/or elaborate on which changes you did when this issues was introduced?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Wed, 24 May 2023 12:44:58 GMT

I am using my central app for this development (not a Nordic example). This app has been used reliably for connecting to unsecure heart rate services for years. I am now attempting to introduce security for certain devices that now require it.

I have confirmed that there is no conflict from multiple attempts to reply to the MTU request. You can see an image of the call stack on the nRF52832 below where the nrf_ble_gatt_on_ble_evt handler is processing the request.

I have also included a snippet of a BT capture showing the behavior. No replay ever appears on the link.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Wed, 24 May 2023 10:49:35 GMT

Hi,

The BLE Heart Rate Collector Example supports bonding out of the box (but without MITM), so you can refer to that. You can refer to the message sequence charts in the SoftDevice specifications to see the detailed sequence diagrams for bonding on the peripheral and central side.

Regarding the error you get on the central I do not know which example you have based this on (as the hart rate collector already supports bonding) and what changes you have done, but generally you will get NRF_ERROR_INVALID_STATE returned from sd_ble_gatts_exchange_mtu_reply() if either the connection handle is invalid, or if there is no pending ATT_MTU request. Have you added code for handling this request in your application? If so, it could be that there is a conflict if, as this is normally hanled by the GATT module if that is used (components/ble/nrf_ble_gatt/nrf_ble_gatt.c). If you also handle the request in in your application, that would mean two calls to sd_ble_gatts_exchange_mtu_reply() for a single request, which is not valid.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

mlyonupdesigns — Tue, 23 May 2023 19:32:43 GMT

I found the hrm_ccd_wr_sec setting and changed it to SEC_JUST_WORKS as a start. This resulted in an "Insuffcient Authentication" error when the Central attempted to enable the characteristic notification.

I then enabled the peer manager functionality in the Central to manage the bonding process. That all worked as expected. I am now struggling with the reconnection after both Central and Peripheral have stored the bonding information. I can see that the Central successfully reaches the sd_ble_gap_encrypt() function; however, the peripheral is sending an ATTMTU request prior to the Central enabling encryption and the Central attempts to reply but receives an NRF_ERROR_INVALID_STATE error in response to sd_ble_gatts_exchange_mtu_reply().

I haven't changed any of the Central logic which was in place prior to supporting security, so typically the nrf_ble_gatt_on_ble_evt() would handle the ATT requests/responses and my application event handler would just start service discovery on the CONNECT event. I suspect this has to change somehow.

Can you point me to a sequence diagram that demonstrates a reconnection between bonded Central and Peripheral (and an example)?

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Einar Thorsrud — Mon, 22 May 2023 13:19:59 GMT

Hi,

In Bluetooth, the security level is set per characteristic. Referring to the Heart Rate example in nRF5 SDK 15.3, you can see that the security level of the heart rate characteristics is set in services_init():

    // Here the sec level for the Heart Rate Service can be changed/increased.
    hrs_init.hrm_cccd_wr_sec = SEC_OPEN;
    hrs_init.bsl_rd_sec      = SEC_OPEN;

If you want to use level 3, change this to SEC_MITM intend of SEC_OPEN. With this, security level 3 is required in order to access the specific characteristics. Note that the mode essentially means that MITM or OOB is used, so you do not need to do other changes in this part regardless of if you are using numeric comparison, passkey or OOB.

The second part is to expand the example to use the MITM protection method you want to use/test. For that, you can refer to other examples and copy-past in relevant parts. For instance, ble_app_gls use passkey (with the nRF being the display), printing the passkey over UART. Which MITM method that works is depending on the I/O capabilities of your product. If it has both a keyboard and a display, you can use numeric comparison (only with LE secure connections and provided the peer also supports it). If it has a keyboard or a display, it can use passkey, provided the peer has the opposite (or both). For OOB you would typically need something application specific.

RE: Creating a Heart Rate Service Peripheral Example Application That Requires Mode 1 Level 3 Security

Edvin — Fri, 19 May 2023 12:22:36 GMT

Hello,
I am sorry, but we are short staffed this week due to Public Holidays in Norway. We will be back on Monday 22nd and hope to be able to answer all incoming requests within a couple of days, depending on the backlog. I am sorry for the inconvenience.

Best regards,
Edvin