DHKey Check failed after public key exchange

[Niclas Heitz]

Hello,

after upgrading to SDK15 and using the new crypto functionality I experience some weird behaviour during bonding.

Our SW is the peripheral and I am starting the Bonding by trying to read a protected characterisitc with the nrfConnect App on Android.

After exchanging Public Keys the Master(Android App) aborts with a DHKey Check failed.

This is the code i use to generate the public key

    /* Init nrf_crypto and the RNG */
    err_code = ble_lesc_init();
    APP_ERROR_CHECK(err_code);

    /* Generate the ECDH key pair and set public key in the peer-manager. */
    err_code = ble_lesc_ecc_keypair_generate_and_set();
    APP_ERROR_CHECK(err_code);

On our peripheral i receive BLE_GAP_EVT_LESC_DHKEY_REQUEST and start ble_lesc_service_request_handler().

It correctly calls ble_lesc_dhkey_calculate_and_set() and I can see that sd_ble_gap_lesc_dhkey_reply() returns success.

But then I receive the abort from the peer device.  I am not sure what can go wrong with the public key on the nRFConnect side. I added the procedure and the public keys below.

We are using NRF52840_XXAA with SoftDevice S140 v6.0.0 and SDK 15.0

If you could provide any insight on why this could happen i would greatly appreciate it.

Best regards,

Niclas

[Kenneth]

Hello,

Likely an issue with nRF5 SDK or softdevice.

It should be pretty straight forward to update to nRF5 SDK v15.3 and v6.1.1 softdevice, so I suggest that as a first step. If you still have issues I suggest trying the latest nRF5 SDK v17.1 and v7.3.0. For an overview see here:
https://infocenter.nordicsemi.com/topic/comp_matrix_nrf52840/COMP/nrf52840/nRF52840_ic_rev_sdk_sd_comp_matrix.html 

Kenneth

[Niclas Heitz]

Hello Kenneth,

we updated to v15.3 and v6.1.1 but the error is still the same. Updating to v17.1 is not an option.

As you can see in the sniffer log, the error is happening on the Master side which is nrfConnect App for Android.

According to the Message Sequence Charts in the Infocenter this is what should happen on the Central

We don't even get to the passkey entry so I would assume it rejects the public key.

With 15.3 we now only call nrf_ble_lesc_init() which initializes crypto and rng and generates the public key so i don't see how we could do something wrong there.

Maybe it's something with the sdk_config which in my experience often causes strange behaviour without throwing errors if configured wrong so here are the relevant settings we enabled

#define NRF_BLE_LESC_ENABLED 1
#define PM_LESC_ENABLED 1
#define NRF_CRYPTO_ENABLED 1
#define NRF_CRYPTO_BACKEND_MICRO_ECC_ENABLED 1
#define NRF_CRYPTO_BACKEND_MICRO_ECC_ECC_SECP256R1_ENABLED 1
#define NRF_CRYPTO_BACKEND_NRF_HW_RNG_ENABLED 1
#define NRF_CRYPTO_BACKEND_NRF_HW_RNG_MBEDTLS_CTR_DRBG_ENABLED 1
#define NRF_CRYPTO_RNG_STATIC_MEMORY_BUFFERS_ENABLED 1
#define NRF_CRYPTO_RNG_AUTO_INIT_ENABLED 1

Thanks and best regards,

Niclas

[Kenneth]

Niclas Heitz said:

we updated to v15.3 and v6.1.1 but the error is still the same. Updating to v17.1 is not an option.

Have you tried any of the examples in v15.3 or 17.1 that support LESC out of the box, such as the heart rate sensor for test/comparison? To try to narrow down if there is an issue with the SDK or it's entirely on the peer (phone) side?

Niclas Heitz said:

As you can see in the sniffer log, the error is happening on the Master side which is nrfConnect App for Android.

Can you share the entire sniffer log? The nRF Connect App doesn't handle the bonding procedure, this is fully handled by the OS.

Is the issue you see specific to one Android phone/version, or do you see this with several phone vendors (please share any phones you have tested that fail or success)?

Best regards,
Kenneth

[Niclas Heitz]

Hi Kenneth,

the hrs example from 15.3 works, so I compared it and in the example I can see no init of the lesc module at all, which seems wrong to me. If I remove all init functions for the nrf_ble_lesc module and just call nrf_ble_lesc_request_handler in the main loop like the example i just get the BLE_GAP_SEC_STATUS_AUTH_REQ error instead.

Also the Example usees NRF_CRYPTO_BACKEND_CC310_ENABLED while we use micro ecc

Here is the sniffer log of the original problem. We tested with different Android phones: Google Pixel 2, OnePlus A5010, Samsung S10+. The log is with OnePlus 8 Pro.

Pairing_Bonding_Failure_19_10_2022.cfa

[Kenneth]

It should be possible to use the micro ecc backend by:

(I am using the cmsis configuration wizard here:
https://infocenter.nordicsemi.com/topic/sdk_nrf5_v17.1.0/sdk_config.html#sdk_config_overriding)

The example should support LESC, but since there are no specific services/characteristics in the HRS example that actually require security level, it may be that the peer don't use the highest security level. So you may consider altering services_init() to ensure the SEC_JUST_WORKS.

I think getting this to work first with the default example is valuable to understand the problem.

I will take a look at the sniffer log now.

Edit: I can see that the HRS example in nRF5 SDK v15.3 doesn't handle BLE_GAP_EVT_LESC_DHKEY_REQUEST no, this is however shown in later SDK's. I can find that BLE_GAP_EVT_LESC_DHKEY_REQUEST is handled in the \experimental\ble_app_hrs_nfc_pairing in SDK v15.3. So that one is likely better to look at here. 

Edit2: The sniffer log doesn't show much information other than it fails, so I suggest I suggest to try the \experimental\ble_app_hrs_nfc_pairing example, hopefully comparing with that will reveal the issue.

Edit3: I suggest to use the \experimental\ble_app_hrs_nfc_pairing with the default CC310 backend by default here, only changing to micro ecc when you have verified that work first.

Kenneth