02-01-2017 11:45 PM
I need to protect my current PCBs from reading out the FPGA-firmware from flash and porting it to another hardware, as well as enabling the user to update the firmware himself, and limit it to the particular PCB.
AFAIK the newer devices have a strategy to do this by providing a DNA which can be used for this. I wnet through some docs but still am confused about that and other protection mechanisms like EFUSE.
If it possible to protect a self built PCB with a lets say Artix 7 that way, that I can provide a individual FPGA code for just one customer and make sure, that this code can only be run on his device?
I have bulit some IP which might be run on any hardware, meaing any person could copy the PCB (because it is simple) and use a read out FPGA image from a original PCB to use it more than once in his labor.
Is there a document which describes the process of prohibitting the readout and copying in detail?
02-03-2017 11:35 AM
Short answer : XAPP1239
No, you can't prevent flash readout, but you can prevent readout of the configuration memory through various access port (JTAG,ICAP,etc.) by blowing the some of the EFUSEs.
That said, if you want to prevent cloning of the configuration file (bitfile), the best solution would be to not share it with anyone ;)
For a more practical solution, you can encrypt the configuration file. The hows, whys, pros and cons of different methods are well explained in XAPP1239.
Feel free to reach out to me again for an even more detailed technical description or elaboration of various threat scenarios.
02-03-2017 11:37 AM
DNA or EFUSE don't prevent you from reading out the flash. Anyone can read out and copy the flash. If you need it to be "copy protected," you would need to use an encrypted bitstream. On the other hand, you can add code to your design that prevents it from running if the DNA does not match the expected value. Assuming that you only provide the code in binary form, this would be enough to prevent most people from replicating the design. It would be up to you to design the mechanism by which the improper DNA prevents the design from working. For example you could read the DNA at startup, and only release the reset to the rest of the design if the DNA matches the expected value. You'd need to generate a bitstream for each device you authorize to use your code with that device's DNA hard-coded in it. This gets a bit messy if you plan to mass produce your board, since it means a lot of tool runs (synthesis through bitstream generation). It would be easier if you could check for DNA being within a certain range, but I don't think it's possible to order parts that have sequential DNA values.
02-03-2017 01:16 PM
Oh please, don't use DNA readout for protection... and a forum post is not enough to detail you how much wrong and problematic this solution is.
For one, as Gabor wrote, for each new FPGA, you would have to generate a new configuration for each FPGA. Now for high enough volume you might be able to script all of this and not to give you bad ideas, I won't detail how to.
It does not prevent people to copy the configuration file on another FPGA.
Seriously, if you are implementing that solution, you are looking for someone to clone it.