STM32 - can cloning be prevented?

[Marco]

Why does only Microchip offer a public pre-programming service? You'd think it would be easy money, is everyone else just too scared of offending their distributors?

[Yansi]

Why do you think that only Microchip does it? If you become large enough customer for any kind of company, they will do almost anything to help you out. 

I think Microchip would not be bothered wit programming your firmware either, unless you are one of their big customer. (like $100k or more annually)

[Marco]

Microchip direct has a minimum order cost of 60$, a bit shy of 100k$. Their program is public instead of the bespoke deals you can make with other manufacturers.

As for why they do it, it's a competitive advantage.

[Kjelt]

So they take them out of the reel program them laser the package and re-reel them for you if you order $60 ?
I don't think that is easy money that is loosing money 

[Marco]

So they take them out of the reel program them laser the package and re-reel them for you if you order $60 ?
I don't think that is easy money that is loosing money 

There's a 29$ setup cost, they don't do it for free ... they just do it for a very reasonable price.

If you offer the programming service to big customers you'll need an automated line to do so any way ... to be able to do it efficiently for small orders you need to have a line which can be reconfigured quickly. That really doesn't add that much to the cost of the robotics, they have to be reconfigurable any way. Not every big customer wants the same thing either. So if you spend the little money and time up front to design those lines well, you can make some extra money and have less competitive disadvantage compared to Microchip. I guess Microchip are just more competent.

[ataradov]

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

I really don't see how this will do anything at all to protect the IP. No matter what you do or how you authenticate the image, eventually it will go though the SWD interface in the clear. And that's where is makes the most sense to sniff it at the stealing end.

[ataradov]

Microchip direct has a minimum order cost of 60$, a bit shy of 100k$.

But the price per part goes up when you do programming. Not by a lot and it certainly worth it in may cases.

And also many if not all distributors will program the parts for you as well. But they typically do have high MOQs for custom parts.

[Yansi]

It does not have to go through the SWD in clear. Don't forget please, that SWD does not program FLASH memory directly, it is only a R/W interface for generic RAM and register area with some command on top (run/halt CPU, etc).

Usually you first put a FLASH loader algorithm program in the SRAM, feed it a chunk of  data to be written and then you run the program from the SRAM, that will program the FLASH memory. I can easily imagine you could implement some cryptography in there.

The large advantage of doing so is that you can write arbitrary flash loaders even for external memory devices, which comes very handy.

[ataradov]

Usually you first put a FLASH loader algorithm program in the SRAM, feed it a chunk of  data to be written and then you run the program from the SRAM, that will program the FLASH memory. I can easily imagine you could implement some cryptography in there.

Yes, and I will sniff you loading the SRAM loader and corresponding keys, and then encrypted data. And then I just run the same SRAM algorithm on the encrypted data outside of the device.

If you can sniff SWD, you can always recover the firmware. No matter what you do on top of it.

[josip]

It does not have to go through the SWD in clear. Don't forget please, that SWD does not program FLASH memory directly, it is only a R/W interface for generic RAM and register area with some command on top (run/halt CPU, etc).

Usually you first put a FLASH loader algorithm program in the SRAM, feed it a chunk of  data to be written and then you run the program from the SRAM, that will program the FLASH memory.

SWD can be used for flashing (any Cortex-M device I know) directly, without executing loader from SRAM.
It is true that is usually used loader executed from SRAM because it is faster method.

[Yansi]

Not true. I can sniff you ethernet cable to your PC, yet I won't be able to steal your data. It is called asymmetric cryptography.

Should work the same with your MCU, shouldn't it?

[ataradov]

It is true that is usually used loader executed from SRAM because it is faster method.

It is not faster, it is easier. Flash loaders let vendors not worry about specific device architecture. The actual programming speed is limited by the Flash, not the interface or the way you get the data into the device.

[Yansi]

It does not have to go through the SWD in clear. Don't forget please, that SWD does not program FLASH memory directly, it is only a R/W interface for generic RAM and register area with some command on top (run/halt CPU, etc).

Usually you first put a FLASH loader algorithm program in the SRAM, feed it a chunk of  data to be written and then you run the program from the SRAM, that will program the FLASH memory.

SWD can be used for flashing (any Cortex-M device I know) directly, without executing loader from SRAM.
It is true that is usually used loader executed from SRAM because it is faster method.

You could possibly do so by manipulating the appropriate registers of the FLASH interface, however that only means you run the flash loader program on the PC, not in the MCU, which of course is the slower and more  stressful  method.

[ataradov]

Not true. I can sniff you ethernet cable to your PC, yet I won't be able to steal your data. It is called asymmetric cryptography.

