I'm a software developer working with hardware devices that are deployed on the field. Every now and then, I would need to update the hardware's firmware (upgrades, patches, etc)

I'm thinking of now, implementing a secure channel to upgrade this firmware, and for some checking to be performed by the hardware before accepting this firmware.

I have a basic understanding on key exchange protocols, encryption ciphers, etc, and that's about it. I do not necesarily know how to apply them in the real world, so I was hoping I could get some help here.

The firmware upgrade would be performed through a custom software that runs on the PC written by me, over TCP/IP.

My main goals are

  1. prevent the firmware from being leaked to public as it contains our IP.
  2. prevent the hardware from running other firmwares other than firmware released by me.

What I do know, on a high level point of view is

  1. To encrypt (with a pre defined shared secret key) the firmware on the PC software, and send it over ot the firmware.
  2. Once the firmware receives this encrypted data, it will decrypt it with the pre defined shared secret key, and performs the upgrade

My questions are:

  1. Is defining a shared secret key secure in this aspect?
  2. Is there a "bread n butter" solution to achieve my requirements?
  • 1
    The only reason a "predefined shared key" might be useful is if you can't $\hspace{1.98 in}$ provide a different ciphertext for each device. $\:$ – Ricky Demer Jul 9 '13 at 8:14

With respect to your goals you need:

  1. Data confidentiality->Encryption. The question is public one or secret one. I guess you need a secret one in which only the owner of the key can encrypt and decrypt. You don't want anyone to encrypt firmware.
  2. That implies an integrity mechanism. If you use a secret key scheme then you want either an authenticated block cipher or a secure combination of MAC (message authentication code) and encryption. Encrypt-then-Mac approach tends to be the more secure for various reasons.

For your questions:

  1. Secret key sharing is secure as long as the involved parties are trusted and as @Ricky mentioned if you can't define different key per device.
  2. You deploy the secret key at your hardware devices and the server and then you use that with AES for encryption. For authentication unless you use an appropriate cipher that combines both you MUST use different keys for the MAC authentication.
  • Can I hardcode a secret key in all my devices, and then encrypt my firmware with this secretkey? – The 8th Bit Jul 9 '13 at 14:54

You're going to need more than application and protocol security. You'll also need robust hardware security.

It's easy to monitor the data flowing to and from the memory chips, or to read the content of a flash chip. Instructions stored in a CPU's flash memory can be retrieved through the JTAG port. Other side channel attacks include differential power analysis, timing analysis, RF emissions, and even ion-beam microscopic examination of the chips. Defending against all of these (and more) has to be considered and weighed against the value of the IP you're trying to protect.

The Payment Card Industry has created a good set of standards on defending PIN pads against reverse engineering. You might want to look to them.

It's becoming more and more common to see people reverse engineering hardware to recover the secrets they contain. For an example of someone willing to dig deep, check out this series of articles on reverse engineering the RF protocol for a wireless burglar alarm.


Why reinvent the wheel? Use rsync+ssh, scp, or sftp.

  • I don't think this really answers the question, they are still going to require some form of shared secret. – Cybergibbons Jul 12 '13 at 10:07

Your question details no computational restrictions so I am assuming I have a modern CPU to solve the problem.

I personally think of shared secret as the lowest form of authentication. What you are describing seems to boil down to "How can this machine trust that the binary package it's being asked to run is in it's circle of trust?".

I assume you have an organization with access to an SSL cert which would form as a trust center. The CA for the SSL confirms the key and all keys signed by that key would be trusted. They are very inexpensive and quick to set up if you lack one.

From there on you have a plethora of protocols to choose from. My instinct would be not to wander into fresh territory, but rely on proven methods. TLS provides for cheap transport and verification of origin. ECDHE provides good forward secrecy. SSH gives you the first privilege channel to generate the client keys and extract the public part for signing if the machines are too remote for a site visit.

The governing principle you should be thinking of is "How do I solve this with systems administration instead of programming?".

Your Answer

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