I have a firmware project that uses asymmetric cryptography for assuring integrity and authority of updates. The private key is stored within the company, and the public key is on the firmware to validate the integrity and authenticity of an update attempt.

Currently, the public key to be used for verifying the signature is 'written' (in NV data) only on factory updates, so the customer can't just overwrite the FW by adding it's own key.

I want to implement a strategy for handling the case of the private key being compromised. Are there any standards or similar documents to refer to?

Some context: The unit with the firmware will not have internet access. A compromised private key would need to have its associated public key replaced manually on-site.

  • You are embedding the private key into the firmware of a product and then ship it to customers? Is it always the same private key or is a new one generated for every unit?
    – user163495
    Aug 29, 2019 at 12:56
  • Edited for clarifying the issue.
    – Dan
    Aug 29, 2019 at 12:58
  • Ah, so you have the private key safe and the public key gets put on the Firmware, I get it. What exactly are you trying to accomplish with it? Signed code? Signed updates?
    – user163495
    Aug 29, 2019 at 13:07
  • 2
    Then your question is more "How can I prevent a customer from installing their own firmware?" rather than how to invalidate the private key. In a simple scenario, a customer could just create their own key and overwrite your public key. This would allow them to install their own firmware without ever stealing your key. By the way, I am sorry if I have to ask so many questions. I am not trying to troll you, I'm just trying to really understand what you want to solve.
    – user163495
    Aug 29, 2019 at 13:22
  • 1
    No, just like there is no way to stop people from pirating videogames, music, images, movies, etc.. As soon as the machine is in the hands of the customer (who is the attacker in this case) they will be able to find a way to defeat your security measures. History has proven this to be true every single time.
    – user163495
    Aug 29, 2019 at 13:50

2 Answers 2


Put multiple public keys in the firmware, with the corresponding private keys stored in diverse locations. Require that updates are signed with all of the private keys, not just one key. Never bring the private keys together, not even for code-signing — instead, move the code around between the locations where the private keys are stored so that each one can sign the code in turn. Then the compromise of one private key will have no impact.


Assuming the question is " "How can I prevent a customer from installing their own firmware?", industry standards regarding this issue are (in short):

  • Use a secure bootloader that would only accept to boot on a firmware that is signed with your key.
  • Use a secure storage (also called fuses, or OTP (one-time-programming)) to store this key so that it just can't be physicaly modified. OR
  • Use an oracle chipset that will do the crypto job for you and abstract the keys.

Moreover, you'll also have to ensure that your device is safe for hardware attack (like changing the flash device after the signature has been verified)

The problem is that your device must be ready for all that. It's the kind of security that must be designed at the very beginning of the project and that is very difficult to add later. What kind of hardware do you have ? Does it implement TEE or SEE mechanisms ? If not, there's some companion chip that you can embed on your hardware to implement this... Anyway, the real point is the private key. If private key is leaked, then the whole security is broken.

Usually (and based on my experience working for companies that manage that kind of secrets) the public key is burnt on the device by the hardware manufacturer during the production at plant and isn't even known by the company developing firmware. To ease development, there usually two sets of keys: production keys, that are the best kept secret and only use in production devices and development keys that are burnt on devices for developers. Usually, on this "development devices", the most critical functions can't be ran.

To go further, search for OTP, SEE, TEE, Key Ladder, etc...

  • Yes, I have read the secure boot schema from here: chromium.org/chromium-os/chromiumos-design-docs/… which I understand is explaning exact;y what you say. The problem is that that schema doesn't deal with the private key being compromised, it relies on a root key that (somehow) can never be compromised.
    – Dan
    Aug 29, 2019 at 14:04
  • 1
    Instead of thinking about "how to deal with compromised private key" you have to think about "how to protect my private key"... One way to ensure this is to use this key only for FW signing, and use other keys for other functions. Then, you have to create a kind of black box that will sign firmwares upon request so that you do not have to give the key to anybody. Maybe the use of a keyladder can help preventing this issue.... But i insist: this private key is probably one of the most valuable secret of your company.
    – binarym
    Aug 29, 2019 at 14:09

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .