STM32 - can cloning be prevented?

[ajb]

Of course it's cube, so it will have the usual tradeoffs--the compiled size of the bootloader is will be of particular concern here, since that eats into available application space.

How does this protect against flash dump? There is nothing you can do without underlying hardware support.

Of course it doesn't, but with an insecure update process it's not necessary to dump the flash at all.  Obviously you'd be better off starting with an MCU with thorough security built in, but the more security you demand at the silicon level the more limited your part options become.  How many MCUs even have dedicated key storage, for example? 

In the end it comes down to whether or not the cost of the additional protections leads to a commensurate or better increase in revenue.  If you're making, say, $20 per unit, then an additional $5k of development time has to eliminate at least 250 clone sales to be worthwhile.  (actually, not just eliminate those clone sales, but turn them into legit sales.  For something like the J-Link probes where a clone costs $10 and the real deal costs $600, a lot of people who are buying clones aren't going to suddenly start buying the legit hardware if the clones stop being available!)

[Kjelt]

If they have the original firmware and bootloader that performs the update it is all useless.
You're security check will just be circumvented in the bootloader, always jump to the "DoFirmwareUpdateFunction()" no matter what the security check function outcome is, with or without fancy security IC. Just change one byte maybe a few in the bootloader which looking at assembler is a piece of cake and done.

As long as the microcontroller it self has no real secure area that can be used to store secret keys and even better run some calculation on it all seperate from the main core, you can better put your energy in making a good product.

The legal way is also not always fruitfull, we had an EU import ban on the chinese clones but they came in through other routes to the EU (China -> Russia -> Poland), hopeless to start suing, takes years and the manufacturer is almost unreachable in China mainland and think about the costs, international lawyers burn up your profit in real time.

Best thing IMO to do is come out each year / two years with a better and newer product with a newer product number and hope legit customers buy the latest and greatest and support your loyal customers.

[Peabody]

Another way for 50 dollar mass volume products is simply go the other route, use courts and sue for counterfeit.
Also as a US based company you have the luxury of direct legal channel to ask for ,dont remember whats its called, homeland patriotism or so to block foreign imports if it hurts domestic manufacturing.There is a known case of a US TV manufacturer who used this and won. Or just bribe your legislator.

No, actually, the manufacturer in this case is a Chinese company.  I don't know if that makes it easier to sue, or more difficult.

[Peabody]

If they have the original firmware and bootloader that performs the update it is all useless.
You're security check will just be circumvented in the bootloader, always jump to the "DoFirmwareUpdateFunction()" no matter what the security check function outcome is, with or without fancy security IC. Just change one byte maybe a few in the bootloader which looking at assembler is a piece of cake and done.

This is where I keep coming out.  As long as they have access to in-the-clear code, it can be modified to bypass all the protections.  It may not  be possible to update the firmware, but the initial sale will have already taken place.

But what about this.  The product is shipped with a significant part of the flash firmware encrypted.  Each part will have a unique key, which is some value embedded in the ATSHA204A .  The original buyer will have to go to the manufacturer's site, enter the serial number, and get  the key, which he will be prompted to enter when he first boots the device.  After that, the encrypted portion will be decrypted to RAM each time the device boots, and will run from there.  Similarly, for a firmware update, the user would need to download his own unique encrypted version, which after flashing would work the same way.

The idea is that you depend on cryptography to obscure a big part of the firmware.  But I'm not sure this does any good.  If they can read out the contents of ROM and Flash, couldn't they also read out the decrypted firmware in RAM?

Well, I suspect there's no foolproof solution to this.  If there was, I think I would have run across that AN or white paper by now.

[ataradov]

If I have access to device flash, I can trace the decryption to RAM process. If you can't rely on a chip lock, then there is absolutely nothing you can do. And if you can, then the whole thing is pretty trivial.

[Elasia]

If you want any form of decent protection by way of economics because it isnt cheap at all to clone this method....

You start using FPGA and CPLD chips... forget everything else. 

Even if you got dozens of samples its very hard when compared to decap and microprobing / selective uv bombardment erasure

[Peabody]

If I have access to device flash, I can trace the decryption to RAM process. If you can't rely on a chip lock, then there is absolutely nothing you can do. And if you can, then the whole thing is pretty trivial.

Yes, and instead of decrypting to RAM, you could decrypt to the serial port.  Well, so much for that idea.

So if you could rely on chip lock, how would you handle firmware updates?

[ataradov]

So if you could rely on chip lock, how would you handle firmware updates?

Firmware is encrypted in transit with a fixed key and bootloader knows the key, which is stored inside the device flash. It is on you to not distribute the key publicly. One of the critical things here is how the key is provisioned in a first place. If it is right in the binary that you gave to folks in China, then you can say goodbye to that key. So factory can only program the empty bootloader and lock the device. Actual key provisioning has to be done in a trusted environment. Obviously this complicates things quite a bit.

