STM32 - can cloning be prevented?

[Peabody]

I've been helping as an alpha tester for a new electronics test gear product.  The company's previous product was very widely copied, including their company and product names. So not just cloned, but counterfeited.  The new product will likely use an STM32F303, and the crypto chip ATSHA204A is also available in the design.  The product has to be firmware upgradeable.

From my research, it appears the read protect function for the STM32 parts, as well as for processors of almost all brands, presents only a temporary stumbing block for the cloner.  There appear to be multiple vulnerabilities, and there's even a Youtube video showing a guy reading out the firmware from a STM32F0xxx part that has the level 1 option set.  And even if that worked, the cloner could just download the first firmware update and be in like Flynn.  By the way, do people younger than me even know who Flynn was?

Anyway, it seems to me there is no solution to this problem if that solution requires keeping the firmware secret.  Is there any other kind of solution that might make use of the ATSHA204A?  I'm thinking of some kind of crypto function that would have to work before the firmware would run.  Or possibly a major portion of the firmware would have to be decrypted on each boot, and run from RAM.   That would require that the firmware updates would have to individualized to each device so as to match the unique innards of each ATSHA204A, but that could be done.

Is there any guidance online on how to actually prevent cloning/counterfeiting of products using microcontrollers?
Or is this really just hopeless?

[sokoloff]

Posting to follow.

[Rasz]

Asking you instead of hiring specialist consulting firm is a signal they dont care all that much.

you can start with those
https://www.blackhat.com/us-18/training/advanced-hardware-hacking-hands-on-power-analysis-and-glitching-with-the-chipwhisperer.html
https://www.blackhat.com/us-18/training/applied-hardware-attacks-embedded-and-iot-systems.html
https://www.blackhat.com/us-18/training/applied-hardware-attacks-hardware-pentesting.html
https://www.blackhat.com/us-18/training/ic-reverse-engineering-and-attacks-101.html

[ataradov]

If you can't consider chip locking to be good enough, then there is really nothing you can do. You can encrypt firmware updates, that's not a problem at all. But decryption key will have to be stored inside the device, so once you have access to the flash contents, you will have the key. But you will also have the firmware to begin with.

You can look at ECC508 and similar chips. They can provide certain protection against clonning. But depending on what the product does, clonners can just re-implement the firmware on their own.

[mac.6]

What you need is secure boot and firmware encryption. Only a few little microcontroller have this option, I recently work on romcode of one, but it's still not openly available.

In this case the firmware key is not stored in flash but fused into the device and cannot be read back (unless decaped and reverse engineered).

[Kjelt]

As mac.6 says is correct if the uC has no special security functionality which almost none have you have an issue.
What you could do to to minimize the issue is indeed give each individual uC its own key (secret device key) and firmware updates have to be unique to some extent also.
Then when a clone shows up in the market you buy it and check the device key , then you blacklist that device, eg no longer issue a firmware for that key.
Now you think you can do this but it takes a lot from the factory and service organization to do this. Best way is to automate it and only allow online firmware updates where you can directly log the ip address of the clones if needed.
You could issue a fake firmware update for those devices that will render the device useless but be carefull with that since the famous ftdi case was clear that some buyers had no clue their device was fake.
I don't know the capabilities of your device but you could in such cases warn the user the device is fake and that they should contact their seller and revert to the simplest earliest firmware and keep the device working.

But in short no you can not prevent cloning of uC's so think of usecases how to deal with clones and blacklist them.

[Peabody]

Asking you instead of hiring specialist consulting firm is a signal they dont care all that much.

They didn't ask me.  All I'm supposed to do is test the UI.  But I was aware of their previous troubles and wondered if anyone had come up with a system that is foolproof (so far).  So far as I know, they are planning to tie the STM32F303 to the ATSHA204A in some way so that the processor will not operate without it's own ATSHA204A being present.

But I don't think that solves anything.  If the cloner can get a copy of the firmware, he can modify it so the processor no longer communicates with the ATSHA204A, and he can use that modified version in his own copy of the device.  Of course it won't be updatable with genuine firmware, but the damage (the initial sale of the clone, which by the way works just like a genuine one) will have been done.

I don't know if they've hired a consultant, but I doubt it.  Anyway, I don't have a solution to the problem, and was hoping someone here knew of one.

[Yansi]

... a Youtube video showing a guy reading out the firmware from a STM32F0xxx part that has the level 1 option set.  And even if that worked, the cloner could just download the first firmware update and be in like Flynn.  By the way, do people younger than me even know who Flynn was?

That vulnerability is only exploitable on STM32F0 series, not others.

Not sure if younger, but Dave already explained in his vijeos on some occasions, who Flynn was.

[T3sl4co1l]

Typical example of how to do that, look at cell phones, or game consoles.

At the most basic, there's a hypervisor: a CPU running from internal mask ROM, including onboard keys (and some other obfuscation features, like extra metallization layers to frustrate decapping, and supply glitch reset circuitry).  It only talks to the boot ROM.  During boot, it checks if the code is encrypted and signed.  If so, it decrypts it to RAM, and the CPU boots.  Otherwise the CPU is held in reset.  No functions are provided to control or manage the hypervisor, nor any BIOS functions are provided by it -- as these could provide a route to reading out its code.

What's an obvious problem with this?  Well, if the update goes wrong, it's bricked.  That kind of stinks.  You might use a staged bootloader process, where there's a secured Flash area, that provides BIOS functions and a recovery screen; and maybe this region can be updated as well (hence Flash versus more mask ROM), but only with signed data (maybe the hypervisor could be called upon to validate a RAM buffer), and only when provided with a separate key (so that, if the bootloader is compromised, the hypervisor is not).

And so on; there are many convenience features that can be added, but each one must be checked for security, and not just individually, but against each other, because emergent patterns can arise even from individually-secure functions.

