EEVblog Electronics Community Forum
Electronics => Projects, Designs, and Technical Stuff => Topic started by: spectramax on January 22, 2019, 01:30:10 am
-
Hello all,
I appreciate your insight as I can't Google this stuff (I've tried). I've started developing a hardware product for a small company (3 people). We are new to the whole "Hardware-is-hard" thing and I certainly appears to be insanely daunting. Let me cut to the chase with a few burning questions that I just can't find good answers on Google.
Some background:
- We are going to be using an STM32L4 CPU
- Develop a custom firmware with RTOS
- Develop a custom bootloader for updating firmware using SDCARD or USB-DFU
- PCB, Case, etc will be manufactured by *different* suppliers in China
- Final assembly to take place in USA & England
- Low to mid-volume, est. 10000-20000/year maximum
Questions:
- How difficult is it to create a hex dump of the bootloader & firmware?
- If it is easy, is it possible for Chinese supplier to make the case, reverse engineer PCB and flash our own firmware (effectively selling "authentic" units)? There is a display on the device so we can put some copyright notice but that becomes irrelevant if the Chinese cloners are literally building replica of our device with authentic firmware and selling it under our brand in the grey market. Thus, the firmware authentication will always work because the firmware is indeed hex-dumped and flashed on the new STM32 chip.
- There are lots of discussions/threads/info about how to checksum firmware and check for its authenticity using crypto. But if the flashed firmware on a cloned hardware is indeed authentic, it is a moot point. Is there any way we can use something like a Drill Battery crypto chip such as Microchip ATSHA204?
- What are common ways to prevent cloning hardware by using the firmware as an authenticator? We don't want to go down the path of "security through obfuscation". In other words, how can we write firmware that can authenticate the serial number or some unique tamper resistant hardware feature securely?
The gist of my curiosity can be captured as "How can we make our firmware *only* run on our hardware."
Thank you :) I am a mechanical engineer but I also do systems programming. However, not much experience in embedded programming so please pardon me for asking if there is an obvious answer.
-
This was discussed a few times here. Short answer - if someone really wants to clone your design - they will.
There are rumors about companies dumping almost any MCU with prices starting at $500. Obviously there is no page with happy customer feedback, so it is hard to verify those rumors.
If device is standalone and does not have connectivity to some of your servers, then ATSHA204 will not help, only slow down a bit, since clonners will have to figure out where the communication happens. After that they will be saving on BOM not including that chip. It will help however if you think that MCU protection is reliable.
But this is really only a problem if your device is very popular and your margin on it is high. Are you sure you will get there?
If the device fills a new need that is not covered by other devices like this, and yours will show the demand, others will just clone the idea. Often times it is much easier than conning the original.
-
There are rumors about companies dumping almost any MCU with prices starting at $500. Obviously there is no page with happy customer feedback, so it is hard to verify those rumors.
https://russiansemiresearch.com/en/service/
PIC10F is $500. STM32 is $2000.
-
https://russiansemiresearch.com/en/service/
Yes, this is one of the most commonly linked places. There are a couple of others.
But I have not heard a definitive feedback. Nor have I seen any independent testing. You would think that it will make a good video for someone's channels. Program a few devices with a known pattern and send it to them to see what happens.
-
Thanks, the russian sites look dubious and I found some more information on stackexchange:
https://reverseengineering.stackexchange.com/questions/1698/bypassing-copy-protection-in-microcontrollers-using-glitching
https://reverseengineering.stackexchange.com/questions/3526/how-do-i-extract-a-copy-of-an-unknown-firmware-from-a-hardware-device
https://reverseengineering.stackexchange.com/questions/13013/reverse-engineer-stm32l151s-firmware
Someone tried to ask the Russian company if they would return the chip undamaged without a response.
However, I realized that the hex-dump question that I asked earlier is moot because we are most likely going to provide the binary firmware image as we upgrade the firmware.
@ataradov- regarding your questions about the demand - we have a unique product with a potential large exposure but it is difficult to estimate the demand. At peak, we are thinking 20k / year. One of my partners has written the code for several years so it is not easy to just roll your own code by the Chinese cloners. They'll need to know substantial information, know how and tribal knowledge to be able to write our software. But you're asking the right question - it may be not worth securing anything. That brings up another question - Electronics such as Cameras (Sony's Alpha Mirrorless cameras have the firmware publicly available for update), Synths, Bluetooth Headsets, etc. have firmware publicly available. So, I am wondering if A) Do they encrypt the firmware somehow with in-chip decryptor? B) They don't bother?
-
Someone tried to ask the Russian company if they would return the chip undamaged without a response.
They probably won't. I would not expect that anyway. Why would you need them anyway? If you have the firmware, you can make as many as you need.
However, I realized that the hex-dump question that I asked earlier is moot because we are most likely going to provide the binary firmware image as we upgrade the firmware.
You can encrypt updates. That is a pretty standard procedure.
They'll need to know substantial information, know how and tribal knowledge to be able to write our software.
That's the best kind of IP protection. I don't think there is anything you can do to prevent direct clonning.
A) Do they encrypt the firmware somehow with in-chip decryptor?
This. You can do the encryption in software, there is no need for fancy hardware encryption.
-
@ataradov: I found this: https://github.com/dmitrystu/sboot_stm32 . I need to check the license but it looks promising.
-
Just forget about it, It can be cloned! I have seen big company products like eltek to be reversed :palm:
-
The gist of my curiosity can be captured as "How can we make our firmware *only* run on our hardware."
Thank you :) I am a mechanical engineer but I also do systems programming. However, not much experience in embedded programming so please pardon me for asking if there is an obvious answer.
To add to the answers by others, I think this is ultimately a futile effort. Lot of devices have been cloned without resorting to dumping/reverse engineering the firmware - the cloner simply replaces the MCU or what have you with their own chip and their own code. Often crappy and what not, but it doesn't matter as long as it sells - I guess you have seen all those fake iPhones running reskinned Android, right? Or all those Hakko soldering iron clones? None of those things run the original firmware (or even uses the original circuitry!).
The best protection against cloners is out-innovating them, not spending lots of engineering time trying to find a "fool proof" method of securing of the firmware - only to have some Asian cloner decap the chip and read the firmware out using an electron microscope. Or replace the chip & firmware wholesale, making your R&D time spent on securing the code completely wasted effort that would have been better spent on building your next product.
So lock the firmware down, even use encryption, if you must (but keep in mind that even that can be bypassed - the chip needs the fw unecrypted to be able to execute it and the decryption key needs to be shipped in the device somewhere ...) but don't go overboard with this. Your time & money is better spent elsewhere.
-
If you pay high enough for these people to clone, they can RE everything.
https://www.ltecusa.com/ (https://www.ltecusa.com/)
Just take at look at their publications.
There's nothing safe with enough incentive.
Absolutely.
Points to consider to limit the incentive: from a technical standpoint, avoid distributing firmware updates without any control and unencrypted. That's too easy. Raw images for USB-DFU should be avoided. A bootloader with encryption is a good start, even though the bootloader itself could eventually be copied, but that would take a lot more effort. Avoid having your device completely manufactured by only one company (doesn't seem to be the case here). Lastly, if you took some steps to at least not make it too easy to clone your product, and it still ends up getting cloned (thus requiring effort to do so), it will usually mean your product is very successful. That's good news. Then the only real way clones could harm your business is if you have been selling this one product for too long. If you don't have new products on a regular basis, your company will eventually die, whether your products are cloned or not.
-
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.
-
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.
-
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.
-
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.
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.
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.
-
@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.
-
No but you're going to ask for more $ and thus set a higher barrier to entry than if the product is easy to clone, so it's not exactly what people will jump for as a first step...
-
@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.
If it's some commodity simple thing without any very new technology, I can probably clone it without getting the physical product on hand.
I can work out how something works just from its marketing material, and a PCB photo will only help. And I'm certainly not the only one who is gifted this capability.
i dont call it cloning. its more like market/product/engineering research. big brand competing companies also did this kind of thing. similarly if you just take a product you want to "clone", remove the original chip, and put your own chip with your own fw, i still dont call that cloning, more proper termed as immitation. clone means we have the original FW and program empty chip without any programming skill effort. 100% similar copy both HW and FW side, cant be distinguished from original. immitation is only similar on the outside, when looking the inside, we know its not original, imho.
-
Well, it's a form of cloning, and many chinese companies actually do this AFAIK. Yes it's a complete development. It requires effort. But they are copying the concept and possibly the image of the product, which are valuable if the product has already been successful on the market. It actually removes one of the biggest uncertainties when it comes to releasing a new product: will it sell? So there is incentive to do it even if it requires significant R&D work.
Obviously, unless they are provably infringing on a trademark or a patent that covers your product (and you have means of defending it), there is absolutely nothing you can do about it.
-
Bye bye spammer....
-
What if they just clone the looks, name, logo and imitate some function, sell if for way less, and then you have angry customers?
-
Don't overestimate the value of your code. As a user I don't appreciate products with locked down bootloaders and being able to rewrite or modify the firmware is a big advantage (mostly because the vast majority of products these days ship with garbage firmware). It's funny reading about trying to "protect" that shit. I don't care about your rubbish piece of crapware I want to be able to run my own code on it.
-
Don't overestimate the value of your code. As a user I don't appreciate products with locked down bootloaders and being able to rewrite or modify the firmware is a big advantage (mostly because the vast majority of products these days ship with garbage firmware). It's funny reading about trying to "protect" that shit. I don't care about your rubbish piece of crapware I want to be able to run my own code on it.
When's the last time you rewrote your TV or toaster firmware?
Really ? on how many items that you have bought have you actually modified the firmware ?