Problems on generating static ECDSA key pair on STM32F429

Hi,there.FIRST OF ALL,thanks Ron Eldor for answer my questions via Email.For wider share, I post my last question and his review below.



Now I can run the ECDSA signature on STM32F429 successfully.
Today my problem is that how I can set my private key unchangeable? As far as I concered, the dafault setting is to make the key pair CHANGED everytime. As you can see examples below.BUT I hope my private can be static. Any thoughts?Thanks a lot!
image
image

Hi Mengyan,
The example you are showing is from the gen_key sample application, which is an example for generating a key. Once you have a generated key, in a PEM \ DER format, you can store it in a secure location, to be used later for generating the signature.
You can look for example at the ecdsa sample application after the key generation for you to see how to sign a hashed message (you will still need to seed your DRBG function), or at the pk_sign example which uses the pk wrapper for the PK operations.
Regards,
Mbed TLS Team member
Ron

I understand what you mean,once the key pair generated, one can use it repeatedly.BUT I wonder if there is setting function which can set the private value ‘d’ fixed .Can I set the d value fixed,in the fuction below?

I am not sure what you mean by setting d value as fixed, in the mbedtls_ecp_gen_keypair(). This function is the function that generates the key-pair (d and Q). This means that it should be called once for every key pair you want to generate, and you shouldn’t call it every time.
You should store the d value in a non volatile secure memory, so it can be used for future operations, also after rebooting( If you thought of setting it as a static variable it won’t work).
You should also store Q in a non volatile memory, but it doesn’t have to be secure, as it is the public key( It is better its authenticity is retained), if you want to send your public key to remote peers to verify your messages.
It is better that the Q is stored in a standard way, such as PKCS#1 or PKCS#8, so the peers will know how to parse and read it.

I totally understand what you say, thanks again Ron~

To explain this: I mean is there possibility that the generation of Q is based on the d which I set personally fixed.You see in in the function of mbedtls_ecp_gen_keypair(),it actually generate ‘d’ in a random way, and returns the function of generating Q in the end .What I thought is that give ‘d’ a fixed value (need to rewrite the source code ),and even when I call this function every time, it doesn’t change its value.

It is better you don’t modify the source code for this purpose. You will disable any possibility for generating different key pairs in the future. And you might encounter future issues. If you really want to go with this approach, you can simply call in your application the function mbedtls_ecp_mul() as it is a public API, after you load your group, as it is a public API. Note that this is a trade off in performance, as you will need to generate your public key every time you need it, and export it to PEM \ DER format, for the remote peer to parse.

Hi~ Ron, Now I can generate public key ‘Q’ based on a given private key ‘d’, thanks for your help.Here I got another question is that, I wonder in the process of ECDSA signature, if I only need
the ‘r’ and ‘s’(do not wrap them with ASN.1, because of the remote peer’s rule).so I directly use the ‘mbedtls_ecdsa_sign_det’ instead of the wrap function ‘mbedtls_ecdsa_write_signature’, but I found that even if the message I prepare to sign is changed, the value of ‘r’ and ‘s’ do not change, so I wonder if the problems occurs on the hash process.


My question is that the message I input whether should or do not have to be hashed, the parameter ‘md_alg’ in the picture above is the option of hash method,does this option relate to the the previously hashed message?

Hi Mengyan,
Please try to create new posts for different issues, as it will be easier to track.

From RFC6979 appendix A 1.3:

An ECDSA signature is a pair of integers.

the signature is consisted of the concatenations of r and s , so if you change the input, then the signature should change.
Since you are using deterministic ecdsa, the drbg function that is used in the signature process, is HMAC, with the md parameter for the HMAC in the drbg.
You should check that the input message ( preferably hashed ) in fact changes when you see same signature.
Regards,
Mbed TLS Team member
Ron