SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

RE: SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

Elfving — Thu, 07 Oct 2021 07:24:10 GMT

No problem!

Btw, it seems that the NRF_BLE_LESC_GENERATE_NEW_KEYS snippet also deals with key refreshes in general. A device should change its private key after every pairing, succesful or failed.

Best regards,

Elfving

RE: SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

RenderMonkey — Wed, 06 Oct 2021 14:22:47 GMT

Thank you Elfving!

RE: SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

Elfving — Wed, 06 Oct 2021 11:04:13 GMT

Hello!

Sorry, it seems I was mistaken. The CVE-2020-26558 security fix is being addressed on line 358.

[quote user="RenderMonkey"] Is it for the highly unlikely case when two units attempt to bond and happen to have the same public key?[/quote]

Yeah I think you are right. The ifdef NRF_BLE_LESC_GENERATE_NEW_KEYS snippet is likely there to avoid the scenario where two devices have the same public key. It is optional because an exception is needed for the NFC library (this library generates LESC keys itself after every pairing attempt).

Best regards,

Elfving

RE: SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

RenderMonkey — Tue, 05 Oct 2021 12:41:43 GMT

Hello Elfving,

I have read the release notes and this is why I am asking. Since this setting is optional, I am asking for clarification when it is needed (or rather why it is optional). Is it for the highly unlikely case when two units attempt to bond and happen to have the same public key?

RE: SDK 17.1.0 - NRF_BLE_LESC_GENERATE_NEW_KEYS

Elfving — Tue, 05 Oct 2021 12:28:55 GMT

Hello RenderMonkey,

It is mentioned in the nRF5 SDK release notes. It is a security mitigation mechanism to address a security vulnerability in the Bluetooth Core spec: CVE-2020-26558.

Best regards,

Elfving