Generating and using secure DFU keys under Linux

[Visti Andresen]

Hi

I'm wondering if anyone have had any success or problems with generating and using secure DFU keys under Linux?

I'm using the latest nrfutil from: github.com/.../pc-nrfutil

SHA1: e5303b994611b1122116ebd07c2185d5a0645d1d

And I'm running Debian (unstable)

[EDIT] I initially forgot to mention the SDK and SD versions and some other things

I'm using s132_nrf52_3.0.0_softdevice.hex from nRF5_SDK_12.1.0_0d23e2a

And the code is running on a custom board containing a nRF52832-QFAA (B0)

[End EDIT]

I generate the private key using:

nrfutil keys generate test.pem

I generate the pubilc key using:

nrfutil keys display --key pk --format code test.pem --out_file src/bootloader/keys/test_key.c

I build the zip archive using:

 nrfutil pkg generate   --application /tmp/app.hex --key-file test.pem --sd-req 0x8C --hw-version 52 --application-version 0 /tmp/g3_test.zip

I can verify / dump the content of the public key inside dfu_req_handling.c by calling:

NRF_LOG_HEXDUMP_INFO(crypto_key_pk.p_le_data, crypto_key_pk.len);

Proving that the key has successfully been used and linked into the .hex file

However the DFU upload using nRF Connect on my Android phone fails on the line:

err_code = nrf_crypto_verify(NRF_CRYPTO_CURVE_SECP256R1, &crypto_key_pk, &hash_data, &crypto_sig);

The error code returned is:

NRF_ERROR_INVALID_DATA If the signature did not match the provided hash or digest.

If I bypass the signature check by not returning NRF_DFU_RES_CODE_INVALID_OBJECT the DFU update completes without any further errors or problems.

Any feedback will be appreciated.

[bjorn-spockeli]

You have removed the debug public key and replaced it with a public key that corresponds to your private key in dfu_public_key.c right?

Have you generated a bootloader settings hex file? If not then I think you have to set the application-version to 0xFF, i.e.

nrfutil pkg generate <name of zip pkg >.zip --application <name of application hex>.hex --application-version 0xFF  --hw-version 52 --sd-req 0x8C --key-file <name of key file>.pem

[Visti Andresen]

Yes and no to replacing the data in the pk array.

I'm not linking with dfu_public_key.c instead I'm linking with the generated public key code file generated by nrfutil.

I have verified that the data in the the "pk" array is the same bytes as in the generated .c file by calling:

NRF_LOG_HEXDUMP_INFO(crypto_key_pk.p_le_data, crypto_key_pk.len);

Earlier in dfu_req_handling.c crypto_key_pk is defined as

static const nrf_crypto_key_t crypto_key_pk =
{
    .p_le_data = (uint8_t *) pk,
    .len = sizeof(pk)
};

[bjorn-spockeli]

Have you tried setting the --application-version to 0xFF?

[Visti Andresen]

With regard to the app version I have yet to initialize the bootloader settings by flashing its hex.

The check for this is done earlier in dfu_req_handling.c and --applocation-version 0 did not cause any problems if I commented out the failure on the crypto verification.

I have however tried setting the version to 0xFF for completeness.

The DFU update still fails for the crypto verification.

Btw. the NRF_LOG_INFO data also seems to indicated that at least in my case app version 0 would also have been accepted:

 :INFO:Req version: 255, Present: 0

[Visti Andresen]

Minor update:

I originally used a nrfutil version that was compiled from the git sources.

I have now also tried to 'pip install nrfutil' and use this version to generate a new set of public and private keys as well as a new application package.

The DFU still fails during 'nrf_crypto_verify' using the pip installed nfrutil