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]

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

[Niclas Heitz]

Hi Kenneth,

I modified the example to use micro-ecc with the same config we are using and now we get the same error here. I hope this can help identify the problem.

Best regards,

Niclas

ble_app_hrs_modified.7z

[Kenneth]

Hi,

Did you have a chance to try any of the other backends?

Can you confirm you are using the specific micro-ecc library mentioned in the documentation "Install version 4.9-2015-q3-update of the GCC compiler toolchain for ARM."

Kenneth

[Niclas Heitz]

Hi Kenneth,

We tried compiling with 4.9 but it makes no difference.

The hrs example we tried with CC310(default) and micro-ecc worked with CC310 but produced the same DHKeyFailure we encountered when using micro-ecc.

We will try if it is possible for us to change to CC310 in our frmware but would be gratefull if you could still look into the issue with micro-ecc since this worked in previous versions for us.

Thanks and best regards,

Niclas

[Kenneth]

You can also use Oberon as backend, after talking with a collegue he suggested adding the following to preprocessor:

uECC_ENABLE_VLI_API=0
uECC_OPTIMIZATION_LEVEL=3
uECC_SQUARE_FUNC=0
uECC_SUPPORT_COMPRESSED_POINT=0
uECC_VLI_NATIVE_LITTLE_ENDIAN=1

He believes it is related to endieness with micro-ecc.

Kenneth