The hypervisor, by the way, would be a chip that you carefully control the design, production and distribution of.  It's the key to making everything work.  As it verifies and decrypts the boot ROM image (at least in part -- hopefully the whole thing, so that any aberration can be detected, and a suitable fallback executed instead), it can't be bypassed (the CPU isn't running at all yet), and it can't be modified (mask ROM).  (Again, hopefully -- but every function added to it, is another risk that it can be affected somehow.)  It is a single point of failure (once the keys are uncovered, anyone can sign and encrypt their own binaries).  What you might do in production, is assemble and build the systems in China, except for the key store, or hypervisor chip, or whatever.  That way, the system is little more than a brain-dead, useless dev kit, until it is unlocked by the OEM in the final stage of manufacture.

There can be no perfect system, of course, but learning from others' mistakes can at least be helpful.  The Black Hat links above look like just such a thing.

And also in the news, Linux is now running on Switch, thanks to some boners in the hardware that didn't take very long to figure out...

Tim

[westfw]

The company's previous product was very widely copied

What processor did the previous product use, and how was IT protected?
The "read protection" is certainly SUPPOSED to be sufficient (combined with encrypting SW-update procedure for upgrades, of course.)  If you REALLY care, you need to pay attention to which chips have "known and easy vulnerabilities."  Almost any chip can probably be hacked, but it can be a level of effort that not a lot of cloners will attempt except for REALLY VALUABLE end-markets.  Sort of like "locking my car is pointless because it has glass windows anyway" - not really true.  (OTOH, I've heard of people explicitly NOT locking their cars, because having someone break a window looking for valuables that aren't there is expensive and especially frustrating.)

[Mechatrommer]

Sell at cheaper than clone and no bloody one will be interested at cloning yours.

[Peabody]

I appreciate all the comments and suggestions.  This product will probably sell for less than $50.  So I suspect there's a limit as to how much hardware and engineering time can be devoted to making it clone proof, but I'm sure they will do what they can within the limits they face.

I don't know what was done to protect the previous product.  Whatever it may have been wasn't enough.  The cloners reproduced the case, the display, the boards and silkscreens, and of course the firmware.  When people tried to return the fakes to Ebay or AliExpress sellers, the cloners produced documents to the sites showing they had been licensed to manufacture and sell the devices as genuine devices, all of which were complete fakes and forgeries.  So it was pretty much a disaster from the beginning, and Ebay and AliExpress were no help.  I believe buyers of fakes from those sites were typically offered only token refunds, if any at all.

I'm sure the manufacturer will make more of an effort this time, but I just hope they don't fall victim to the FTDI effect.  You can't go bricking something that the customer didn't know was a fake when he bought it.

I was just hoping there was an app note somewhere on how to do this protection effectively from start to finish.  But I think the problem is that so much of the security effort is devoted to prevent "hacking" the device - taking over the device or modifying what it does.  But that really isn't the problem for anti-cloning.  You just need to make the cloner write his own firmware if he wants to copy the device.

[MosherIV]

Build in a serial number into the device, make sure it is located somewhere where it looks like parts of the binary, eg at the ned of the executable binary or in area of emulated EEPROM in flash.
The serial number may need to be encoded in some way, at least so that it is not directly obvious when looking at the raw Intel/Motorola Hex when ready out with a programmer.
(The idea is to make it look like the serial difficult to identify)
Make sure the procedure for entering the serial number is no overly complicated eg as part of the flashing process, there is a part that enters the serial number.

When the cloner come along, they will not realise and clone the serial number.

You should then be able to trace who the original was sold to.

[agehall]

Build in a serial number into the device, make sure it is located somewhere where it looks like parts of the binary, eg at the ned of the executable binary or in area of emulated EEPROM in flash.
The serial number may need to be encoded in some way, at least so that it is not directly obvious when looking at the raw Intel/Motorola Hex when ready out with a programmer.
(The idea is to make it look like the serial difficult to identify)
Make sure the procedure for entering the serial number is no overly complicated eg as part of the flashing process, there is a part that enters the serial number.

When the cloner come along, they will not realise and clone the serial number.

You should then be able to trace who the original was sold to.

And how does that prevent the cloning?

[MosherIV]

And how does that prevent the cloning?

It does not directly stop the cloning.

You are all trying to find a technology driven approach, I suggest a businese driven approach.
Try and track down who is doing the cloning, you can then try leagal means or just stop selling to them in future.
It does at very least present a means to detect clonned deviced ebause they will all have the same serial number.

[sokoloff]

Without a fair bit of effort to have the serial number change change lots of the binary, a cloner can buy two units, dump the firmware, and diff the dumps to find the serial number. For a $50 device, this is no hurdle whatsoever.

[Psi]

i've heard you can deliberately burn out a flash/eeprom pattern into the IC before shipping via excessive writes, then have the firmware confirm this at startup.

Unless they think to check for this anyone copying your IC will copy it onto a new IC with good flash/eeprom and your code can detect it is running on copied hardware.

However i've never looked into implementing this sort of system myself.

[Marco]

In this case the firmware key is not stored in flash but fused into the device and cannot be read back (unless decaped and reverse engineered).

Ignoring hardware bugs you can't directly read back protected flash either, only the running firmware has direct access (on some microcontrollers not even the firmware for code only sections). Bugs and side channel attacks can reveal data in ROM as easily as flash.

IMO the ATSHA204A is only useful as a defense at the the firmware update process. Have the firmware update software check the authenticity of the product through the ATSHA204A.

[MT]

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.

[MosherIV]

So another solution based on technology.....

Similar to what I said before but this time have a 3 part CRC/checsum for the binary, stored just after the binary in flash.
The first part is the actual CRC or checksumming of the binary
Second part, use 32/64 bit epoch time stamp, which must be written prior to the checksum. The timestamp may be the date the unit was programmed or commission (but must be different for every unit)
Third part is to used the ATSHA device to generate a hash number based on both the CRC/checksum and the timestamp.

The code must check at startup the CRC/checksum, take the epoch timestamp and pass both into the ATSHA to re-generate the hash number, if this does not match the one stored then stop the unit from working.

Many companies do something similar for software enabled features

Edit. For some additional security, add some checks on the epoch time stored to make sure the time is valid, ie after the product is released but before something stupid like next century

[ajb]

Just got this in an email from ST this morning, apparently Cube now has a secure firmware update module: http://www.st.com/en/embedded-software/x-cube-sbsfu.html

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.

[agehall]

And how does that prevent the cloning?

It does not directly stop the cloning.

You are all trying to find a technology driven approach, I suggest a businese driven approach.
Try and track down who is doing the cloning, you can then try leagal means or just stop selling to them in future.
It does at very least present a means to detect clonned deviced ebause they will all have the same serial number.

But it's a really crappy solution which also punishes your actual customers. Just like those damn FBI warnings on movies that they insisted on putting on on all DVDs - you only got to see them and get annoyed by them if you paid for the DVD...

[ataradov]

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.

i've heard you can deliberately burn out a flash/eeprom pattern into the IC before shipping via excessive writes, then have the firmware confirm this at startup.

This is an urban legend, which is probably a modern interpretation of damaging tracks on diskettes and mapping the damage for copy protection. This will not work with Flash/EEPROM. And even if it did, it would take forever to achieve.

[JS]

...
The code must check at startup the CRC/checksum, take the epoch timestamp and pass both into the ATSHA to re-generate the hash number, if this does not match the one stored then stop the unit from working.
...

  Please, don't go the FTDI route, nobody likes that, customers who bought the item thinking it was genuine and get them bricked won't be happy with the company, it might hurt the company more than it helps by protecting it. Also they already bought it, so the counterfeit was already sold, the money is already loss.

  The other thing to consider is the market cycle of the product, if it will be obsolete or replaced with a better one in the next year counterfeiting it isn't as rentable as it is if the product would be selling for 10 years, in which case a bit more effort could be putted into protecting it.

  Hardware protection is also possible by making it harder to clone with ancient techniques of scraping part numbers, using custom part codes or potting the thing. Harder to service, specially with potting, but does work to some extent. That over some firmware protection and maybe using some custom parts if possible could make it hard enough to clone.

  A last option I could think is to make something as high security stuff is done, some case open detection which will brick the device, if it's battery powered might be even easier than if it hasn't a battery. When it detects the case is open it corrupts it's internal data and you can't clone it anymore. With the case closed you can't access the jtag/swd port, just some usb connection that's able to write the firmware update but not reading.

JS

[wraper]

A last option I could think is to make something as high security stuff is done, some case open detection which will brick the device, if it's battery powered might be even easier than if it hasn't a battery. When it detects the case is open it corrupts it's internal data and you can't clone it anymore. With the case closed you can't access the jtag/swd port, just some usb connection that's able to write the firmware update but not reading.

That would need to be some extraordinary and expensive effort to make cloning harder by just a little bit. If made simple, it won't stop from cloning, as you can bypass it. You could use secure MCUs for much less.

[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

[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.

[agehall]

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...

[Yansi]

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.

[Peabody]

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.

[ajb]

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.

[westfw]

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...

[ataradov]

"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.

[Peabody]

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.)

[ataradov]

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.

[Peabody]

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.

[ataradov]

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.

[Peabody]

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.

[ataradov]

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.

[janoc]

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 

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

[andersm]

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.

[Kjelt]

Assume 

[janoc]

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.

[Marco]

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.

[andersm]

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.

[janoc]

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.

[ajb]

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.

[Kjelt]

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.

[Marco]

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.

[Kjelt]

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.

[Jeroen3]

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.

[Kjelt]

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.

[ali_asadzadeh]

Everything can be cloned! so add it to your business model   When they can hack every software out there, like windows,altium,keil,solidworks,ISE,matlab, Vivado , quartus,3d max,visual studio etc... and some hardware like J-link have clones too! So you can make your product more complicated to replicate, by adding more complex mechanical case, more layers to PCB, use finer pitch parts, add encryption to your software, add battery backed up encryption keys, add tamper protection, you can make it harder, but if it's worth cloning they would clone it!

Also I have found making a product opensource, prevents many from cloning it! take linux as an example

The best hardware way is to use ASiCs, you can rollout your own M0 for 40K USD ARM license and prevent anybody to copy it easily!

[SiliconWizard]

Actually, having one's product cloned is a very good sign of success.

Now if you keep giving your customers relevant updates and add value by other means (tech support, good after-sales service, ...), your clone competition won't be able to put up. So it will only reach a market share you wouldn't have gotten anyway, and it helps making your product popular. Think of the J-link for instance. Most people buying the clones wouldn't have bought the real deal. (And I can tell you from testing one that they're not nearly as robust either!)

Of course if you don't do any of those things and just never give anything to your customers once the sale is done, the clones will kill you. But you would die sooner or later anyway (unless maybe your product is SO good that it's self-sufficient forever, but that rarely happens).

