Generate Keys with nrfutil

[yes]

Hi,

Our device is based on nRF52840 + SDK 15.0.0 and we use cc310 backend for crypto tasks

Messages and SW packages are signed by Ecdsa.

I installed nrfutil and try to generate paired keys (see below for the keys).

I tried to test the key by embedded them in ecdsa example  (..\nRF5_SDK_15.0.0_a53641a\examples\crypto\nrf_crypto\ecdsa)

It failed with internal error (34070) at line 127  in cc310_backend_ecc.c

crys_error = CRYS_ECPKI_BuildPublKeyFullCheck(p_domain,
ucompressed_key,
p_info->raw_public_key_size + 1,
&p_pub->key.cc310_public_key,
p_temp_data);

Any suggestion for solving this issue?

The following keys were generated and hard coded into main.c (example original keys were commented out):

Private

// 550b4ec77284f0538eae285a6d949a3ba8b8ca6bc3b2cbffcf0e8a6cc197db91

/** @brief Predefined example private key.
*
* This private key contains some dummy data just to show the functionality. Is should never be
* placed in any practical usage. Is is not secure, because it is filled with ones (in HEX).
*/
static const uint8_t m_alice_raw_private_key[] =
/*
{
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, // This is an example. DO NOT USE THIS KEY!
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, // This is an example. DO NOT USE THIS KEY!
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, // This is an example. DO NOT USE THIS KEY!
0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, 0x11, // This is an example. DO NOT USE THIS KEY!
};
*/
{
0x55, 0x0b, 0x4e, 0xc7, 0x72, 0x84, 0xf0, 0x53,

0x8e, 0xae, 0x28, 0x5a, 0x6d, 0x94, 0x9a, 0x3b,

0xa8, 0xb8, 0xca, 0x6b, 0xc3, 0xb2, 0xcb, 0xff,

0xcf, 0x0e, 0x8a, 0x6c, 0xc1, 0x97, 0xdb, 0x91
};

 

Public

 

/** @brief Predefined example public key that is associated with example private key
* @ref m_alice_raw_private_key.
*/
static const uint8_t m_alice_raw_public_key[] =
/*
{
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,
};
*/
{
0x91, 0x4f, 0x70, 0x0b, 0x68, 0x6e, 0xe7, 0xd0, 0xad, 0xdb, 0xce, 0xef, 0xf5
, 0x6f, 0xb2, 0x8e, 0xe6, 0x25, 0xbc, 0x2c, 0x83, 0xb1, 0x85, 0x50, 0xbf, 0x5c,
0xdc, 0xa4, 0x7e, 0x6b, 0x28, 0x44,
0xfd, 0x43, 0xec, 0x21, 0x48, 0xf4, 0x03, 0x90, 0xcb, 0x29, 0xe9, 0x4d, 0x5a
, 0x68, 0xeb, 0xf8, 0xab, 0xbc, 0x52, 0x86, 0x61, 0x95, 0xcb, 0x1b, 0xea, 0xeb,
0x3f, 0x81, 0xa6, 0x6e, 0x95, 0xfd,
};

[Vidar Berg]

Hi,

The key pair format (endianess) from nrfutil is made to be used with the bootloader. But you can make it work by reversing the endianess (32 bytes at a time). But I didn't manage to make it work with the key-pair you posted, maybe I copied it in wrong. In any case, here is my private key and converted arrays that I used to verify this here:

__ALIGN(4) static const uint8_t m_alice_raw_private_key[] =
{
    0x97, 0x36, 0x50, 0x4f, 0xda, 0x46, 0x8d, 0x57, 
    0x4e, 0xd2, 0xe3, 0x2d, 0x8a, 0xa3, 0x8a, 0x21, 
    0x99, 0x0f, 0x4f, 0xe1, 0xd6, 0x45, 0xbd, 0xc0, 
    0x58, 0x17, 0xf7, 0xe4, 0xc4, 0x26, 0x5f, 0xf5
};

__ALIGN(4) static const uint8_t m_alice_raw_public_key[] = 
{
    0x7e, 0x2e, 0x9d, 0xe0, 0x5a, 0x52, 0x1e, 0xfc, 
    0xe6, 0x2d, 0xd4, 0x9c, 0x26, 0xfb, 0x26, 0x5b, 
    0x8f, 0xdd, 0xf0, 0xef, 0xd2, 0x09, 0xe5, 0xce, 
    0xc7, 0x33, 0x44, 0x3f, 0xe5, 0x5e, 0x8c, 0x97,
    /**********************************************/
    0xa8, 0x93, 0x3e, 0xd5, 0x80, 0xdd, 0xb2, 0xfd, 
    0x8d, 0xdf, 0x9e, 0x9d, 0xf5, 0x78, 0xc2, 0xd1,
    0x4c, 0x94, 0x24, 0x85, 0x22, 0xfd, 0xca, 0x3f, 
    0x8d, 0x67, 0x3f, 0xa0, 0x00, 0x1d, 0x2a, 0xc1
};

private.zip

[yes]

Thanks for the answer.

Just to be sure I understand. The keys pairs which are generated by nrfutil should be used as is for signing sw if we use dfu but should be endianness reversed otherwise?

Do we need to reverse endianness of both private and public keys?

For the public key (64 bytes) should we use  double swap Nordic's function?

Thanks in advance

[Vidar Berg]

yes said:

Just to be sure I understand. The keys pairs which are generated by nrfutil should be used as is for signing sw if we use dfu but should be endianness reversed otherwise?

Correct. I'm not sure why we are using a different byte order in the bootloader. Excerpt from sdk_config:

NRF_CRYPTO_BACKEND_MICRO_ECC_LITTLE_ENDIAN_ENABLED - Enable non-standard little endian byte order.

// <i> This affects parameters for all ECC API (raw keys, signature, digest, shared secret). Only for use in nRF SDK DFU!

yes said:

Do we need to reverse endianness of both private and public keys?

Yes.

yes said:

For the public key (64 bytes) should we use  double swap Nordic's function?

It should work as long as you set the size to 32 bytes. 

[yes]

We intend to use nrfutil for signing data packet which can't be transffered over DFU

As mentioned above nrfutil generates little endian byte order pair key 

It signs package using private key pem file

We can convert the pem format into hex format and swap key endianness but can't convert it back to pem format. 

As mention above there is the flag NRF_CRYPTO_BACKEND_MICRO_ECC_LITTLE_ENDIAN_ENABLED but it only for CC310 boot loader mode

Is there a way to force CC310 backend (not BL mode) to use little endianness byte order?

Thanks in advance

[Vidar Berg]

You can try to modify the full cc310 backend using the bl variant as a reference. Search for  NRF_CRYPTO_BACKEND_CC310_BL_ECC_LITTLE_ENDIAN_ENABLED and NRF_CRYPTO_BACKEND_CC310_BL_HASH_LITTLE_ENDIAN_DIGEST_ENABLED in the bootloader backend.