Spartan 6 Bitstream Configuration Protection

[petersanch]

The lower Xilinx Spartan 6 FPGAs have no bitstream encryption.
What is the best way to protect the bitstream configuration from running on unauthorized hardware?

Xilinx suggested using DNA. https://forums.xilinx.com/t5/FPGA-Configuration/Spartan-6-copy-protection-options/td-p/932079

Function of Device DNA : Prevent the design from operating (or operate in a limited manner) if unique identifier is not recognized.
For example : If someone steal your bistream and tries to configure his FPGA, then it will not happen, because unique identifier is not recognized.

Has some one had success with that? Is it a trusty way of protection or can bitstreams with different DNAs be compared and reverse engineered?

Cheers!

[Neekeetos]

Has some one had success with that? Is it a trusty way of protection or can bitstreams with different DNAs be compared and reverse engineered?

DNA is just a simple shift register containing uniq number. User can read it and use for protection. Protection itself is totally defined by user, it could be just comparator , so bitstream is applicable only on single chip. Also this dna id could be used as a part of initialization process, calculations etc. You could probably find comparator inside bitstream and circumvent protection logic, but for more complex schemes it will become problem to patch actual bitstream.

[NorthGuy]

This protection is very weak. The attacker can simply inject a block into your design which will impersonate the DNA block, then disconnect your design from the real DNA block and connect it to their malicious impersonator. The impersonated block will provide any DNA they want. Your design will think it still runs on your FPGA.

Bitstream encryption is not much better since it has long been cracked.

[xlnx]

Protecting the bitstream itself may not be feasible, but you can protect your running design using an external challenge/response authenticator.

It involves setting aside some resources in the FPGA to build a random number generator and a small MCU (picoblaze or similar) to implement a hash function + communications with the external authenticator. TRNG (True Random Number Generator) can be built quite easily in FPGAs by implementing ring oscillators.

https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5803.html

Of course - you could also build your own external authenticator using your favorite MCU, if you can trust that it cannot be broken.

[petersanch]

This protection is very weak. The attacker can simply inject a block into your design which will impersonate the DNA block, then disconnect your design from the real DNA block and connect it to their malicious impersonator. The impersonated block will provide any DNA they want. Your design will think it still runs on your FPGA.

Bitstream encryption is not much better since it has long been cracked.

Is another method you can recommend to protect IP from working on an unauthorized hardware?

Protecting the bitstream itself may not be feasible, but you can protect your running design using an external challenge/response authenticator.

It involves setting aside some resources in the FPGA to build a random number generator and a small MCU (picoblaze or similar) to implement a hash function + communications with the external authenticator. TRNG (True Random Number Generator) can be built quite easily in FPGAs by implementing ring oscillators.

https://www.maximintegrated.com/en/design/technical-documents/app-notes/5/5803.html

Of course - you could also build your own external authenticator using your favorite MCU, if you can trust that it cannot be broken.

Sounds like a good idea but if there iss another method without extra hardware that will be preferred. Cheers.

[NorthGuy]

Is another method you can recommend to protect IP from working on an unauthorized hardware?

Every FPGA is unique. You can build combinatorial loops and time them. But this is not that easy because the timing will change with temperature and voltage.

Not that many people can reverse-map your bitstream to the actual design (aka netlist), but this certainly can be done. If there are people who are in business of stealing FPGA bitstreams, they should be able to do this. Then, no matter what you do, they can change it. It's similar to software protection. You can make it difficult to crack, but you cannot really prevent cracking.

[laugensalm]

Since it's just a matter of reverse engineering (some can do very easily, some it will take longer), a simple CPU core controlling/configuring your IP will mostly do the job just fine, like locking firmware (generated) to a serial number in the SPI flash. There are many options of cheap obfuscation you can apply to make it very painful/complex for an R-Engineer to identify the right bits to turn in order to make it work. For example, shuffling opcode bits of a known architecture can create a lot of headache already.