ECC key generation example

Hi,

I'm trying to find an example of using the ECC key wrapping. I've seen the example application note: 

https://www.renesas.com/cn/en/doc/products/renesas-synergy/apn/r11an0348eu0102-synergy-device-identity-application.pdf

But i can't find the project that goes with it. Where is this project located for download?

Also i have seen another post on here talking about ECC generation at the HAL level. Are there any examples showing the process using the frameworks from start to finish?

Thanks,

Matt

  • The project for the application note can be downloaded from here :-

    www.renesas.com/.../D6003976.html
  • In reply to Jeremy:

    Hi Matt-
    A good trick to find the downloadable project associated with an application note is to search on the app note ID Number (without the suffix, as seen below).
    www.renesas.com/.../keyword-search.html

    This will bring up both the app note and the project download.
  • In reply to Jeremy:

    Thanks for the quick reply, I'll have have a look through the project.
  • In reply to WarrenM:

    This is a great tip! I'll definitely be using this
  • In reply to Jeremy:

    A quick question when using the frameworks.

    I can see that when i add the sf_crypto_key framework stack i get functions on it to create the key.

    status = g_sf_crypto_key0.p_api->keyGenerate(g_sf_crypto_key0.p_ctrl, &private_key, &public_key);
    if(status != SSP_SUCCESS)
    {
    __BKPT(0);
    }

    but that is the only function at that level.

    When looking at the example project it seems like it uses the ECC functions directly. How do i get access to the instance of the ECC module to use other functions?
  • In reply to M_Travers:

    Hi Matt-
    Try reviewing the Crypto Framework section of the SSP User Manual- section 4.1.18 (r11um0140). It provides an overview of all the crypto modules. You will see which other modules you need to use, in addition to the key module, like crypto cipher for encryption and decryption services. Let us know if this helps...
  • In reply to WarrenM:

    Thanks for the information, found it to be very useful.

    I have another question regarding the key generation and the ECC parameters (Not sure if this is the correct place).

    I have some requirements for the curve which are to use the following one from openssl (prime256v1). I have generated the parameters for this using:

    openssl ecparam -name prime256v1 -out prime256v1.pem
    openssl ecparam -in prime256v1.pem -noout -C

    Which gives me arrays for:
    ec_p_256
    ec_a_256
    ec_b_256
    ec_gen_256
    ec_order_256
    ec_cofactor_256

    using the example given here:
    renesasrulz.com/.../ecc-create-key-sign-and-verify-sample-code

    I have combined the following into the domain array:
    ec_a_256
    ec_b_256
    ec_p_256
    ec_order_256

    This looks to be the correct length of bytes.

    However when i look at the outputted generator array ec_gen_256 it appears to be larger than the defines set in r_ecc_api.h (ECC_256_GENERATOR_POINT_LENGTH_WORDS) 65 instead of 64.

    Is there something I am missing?

    I'll include the outputted and formatted arrays i have made:

    uint8_t domain[ECC_256_DOMAIN_PARAMETER_WITH_ORDER_LENGTH_WORDS * sizeof(uint32_t)] =
    {
    /* a */
    0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFC,
    /* b */
    0x5A, 0xC6, 0x35, 0xD8, 0xAA, 0x3A, 0x93, 0xE7, 0xB3, 0xEB, 0xBD, 0x55,
    0x76, 0x98, 0x86, 0xBC, 0x65, 0x1D, 0x06, 0xB0, 0xCC, 0x53, 0xB0, 0xF6,
    0x3B, 0xCE, 0x3C, 0x3E, 0x27, 0xD2, 0x60, 0x4B,
    /* p */
    0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x01, 0x00, 0x00, 0x00, 0x00,
    0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF, 0xFF,
    /* n */
    0xFF, 0xFF, 0xFF, 0xFF, 0x00, 0x00, 0x00, 0x00, 0xFF, 0xFF, 0xFF, 0xFF,
    0xFF, 0xFF, 0xFF, 0xFF, 0xBC, 0xE6, 0xFA, 0xAD, 0xA7, 0x17, 0x9E, 0x84,
    0xF3, 0xB9, 0xCA, 0xC2, 0xFC, 0x63, 0x25, 0x51
    };

    uint8_t generator_point[ECC_256_GENERATOR_POINT_LENGTH_WORDS * sizeof(uint32_t)] =
    0x04, 0x6B, 0x17, 0xD1, 0xF2, 0xE1, 0x2C, 0x42, 0x47, 0xF8, 0xBC, 0xE6,
    0xE5, 0x63, 0xA4, 0x40, 0xF2, 0x77, 0x03, 0x7D, 0x81, 0x2D, 0xEB, 0x33,
    0xA0, 0xF4, 0xA1, 0x39, 0x45, 0xD8, 0x98, 0xC2, 0x96, 0x4F, 0xE3, 0x42,
    0xE2, 0xFE, 0x1A, 0x7F, 0x9B, 0x8E, 0xE7, 0xEB, 0x4A, 0x7C, 0x0F, 0x9E,
    0x16, 0x2B, 0xCE, 0x33, 0x57, 0x6B, 0x31, 0x5E, 0xCE, 0xCB, 0xB6, 0x40,
    0x68, 0x37, 0xBF, 0x51, 0xF5
    };

    generator point length is 65 instead of 64

    Thanks,
    Matt
  • In reply to M_Travers:

    Looking at the example in the other forum thread and using the secp256k1 in the same process i followed it looks as though the first byte of the generator_point array is deleted (0x04). In my generated array i also have this same starting byte. Is there a reason this is deleted?
  • In reply to M_Travers:

    I believe that byte specifies whether the data is raw or compressed. I presume as the driver only supports raw there is no need for this byte.

    Regards,

    Ian.