Secure the off-site production programming of your embedded products -

Secure the off-site production programming of your embedded products


Is it possible to be too successful? Well, if you create an embedded system that sells in low quantities, you can control the entire process in-house. However, if your product proves to be wildly popular, thereby requiring high-volume production, you will probably end up working with a contract manufacturer (CM), and one of the tasks performed by the CM will be to program your firmware into your product's microcontroller(s).

If you are using a CM, one of the things you need to protect yourself against is theft of your IP and overproduction of your system. It's estimated that around 10% of electronic products around the world are counterfeit, and overproduction by CMs accounts for a substantial proportion of these knock-offs.

Different people think of IP (intellectual property) in different ways. With regard to an embedded system, the hardware design is one form of IP and the firmware is another. In some cases, it may be relatively easy to clone the hardware, but the hardware is useless without the firmware. If a CM is provided with unfettered access to both hardware and firmware, the originators of the system are left with little recourse but to rely on the CM's ethics and reputation, until now…

At the recent Embedded World Conference, which was held earlier this month in Nuremberg, Germany, SEGGER announced a new production programming system called Flasher SECURE that targets the problems of IP theft and overproduction.

(Source: SEGGER)

There are various possible use models. The diagram above reflects a common scenario. This is based on the fact that each microcontroller contains a unique identifier (UID). The owner of the firmware IP — typically the designer of the embedded system — provides the CM with the Flasher SECURE platform. Meanwhile, the firmware itself resides on a trusted server that remains under the control of the IP owner.

When the time comes to program the system, Flasher SECURE reads the UID from the device to be programmed and transmits this to the trusted server, which validates the UID and generates a cryptographic signature. The firmware and the signature are then returned to Flasher SECURE, which programs them into the microcontroller.

When the product is powered up, the first thing the firmware does is to read the UID on its microcontroller and check that this corresponds to the signature it was given before it does anything else. The bottom line is that this instantiation of the firmware will only run on this specific microcontroller.

But “time is money,” as they say. If this process slows down production, then it's also going to increase costs. Well, fear not, because the folks at SEGGER have taken this into account. In fact, the firmware is only downloaded from the trusted server one time as part of programming the very first device, after which it is stored in Flasher SECURE.

(Source: SEGGER)

When it comes to subsequent units, at the same time that Flasher SECURE is programming the firmware, it's also reading the microcontroller's UID and sending this UID to the trusted server. The trusted server validates the UID and creates and returns the corresponding signature before the programming has been completed. Once the firmware has been loaded into the device, all that remains is to load the signature, which takes an infinitesimal amount of time.

So, what happens if the firmware determines that it's running on a counterfeit system? Well, this is up to its creators. One option is for it to simply refuse to do anything at all. Another possibility would be for the firmware to display a message informing the end-users that they are working with an illegal product. Depending on the system (you wouldn't want to do this in a safety-critical product), if would be possible for the firmware to pretend to be doing its job while actually producing erroneous results or performing nonsensical actions, thereby disgruntling its new owners who would forcibly express their feelings of discontent to the little scamps who had ripped-off the system in the first place.

Another option to which I'm particularly partial would be for the firmware to pretend to be doing its job while actively trying to access the Internet and broadcast as much information as possible to help the owners of the IP track it down.

If you wanted to be really nasty, you could get the firmware to do its best to wreak havoc on anything it came into contact with, but perhaps we should try to restrain ourselves from sinking to the level of the bad guys. What do you think? If someone stole one of your designs, would a simple “Warning: This is a counterfeit system,” message suffice, or would you want to “Cry havoc and let slip the dog bytes of war?” (with apologies to The Bard)?

1 thought on “Secure the off-site production programming of your embedded products

  1. “I think your idea of letting the CM think everything is working while in fact the firmware is actually try to help the OEM locate where the counterfeiting is taking place – That would be a really good thing”

    Log in to Reply

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.