[ataradov]

The best hardware way is to use ASiCs, you can rollout your own M0 for 40K USD ARM license and prevent anybody to copy it easily!

This is absolutely the worst way to go. First of all, you need to add at least $5-10 million until you get first working parts. And then, what stops clonners from decapping your parts, jut like any other MCU out there? Are you sure you can get the security right on your first try?

[Peabody]

Actually, having one's product cloned is a very good sign of success.

Now if you keep giving your customers relevant updates and add value by other means (tech support, good after-sales service, ...), your clone competition won't be able to put up. So it will only reach a market share you wouldn't have gotten anyway, and it helps making your product popular. Think of the J-link for instance. Most people buying the clones wouldn't have bought the real deal. (And I can tell you from testing one that they're not nearly as robust either!)

Of course if you don't do any of those things and just never give anything to your customers once the sale is done, the clones will kill you. But you would die sooner or later anyway (unless maybe your product is SO good that it's self-sufficient forever, but that rarely happens).

In this case the company provides significant ongoing customer support, including firmware updates.  But it doesn't want to expend resources providing support to clone owners.  The problem is that the clones look identical to the original, and claim to be the original, so the customer has no idea he is buying a clone.  Firmware updates don't work on clones, and may leave the clone bricked, although that's not the intention.  So they are trying to figure all this out with respect to new products.  The irony is that this is a Chinese company.  I guess the counterfeiters don't discriminate based on nationality.

[SiliconWizard]

The problem is that the clones look identical to the original, and claim to be the original, so the customer has no idea he is buying a clone.  Firmware updates don't work on clones, and may leave the clone bricked, although that's not the intention.  So they are trying to figure all this out with respect to new products.  The irony is that this is a Chinese company.  I guess the counterfeiters don't discriminate based on nationality.

I understand your point, and I guess it would all depend on a few factors.

