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

[mlyonupdesigns]

I am using SDK v15.3 and would like to modify the peripheral heart rate service example to require the Central to establish mode 1, level 3 security. I am undecided on whether it will be numeric comparison, passkey or OOB, but would like to evaluate each.

If there is another example I could reference to help with the changes to the heart rate service example, please advise.

[Einar Thorsrud]

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?

[mlyonupdesigns]

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?

[Einar Thorsrud]

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

[mlyonupdesigns]

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?

[Einar Thorsrud]

Hi,

mlyonupdesigns said:

I assume there is nothing that precludes repeated discovery if you choose not to implement the "remote_db" functionality.

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

mlyonupdesigns said:

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?

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

mlyonupdesigns said:

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

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.