Electronics > Projects, Designs, and Technical Stuff
Embedded Firmware & IP Protection from Chinese clones
jbb:
People are right that it's impossible to provide perfect security. But you can make them work for it...
Here are some recommendations that will make it harder for cloners:
* Lock out the JTAG port during production (see STM documentation)
* Lock out the STM factory bootloader code(see STM documentation)
* Lock out the FW development debug commands. The preferred method for doing this is to have a Debug / Dev build with debug commands compiled in and then a Production build with the debug commands not compiled in.
* Lock out the debug UART pin header that you thought people wouldn't notice.
* Review the firmware to check what happens if you feed it unexpected inputs / commands (the classic being a buffer overflow attack). Remember to have a look at I2C drivers and the like too.
* Enable brown out detection. It might help.
* If your chip has security monitors for voltage and temperature, generally called 'environmental sensors,' read the documentation and enable them.
* Use a secure boot loader to handle firmware update. Some suggestions:
* Someone might have done it already - check STM documentation or your RTOS supplier.
* Encrypt the binary using a decent method (e.g. AES128 with CBC). Don't use DES (it's too weak) or 3DES (getting too weak). If possible, use hardware encryption (e.g. AES peripheral)
* I suggest using a fresh AES key for each product line. This will make it harder for the attacker to clone your next product.
* Authenticate the binary using asymmetric cryptography. I.e. you have a private key back at the office (stored carefully!!), with which you sign (unencrypted) firmware binary. Each device has the public key loaded in and verifies the binary before running code. It's no big deal if the attacker gets the public key.
* Think about what happens if someone has a 'magic' SD card that delivers the original binary while your micro verifies the public key and then a different binary while your micro copies into Flash. This is bad news and should be considered.
* Optional but good practice: check the firmware revision # and only allow firmware update to a higher revision #. This prevents someone downgrading the device to a version which has a vulnerability.
Why am I stressing out about firmware runtime and update security? Because you don't want an attacker to load a short bit of binary code that says "dump Flash memory to UART0".
Does the device have some kind of (indirect) internet connection? It's more fiddly, but doing Firmware Over The Air updates is rather nice because the user doesn't have to mess around.
djacobow:
What I'm hearing here is that you can RE anything for a price, but i think it is the price that matters. If it is higher than the value to the cloner, then you don't have to worry about cloning.
Last year i sold a holiday-oriented product. I sold a bunch of units but lost a few bucks overall. It was my first ever foray into selling hardware. Next year I'll probably make a few bucks as I'll have no new NRE and higher volume. But if someone rips me off, I'm toast.
I think what's hard for the starting entrepreneur is that we don't know how valuable our product is. We might have a hunch, it if we're lucky and industrious, some good market research. But in the end, it's no fun to develop a product to have it snatched from you only once it becomes clear it's worth something.
I think that is why so many new products are tied to proprietary internet services. They are this generation's license dongle.
free_electron:
there are microcontrollers that have a unique crypto serial in them. When flashing the binary it is encrypted using that serial. This happens on board the cpu. The instructions are decrypted as they are executed.
Even if you succeed dumping the rom it is useless as any chip you buy can not run it. their key is different ...
Dallas Semi has those, Maxim has those and NXP has those. They have additional dummy layers in silicon which makes it very hard to strip them and get to the data.
Even if you can read the crypto key it is useless to you as the chips come pre-programmed and can not be altered.
Kilrah:
A company I work with just distributes their firmware in encrypted form, and their custom bootloader decrypts it when flashing. Obviously the chip is code-protected, and no one but them has a copy of the bootloader.
Doesn't protect from physical attacks, but... well we don't know what you're doing, but at some point if you make something successful while you might weed out 1:1 cloners you'll still have people reverse-engineering / reimplementing the functionality anyway. That is the case with that product, you don't find exact clones running the same firmware, but people have reversed what the firmware does and made "compatible" devices.
--- Quote from: free_electron on January 23, 2019, 04:47:56 pm ---there are microcontrollers that have a unique crypto serial in them. When flashing the binary it is encrypted using that serial. This happens on board the cpu. The instructions are decrypted as they are executed.
--- End quote ---
That can be a pain to manage though since every device then needs its specific firmware binary, need to really be sure it's worth the trouble setting up the backend to manage that and generate/distribute the individual files.
Bud:
@OP Some protection is better than no protection. Do what you find reasonable after assessing risk as people in this thread advised. If everybody would say what is the point if anything can be cloned we would not have any protection anywhere.
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version