This is a good enough approach for low to medium value targets.

[Kjelt]

I agree but would add secure key derivation (NIST has a paper on it) so you never use the original key but always a derived key, you only need to add some overhead info in front of the firmware.
Also not only encrypt (with some secure mode of operation ofcourse) but also calculate a secure hash with a different (derivated) key. You could use the same secret key but different derivations for encryption and hashing.

As Ataradov stated correctly if you manufacture the device in an untrusted factory , like China, you don't want those secrets to be programmed there, it needs a seperate step.

[Marco]

If you are going to be paranoid better to program the whole thing yourself, if they don't know the encryption used it will be harder to use differential power analysis.

Obscurity adds security.

[Peabody]

I agree but would add secure key derivation (NIST has a paper on it) so you never use the original key but always a derived key, you only need to add some overhead info in front of the firmware.
Also not only encrypt (with some secure mode of operation ofcourse) but also calculate a secure hash with a different (derivated) key. You could use the same secret key but different derivations for encryption and hashing.

As Ataradov stated correctly if you manufacture the device in an untrusted factory , like China, you don't want those secrets to be programmed there, it needs a seperate step.

I guess I don't understand what all the extra key deriving and hashing accomplishes.  If Read Protect works, then it seems an appropriate encryption algorithm and key should make it computationally infeasible to brute force.  All the other stuff would let you do is brick the device if you detect it has been hacked, and I don't think they want to do that (see FTDI).

The company producing and selling this product is Chinese.  So everything is going to happen there.  But I take your point that the actual secrets shouldn't be flashed into the chip by whoever they use to manufacture and populate the boards.  I'm sure they are aware of those risks from their own countrymen.

[ataradov]

I guess I don't understand what all the extra key deriving and hashing accomplishes.  If Read Protect works, then it seems an appropriate encryption algorithm and key should make it computationally infeasible to brute force.  All the other stuff would let you do is brick the device if you detect it has been hacked, and I don't think they want to do that (see FTDI).

It prevents attacks on multiple encrypted firmware images. We can assume that attackers have all encrypted images. But many MCU programs have predictable parts, like interrupt vector table in the beginning. There are weaknesses in secure algorithms that come with key reuse on the same data. Key reuse is a big no-no.

Including a nonce in the image and deriving the key for each image solves all of that.

I wrote an application note for secure bootloader. It is mostly for SAM D10, but there is an appendix with a general theory. Here is a link ww1.microchip.com/downloads/en/AppNotes/00002570A.pdf . Encryption and authentication do not need to be hard and take a lot of space, especially for bootloaders. Even simplest encryption algorithms are plenty strong to have attackers look for some other way in.

[Kjelt]

If you are going to be paranoid better to program the whole thing yourself, if they don't know the encryption used it will be harder to use differential power analysis. Obscurity adds security.

This is against any good security advise, the chance you make it worse is much much greater than that it improves security.
I once have worked with PhD's to redesign a security protocol because the existing protocol was too costly on RAM.
A year later I think I found 20 or so weaknesses that were introduced, so the whole thing went in the dumpster.

[ataradov]

He is not suggesting to design your own security, just keep the regular one (semi-)secret. You are not relying on the secrecy of the scheme, it just prevents people from immediately targeting a specific implementation.  And it is not a bad advice.

[Kjelt]

It prevents attacks on multiple encrypted firmware images. We can assume that attackers have all encrypted images. But many MCU programs have predictable parts, like interrupt vector table in the beginning. There are weaknesses in secure algorithms that come with key reuse on the same data. Key reuse is a big no-no.
Including a nonce in the image and deriving the key for each image solves all of that.

Indeed. Using a single key is not done anymore, even the Germans in WW2 changed their keys dayly. Still they were cracked because the start of their message was almost identical each time (weather forecast etc.) and they signed their messages always with the same HH 

Encryption and authentication do not need to be hard and take a lot of space, especially for bootloaders. Even simplest encryption algorithms are plenty strong to have attackers look for some other way in.

AFAIK XTEA is still secure, it only takes 10 lines of C -code. Would not recommend it for strong security applications but for simple stuff or own stuff it is still nice.

[Kjelt]

He is not suggesting to design your own security, just keep the regular one (semi-)secret. You are not relying on the secrecy of the scheme, it just prevents people from immediately targeting a specific implementation.  And it is not a bad advice.

Yeah but pretty useless, if you for instance use AES-128 every hacker sees the 10 S box cycle computation return in the power analysis.
But indeed keeping quiet does not worsten the situation 

[ataradov]

And that's why he suggests to program the whole thing yourself, so hackers don't see S-boxes.

This is on opposition to letting the factory program the bootloader, but programming the keys yourself. The argument is that it is better to program the whole thing yourself.

