5

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.

Dan
  • 153
  • 4
  • 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? –  Aug 29 '19 at 12:56
  • Edited for clarifying the issue. – Dan Aug 29 '19 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? –  Aug 29 '19 at 13:07
  • Signed updates mostly. – Dan Aug 29 '19 at 13:09
  • I edited your question to be a bit easier to read. I hope it still captures your situation quite well. What exactly is your threat model? Are you worried your customers would install custom firmware over yours? Or are you worried about attackers pushing malicious firmware onto the devices? –  Aug 29 '19 at 13:14
  • The main concern is a customer/attacker installs its own version of the FW. – Dan Aug 29 '19 at 13:16
  • 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. –  Aug 29 '19 at 13:22
  • I have added a clarification for the issue with the customer overwriting the public key. Notice that the public key is actually embedded within the FW image, but it gets overwritten only in case of factory updates, that are totally different to the customer ones. The customer will never be able to perform a factory update. Regarding the question, what I actually want is to understand the current industry standard with regards to pub/priv. keys in case of FW, for this particular scenario (pr. key compromised) – Dan Aug 29 '19 at 13:43
  • Yes, it was just an example to show that the customer may be able to write a custom firmware without compromising the private key. I'm aware that the key is most likely not as easy to overwrite. From my experience, locking down the system enough to make custom firmwares impossible will likely be a futile task. Sony, Nintendo and Microsoft tried in every console generation and failed every time so far. –  Aug 29 '19 at 13:46
  • You mean that there is not a robust trusty standard in the industry for dealing with this problem? – Dan Aug 29 '19 at 13:47
  • 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. –  Aug 29 '19 at 13:50
  • [This Answer](https://security.stackexchange.com/a/4639/163495) should hopefully shed some light on the situation. –  Aug 29 '19 at 14:04

2 Answers2

4

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.

Mike Scott
  • 10,134
  • 1
  • 28
  • 35
1

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...

binarym
  • 754
  • 4
  • 8
  • Yes, I have read the secure boot schema from here: https://www.chromium.org/chromium-os/chromiumos-design-docs/verified-boot-crypto 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 '19 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 '19 at 14:09