How to protect my Virtex5 design without battery?
vcar
Virtex5 bitstream encryptioncould not be used. In this situation, what
could I do to protect my design on areasonable level?
My design hasVirtex5 and XCF16P, and the two devices are linked on
JTAG chain, and I programXCF16P with my design through JTAG chain. I
have set the security options inboth BitGen and iMPACT utilities, so I
can prevent any JTAG readback/partialreconfiguration though JTAG
chain. However I have the following questions:
1. Although inhardware, XCF16P will be disabled after configuration is
done. But with minorfly wire modifications in hardware, the attacker
could access XCF16P afterconfiguration. And I found that using the
combination of USER_ACCESS_VIRTEX5 +STARTUP_VIRTEX5 could make FPGA
read back data from XCF16P, it is possible?
2. Since Idisabled the possibility of reading back via JTAG, need I
initiateBSCAN_VIRTEX5 + ICAP_VIRTEX5 and clear the entire FPGA once
JTAG chain activityis found?
Thanks a lot!
Frank Buss
> For certainreasons, I could not use battery on my board, so the
> Virtex5 bitstream encryptioncould not be used. In this situation, what
> could I do to protect my design on areasonable level?
I don't know the answers to your questions, but I guess an attacker could
at least just desolder the XCF16P and reading it like the FPGA does when
booting, so even the read protection bit of the flash is useless. If you
want to secure your device, I would use something like the DS2401. This
provides a unique id. You could save this in the flash and compare it from
the FPGA with the chip. The chip is available in packages which looks like
a capacitor or diode:
http://search.digikey.com/scripts/DkSearch/dksus.dll?Detail&name=DS2401X1CT-ND
I've written some VHDL code for reading the one-wire id:
http://www.frank-buss.de/vhdl/spartan3e.html
(see the DS2432 ROM id reader in the zip file)
--
Frank Buss, f...@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de
glen herrmannsfeldt
> vcar wrote:
>> For certainreasons, I could not use battery on my board, so the
>> Virtex5 bitstream encryptioncould not be used. In this situation, what
>> could I do to protect my design on areasonable level?
Protecting against exact clones is difficult. In many cases, decoding
the bits back to logic is hard enough not to worry about that.
> I don't know the answers to your questions, but I guess an attacker could
> at least just desolder the XCF16P and reading it like the FPGA does when
> booting, so even the read protection bit of the flash is useless. If you
> want to secure your device, I would use something like the DS2401. This
> provides a unique id. You could save this in the flash and compare it from
> the FPGA with the chip. The chip is available in packages which looks like
> a capacitor or diode:
As long as they don't read this newsgroup and know what to look for...
-- glen
Frank Buss
> As long as they don't read this newsgroup and know what to look for...
You are right. And if an attacker has the money to clone a Virtex design,
this just delays the cloning process a bit. But the AES encryption
integrated in Virtex devices is better. It's a pity that the key can't be
stored in non-volatile memory inside the chip.
Another idea against cloning would be to implement a challenge response
protocol with an external small microcontroller, e.g. a hash function,
where the microcontroller adds some bytes before hashing. If the
microcontroller has some protection, then the attacker would need at least
an electron microscope (assuming that it is not easy to extract the logic
from the programming byte stream for the Virtex).
vcar
Hi, glen.
My point is to protect my board from cloning, so the attacker do not
need to decoding bit stream back to logic. Once they obtain the bit
stream, they can produce my board themselves.
I could not protect the PCB from cloning, so I have to do something on
my bit stream. Otherwise it is very easy to copy my board.
vcar
> vcar wrote:
> > For certainreasons, I could not use battery on my board, so the
> > Virtex5 bitstream encryptioncould not be used. In this situation, what
> > could I do to protect my design on areasonable level?
>
> I don't know the answers to your questions, but I guess an attacker could
> at least just desolder the XCF16P and reading it like the FPGA does when
> booting, so even the read protection bit of the flash is useless. If you
> want to secure your device, I would use something like the DS2401. This
> provides a unique id. You could save this in the flash and compare it from
> the FPGA with the chip. The chip is available in packages which looks like
> a capacitor or diode:
>
>
> I've written some VHDL code for reading the one-wire id:
>
> http://www.frank-buss.de/vhdl/spartan3e.html
>
> (see the DS2432 ROM id reader in the zip file)
>
> --
> Frank Buss, f...@frank-buss.dehttp://www.frank-buss.de,http://www.it4-systems.de
Comparing to DS2401, DS28E01 or DS2432 is more applicable.
If I use these chips, need I use BSCAN_VIRTEX5 + ICAP_VIRTEX5 to
monitor JTAG activities?
Nico Coesel
>On 12=D4=C229=C8=D5, =CF=C2=CE=E76=CA=B112=B7=D6, glen herrmannsfeldt <g...=
>@ugcs.caltech.edu> wrote:
>> Frank Buss <f...@frank-buss.de> wrote:
>> > vcar wrote:
>> >> For certainreasons, I could not use battery on my board, so the
>> >> Virtex5 bitstream encryptioncould not be used. In this situation, what
>> >> could I do to protect my design on areasonable level?
>>
>> Protecting against exact clones is difficult. In many cases, decoding
>> the bits back to logic is hard enough not to worry about that.
>>
>> > I don't know the answers to your questions, but I guess an attacker cou=
>ld
>> > at least just desolder the XCF16P and reading it like the FPGA does whe=
>n
>> > booting, so even the read protection bit of the flash is useless. If yo=
>u
>> > want to secure your device, I would use something like the DS2401. This
>> > provides a unique id. You could save this in the flash and compare it f=
>rom
>> > the FPGA with the chip. The chip is available in packages which looks l=
>ike
>> > a capacitor or diode:
>>
>> As long as they don't read this newsgroup and know what to look for...
>>
>> -- glen
>
>Hi, glen.
>My point is to protect my board from cloning, so the attacker do not
>need to decoding bit stream back to logic. Once they obtain the bit
>stream, they can produce my board themselves.
>I could not protect the PCB from cloning, so I have to do something on
>my bit stream. Otherwise it is very easy to copy my board.
In that case you'll need to add a microcontroller which does part of
the job.
--
Failure does not prove something is impossible, failure simply
indicates you are not using the right tools...
nico@nctdevpuntnl (punt=.)
--------------------------------------------------------------
Ed McGettigan
>
> - Show quoted text -
If the bitstream is not using the AES encryption then there is very
little that you can do to prevent the entire board from being cloned
as anyone that has one of your original boards can easily extract the
data from the PROM.
There are some alternatives, but they aren't as secure. See Xilinx
Whitepager WP266 and Application Note XAPP780
Ed McGettigan
--
Xilinx Inc.
Frank Buss
> Comparing to DS2401, DS28E01 or DS2432 is more applicable.
You are right, the DS2432 looks interesting with the SHA1 hash function.
But I couldn't find it at Digikey and you have to register at Maxim to just
get the price for it, so maybe a small PIC (which has program read
protection) is better.
> If I use these chips, need I use BSCAN_VIRTEX5 + ICAP_VIRTEX5 to
> monitor JTAG activities?
I don't think this is needed, because an attacker could desolder the flash
anyway and simulate a FPGA to read the bitstream, or use a logic analyzer
for recording the FPGA boot process.
vcar
Yeah, Now I decide to adopt DS2432 way.
vcar
Thank you for your advice. The short answer should be no any strange
primitives in my final bit stream.
untergangsprophet
> For certainreasons, I could not use battery on my board, so the
> Virtex5 bitstream encryptioncould not be used. In this situation, what
> could I do to protect my design on areasonable level?
What about an Atmel crypto-memory?
It has your Key, which is very difficult to clone.
The FPGA logic can then have random values encrypted by the crypto-
memory and verify them with its internal key.
You should spent some effort to make sure your "random values" are
sufficiently random.
You could go the same Way using for example a LPC (NXP) flash-
microcontroller which can be read-protected.