0

Our medical device has embedded processors and a USB port used for firmware updates and logfile transfers. The usual USB viruses are not a concern (no mechanism to load or execute them, wouldn't run in our unique environment). However a secure upgrade method is required by a regulatory agency, in case of malicious attack by someone with a copy of the source code, build environment and schematics.

In learning about security, our current concept is to use signing and encryption for upgrades and to embed the public key. Then we have to keep the private key private for the product lifetime, hopefully on the order of twenty years.

Is there a standard way to do that? Keep it on a secure build server?

|improve this question
1

The normal approach is to store your private key in a manner in which it can't be compromised by a human being. Meaning, a disgruntled employee can't just steal it and then create malicious updates which have been signed with your key.

You will want to look at Hardware Security Modules which are capable og being fed your update or install image and and outputting the signature. That hardware device is then maintained under strict physical security ("locked in a safe").

|improve this answer
  • With that approach I imagine using a different (non-secure, available to developers) key pair for iterative in-house development and testing. Only use the secure public key (involving access to the safe) for builds intended for release. – Technophile Sep 8 at 23:25
  • 1
    @Technophile - That's the standard practice. – Julie in Austin Sep 9 at 16:54
  • 1
    @Technophile - Note that you can often still use the HSM without ever exposing the key itself - most HSMs will expose an API to pass data to be signed/encrypted, which you would call during the build process. In many cases, the HSMs are designed to make the private key entirely non-recoverable, since it would be such a large target. – Clockwork-Muse Sep 9 at 17:13
  • 1
    @Clockwork-Muse - Using the "real" HSM for development builds would allow an attacker to create a signed and malicious update. That's one of the primary reasons for not allowing developer access to the HSM. – Julie in Austin Sep 9 at 17:46
  • 1
    @Clockwork-Muse - Physical HSMs in secured locations is a pretty typical approach. My employer (a Fortune 500 company) uses that approach and I'm not worried an employee is going to walk off with it. For smaller companies there are other solutions than having a safe on premises, such as a bank safe deposit box, which only the officers can access. For extremely small companies (like the one I used to own), trusted friends are another solution for "off-site storage" for things which aren't as critical as an HSM. For super-critical things, I had a concrete-encased floor safe -- 12" of concrete ;) – Julie in Austin Sep 11 at 12:00

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.