nRF51822 Le secure connection

RE: nRF51822 Le secure connection

m-o — Tue, 20 Aug 2019 07:42:12 GMT

Sorry, the above was unnecessary.

The cause has been found.
uECC.c was not working because it was included in the compilation.

Thank you for your cooperation.

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 15 Aug 2019 06:29:39 GMT

No. Why do you ask?

RE: nRF51822 Le secure connection

m-o — Wed, 14 Aug 2019 15:29:32 GMT

Thank you for the test function.

I will check it.

Have you changed thumb_crt0.s?

RE: nRF51822 Le secure connection

Einar Thorsrud — Tue, 13 Aug 2019 11:55:23 GMT

Hi,

I understand (I had a vague understanding that you were using Keil as well, but that was probably just for testing this).

I was not able to test the way you describe since for some reason I did not see the advertisement packets on air. Since you reported that the issue was specifically with the calculation of the shared secret I instead put together a simple test function that verifies the crypto operations needed for LESC, which you can see here (and run yourself by copy-pasting into your code and calling from your main function):

// Test crypto functions needed for LESC. To be used in the ble_app_multirole_lesc example in SDK 12.3.
static void crypto_test(void)
{
    ret_code_t err_code;

    // Own key structures
    __ALIGN(4) static const ble_gap_lesc_p256_sk_t sk =
    {{
        0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
        0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
        0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
        0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11,
    }};
    __ALIGN(4) static ble_gap_lesc_p256_pk_t lesc_pk;    /**< LESC ECC Public Key */
    __ALIGN(4) static ble_gap_lesc_dhkey_t lesc_dhkey;   /**< LESC ECC DH Key */

    static nrf_crypto_key_t own_sk =
    {
        .p_le_data = (uint8_t *) sk.sk,
        .len = sizeof(sk.sk)
    };
    static nrf_crypto_key_t own_pk =
    {
        .p_le_data = (uint8_t *) lesc_pk.pk,
        .len = sizeof(lesc_pk.pk)
    };
    static nrf_crypto_key_t key_dhkey =
    {
        .p_le_data = (uint8_t *) lesc_dhkey.key,
        .len = sizeof(lesc_dhkey.key)
    };

    // Valid own public key
    __ALIGN(4) static const uint8_t valid_own_pk[] =
    {
        0x02, 0x17, 0xE6, 0x17, 0xF0, 0xB6, 0x44, 0x39,
        0x28, 0x27, 0x8F, 0x96, 0x99, 0x9E, 0x69, 0xA2,
        0x3A, 0x4F, 0x2C, 0x15, 0x2B, 0xDF, 0x6D, 0x6C,
        0xDF, 0x66, 0xE5, 0xB8, 0x02, 0x82, 0xD4, 0xED,
        0x19, 0x4A, 0x7D, 0xEB, 0xCB, 0x97, 0x71, 0x2D,
        0x2D, 0xDA, 0x3C, 0xA8, 0x5A, 0xA8, 0x76, 0x5A,
        0x56, 0xF4, 0x5F, 0xC7, 0x58, 0x59, 0x96, 0x52,
        0xF2, 0x89, 0x7C, 0x65, 0x30, 0x6E, 0x57, 0x94,
    };

    // Peer public key structures
    __ALIGN(4) static const uint8_t peer_raw_public_key[] =
    {
        0xA5, 0x62, 0xBD, 0x02, 0x60, 0x88, 0x81, 0x2E,
        0x0A, 0x26, 0xE6, 0xA3, 0x55, 0x0E, 0xFA, 0xC6,
        0x06, 0xE6, 0x91, 0xDE, 0xB5, 0x6F, 0xA2, 0x1B,
        0x19, 0x8F, 0x2E, 0xFD, 0x0B, 0xD5, 0xCB, 0x25,
        0x9B, 0x4A, 0x96, 0x09, 0x12, 0xFD, 0x30, 0xD8,
        0x79, 0xA4, 0x52, 0x47, 0xF8, 0x05, 0x08, 0xE1,
        0x33, 0x3C, 0xA2, 0x5A, 0x4B, 0x83, 0x26, 0x23,
        0x3A, 0xE8, 0x26, 0x82, 0x46, 0x5A, 0x21, 0xCD,
    };

    static nrf_crypto_key_t peer_pk =
    {
        .p_le_data = (uint8_t *) peer_raw_public_key,
        .len = sizeof(peer_raw_public_key)
    };

    // Compare shared secret with valid shared secret
        __ALIGN(4) static const uint8_t valid_shared_secret[] =
    {
        0x6C, 0x21, 0xB1, 0xAB, 0xCF, 0x65, 0xFC, 0xB7,
        0x50, 0x48, 0xF2, 0x1B, 0x43, 0xA5, 0x31, 0x22,
        0xF8, 0x13, 0x65, 0x17, 0x02, 0x71, 0x5E, 0xBE,
        0xD2, 0x77, 0xFD, 0xB8, 0xA2, 0x4C, 0x5E, 0x73,
    };

    // -------------------------------- Begin test --------------------------------

    NRF_LOG_INFO("Test crypto operations used for LESC...\r\n");

    // Calculate own public key (not really needed in this test since we will not pass to a peer in
    // this test) but it is done to verify that it works since it is used in the real LESC procedure.
    nrf_crypto_init();
    err_code = nrf_crypto_public_key_compute(NRF_CRYPTO_CURVE_SECP256R1, &own_sk, &own_pk);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_INFO("Calculated public key:\r\n");
    NRF_LOG_HEXDUMP_INFO(own_pk.p_le_data, own_pk.len);

    // Compare with valid public key
    if (memcmp(own_pk.p_le_data, valid_own_pk, 64) == 0)
    {
        NRF_LOG_INFO("Calculated public key is correct.\r\n");
    }
    else
    {
        NRF_LOG_ERROR("Fail: Calculated public key is INCORRECT!\r\n");
    }

    // Calculate shared secret
    err_code = nrf_crypto_shared_secret_compute(NRF_CRYPTO_CURVE_SECP256R1, &own_sk, &peer_pk, &key_dhkey);
    APP_ERROR_CHECK(err_code);

    NRF_LOG_INFO("Calculated shared secret:\r\n");
    NRF_LOG_HEXDUMP_INFO(key_dhkey.p_le_data, key_dhkey.len);

    // Compare with valid shared secret
    if (memcmp(key_dhkey.p_le_data, valid_shared_secret, 32) == 0)
    {
        NRF_LOG_INFO("Calculated shared secret is correct.\r\n");
    }
    else
    {
        NRF_LOG_ERROR("Fail: Calculated shared secret is INCORRECT!\r\n");
    }
}

