Two devices are communicating only with each other and shall do this with AES encryption. Both devices are offline, have very limited storage and use a small cryptographic coprocessor which is able to perform AES/ECDH/ECDSA/RNG. Also keys and certificates can be stored in it. Any device must work with any other device, as they are not coupled in any way per default.

I planned on doing an ECDH key exchange to create random keys for the AES communication. Then I encountered the MITM problem, which makes ECDH alone invalid for creating random keys out of thin air without further validation.

If I wanted to use ECDSA I would need to store a certificate, which would be static for the entire life of the product, as I can't update it. It would also be the same for every device, as every device must be able to communicate with every other device. If the private key is compromised, so are all the devices.

I could also store a factory key in the devices and use that to transfer a randomly generated keys. For that I could directly use AES and ditch ECDH completely. The problem here is, that the factory key might get compromised, exposing all the other devices using the same key. As mentioned I could use a fixed public/private key pair, but I see no advantage in this case over simply using AES.

Then another problem: One device might stop working, which then needs a replacement. The new device would then have to exchange a new key with the old device. A function would be necessary, that makes the old device ditch its key and accept a new one. If an adversary knows the factory key, he could intercept the new key and listen to the communication.

I am looking for suggestions on how to approach this key exchange problem and make the system as secure as possible. Thanks in advance and BR.

  • $\begingroup$ "... and use a small TPM..." - which version of the TPM specification do these devices implement? $\endgroup$
    – Crowman
    Jan 11, 2021 at 15:56
  • $\begingroup$ @Crowman I think I used the term TPM wrong. It is a cryptographic chip, that can perform the algorithms I mentioned. I am going to edit the question. $\endgroup$
    – earthling
    Jan 11, 2021 at 16:02
  • $\begingroup$ It would be helpful to know exactly which cryptographic chip your devices have, as it may have facilities which can help with your objective. $\endgroup$
    – Crowman
    Jan 11, 2021 at 17:34
  • $\begingroup$ You can give each device a unique certificate signed by the manufacturer. $\endgroup$
    – Myath
    Jan 11, 2021 at 22:14
  • 1
    $\begingroup$ @earthling -- oh wow -- 32K total is really tight!! That is a difficult task. It's good that you're not using RSA for the key exchange, there have been attacks and vulnerabilities that are specific to RSA. You are on the right track. Best of luck! $\endgroup$
    – Dan
    Jan 27, 2021 at 14:25

1 Answer 1


You can assign each device its own unique certificate with a signature issued by the CA (for example, could be the manufacturer) on the certificate. So each device stores the following: its own unique certificate (its public key), its corresponding secret key, and the signature on its certificate issued by the CA. During key exchange, 2 devices would send each other their respective certificates plus the CA's signatures on those certificates, which can be verified using the CA's public key.

  • $\begingroup$ This looks very promising. Thank you for your time. $\endgroup$
    – earthling
    Jan 14, 2021 at 8:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.