Unless we are talking about a very low-cost product (even the genuine one), the customer usually knows, or at least should reasonably know, that  they are buying a clone. Clones are usually much cheaper - that's the whole point. Now if some clones are sold at prices in the same ballpark as the genuine product, this is another problem: this is just plain rip-off, and the customer would be entitled to get back at the reseller. But it's pretty rare, unless you like buying from very suspect sources. Usually the clones are way cheaper, and a moderately-educated customer should figure out this can't be a genuine product, and if in doubt, testimonies are usually not hard to find before you decide to buy.

If a customer is silly enough to believe they can actually buy a genuine product for 10 times less than the market price, they are living in a fairy world. And if on the other hand, they understand they are buying a clone and still think they will get full support and equivalent quality - again they are fooling themselves. So I personally think this is the customer's responsibility, and in some cases, the reseller's (if they really advertise some product as a genuine one and sells it at equivalent prices). One of the two is not being honest IMO.

Now for very low-cost products, you may not notice the difference, and you can get fooled easily - but it won't matter much, it's cheap.

This is a consideration for end-products. For semi-finished products or components, this is a slightly different story. The responsibility shifts from the customer (or reseller) to the manufacturer using said components. Let's take the FTDI case. A few manufacturers may have bought what they thought were genuine parts, and they weren't. But that's their responsibility. If you care for your business, selecting reputable suppliers is a big part of the story. If you don't, well, you know what to expect. And for the huge majority of manufacturers that were fully aware they were using cloned FTDI chips in their products to lower costs, this is all the more their responsibility: if anything goes wrong, they should fully refund their customers. Plain and simple. In this FTDI case, you may or may not agree with FTDI's move (bricking fake chips) which admittedly was pretty inept, but that doesn't change the fact that the full responsibility lies on the manufacturers' heads.

Anyway, just my opinion.

But just to get back to this "not-aware customers" thing: again apart from plain and obvious rip-off, customers should really get educated regarding their consuming habits in general, especially in this now completely world-wide market. Some people are gullible enough to think that they can get products that are overpriced in the western world, at barely manufacturing costs just because the reseller is from China. This is very rarely the case. Most of those products are either clones, or in some cases, indeed genuine products coming from the plants that manufacture them, but just the ones that got rejected at QC control, so they may present various issues, including being DOA.

[Kjelt]

I have seen cloned products going through proper retail channels because they had no idea they were fakes. That is how good the copycats are these days. The only way the engineers could tell they were fakes was because they used chinese inductors instead of the german branded ones but the rest was identical.
So the customers are not always to blame or should be aware of this.

[C]

The whole PC industry is based on legal cloning.

Start with the legal clone of the IBM PC bios program.
Then you have clones of video CGA, EGA & VGA.

Now from this list is it proper to call these clones or functional work-a-likes.
Does not take much searching that each of these were most likely far better them the original.

So is it proper to call the FTDI a clone or a functional work-a-like?
From what I have seen they are work-a-like. 
So the only problem here is the use of the FTDI software driver unless you can legally protect how a chip works and it's pin-out.
If FTDI did not want their software driver working with NON-FTDI functional chips, Fine make it not work.
They did not have right to harm what they did not create.

That last sentence if important, No one has a right to harm what is not theirs or that they did not create!!

If FTDI could not prevent their driver functioning with a work-alike with out harming work-alike then they had a choice.continue shipping the software & chip or stop shipping these.
A simple live with it or move on to newer software & chip.

Now a simple look at history and you find that IBM tried to take back control of PC with it's PS2 line of computers. A fail for many reasons.

Now I have problems with sellers not stating it is a FTDI Clone or FTDI work-a-like. Would be even better if the chip was better then original like has happened with PC's.

Your customer wants the best hardware & software for a cheap as passable price.

The higher the price for what is received, the more likely a clone or work-a-like will happen.

You should build what you can easily, quick and cheap and start designing/making a better model.

Some micro-controllers come with a built-in serial number. Most have some ways to protect firmware.
Do the best you can with out high expense and call it good.
The higher the cost the more likely someone will start looking for a security hole in what is created.
A tiny hole can bring down the mighty.

The result could be legal or not legal.

C

[ataradov]

They did not have right to harm what they did not create.

They had the right to write their drivers however they feel like. If "work-alikes"  reused USB VID/PID numbers, but are not fully compatible, then it is work-alikes problem, not FTDI's.

[C]

They did not have right to harm what they did not create.

They had the right to write their drivers however they feel like. If "work-alikes"  reused USB VID/PID numbers, but are not fully compatible, then it is work-alikes problem, not FTDI's.

Simple then show where FTDI can buy simple numbers as that is what they are. No body can buy numbers, someone can grant their use but they are not owned.

C

[ataradov]

Simple then show where FTDI can buy simple numbers as that is what they are. No body can buy numbers, someone can grant their use but they are not owned.

Technically yes, but the potential problems of releasing USB devices with colliding IDs are known, so it is on the clonners. And it is pretty clear what they were trying to do here (save money on engineering and supporting driver and marketing), so that position is really indefensible.

[Kjelt]

You can not compare ftdi with the cga/ega/vga clones simply because the latter supported their hardware by writing and releasing software drivers for their products.
In fact hardware is half the job, supporting software, getting the software MS approved and regular updates esp. when new OS's are released is the second part where many modern cloners fail to deliver.

[ataradov]

I was mostly factoring in having to hire people to do the work, and likely having to scrap first set of masks. There is absolutely no way that rolling your own chip is the best way to go, unless you are Google or Apple.

[matseng]

...With MPW, you don't have your own mask. The $5k service fee includes all shared cost and fab's and broker's profit. You pay $5k, you send the GDSII, you get a few tens of sample chips.

How much will the required design/verify software set me back?  It is *almost* tempting to spend 5K and a lot of time for my own chip just for the sake of self-accomplishment.

[C]

Kjelt

Again a look through history will show that hardware using someone else's ID numbers has been very common.
This was common a long time before the first PC.

Just a simple look back and you would find many clones of DEC's VT terminals, these were not true clones but "work-a-likes"
You would find all kinds of hardware that ID's as something else.

Clones or more properly work-a-likes have existed for a very long time.