Interestingly this test passes in your SES project, so there does not seem to be any problems with mciro-ecc. I don't know why LESC files when you test, nor do I know why I don't even see the advertisement packets on air on my side. Everything else looks OK to me. So it is a bit of a mystery for now.

RE: nRF51822 Le secure connection

m-o — Mon, 12 Aug 2019 21:44:35 GMT

Thank you for the survey.

Since development has ended,I cannot be changed to KEIL.

Has the symptom reproduced?

RE: nRF51822 Le secure connection

Einar Thorsrud — Mon, 12 Aug 2019 13:09:31 GMT

Hi,

I have been looking into this, but I do not yet understand what is going on. Is it OK for you to keep using Keil in the meantime?

RE: nRF51822 Le secure connection

m-o — Fri, 09 Aug 2019 09:00:28 GMT

thank you for your answer.

For my test, connect the board of DK (bRF52832) and nRF51822 according to the following procedure.

1. Connect DK to PC

2. Start "nRF Connect for Desk top" and select DK.

3. Write the firmware to the nRF51822 board.

4. Connect nRF51822 board (peripheral) and DK (central).

5. Pair using LESC.
→ DHKEY error occurs

RE: nRF51822 Le secure connection

Einar Thorsrud — Fri, 09 Aug 2019 07:39:51 GMT