[Marco]

Yeah but pretty useless, if you for instance use AES-128 every hacker sees the 10 S box cycle computation return in the power analysis.
But indeed keeping quiet does not worsten the situation 

There's a multitude of vetted algorithms and implementations out there, simply not picking AES for this strengthens the security. Obscurity helps.

[Kjelt]

There are only a handfull secure and approved algorithms out there.
You suggest choosing a different algorithm for instance like threefish? As long as you don't invent the encryption algorithm yourself unless your one of the top notch encryption persons in the world you won't make it more secure. Re-coding to obscure the calculation cycles is possible but makes it sloooooooooooow.

[ataradov]

Handful of algorithms + unknown image format (where is nonce in this noise?) make it pretty hard to identify which once is actually used and how exactly.

[Acecool]

Why not add a software solution.... If there is a display, then display ( this item is counterfeit - call law enforcement to report the seller ) after a set period of time... Deviate the message and break it up so the string isn't easily findable...

Adding too much protection simply adds costs to the unit which need to be passed on the consumer and loses you profit margin - that money could be spent on making the product better... Adding 'protection' punishes the consumer, no one else... But, a software solution with your flash could at least expose who did it forcing them to stop after legal issues... It's also low enough profile that they may miss it..

You could do the same thing as CodeMasters, the developers of Operation Flashpoint. They created something codenamed Fade - a technology which when it detects a bad copy of the game via stolen serial number, or other means, it slowly degrades the performance of the game until it is unplayable... There were cases of false positives and that is something that has to be resolved, but the solution isn't bad because the counterfeiters will likely only turn the devices on for a moment to test they power up - they rarely ever use the device long enough to encounter something like this... The one thing you'd need to do is have a solid way to detect forgeries....

The best defense is a good offense in this case instead of defending the product, charging more to consumers, etc.. attack the forgers who will use your code or a variation of it to run their counterfeit products.... You could add a fade method to detect forgeries if the uploaded data isn't exactly what you provide ( this limits custom modifications which isn't always good ), or you can use resistance, etc.. to detect... Use a cheap circuit to monitor a component - something you know the counterfeiters would use a poor quality variation of, or something along those lines... Then you can target the hardware specifically... Make the circuit integral into the functionality and not obvious as to the purpose..


There are many different ways to protect your work - however if you punish customers who rely on your work then they will go elsewhere and you'll lose the money anyway... Counterfeiters remove things that ruin products - they remove DRM, they remove spyware, nagware, bloatware, and other garbage from everything they release. If you download a game without buying it, you won't have to deal with third party software which can monitor your computer, modify data, scan for other things, etc.. so there really is a benefit to people who want their privacy and other reasons which is why people will download games, movies, etc.. instead of buying them because when they buy, they are violated repeatedly by the manufacturer...

It is a narrow line between protecting your product and screwing your clients.

I personally don't buy games with extensive DRM, or I return them when I find out ( legally even opened games, movies, etc.. can be returned if you don't agree with their terms of use / or end user license agreement and no store can refuse to refund you if you don't agree with the license because you can only view it after you've purchased it ).. I've had games previously which installed DRM which ended up doing some very malicious things with my computer such as using my processing power and frying my components while idle, deleting files, editing files, etc.. despite having no illegal material.... There are plenty of games which install 3rd party software which runs 24/7 and you can't do anything about it other than not buying it, or not installing it... if you stop the tasks running or delete them, then the game won't run at all... but if you leave them running, they behave maliciously like a virus, track you, and can even give out passwords by opening backdoors - it's a disgusting practice... It's also why I don't put thirdparty software with my releases...

[Kjelt]

You can not compare online games with a standalone hardware product.
Being 24/7 or regularly connected to the internet in order for the product to operate brings a lot of possibilities that standalone unconnected hardware simply does not have.

[andersm]

Segger have a product which they claim solves the factory programming problem. I have no idea about how secure or insecure it actually is.

[Peabody]

I've found a possible problem with STM32 read protection.  ST offers a program called STM32 Flash Loader Demonstrator, and that's what this company has recommended to customers in the past for appying firmware updates.  However, it appears this program can be configured to leave the RDP setting at zero after flashing new firmware.  I'm getting this from UM0462, and need to test it.  But if that's true, then read protection would not survive the first firmware update if the system bootloader is used.

So that would mean that the custom bootloader, in addition to decrypting the firmware file, would also have to reapply RDP at level 1, if that can even be done from the bootloader.

[Yansi]

No, ST does not recommend FLASH Loader Demonstrator for production. If the company has used it, likely their fault.

Here is a list of production programming tools:
http://www.emcu.eu/wp-content/uploads/2016/10/en.stm32_production_programming_solutions.pdf

Please note that STLINK is not a production tool either.

Y