Protecting design from being downloaded on other (similar) FPGA devices

Hi, I need to know how can I prohibit a configuration file from being downloaded on a similar FPGA device. For example, if I have two similar FPGA boards and I want only one FPGA board to be successfully programmed with the configuration file whereas if the same configuration file is downloaded on the other FPGA board, it should not get programmed. The target device is Virtex II Pro. I know there is this encryption feature available there for Virtex II and VIrtex II Pro devices but I am talking about the environment where the FPGAs will be programmed on startup through host application through PCI and there is no human intervention for programming the FPGA (or providing the encryption key). Here is the whole concept. I have a PC system where a PCI based 'COTS' FPGA card is installed. On startup, my application programs the FPGA board with the configuration file. However, if another similar FPGA board is installed in the same PC system, the application should (somehow) not programm the FPGA or the FPGA fails to get programmed successfully. I looked into the Device IDCODE thing but I came to know that the IDCODEs are the same for all FPGAs belonging to a particular family for example Spartan 3 sc3s1000 FPGA parts will have the same IDCODE. (had it been unique, I would have stored the IDCODE in my application and on finding a different IDCODE, I would have aborted the programming device sequence)

I hope I have mentioned my problem statement clearly........

Any suggestion.........

Farhan

Reply to
maverick
Loading thread data ...

V2Pro has no efuse like V5 has, so you cant personalize the FPGAs on COTS board

so whatever you do for your goal it need something on the boards to be different (except the FPGA) the only possibility would be the encryption, if not using it, need something else

Antti

Reply to
Antti

All,

Possible solutions exist today for Virtex II, IIP, 4, 5: use encryption. Only the device with the proper key configures.

In Spartan 3A, 3AN, 3ADSP, there is the "DeviceDNA" feature which may be used to identify a specific device. This identification requires a customer design to provide the function you desire (reference designs are available).

This is really not a good way to do what you ask (encryption is not authentication and the device ID is not a standard, so it can make no claims of perfect security like one can with SHA), but does work. More advanced would be to have a "secure hash algorithm" like SHA128, which could be used with some user readable efuses to provide for a secure means to authenticate.

Austin

Reply to
austin

Since you mention that you are loading the bitfile over the PCI bus, I am assuming that the FPGA is on the PCI card, as opposed to a daugher card. Is this correct?

If so, you could use the PCI configuration space to tell the cards appart. If you also know what board the bitfile is for, then the drive could check to make sure that the board and bitfile versions match, and refuse to load the bit file if it does not.

Regards,

John McCaskill

formatting link

Reply to
John McCaskill

I was just about to suggest the same solution. PCI spec requires every type of board to have unique Vendor, and device IDs, as well as there are SubSystem IDs. Now, this is all great unless the OP is implementing the PCI bridge in the same FPGA... Ooops...

/Mikhail

Reply to
MM

e
I

Thanks everyone for your replies. I think I need to add some more info here. Infact, I am not trying to secure my FPGA design or bitstream here. I am trying to prohibit generation of multiple copies of the same system. For example, assume that I have developed a system which comprises of a PC and a PCI based FPGA board which is mounted on the PCI slot of the same PC. The PCI based FPGA board is commercially availble from a vendor. The host application that runs on the PC programs the FPGA on application startup. If I deliver this system to a customer, it is quite possible that the Hard Disk image of the actual system is created, the same PCI based FPGA board is purchased from the same vendor and exactly the same PC is purchased. When all these things are hooked up in the PC...........bingo..........we have another system ready. In this scenario, I dont see the device ID or vendor ID stuff is of any use because these IDs would be the same for the same FPGA board. I dont have any non-volatile memory on the FPGA board where I can write my own sequnce which can be read out and verified by the application at startup.

Any thoughts.............

Farhan

Reply to
maverick

NO.

if you look at your spec, you see yourself there is no option. if you CAN NOT customize (nonvolatile setting!) anything on your PCI board then you can not use it as software dongle

.

some FPGA's have serial numbers, but yours does not. so you need to add something to your system that is used to protect it

Antti

Reply to
Antti

:) I must correct myself - there is a way without using any extra silicon devices, but its kinda weird, and needs lots of special work to be done