Hi,

I see. I tested with SES and then it seems to run. What is the test procedure (how do I get the DK to connect to something)?

RE: nRF51822 Le secure connection

m-o — Thu, 08 Aug 2019 15:00:08 GMT

No, I don't want to know general transplantation methods.

Confirmed that uploaded project is connected with peripheral

What I want to know is that reason DHKEY errors do not occur in IAR and DHKEY errors occur in SES.

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 08 Aug 2019 13:14:55 GMT

Hi,

I just tested briefly, and the SES project seems to have other issues as well (I don't see the two LED's lit, which I do with your Keil project). Do you have a SES project that was working except for the LESC DHkey calculation, or is this question more about porting a SDK 12.3 Keil project to SES in general?

RE: nRF51822 Le secure connection

m-o — Thu, 08 Aug 2019 10:46:17 GMT

Thank you for checking everything

A complete project has been uploaded.

devzone.nordicsemi.com/.../nRF5_5F00_SDK_5F00_12.3.0_5F00_d7731ad_5F00_2.zip

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 08 Aug 2019 10:21:02 GMT

Can you upload the complete project with everything together so that I can build and test on my side? Please package everything together so that I can test out of the box.

RE: nRF51822 Le secure connection

m-o — Thu, 08 Aug 2019 09:53:15 GMT

There is no warning.

Do you have the necessary information and files?

Upload the created library file.
Is there a difference there?

devzone.nordicsemi.com/.../2630.micro_5F00_ecc_5F00_lib_5F00_nrf51.a

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 08 Aug 2019 09:28:08 GMT

I see. Not even warnings during linking? It is odd that the library just fails silently...

RE: nRF51822 Le secure connection

m-o — Thu, 08 Aug 2019 09:25:12 GMT

I'm sorry, it seems that the writing was not good.

No error occurred in the build.
What is occurring is a DHKEY error.

I wanted to check if it was necessary to change the compile options to improve the DHKEY error.

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 08 Aug 2019 09:12:32 GMT

What exactly does the error message(s) you get when you build the project say?

RE: nRF51822 Le secure connection

m-o — Thu, 08 Aug 2019 09:03:58 GMT

thank you for your answer.

I changed to the armgcc library, but the symptom did not change.
Is there any need to change the SES project file and library makefile?

RE: nRF51822 Le secure connection

Einar Thorsrud — Thu, 08 Aug 2019 06:30:27 GMT

Hi,

[quote user="m-okabe"]Which folder should I use for the library used in Segger Embedded studio?[/quote]

You should use the library file which you can build under <SDK>\external\micro-ecc\nrf51_armgcc, since SES uses GCC as the compiler.

[quote user="m-okabe"]Is there anything strange about the uploaded project file?[/quote]

There is at least a problem that you use the wrong library file for micro-ecc. I see that you use /external/micro-ecc/nrf51_keil/armgcc/micro_ecc_lib_nrf51.lib, which is not suitable with GCC. There might be other problems that I have not spotted as well.

RE: nRF51822 Le secure connection

m-o — Wed, 07 Aug 2019 02:51:18 GMT

Thank you for your reply.
I was able to approach the solution.

I checked the operation of “ble_app_multirole_lesc” with IAR and it worked.

Segger Embedded studio does not work.

Which folder should I use for the library used in Segger Embedded studio?

Is there anything strange about the uploaded project file?

devzone.nordicsemi.com/.../flash_5F00_placement.zip

RE: nRF51822 Le secure connection

Einar Thorsrud — Tue, 06 Aug 2019 10:38:47 GMT

Hi,

[quote user="m-okabe"]ecc was compiled with cygwin's gcc.[/quote]

You must use a cross-compiler that compiles the code for ARM. I suggest you download and install GNU Tools ARM Embedded 4.9 2015q3, as that is the toolchain that was tested with SDK 12.3. Then set the correct path in <SDK>components\toolchain\gcc\Makefile.windows and build the micro-ecc library which you use by simply calling "make" in the correct folder for your toolchain under <SDK>\external\micro-ecc\.

