1
$\begingroup$

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.

$\endgroup$
14
  • $\begingroup$ "... and use a small TPM..." - which version of the TPM specification do these devices implement? $\endgroup$ Commented 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$ Commented 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$ Commented Jan 11, 2021 at 17:34
  • $\begingroup$ You can give each device a unique certificate signed by the manufacturer. $\endgroup$ Commented 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$ Commented Jan 27, 2021 at 14:25

1 Answer 1

2
$\begingroup$

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.

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

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.