Author Topic: STM32 - can cloning be prevented?  (Read 27210 times)

0 Members and 1 Guest are viewing this topic.

Online agehall

  • Frequent Contributor
  • **
  • Posts: 381
  • Country: se
Re: STM32 - can cloning be prevented?
« Reply #75 on: May 10, 2018, 08:11:43 am »
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

I'm not referring to production.  Demonstrator is what customers use to flash the latest firmware update to their device.

Doesn't lowering RDP erase the flash? I don't see a problem here...
 

Offline Yansi

  • Super Contributor
  • ***
  • Posts: 3893
  • Country: 00
  • STM32, STM8, AVR, 8051
Re: STM32 - can cloning be prevented?
« Reply #76 on: May 10, 2018, 09:22:53 am »
Yes it does, however if you give em the binary to flash it with the Loader Demonstrater, then what is the purpose of the RDP?

No wonder the product got cloned, if you are distributing the binary for update like this to customers. just rofl.
 

Offline PeabodyTopic starter

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #77 on: May 10, 2018, 02:16:39 pm »
Yes it does, however if you give em the binary to flash it with the Loader Demonstrater, then what is the purpose of the RDP?

No wonder the product got cloned, if you are distributing the binary for update like this to customers. just rofl.

To be fair, the manufacturer refers customers to the Loader Demonstrator for flashing firmware updates.  But recommended or not, Demonstrator is available to anyone who goes to the ST site.  It's freeware, available to anyone, including clone guys.  Anyway, even if the device arrives with RDP set to level 1, all of that is unwound in the process of doing the first update, which leaves the device updated, but with RDP set to zero (it can be reset to one, but that isn't required).

Demonstrator of course uses the system ROM bootloader, which I believe has no provision for encryption, nor does it automatically set RDP to 1 after flashing.  So if updates are to be done at all, it seems the manufacturer will need to write their own custom bootloader, and their own Windows app to drive that process (or build in a microSD port, which would be my preference for a variety of reasons - like Dave does updates on his new meter).

Speaking of Dave, I wonder if he does anything to prevent firmware readout.


 

Online ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #78 on: May 10, 2018, 07:33:20 pm »
To be fair, the manufacturer refers customers to the Loader Demonstrator for flashing firmware updates.  But recommended or not, Demonstrator is available to anyone who goes to the ST site.  It's freeware, available to anyone, including clone guys.  Anyway, even if the device arrives with RDP set to level 1, all of that is unwound in the process of doing the first update, which leaves the device updated, but with RDP set to zero (it can be reset to one, but that isn't required).

But if you're using the built in bootloader & demo software, you have to send the customer an unencrypted binary image, so you've already lost anyway.  With RDP set to 1, the factory bootloader cannot access main flash, which is why it has to clear RDP.  But a bootloader in flash can access flash, so it can reprogram the chip without clearing RDP.  And BTW, it is possible to set RDP or any of the other option bytes from application code, although a reset is required to apply certain changes. 

MCUs that have secure key storage where keys can be programmed but not read out could in theory implement quite secure ROM bootloaders (as long as serious care is taken to avoid leaks), but generally ROM bootloaders are only useful if you don't care about security.
 