Until USB most or all keyboards IDed as a IBM XT or IBM PS2 keyboards.
IBM did not have the right to harm a clone PS2 keyboard when plugged into a IBM PS2 computer.
Just like FTDI had no rights doing what they did.
In fact it could be shown that FTDI acted with a criminal intent to harm with their drivers.

As for the cga/ega/vga all start using default drivers. The special drivers were to enable more feathers then original IBM versions.

And not everything is Windows.
And Microsoft does not OWN your or my computer. Microsoft also not allowed to harm hardware or software.
And when Microsoft learned something they supplied was harming hardware they had some responsibility to remove the code causing the harm.

Clone work-a-likes cam be better or worse then original.
Some work-a-likes clones as the PC industry shows can win over the original and be legal.

C

[Kjelt]

Again a look through history will show that hardware using someone else's ID numbers has been very common.
This was common a long time before the first PC.

What happened in the past does not make it right today. In the not so far past countries invaded other countries and took ownership, does that make it right to do this today?
In the beginning of the PC where you are talking about software was illegally copied more often than bought originally, there were no laws against that either back then, does that make it right today?
And so on.

What the real problem in this situation is: there are customers that bought ic's that they thought were original ones but they were not.
This even happened to major companies that put a fake chip in their products.
If it was clear that the chips were fake no-one would have given a damn about a driver not working anymore (they did not kill the chip they just did not work with their drivers anymore), that is the risk you take buying fakes.

[Kjelt]

With MPW, you don't have your own mask. The $5k service fee includes all shared cost and fab's and broker's profit. You pay $5k, you send the GDSII, you get a few tens of sample chips. Period.

So how does this work exactly. I heard pricing of a set of reticles going up to several hundreds of thousands of $. That's right multiple 100k$ for a reticle set (20+ layers or so on 16nm) How can they get their money back with a $5k service like that? There must be a big catch somewhere.

[ataradov]

Again a look through history will show that hardware using someone else's ID numbers has been very common.

That's fine, but it comes with a foot note that whoever wrote the software controls you. That's all. Clonning is fine as long as you accept responsibility.

That's FTDI drivers, they can do whatever they want with them. There is nothing criminal about it.

[ataradov]

How can they get their money back with a $5k service like that? There must be a big catch somewhere.

It is a shuttle service. You get 10 pieces of silicon, hundreds of others on the same wafer also get 10.  If you want real quantities, you will have to pay for the real masks.

The primary cost driver is still engineering. You need to either know what you are doing, or hire people who know. Neither option is cheap.

[Kjelt]

Now I have problems with sellers not stating it is a FTDI Clone or FTDI work-a-like. Would be even better if the chip was better then original like has happened with PC's.

Well it would have also helped tremendously if they had not marked the chips with the FTDI logo 

Hey but you are right, they should not have rendered the ic inoperational.
What they should have done is
- on driver init test the ic with their "illegal check" for authenticity, so check if it is genuine FTDI, and roll it back so also clones remain in the same state as before.
- If it is an authentic chip continue as usual.
- if it is not an authentic chip then display an annoying message onscreen that you have the wrong driver for this unknown IC and you should contact your seller or company for the correct driver, and abort.

That is how it should have been done.

[ataradov]

- on driver init test the ic with their "illegal check" for authenticity, so check if it is genuine FTDI, and roll it back so also clones remain in the same state as before.

The check procedure itself was destructive. I'm sure their new designs will have a better one, but for now we have what we have.

- if it is not an authentic chip then display an annoying message onscreen that you have the wrong driver for this unknown IC and you should contact your seller or company for the correct driver, and abort.

Drivers can't display messages, they don't have access to the GUI. FTDI tried the best they could - inject a message into the COM port.

[ataradov]

The undocumented ExRaiseHardError function from ntddk can trigger a CPU hard error, which then gets processed by csrss and csrss will pop up a message box. Text and icon can be customized.

Yes, using undocumented functions is what you want to do in a driver installed on millions of machines. That does however sound like something drivers for clonned devices would do.

[C]

ataradov

You are missing a major point.

FTDI did not even have the right to harm the chip they created.

They do not own the chip any longer as it has been SOLD.

That test that harms others property is a showing of Malice.

That a driver is limited in what it can do is not a right to do more then the chip was intended to do.
That chip was intended to be a USB connected UART.
A device that exchanges any type of data. Could be Ascii or Binary. They did not have the right to send any data but what was sent to the driver.
Work or not work with the chip is the two options here.
Other ways that a normal driver could commutate would be fine.
A log entry or a driver error message for example.
It's not that hard for a driver to create a Baud rate error or other error for a non FTDI Chip.

I do not see a Work-A-Like clone as having a legal problem, Unless there is legal way that FTDI has legal protection on how the chip communicates, I see none. Here some might show that how the USB side works is a industry default standard.

If chip had a FTDI logo then that is not legal unless fair use in the USA can be shown.

But this tread is supposed to be preventing a STM32 clone.
From software/firmware side a small security hole allows this to happen. It is a little hard to have encrypted firmware when the CPU runs UN-encrypted software/firmware.
If you can get access to UN-encrypted startup then this is a security hole.
The more cost spent adding security, the higher the price and this increases chance of a clone or work-a-like.

You might be able to create something not hackable, but if the resulting cost is high then expect the work-a-likes.

The best idea I can think of is protected code that runs an interrupter that understands the encrypted source. Even here all UN-encripted code must stay protected at all times and not have any security holes.

C

[ataradov]

FTDI did not even have the right to harm the chip they created.

But they did not harm their chip, not at all. Furthermore, the software is supplied as is with no warranties. It is obviously not in FTDI's interest to kill their own chips, but they could legally do so, if they wanted to.

If chip had a FTDI logo then that is not legal unless fair use in the USA can be shown.

But they did, and that's why it was so hard to tell them apart.

[ali_asadzadeh]

This is absolutely the worst way to go. First of all, you need to add at least $5-10 million until you get first working parts. And then, what stops clonners from decapping your parts, jut like any other MCU out there? Are you sure you can get the security right on your first try?

These prices are for owning the machines to etching lower tech IC's for you! the point is to prevent others to copy your product, if you have a custom MCU in your heart and nobody have the blueprint to produce it, they can not clone it directly, because they do not have the chip mask! Also there are lot's of freelances willing to do the job for you if you do not have the required skills to design the chip. I have talked to cadance before about designing a M0 for us, they charged around 100K for the whole part,and it would run for the first run, also they would teach us the process of designing the chip in this price, if you go with freelancer approach you can get it done way bellow that.

