Un-encrypted bit file and Device DNA

[suzero]

Hello everybody.
I want to implement a security precaution against overbuilding an
clonning. However I have some questions. If I am implementing the design i
a Spartan 3A Device, I have Device DNA feature but I dont have any on-boar
cryptographic feature. In the documents from Xilinx it is written that,

1) Read Device DNA Value
2) Generate your active code
3) Compare the active code and previously generated code
4) If they are equal, just enable the real part of your design.

Here I wonder that, is that possible a hacker or theft just copies my .bi
file while downloading from PROM to FPGA and he makes some modifications i
my netlist. This modification can be just to tie the enable bit(s) to Vcc
Then, my security precaution will be bypassed and the real part of m
design will work always because of enable bit(s) that tied up to Vcc b
hacker.



---------------------------------------
Posted through http://www.FPGARelated.com

 

[Christopher Head]

On Fri, 24 Dec 2010 13:02:23 -0600
"suzero" <orhunsuzer@n_o_s_p_a_m.gmail.com> wrote:

Hello everybody.
I want to implement a security precaution against overbuilding and
clonning. However I have some questions. If I am implementing the
design in a Spartan 3A Device, I have Device DNA feature but I dont
have any on-board cryptographic feature. In the documents from Xilinx
it is written that,

1) Read Device DNA Value
2) Generate your active code
3) Compare the active code and previously generated code
4) If they are equal, just enable the real part of your design.

Here I wonder that, is that possible a hacker or theft just copies
my .bit file while downloading from PROM to FPGA and he makes some
modifications in my netlist. This modification can be just to tie the
enable bit(s) to Vcc. Then, my security precaution will be bypassed
and the real part of my design will work always because of enable
bit(s) that tied up to Vcc by hacker.

The Spartan 3 series Device DNA mechanism relies on the netlist
modifications you mention being impossible (i.e. it relies on the fact
that the "nobody" knows the bitstream format well enough to modify it).
The configuration user guide (UG332) states in the introduction section
to chapter 15, "The Xilinx bitstream format is both proprietary and
confidential.". Is this good enough to actually protect a design?
Honestly, I have no idea, though it doesn't seem like a very strong
protection to me. But I come from the software world, where reverse
engineering is done on a daily basis...

Chris