Offline westfw

  • Super Contributor
  • ***
  • Posts: 4196
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #79 on: May 11, 2018, 05:17:07 am »
Quote
Direct programming is never slower. I know, I made a tool that does direct programming over SWD (https://github.com/ataradov/edbg).
"Never" seems like a pretty strong statement.
Isn't that highly dependent on the NVM controller of the chip, the SWD hardware implementation and its communications link with the PC?   I can easily imagine a chip that is set up in such a way that each word of flash programmed ends up taking multiple "full-speed" USB transactions over a not-so-fast CMSIS-DAP driver.  For example, while the SAMD chips seem to have nice 64-word flash page buffer written as normal memory before each "program flash" command, but the Kinetis-E chip I'm looking at (MKE02) seems to only program two words for each command :-(  Sort of like the occasional USB-ISP programmer for AVR that works over an HID interface, and does one 4-byte ISP command at a time...
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: STM32 - can cloning be prevented?
« Reply #80 on: May 11, 2018, 05:39:42 am »
"Never" seems like a pretty strong statement.
Ok, you can always come up with poor architecture that prevents efficient programming.

but the Kinetis-E chip I'm looking at (MKE02) seems to only program two words for each command :-(
That is fine. SWD_TRANSFER is actually a very powerful command that can poll for a value specified number of cycles. So each frame can carry two words of data, instruction to poll for the ready bit. And 64-byte frame can probably fit 4-5 such sequences. Given that programming two words takes 0.2 ms, it will done be right in time for the next USB request.

And this even remotely a problem on Full-Speed devices. With High-Speed you don't need to worry about any of this.

This is obviously very part-specific, and I don't expect generic tool vendors to do things this way. But that's always the difference between well-crafted software, and generic stuff.

PS: CMSIS-DAP and SWD protocols are miracles of good engineering. Whoever designed them managed to work around USB limitations in a very beautiful way. There is stuff to be learned from their design.
« Last Edit: May 11, 2018, 05:54:50 am by ataradov »
Alex
 

Offline PeabodyTopic starter

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #81 on: May 15, 2018, 04:57:55 pm »
Ataradov, the Wikipedia entry for RC4 lists the RC4 variants, including Spritz, but it says Spritz has been broken.  However, I looked at a pdf of the referenced paper, and it seems to me that "broken" may be an exaggeration, at least as to any effect on a firmware file of a couple hundred K.

https://eprint.iacr.org/2016/092.pdf

What do you think?

I looked at your AN, and also found an STM32 bootloader with encryption in C on Github:

https://github.com/dmitrystu/sboot_stm32

The arc4.h and arc4.c files are pretty short.  I really didn't know it was quite that simple.  It seems the biggest challenge is not the encryption, but figuring out a way to get the device flashed intiially without giving all the secrets away.

Also, I assume the firmware update file should be an encrypted version of the raw binary, not an encrypted version of the .hex file.  (The .hex file has "[CRLF]:10" at regular repeating intervals.)

 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: STM32 - can cloning be prevented?
« Reply #82 on: May 15, 2018, 05:03:23 pm »
Ataradov, the Wikipedia entry for RC4 lists the RC4 variants, including Spritz, but it says Spritz has been broken.  However, I looked at a pdf of the referenced paper, and it seems to me that "broken" may be an exaggeration, at least as to any effect on a firmware file of a couple hundred K.
"Broken" is not the right word to apply to security ciphers. There are a number of reduction of strength attacks. But most of them are irrelevant, since even reduced strength is way more than required in practice. No point of attacking the encryption if it is cheaper to just decap the device and dump the flash.

I've heard that it can be as cheap as $500 to dump some devices. Not sure how true that is, since it is very hard to find verifiable information on this.

The arc4.h and arc4.c files are pretty short.  I really didn't know it was quite that simple.  It seems the biggest challenge is not the encryption, but figuring out a way to get the device flashed intiially without giving all the secrets away.
There are a lot of very simple algorithms that are plenty strong for this application, even XTEA is string enough. And yes, the real challenge is initial programming.

Also, I assume the firmware update file should be an encrypted version of the raw binary, not an encrypted version of the .hex file.  (The .hex file has "[CRLF]:10" at regular repeating intervals.)
My implementation uses raw files, since hex files are pointless. And it is impractical to parse hex files on the device anyway.
« Last Edit: May 15, 2018, 05:07:45 pm by ataradov »
Alex
 

Offline PeabodyTopic starter

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #83 on: May 16, 2018, 12:12:38 am »
It seems that RC4, or something like RC4+, would be a good bit simpler to code than Spritz.  If the first bytes of output were discarded from RC4, and key+nonce lengths of 32 bytes used, do you think it would be adequate for this purpose?  Reading about all the vulnerabilities of RC4, it seems a large amount of traffic has to be processed to break it, and here we would only be looking at a few update files, each with a different nonce.  Isn't it really, really unlikely the encryption could be broken with any reasonably acceptable effort, particularly when, as you say, there are decapping options available?  I just don't want the company to spend a lot of extra time on Spritz only to discover that the cloners got in another way.  Based on my reading, it just seems RC4 or RC4+ would be really simple, and good enough for this, if encryption is going to protect them at all.
 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: STM32 - can cloning be prevented?
« Reply #84 on: May 16, 2018, 12:31:46 am »
RC4 will probably work too. I liked Spritz for some of its properties, like sponginess. The whole implementation is ~150 lines of code just written straight up from the original whitepaper. It takes a day to implement and debug.
Alex
 

Offline PeabodyTopic starter

  • Super Contributor
  • ***
  • Posts: 1965
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #85 on: May 20, 2018, 07:57:11 pm »
I've had further communications with the company I'm working with, and they've decided to implement encryption for all firmware update files.  I've suggested the following method to protect the master key and the firmware itself from being copied during manufacture:

Their production contractor would flash into the chip ONLY the custom bootloader, including a temporary master key.  Then the company itself would flash the firmware and the real master key to the device.  An alternative would be that the company flashes only the real master key, overwriting the temporary key, and ship the device with no firmware installed.  Then the customer would download the encrypted firmware from the website and flash it with the custom bootloader.  The disadvantage of that alternative is there would be no opportunity to test the device before shipping.

This system would require that the master key can be erased and reflashed independently from both the bootloader and the operating firmware.  It think that just means it has to be in its own 512-byte erase block.

They understand that decapping is a possibility, but there is very little cost to the encryption, and forcing the counterfeiter to pay some amount of money to get the decapping done just might be enough to discourage him.

 

Offline ataradov

  • Super Contributor
  • ***
  • Posts: 11228
  • Country: us
    • Personal site
Re: STM32 - can cloning be prevented?
« Reply #86 on: May 20, 2018, 08:02:08 pm »
This is the approach I would take. With the firmware updated at the factory, even if takes a bit of time. It is better to have the device functional out of the box.

I personally started including keys as part of the bootloader itself, and my bootloaders are capable of updating themselves. So the key update is the same operation as bootloader update. And of course new bootloader is encrypted using the old key, so the only way to update the key is to know the old one.

The risk of failed updates is almost the same in this case, since if key update failed with a static bootloader, you are still locked out of the device.
« Last Edit: May 20, 2018, 08:03:58 pm by ataradov »
Alex
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: STM32 - can cloning be prevented?
« Reply #87 on: May 20, 2018, 09:19:24 pm »
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

So instead of someone cloning your MCU firmware they will get it from the configuration flash of your FPGA - which typically has no read protection at all. That is really helpful in this context  :-DD

And flash-based FPGAs/CPLDs are about as secure as any flash-based micro. That's only security by obscurity, nothing else.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: STM32 - can cloning be prevented?
« Reply #88 on: May 20, 2018, 10:47:45 pm »
So instead of someone cloning your MCU firmware they will get it from the configuration flash of your FPGA - which typically has no read protection at all.
Many FPGAs support encrypted bitstreams (see eg. Altera's app note Using the Design Security Features in Intel FPGAs). There's been successful attacks against older devices ("On the vulnerability of FPGA bitstream encryption against power analysis attacks: Extracting keys from Xilinx Virtex-II FPGAs"), I'm not sure what the state of the art is, but I would assume newer devices are more secure.

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #89 on: May 21, 2018, 08:50:53 am »
Assume  ::)
 

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: STM32 - can cloning be prevented?
« Reply #90 on: May 21, 2018, 09:51:49 am »
So instead of someone cloning your MCU firmware they will get it from the configuration flash of your FPGA - which typically has no read protection at all.
Many FPGAs support encrypted bitstreams (see eg. Altera's app note Using the Design Security Features in Intel FPGAs). There's been successful attacks against older devices ("On the vulnerability of FPGA bitstream encryption against power analysis attacks: Extracting keys from Xilinx Virtex-II FPGAs"), I'm not sure what the state of the art is, but I would assume newer devices are more secure.

Given the manufacturing complexity this brings and the cost of those FPGAs - typically only the high end parts support encrypted bitstreams - you are better producing a high margin product where this is worth it, not some $50 mass market gizmo where one would commonly be worried about cloning. The FPGA alone would costs more than that.

Also, as Kjelt hinted at, given that there are no independent audits, everything is secret sauce with these FPGAs, you are effectively trusting Intel or Xilinx that a) there isn't a fatal bug in the silicon, b) that there isn't an intentional backdoor. A is not uncommon to find these days and B has been speculated in the past, especially when talking about the so called secure FPGAs certified for governmental applications.

« Last Edit: May 21, 2018, 09:55:50 am by janoc »
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #91 on: May 21, 2018, 03:37:37 pm »
With a flash FPGA you could implement your own update procedure internal to the FPGA at least, so you don't have to rely on the existing encryption.

They also often have anti-tamper features like internal clocks and temperature detection which on microcontrollers are only available on NDA'd ones.
 

Offline andersm

  • Super Contributor
  • ***
  • Posts: 1198
  • Country: fi
Re: STM32 - can cloning be prevented?
« Reply #92 on: May 21, 2018, 05:15:36 pm »
Also, as Kjelt hinted at, given that there are no independent audits, everything is secret sauce with these FPGAs, you are effectively trusting Intel or Xilinx that a) there isn't a fatal bug in the silicon, b) that there isn't an intentional backdoor.
The same concerns apply to every integrated circuit. But if you're going down that road, then you're not making electronics, full stop.

Offline janoc

  • Super Contributor
  • ***
  • Posts: 3781
  • Country: de
Re: STM32 - can cloning be prevented?
« Reply #93 on: May 21, 2018, 06:40:38 pm »
Also, as Kjelt hinted at, given that there are no independent audits, everything is secret sauce with these FPGAs, you are effectively trusting Intel or Xilinx that a) there isn't a fatal bug in the silicon, b) that there isn't an intentional backdoor.
The same concerns apply to every integrated circuit. But if you're going down that road, then you're not making electronics, full stop.

