Author Topic: Spartan 6 Bitstream Configuration Protection  (Read 2178 times)

0 Members and 1 Guest are viewing this topic.

Offline petersanchTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: 00
Spartan 6 Bitstream Configuration Protection
« on: December 23, 2020, 11:23:58 am »
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
Quote
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!
 

Offline Neekeetos

  • Contributor
  • Posts: 27
  • Country: ru
Re: Spartan 6 Bitstream Configuration Protection
« Reply #1 on: December 23, 2020, 12:22:55 pm »
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.
 
The following users thanked this post: petersanch

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3243
  • Country: ca
Re: Spartan 6 Bitstream Configuration Protection
« Reply #2 on: December 24, 2020, 02:00:53 am »
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.
 
The following users thanked this post: petersanch

Offline xlnx

  • Contributor
  • Posts: 20
  • Country: no
Re: Spartan 6 Bitstream Configuration Protection
« Reply #3 on: December 24, 2020, 11:35:39 am »
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.
« Last Edit: December 24, 2020, 11:40:08 am by xlnx »
 
The following users thanked this post: petersanch

Offline petersanchTopic starter

  • Regular Contributor
  • *
  • Posts: 62
  • Country: 00
Re: Spartan 6 Bitstream Configuration Protection
« Reply #4 on: December 25, 2020, 10:24:26 am »
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.
 

Offline NorthGuy

  • Super Contributor
  • ***
  • Posts: 3243
  • Country: ca
Re: Spartan 6 Bitstream Configuration Protection
« Reply #5 on: December 25, 2020, 04:16:34 pm »
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.
 

Offline laugensalm

  • Regular Contributor
  • *
  • Posts: 129
  • Country: ch
Re: Spartan 6 Bitstream Configuration Protection
« Reply #6 on: December 27, 2020, 11:14:48 am »
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.
 


Share me

Digg  Facebook  SlashDot  Delicious  Technorati  Twitter  Google  Yahoo
Smf