1

I'm reading up on how to perform signed updates for remote hardware devices. I need to check if the new software has been generated by a "trusted" source, ie me.

Based on my understanding of asymmetric cryptography I understand that I can embed a public key on all my devices and then any new software that needs to be updated on the device, needs to have a signed hash in a header that I could check against. I'm all onboard until this part, and it sounds great for secure updates, but I'm wondering how one would securely store the private key. Say I built 1M units. All have the public key programmed on them. If my private key is lost for whatever reason, I lose the ability to update any of these devices. It sounds like the jugular vein. Should I accept storing private keys very safely as a cost of doing business, or is there a better way to handle this case?

  • If you sell 1M devices, you have enough money to safeguard your keys. – ThoriumBR Jun 17 '20 at 22:42
  • Exaggerated example. 1000 devices for poor me. In any case, my question pertains to the what-if scenario. – rookie Jun 17 '20 at 22:46
  • Backups help here. You could store a copy in a safe deposit box. – multithr3at3d Jun 17 '20 at 22:51
  • Yeah I guess that is doable – rookie Jun 17 '20 at 22:58
  • 7zip the private key with aes256 and memorize the password. – Pedro Lobito Jun 18 '20 at 1:12
1

I need to check if the new software has been generated by a "trusted" source, ie me.

This means you need a single key - your key. You embed your public key into each device. When later on you upload an update to each device, you sign the upload package with your private key. Each device verifies your signature using your public key that you have embedded into the device.

If my private key is lost for whatever reason, I lose the ability to update any of these devices.

Correct. I would suggest you to proceed like CAs do. Often the end-consumer certificates are issued not by the "top level" CA, but by some "intermediate" CA.

So you can create a "top level" key pair and corresponding certificate, and embed public key (or certificate) into each device. You should keep this private key in a very secure place.

Then let say every 3 months you do following: You generate a new intermediate key pair, create a certificate which expires in 3 months. You sign this certificate with the top level key. You use this intermediate private key to sign any updates in the next 3 months.

Since you want to sign 1M units, it may happen that you lose the private key. In such case you just generate a new intermediate key pair (without waiting 3 months), sign it with the top level key, and use this new intermediate key to sign updates from now on.

Each device should verify the packages as follows:

  1. Check if signature matches the certificate attached to the update.

  2. Check that certificate is issued by the top level key, which is embedded into device.

  3. Check certificate expiration date.

Of course, if you lose the top level key, you will be blocked. But since the top level key will be used rarely and kept much more securely than a key used for 1M signatures, the chance to lose it essentially lower.

I'd suggest that you consider also revocation of the keys. It can be needed if a key used to sign updates is stolen, or if you just suppose it is stolen. You may want to prevent the attacker from uploading malicious updates signed with your stolen private key. In such case you can have a CRL (certificate revocation list) on each device. In case you want to declare some key as untrusted, you generate certificate revocation info for the compromised key and push to all devices. Then generate a new intermediate key pair. In case the device obtains a package signed by a stolen key and finds this key in its CRL list, it should not trust such signature and should reject such update package.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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