Definitely. The point was more that it is rarely worth going overboard with trying to make something "clone-proof", wasting tons of engineering effort that could have been spent on actually making a better or new product instead. And then someone discovers a bug or a way to recover your encryption keys and it was all for naught.
 

Online ajb

  • Super Contributor
  • ***
  • Posts: 2582
  • Country: us
Re: STM32 - can cloning be prevented?
« Reply #94 on: May 21, 2018, 06:43:32 pm »
If the company is willing to reflash the chips anyway, the contract manufacturer doesn't need the bootloader at all.  Instead the company can send the CM a basic test program that just does whatever functional tests the CM needs to do before shipping. 

If there isn't a debug header accessible once the device is fully assembled, you could even use the ROM bootloader to initially load the real bootloader after receiving the devices from the CM.  The bootloader can then set the device's readout protection and, at least on some devices, change the boot address to disable the ROM bootloader.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #95 on: May 21, 2018, 09:02:54 pm »
As long as uC's and FPGA manufacturers can not use security features as major selling points where their major clients are willing to pay a premium for, it will always be a smalltime PR effort.
If you have seen what companies as Riscure in the Netherlands can do to electronic devices to retrieve keys or break their security with side channel attacks and analysis it is hopeless unless you spent  major $ on your product. This is only interesting for high security or big money products such as paycards, tv smartcards and such. Those companies will loose major $ if their security is broken and they are willing to spent a lot of effort to prevent this.
I did hear that new microcontrollers are surfacing that have an integrated security vault with the same security features such as metal layering, tamper detection etc.
Probably this will be two ic's in one package but till I see a real datasheet this is a guestimate from my side.
 