[Kjelt]

if you have a custom MCU in your heart and nobody have the blueprint to produce it, they can not clone it directly, because they do not have the chip mask! 

designing a M0 for us,

A custom MCU with a standard processorcore ? So only the peripherals are custom? And you are going to create peripherals that the big uCs producers did not think of ?
You still have the code that is easily reverse engineered or are you going to obfuscate that as well?
If you have a processor where all (internal or external) instructions are de-encrypted in hardware and on chip just before execution you might have an interesting product.

[ali_asadzadeh]

A custom MCU with a standard processorcore ? So only the peripherals are custom? And you are going to create peripherals that the big uCs producers did not think of ?
You still have the code that is easily reverse engineered or are you going to obfuscate that as well?
If you have a processor where all (internal or external) instructions are de-encrypted in hardware and on chip just before execution you might have an interesting product.

It can have some custom peripherals, but it does not need something new, a new peripheral arch would prevent most of us to switch to another company that makes Cortex parts, for example if you are ok with ST, it's hard for you to convince yourself to do a design in a similar part in a NXP part for example, also please remember that NO ONE has your chip in his/her hands! so why do anything! it's the magic secret in a lot of scopes, with custom parts in them, and I'm sure they could have used regular of the shelf parts if they wanted to.

[Kjelt]

remember that NO ONE has your chip in his/her hands! so why do anything! it's the magic secret in a lot of scopes, with custom parts in them, and I'm sure they could have used regular of the shelf parts if they wanted to.

I think you are mistaken. The custom parts in the scopes et all are special analog ic's not digital microcontrollers we are discussing right now. BIG DIFFERENCE!
If you use a standard core and you have no protection on your code your product can and will be cloned in weeks.
That is what we are discussing right now how to protect your product if it is solely based on a microcontroller, SW and jelly bean parts.

[SiliconWizard]

ataradov

You are missing a major point.

FTDI did not even have the right to harm the chip they created.

They do not own the chip any longer as it has been SOLD.

I don't quite agree with that.

As I said, I reckon FTDI's decision was kind of inept for various reasons, but they were not "harming" the chips they sold. They were kind of disabling the counterfeit ones, not the genuine products.
This was not necessarily smart, but the idea was probably to force the manufacturers using counterfeit chips (and in turn the counterfeiters) to be harmed. And if customers had been smart that's exactly what should have happened. They should have gotten back at the dubious manufacturers way before getting back at FTDI. The manufacturer is ultimately 100% responsible for what they sell. And those who were unaware of using counterfeit chips were either not having the right supplier selection process or themselves got abused - then they should have gotten back at their supplier, and so on. But I guess most of them were aware and did it to get higher margins. Let's not be excessively naive.

Truth is, until customers actually notice there is a problem, nobody cares about using illegal stuff when it lowers costs, and nobody cares whether the cloned stuff works as well as the genuine or not. That's the root problem IMO. And quite often, it concerns products that have low margin anyway and it would not be cost effective to take any action against counterfeiting, unless customers stop buying or even ask for refund.

I would consider different classes of cloning though, from what has been mentioned in this thread.
* Clones in the common "PC-world" sense: making functionally-equivalent products but without just plain copying them. This usually works well for the customers, is non-ambiguous (they know they are not buying the original stuff), and often triggers sane competition. Here the cloners are not exactly parasiting the products themselves, but rather their market and ecosystem;
* Copies of products: more or less exact copies that are unauthorized, are usually not quite as reliable as the original, much cheaper and don't try to pass as genuine. The customers know they're buying a clone and accept the risks. Sometimes the copies are not quite as good, but occasionally they offer extra features that make them attractive;
* Counterfeits: copies of products that pass as genuine. This is not only unauthorized copying, but is also misleading for the customers. It's just plain fraud. And when the counterfeit products are sold at the market price of the genuine, it's not just fraud, it's a rip-off.

[Peabody]

* Counterfeits: copies of products that pass as genuine. This is not only unauthorized copying, but is also misleading for the customers. It's just plain fraud. And when the counterfeit products are sold at the market price of the genuine, it's not just fraud, it's a rip-off.

This is essentially what happened to the company's first product.  The product was copied exactly, and the copies were represented as genuine, and sold at the same price.  In fact, when customers discovered later that what they bought was a counterfeit (because the firmware updates didn't work), the counterfeiters produced documentation to both AliExpress and Ebay showing that they were authorized to manufacture the products, all of which was competely fraudulent.  But AliExpress and Ebay then refused refunds to customers on the ground that what they received was genuine.  So the customers were royally screwed.  And in fact the counterfeits are still being sold on both sites, which I think is shameful.  So now the company is trying to prevent that on the next product, if possible.

[C]

 ataradov & SiliconWizard

Simple questions:

1. who owns all your computer equipment?

2. who has liabilities for improper function?

Think about #1
If you side with chip maker then The tire maker can come and do anything to your car tires.

For #2
You can find many cases where INTEL made a bad chip and replaced it, just like a tire maker has to replace defective tires.

To repeat
I see no problem with making a Work-A-Like unless there was a legal barrier for the USB communications to chip.
You have the Intel 8080 & the Zilog Z80. My understanding is that Intel had a copy-write on the Assembler Source mnemonics. So Zilog had to change this. But the actual binary format of the instructions was not protected. So Zilog could make a CPU that used the same binary.
Other cases were different and Intel took them to court.
Was the chip a legal work-a-like or not. I have seen nothing stating this part was not legal.
Chip maker could not have said it was a FTDI chip
If legal, chip maker could have said almost anything else.

Past this I just see Bad acts with some not legal

With a showing of harm, you have non-functioning work-a-like & harm caused by sending data not sent to driver, FTDI would lose on liability.

I think the whole supply chain would do better just stating the truth.
If sold as a clone or work-a-like, fine, if not then remove it from supply assuming work-a-like was NOT legal.

Electronics industry has a lot of businesses that make a legal copy of something.
For the computer side this is also true.

 SiliconWizard, nice list