FPGA I/Os can be used to "sense" external capacitance, so if you find some unused traces on the PCB that connect to the FPGA, you can put a small paper label with hidden piece of metal foil onto the PCB, and compare the relative capacitance on that IO to some other unused IO that is AS IS. The PCB without that lable will sense different relative capacitances

but the amount of time to make this kind of system reliable for real products doesnt make sense.

if it is doable, i have used FPGA to sense human finger, plastic FPGA can even sense via package so it can be possible to say what egde of FPGA your finger is touching, but as said, it makes no sense for you to try use this trick.

just buy a usb dongle, or add some other thing to your board, for the chip-id that you need

Antti

Reply to
Antti

When FPGA serial no. functionality is not available Physically Unclonable Functions (PUFs) can do the job. In few words it is a challenge-response mechanism where the response is unique thanks to FPGA fabrication variance, thus (in theory) unclonable. Compulsory lecture refs below.

Regards, Krzysztof

Lee, J. W.; Lim, D.; Gassend, B.; Suh, G. E.; van Dijk, M. & Devadas, S. A technique to build a secret key in integrated circuits for identification and authentication application Proceedings of the Symposium on VLSI Circuits, 2004, 176-159

Abstract

This paper describes a technique that exploits the statistical delay variations of wires and transistors across ICs to build a secret key unique to each IC. To explore its feasibility, we fabricated a candidate circuit to generate a response based on its delay characteristics. We show that there exists enough delay variation across ICs implementing the proposed circuit to identify individual ICs. Further, the circuit functions reliably over a practical range of environmental variation such as temperature and voltage.

Suh, G. E. & Devadas, S. Physical unclonable functions for device authentication and secret key generation Design Automation Conference, ACM Press, 2007, 9-14

Abstract Physical Unclonable Functions (PUFs) are innovative circuit primitives that extract secrets from physical characteristics of integrated circuits (ICs). We present PUF designs that exploit inherent delay characteristics of wires and transistors that differ from chip to chip, and describe how PUFs can enable low-cost authentication of individual ICs and generate volatile secret keys for cryptographic operations.

Reply to
Krzysztof Kepa

How about adding an XC2C32 CPLD to the board and routing all of the bitstream data through it? Since it is flash based you could put a unique key in each one at board build time and use the key to encode/decode the bitstream. This does not give good protection since a digital scope on the DIN and CCLK pins would give the unencrypted bitstream but it might be enough for your needs. The XC2C32 is a little over a buck in 100 quantity at Digi-Key.

HTH Bob Smith

Reply to
Bob Smith

the OP wants COTS board to be used

1) with no mods to the board 2) with no additions to the board

so adding anything isnt an option

Antti

Reply to
Antti

Every PCI slot on a PC has a unique bus/slot number that you could use to selectively download fpga code. Unfortunately, the mapping between these numbers and the physical slot is not always obvious.

If you have two identical cards and no way to tell them apart, you are going to need some sort of user intervention to select which card to program. The mental telepathy option is usually disabled in the BIOS.

Actually, if the cards are truly identical, then it shouldn't matter which one you program. Just program the first one you find and assume there aren't any others.

Alan Nishioka

Reply to
Alan Nishioka

Add a 0402 pullup resistor to an unused pin or just short two FPGA pins. Either of these is hard to see on the board if done properly, but easy to detect from inside of the device if you know what you are looking for. Not as secure as the methods Antti mentioned, but much easier to implement.

Which PCI bridge is the card using? Are you sure that there is no EEPROM attached to it?

/Mikhail

Reply to
MM

One way to do this (which is somewhat based on security through obscurity) would be to modify the BIOS on the computer so that it writes some secret initialization sequence to the FPGA to enable it. There are tools available which allows you to easily insert or remove an option ROM image into an AWARD base BIOS.

Of course, this will not buy you _real_ security. But it is enough to make sure that someone will have to spend some time to analyze what is really going on in your device.

If you want to tighten things up further you could make sure that the secret initialization sequence will depend on a serial number present in the computer (harddrive or DDR dimm for example). This will make things much more complicated for you and might also annoy a customer if they have more than one of your device and for some reason want to exchange parts in it.

Otherwise, perhaps you could use a TPM module in some way, but I don't know if that could work or not in your case.

/Andreas

Reply to
Andreas Ehliar

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.