[quote user="m-okabe"]Compiler: Segger Embedded studio v3.34a[/quote]

SES was not supported in 12.3, and while it is possible to use it requires a bit of tweaking, so it could also be related. If you still have problems after building micro-ecc properly, I suggest you try to build with another toolchain (for instance Make with arm gcc) and check if you get the same behavior. The SDK provides a Makefile for the multirole LESC example project that works out of the box (<SDK>examples\ble_central_and_peripheral\experimental\ble_app_multirole_lesc\pca10028\s130\armgcc\Makefile).

RE: nRF51822 Le secure connection

m-o — Tue, 06 Aug 2019 10:05:33 GMT

thank you for your answer.

Even if "ble_app_multirole_lesc" that does not change the BLE processing is used, a DHKEY error occurred.

Is there a problem with the development environment and tool settings?

【Development environment】
Compiler: Segger Embedded studio v3.34a
* KEIL project has been changed.
The project file could not be uploaded
ecc was compiled with cygwin's gcc.

devzone.nordicsemi.com/.../528486.main.c

devzone.nordicsemi.com/.../4520.micro_5F00_ecc_5F00_lib_5F00_nrf51.lib

RE: nRF51822 Le secure connection

Einar Thorsrud — Tue, 06 Aug 2019 09:09:54 GMT

Hi,

From the sniffer trace, I see that Authentication stage 1 commences as expected, but authentication stage 2 (DHKey checks) fails. This indicates that there was a problem with the DHKey calculation, and therefore both peers do not have the same key.

Your configuration (of m_sec_params) is identical with the unmodified multirole example, except that you use to display only for IO capabilities. I tested this on my side now, using nRF Connect on a PC and it works as expected.

What other modifications have you done to the example? Have you done any changes to the handling of the BLE_GAP_EVT_LESC_DHKEY_REQUEST event, where the key (shared secret) is calculated? Can you test again using an unmodified example, where the only modification is the io capabilities?

RE: nRF51822 Le secure connection

m-o — Mon, 05 Aug 2019 09:11:04 GMT

thank you for your answer.

Only the connection between modules is confirmed before modifying.
It worked correctly.

The same DHKEY error occurs in SDK 12.3 "ble_app_multirole_lesc".

The evaluation method is connected with LES (module: display only , PC: keybord).

Sorry, the code can not be disclosed.
Describes the setting value and sniffer data.
Please let us know if you have other necessary information.

[Setting value]
m_sec_params.bond = true;
m_sec_params.mitm = true;
m_sec_params.lesc = true;
m_sec_params.keypress = false;
m_sec_params.io_caps = m_io_capabilities;
m_sec_params.oob = false;
m_sec_params.min_key_size = 7;
m_sec_params.max_key_size = 16;
m_sec_params.kdist_own.enc = 1;
m_sec_params.kdist_own.id = 1;
m_sec_params.kdist_peer.enc = 1;
m_sec_params.kdist_peer.id = 1;

err_code = pm_sec_params_set (& m_sec_params);
APP_ERROR_CHECK (err_code);

【Sniffer data】

devzone.nordicsemi.com/.../4111.ble_5F00_app_5F00_multirole_5F00_lesc.pcapng

RE: nRF51822 Le secure connection

Einar Thorsrud — Mon, 05 Aug 2019 08:37:00 GMT

Hi,

The post that you link to describes how to adapt the LESC implementation in SDK 15.3 to fix the security issue that was closed in the Erratum 10734 of the BLE spec. The code changes shown in the post describes what you need to change from the Experimental: BLE LE Secure Connections multirole example, and this is verified to be functional.

Did your LESC implementation work before you started to modify it according to the post, or did it never work? If not, I suggest you first try to implement LESC in the same way as is done in the SDK example and only modify it further once it is working. The modification itself is straight-forward (just copy-paste as described in the post), but it is better to do one step at a time.

If you still need assistance after that, please elaborate on what you have done, (show your code, describe how you have tested and how it behaves, etc.).