but one problem here is that you may not need the authorization.
So "Copies of products: " you have two sub categories for authorization

Peabody
You might be thinking the wrong way.
As I have stated a tiny hole is a problem.
You should do all you can do easily.
They used a back door on you, Do the same to them each place you can.
In the USA you have copyright, trademarks that can protect a part.
For example, make it easy for all to find who is allowed to make this. A document on your web site.
Make it easy for customs.
Check legal but you might be able to have a web page stating  that ebay or allexpress are selling clones.

And still do all you can with STM32.
In the USA last I knew a copywrite message in the chip was good.
 

C

[ataradov]

If you side with chip maker then The tire maker can come and do anything to your car tires.

If I agreed in a contract that tire maker can slash my tires, then yes they can do so.

Chip vendor has no way to install new drivers (if Microsoft does not push them, but that's a different story). You chose to update the drivers and if something broke, intentionally or due to some bug, vendor is not responsible according to the driver EULA.

You can find many cases where INTEL made a bad chip and replaced it, just like a tire maker has to replace defective tires.

Examples?

[SiliconWizard]

(...) But AliExpress and Ebay then refused refunds to customers on the ground that what they received was genuine.  So the customers were royally screwed.  And in fact the counterfeits are still being sold on both sites, which I think is shameful.  So now the company is trying to prevent that on the next product, if possible.

Not meaning to be rude to AliExpress or eBay, but I wouldn't count those two as reputable retail channels. 
I rather see those as some kind of giant flea markets. I still use them occasionally. Flea markets can be fun.

[ataradov]

I agree. Anything I buy on eBay or AliExpress, I just assume to be fake and set my price expectations accordingly.

[ataradov]

One well known case being Intel replaced defective IVB/SNB-era PCH chips. Owners of affected motherboards can go to their mobo manufacturer and request a replacement. Intel screwed up by using Vcore thin oxide on Vpll circuitry, hence TDDB caused ridiculously low reliability on affected chips.

I don't believe they were mandated to do this, they just did not want to lose customers. And this is a problem that is in the design of the product, not something that happened later.

There is some talk that Intel will have to do something about performance-affecting Meltdown microcode patches, but I don't know what will come out of this. And the worst case scenario they will be caught in a contract violation with large data centers.

If company destroys their product through an update on purpose, they are pretty much committed to going out of business, and probably don't care much about the customers. And company can do that, if they chose to do so.

[Kjelt]

ataradov & SiliconWizard
Simple questions:
1. who owns all your computer equipment?
2. who has liabilities for improper function? 

You are asking the wrong questions, you are HW thinking but you should be system thinking.
The real and only question is:

- Who owns the legal rights to the FTDI driver software ?
The subquestion is:
- Who has the right to use that driver sw for their own fabricated chips ?

You are mistaken to think that if Company A writes a driver for their ic , that company B can (mis) use it also legally and get away with it.
This is not the case.

You claim PC clones, where Compaq reverse engineered the BIOS software and rewrote it from scratch to get out under legal issues.
If Compaq re-used the BIOS 1:1 they would have lost the courtcase and no-one would have heard of them.

You talk about USB ID's which is totally besides the point. If it were only a USB ID then why do my other brand USB-COM converters do not work with the FTDI drivers but need their own special driver installed ?
Why do some older USB-COM converters only work with older SW and not with the latest drivers and is this explicitly mentioned in the documentation of the newer drivers?

You are trying to talk a bent banana straight (dutch saying).

[iMo]

The end user is the one (unknowingly) installing FTDI drivers, which is illegal.

A "standard buyer" is not able to distinguish whether a product he/she purchased on "the market" in "good faith" is a "clone" or not. If he/she acquired a chip sold as "XYZ" and the "OS" installs a driver for it, he/she is definitely not liable for any damages or losses, direct or subsequent, caused to any "party" involved.

You cannot prevent cloning. You may file a "patent" or register a "trade mark", etc., when you consider your product is somehow special.

This topic is pretty complex stuff and even the experts in this area have usually problem to deal with such a Case.

Thus let us focus on issues in electronics we understand better

[Kjelt]

The end user is the one (unknowingly) installing FTDI drivers, which is illegal. The cloning company might be held responsible for inducing the user to conduct illegal acts, but the cloning company itself doesn't breach license agreements at all, unless it provides download for FTDI drivers on their websites.

If you are talking law, there is no law that prevents a sw manufacturer to do what FTDI did.
They even stated the possible side effects in their EULA:

Use of the Software as a driver for, or installation of the Software onto, a component that is not a Genuine FTDI Component, including without limitation counterfeit components, MAY IRRETRIEVABLY DAMAGE THAT COMPONENT

It is only the bad publicity that they reversed their driver software.

Now we can argue all day but the law is not helpfull in this situation. In fact what FTDI did with their software is what is going on dayly with illegal import products, they are destroyed at the customs entry of the EU, USA etc. The customer is screwed since the stuff is not delivered and (s)he should see how to get their money back.

[Kjelt]

The end user is the one (unknowingly) installing FTDI drivers, which is illegal.

A standard buyer is not able to distinguish whether a product he/she purchased on the market in good faith is a clone or not. If he/she acquired a chip sold as "XYZ" and the OS installs a driver for it, he/she is definitely not liable for any damages or losses, direct or subsequent, to anybody.
You cannot prevent cloning. You may file a patent or register a trade mark when you consider your product is somehow special.
This topic is pretty complex stuff and even the legal experts have usually problem to deal with such a Case.

So, if tomorrow a chip is sold on the market that destroys itself when a FTDI driver is run instead of their own driver than MS or FTDI would be accountable ?
How could MS / FTDI prevent this from happening exactly if the chip manufacturer re-uses their ID ?
The only solution to this is that MS will ask each user each time if they accept to install a driver for that product.

[iMo]

The end user is the one (unknowingly) installing FTDI drivers, which is illegal.

A "standard buyer" is not able to distinguish whether a product he/she purchased on "the market" in "good faith" is a "clone" or not. If he/she acquired a chip sold as "XYZ" and the "OS" installs a driver for it, he/she is definitely not liable for any damages or losses, direct or subsequent, caused to any "party" involved.

You cannot prevent cloning. You may file a "patent" or register a "trade mark", etc., when you consider your product is somehow special.

This topic is pretty complex stuff and even the experts in this area have usually problem to deal with such a Case.

Thus let us focus on issues in electronics we understand better

[SiliconWizard]

So, if tomorrow a chip is sold on the market that destroys itself when a FTDI driver is run instead of their own driver than MS or FTDI would be accountable ?
How could MS / FTDI prevent this from happening exactly if the chip manufacturer re-uses their ID ?
The only solution to this is that MS will ask each user each time if they accept to install a driver for that product.

It's obviously the chip manufacturer's responsibility. Re-using proprietary USB IDs that you don't own or have been granted authorization of use (such as if you buy from FTDI AND use their standard IDs, which FTDI permits, but obviously doesn't if you use pirate copies of their chips) is wrong, deceitful and probably illegal. It's just pirating.

