How to protect QSPI Flash??

[ataradov]

Chris, Dmitry, Andrew et al can do that type of thing. But it gets very annoying and tedious. Can it be cracked? Of course. Can it be done cheaply? Not really. The overhead involved in running those machines is substantial, they use consumables. The operator must be pretty skilled, and understand why it works.

There is no question that it is totally impractical. Still cool that there is technology to do this kind of stuff.

And I'm sure all that tech exists not only for cracking. I can see a lot of uses for debugging silicon issues.

[marshallh]

There is no question that it is totally impractical. Still cool that there is technology to do this kind of stuff.

And I'm sure all that tech exists not only for cracking. I can see a lot of uses for debugging silicon issues.

Exactly, all those tools were designed for the chip industry. They are a staple of fab and sometimes design houses. That's how Chris got his (there is always a resale market, no matter what it is!)
Not many folks using them to exclusively crack stuff instead of troubleshooting a faulty design, though.

[wraper]

There is no question that it is totally impractical. Still cool that there is technology to do this kind of stuff.

Depends on the gains obtained, it can be very practical. Like crack some apple security chip in the cable and then make ten millions clones later. Or pirated sat tv. Of course hacking it is not worth if it can be made from a scratch in a few days.

[Ian.M]

If your production and final assembly is in China, all the wannabe cloners have to do is find out who makes it and persuade the line manager to run a ghost shift.  If you get case, board etc. made in widely separated locations, with only test firmware preloaded on the board, then do the final assembly and firmware load in-house, it means they will have to work a bit harder and invest more capitol.

However, last time I checked $5000, and three identical programmed MCUs  would get you a firmware dump of most MCUs.  The more reputable companies would offer you a new MCU programmed with the firmware so you could confirm successful cloning, before you made the final funds transfer to get the hex file.  There are even USA based companies offering this sort of service, though I assume they'd be fairly fussy about you signing a contract that stated you were either the I.P. owner or were legitimately reverse engineering it for protocol compatibility.  That sort of pricing and availability means cloning your product is well within the range of even small players with a workshop in their garage and a cousin in Shenzhen. 

That means that if you decide you need to control cloning, if your product needs to interact with proprietary PC software, you need to control the licensing and use of that by means other than just checking if compatible hardware is connected.  If you get it wrong, you get a mess like FTDI has.   Alternatively, if your product has network or USB connectivity, you will need to implement some form of secure registration to unlock its full feature set.  If its entirely standalone you are probably FUBARed as it could be cloned in its registered state.

Back to the O.P.s problem:  Just about the only hope is to stick a secure FPGA between the QSPI flash and the MCU to manage encryption.   The bootloader would be transferred in clear, and subsequent data blocks transferred over the MCU interface would be encrypted with a persistent rolling code so a direct decrypted firmware image dumped from the MCU's RAM wouldn't help.  As much as possible of the processing should be offloaded to the FPGA to make it harder to reverse engineer from a firmware dump.    That's a lot of work and even so, if your market is valuable enough and your product is unique enough and in high demand, someone will probably invest the time and money required to crack it.

[mikeselectricstuff]

If the CPU can read it then so can anyone else.

If you need security, either use a micro that has sufficient intrinsic security features, or use additional hardware.
There is no such thing as  total security - you need to assess the risks and work out how much it's worth spending to mitigate them sufficiently.
There are QSPI devices with security features, like OTP areas and unique serial numbers, which can be used in conjunction with your software to prevent simple cloning.

You could load in a small bootloader and have the rest of your code encrypted, using keys stored elsewhere - OTP area in QSPI, MCU unique serial number if it has it, or one of the various secure memory products out there.

 

[tszaboo]

If your production and final assembly is in China, all the wannabe cloners have to do is find out who makes it and persuade the line manager to run a ghost shift. 

So probably the best way to avoid this, is to order preprogrammed ICs from the proper vendors/suppliers, and trace the batches, and require strict handling of the scrap boards.