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

[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