The trust there is based on a pre-generates certificates one part of which is secret. There can be no secrets over SWD interface. If I have full access to your PC and can sniff your Ethernet traffic, I can get it decrypted.

Should work the same with your MCU, shouldn't it?

Nope.

[ataradov]

You could possibly do so by manipulating the appropriate registers of the FLASH interface, however that only means you run the flash loader program on the PC, not in the MCU, which of course is the slower and more  stressful  method.

Direct programming is never slower. I know, I made a tool that does direct programming over SWD (https://github.com/ataradov/edbg). It basically runs at the same speed as flash loaders do, because the speed is limited by the flash write speed. There is a lot of time spent sitting in a busy-wait loop waiting for the flash to be done writing.

[Yansi]

Then you should state some specific facts, not just fuck off any of my statements with just "nope". That is not nice.

[ataradov]

I explained why it is impossible in the first statement. Ethernet (SSL) security based on the lack of access to the private key. With SWD you have access to absolutely everything.

If you think that it is possible to somehow secure SWD, then propose a scheme. "It should be possible" has only one answer - "Nope".

And the easiest way to bypass any encryption schemes you can come up with is to unplug the programming cable close to the end of the process so that most of the firmware is in the flash, but the lock bit is not set yet. Then go and read the firmware back using a normal tool.

[mikeselectricstuff]

Microchip direct has a minimum order cost of 60$, a bit shy of 100k$.

But the price per part goes up when you do programming. Not by a lot and it certainly worth it in may cases.

And also many if not all distributors will program the parts for you as well. But they typically do have high MOQs for custom parts.

And may not offer the service outside the USA due to retarded export issues - you code might include controlled encryption stuff. Digikey for one won't.
Third-party programming is typically fairly expensive, especially for smaller parts relative to part cost. Microchip can do it cheaply as it's integrated into microchipDirect. In some case, for higher volumes, they actually program parts during wafer test, before packaging.

[Yansi]

I explained why it is impossible in the first statement. Ethernet (SSL) security based on the lack of access to the private key. With SWD you have access to absolutely everything.

If you think that it is possible to somehow secure SWD, then propose a scheme. "It should be possible" has only one answer - "Nope".

Well I am no cryptography expert, but still see a lot of similarity with the PC stuff, even though you deny it working in any way shape or form.

On a different note:
Also I would like to notice there is an interesting feature built into some of the STM32 chips, named PCROP Meaning you can lock a section of FLASH to be jsut readable only using the I-code bus of the core. No way you could use SWD to read that out, even if having the debug access to it.
I can see possible use cases for it regarding the SFU and IP protection, but that is not related to the above about the SWD problem.

[ataradov]

Well I am no cryptography expert, but still see a lot of similarity with the PC stuff, even though you deny it working in any way shape or form.

Again, it is not similar in any way.

In SWD you establish the channel from the tool side, there is nothing on the device side. On a PC you have two sides that are actively communicating to establish a secure channel. The whole security is based on them keeping private parts of the key secret.

And it still would not matter, since all you need to do is not let the device to be locked from reading at the very end.

[Marco]

The Segger docs suggest ST can supply microcontrollers with a secure boot code, which would allow secure programming, but it doesn't seem a public program (they have the X-CUBE-SBSFU solution, but no mention of anything pre-programmed from factory). That's the only way it's going to work, the rest is just security theater.

[Yansi]

As I have said, you need to be a customer of certain business impact, to become involved in such things. As a home-gamer, it is not likely they will supply you the SFU details or any codes. Also a SLA agreement has to be signed as a minimum precursor for that.

A lot of other ST products require SLA and honestly, I am not a fan of that. And many times, it is just funny what they need you to sign the SLA for.

[josip]

It is true that is usually used loader executed from SRAM because it is faster method.

It is not faster, it is easier. Flash loaders let vendors not worry about specific device architecture. The actual programming speed is limited by the Flash, not the interface or the way you get the data into the device.

Maybe we are talking about different things. I was thinking on example like in https://www.silabs.com/documents/public/application-notes/an0062.pdf
where direct SWD flashing rate was 12 KByte/s, while using same SWD rate, but with downloaded loader to RAM rate was 85 KByte/s. It is more complicated, but faster.

[ataradov]

where direct SWD flashing rate was 12 KByte/s, while using same SWD rate, but with downloaded loader to RAM rate was 85 KByte/s. It is more complicated, but faster.

We are talking about the same stuff. And I really don't see why this would be the case. Someone did something wrong there or it is some EFM specific tools issue.

Most of the time you spend programming is in a wait loop for the flash to be ready, and the remaining part is transferring the data, which will take the same amount of time either way. There is no reason for direct programming will be slower apart from inefficient implementation of the programming algorithm on the host side.

[Peabody]

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.