Online Marco

  • Super Contributor
  • ***
  • Posts: 6694
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #96 on: May 22, 2018, 03:01:34 am »
Unfortunately all the micros with shielding, tamper detection and zeroization are either limited to just doing a couple of crypto-functions or buried under NDAs.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #97 on: May 22, 2018, 07:02:23 am »
Unfortunately all the micros with shielding, tamper detection and zeroization are either limited to just doing a couple of crypto-functions or buried under NDAs.
At the moment yes, but change is coming, or should be coming is better stated.
The big question is: when?
IoT devices without proper security is the end of the internet, no serious company wants to see their product on the IoT wall of shame, or mentioned as the main culprit in a large DDOS attack.
 

Offline Jeroen3

  • Super Contributor
  • ***
  • Posts: 4067
  • Country: nl
  • Embedded Engineer
    • jeroen3.nl
Re: STM32 - can cloning be prevented?
« Reply #98 on: May 22, 2018, 07:10:42 am »
Unfortunately all the micros with shielding, tamper detection and zeroization are either limited to just doing a couple of crypto-functions or buried under NDAs.
That is still security trough obscurity.
Don't forget the import/export restrictions.
 

Online Kjelt

  • Super Contributor
  • ***
  • Posts: 6459
  • Country: nl
Re: STM32 - can cloning be prevented?
« Reply #99 on: May 22, 2018, 08:44:27 am »
Unfortunately all the micros with shielding, tamper detection and zeroization are either limited to just doing a couple of crypto-functions or buried under NDAs.
That is still security trough obscurity.
Don't forget the import/export restrictions.
I am not sure if the NDA's are there to obfuscate their security implementation because the datasheets I have seen are absolutely not about silicon topography.
The used encryption algorithms are pretty much known so hiding that would also be a bit strange.

IMO those companys NDA's are there to keep the future roadmaps of the vendor restricted and my guess is also to prevent large customers to re-sell the chips.
The large volume discounts I have heard off are really steep, so it would be very interesting for a large company to buy 10 times more chips and re-sell them to (smaller) other companies. But that's my two cents.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf