In my case, in my application firmware, I already have a device _priv key and I receive a server_public key; both generated using a curve ECP_DP_SECP256R1. I would like to do generate a shared secret from here on and preserve it for future use.
The following is the steps that I do:
Create a new client context, entropy context, ctr_drbg context variables.
use mbedtls_“respective”_init() to initalize all the three variables
Seed a random number using mbedtls_ctr_drbg_seed() function.
load the P256 elliptic curve in client context using mbedtls_ecp_group_load()
Generate a keypair for client context using mbedtls_ecdh_gen_public(&ctx_cli.grp, &ctx_cli.d, &ctx_cli.Q, mbedtls_ctr_drbg_random, &ctrDrbg)
Then use mbedtls_mpi_lset() to set Qp.Z =1
Then read the server pub key using mbedtls_mpi_read_binary(&ctx_cli.Qp.X, server_pub, 65);
Now the question is: Should I initialize the ctx_cli with my already generated device_priv key using
mbedtls_mpi_read_binary(&ctx_cli.d, device_priv_key, 50) ?
Then I plan to use mbedtls_ecdh_compute_shared(&ctx_cli.grp, &ctx_cli.z, &ctx_cli.Qp, &ctx_cli.d, mbedtls_ctr_drbg_random, &ctr_drbg); to compute the shared secret in z.
Also, if I am generating a hardware random number already in my platform, based on the HWTRNG, I should not be changing anything on the mbedtls_ecdh_compute_shared() function, correct? Instead I should be implementing the hardware poll along with HARDWARE_ALT define and the ctr_drbg_random will take care of the binding? Please confirm on this.
Please let me know if the flow is correct. In all the examples, they generate a key pair and just update the public key part (Qp.X) of the key. Thye do not touch the private key part (d) of the key. Please confirm if I can upload my private key directly in my case.
Also if my platform is a little endian, is there a recommended step before using mbedtls_mpi_read_binary functions?
Thanks so much for your help in advance!