[C]

A look back and you will find,
Mouse with switches that selected the com mode
Keyboards with switches selecting mode.
Printers, disk drive controllers and more.

The FTDI chip it's self allows changing USB ID's.

And there are valid legal reasons for these to exist.

From what I have seen the chip is a work-a-like.
Did the chip maker create software?
Most assume chip maker did not, but I have seen nothing valid ether way.
If initial design was for linux which does NOT use FTDI driver, did they need to create a driver?

Was it the Chip Maker that set the ID or someone else?
Again I think this is unknown.

FTDI original driver did not set the ID of the chip. A different FTDI program did that.

Many replies make the bad assumption that Windows is the only USB HOST in the world.
Open your eyes, it's NOT.
There are many devices that are USB Hosts and do Not allow a change of drivers. That pick a default standard for connected devices.
For these the user has only one choice, buy what works.

EULA's are often not legal or not enforcible.
Again a lot of assuming.

A chip maker does not get to decide what becomes the default standard.

Their are two sides to each coin.

A lot here are arduino users here, Would it be all right for makers of arduino IDE and some boards to make a software change making all the arduino work-a-likes stop functioning?


C




 

[Koen]

"STM32 - can cloning be prevented?" was an interesting topic. Could we get back to it ?

[helius]

"STM32 - can cloning be prevented?" was an interesting topic. Could we get back to it ?

Excellent suggestion.

This paper presented at last year's USENIX details three approaches to overcome the firmware protections in the STM32. RDP Level 2 can be downgraded to Level 1 after decapsulating the chip and exposing it to UV light. In RDP Level 1 the debug interface is active and exploits against it can be used.

[MrAureliusR]

Quote from: Peabody on 06-05-2018, 08:24:51

I've been helping as an alpha tester for a new electronics test gear product.  The company's previous product was very widely copied, including their company and product names. So not just cloned, but counterfeited.  The new product will likely use an STM32F303, and the crypto chip ATSHA204A is also available in the design.  The product has to be firmware upgradeable.

From my research, it appears the read protect function for the STM32 parts, as well as for processors of almost all brands, presents only a temporary stumbing block for the cloner.  There appear to be multiple vulnerabilities, and there's even a Youtube video showing a guy reading out the firmware from a STM32F0xxx part that has the level 1 option set.  And even if that worked, the cloner could just download the first firmware update and be in like Flynn.  By the way, do people younger than me even know who Flynn was?

Anyway, it seems to me there is no solution to this problem if that solution requires keeping the firmware secret.  Is there any other kind of solution that might make use of the ATSHA204A?  I'm thinking of some kind of crypto function that would have to work before the firmware would run.  Or possibly a major portion of the firmware would have to be decrypted on each boot, and run from RAM.   That would require that the firmware updates would have to individualized to each device so as to match the unique innards of each ATSHA204A, but that could be done.

Is there any guidance online on how to actually prevent cloning/counterfeiting of products using microcontrollers?
Or is this really just hopeless?

Tell them to use the movfuscator XD https://github.com/xoreaxeaxeax/movfuscator
It's a compiler which turns any code into just MOV instructions. It's only written for x86 but I bet it could be adapted to any architecture... the guy who wrote it also did this insane project that would turn the code flow diagrams in IDA into images like "Nice try" etc... absolutely hilarious!

(No, this isn't a fully serious suggestion, but extreme obfuscation could actually work in delaying them enough for the company to turn a profit. China WILL clone it if it's worth cloning, all you can do is delay it. Their court system is a joke. If the company doesn't have trusted vendors like the huge OEMs do, then the firmware and stuff will leak if it's assembled there.)

[luiHS]

 
Any microcontroller that stores the program without encryption can be cloned. No matter what technique you use, someone can always dump that flash, normally deactivating the reading protection fuse, once the encapsulation with acid has been eliminated and the chip put under the microscope.

One solution would be to work with microcontrollers that store the encrypted program, and decrypt it at runtime. I think that the new series i.MX RT1020 / 1050/ 1060 of NXP can store the encrypted program, in fact it is almost mandatory for a commercial product, since these microcontrollers do not have internal flash, it has to store the boot system and program in external memories (QSPI, Hyperflash), or SD card, and these can be encrypted.

Some time ago I also saw some MAXIM microcontrollers that stored the encrypted program, and they decrypted it at runtime.
https://www.maximintegrated.com/en/products/embedded-security/secure-microcontrollers.html

[Marco]

Looks like another NDA only chip.

[amyk]

One solution would be to work with microcontrollers that store the encrypted program, and decrypt it at runtime. I think that the new series i.MX RT1020 / 1050/ 1060 of NXP can store the encrypted program, in fact it is almost mandatory for a commercial product, since these microcontrollers do not have internal flash, it has to store the boot system and program in external memories (QSPI, Hyperflash), or SD card, and these can be encrypted.

Some time ago I also saw some MAXIM microcontrollers that stored the encrypted program, and they decrypted it at runtime.
https://www.maximintegrated.com/en/products/embedded-security/secure-microcontrollers.html

Extracting the key might be hard for "young players" but if your product is worth enough, people will do it.

Ultimately, if the bulk of the functionality in your product is contained inside it, no matter how obfuscated or protected it is, you can crack it. This is like the "axiom of software cracking" --- you have the whole environment that can run it, you can also analyse it to your heart's content. This also explains the whole move to "cloud services" --- the software isn't available to the user anymore.