How to protect fpga based design against cloning?

Yes it is possible to clone an FPGA that gets its config from a boot prom if somebody really wanted to do so. However if you are worried about this for your design then there are device families out there that are flash or antifuse based which make this much harder if not almost impossible. Actel have a feature called 'FlashLock' in their ProASIC+ devices which I believe is designed to protect against this and their Accelerator family as well as their older families are antifuse. Also Xilinx do what are called 'Hardcopy' devices which are basically the same as the original FPGA but with hardwired logic rather than being configurable. There are many other choices from Altera, Quicklogic, etc aswell I should imagine.

Cheers,

Pete.

Markus,

You might want to look at Lattice PLD's. They have on board flash. You write to the chip initialy in the normal manner via JTAG, your code is then stored on the chips flash untill you reprogram it.

Matt

You are right, and it is a problem.

I have been thinking about it too.

Overall I feel there isn't much security in the FPGA chips themselves, but I thought it might be an idea to have a smart card chip (as used in the SIMs for mobile phones). Your FPGA system configures as per normal.

It then has encrypted conversation with the SIM (which is a far more secure device), and if it confirms the SIM is valid it works as normal, else it shuts down as you wish.

This transfers the problem of cracking from the FPGA to the SIM.

The FPGA config can still be ripped off of course, but without the SIM it will be useless.

SIMs are pretty small and the carriers are easily available.

The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V. (I run my design off 14.3181 MHz, so this is easy to obtain). The SIM reader electronics is easy to implement.

You still have to write the verification protocol. Sounds easy but it is not trivial making sure it has no security holes (I've worked with these chips). But easier to make the SIM secure (that's what they were designed for) than the FPGA/config ROM system.

If you do manage to implement this, then it opens up a lot of possibilities.

The SIM is detachable so you can get your stuff built in say the far east and post the SIMs to the end user by trusted carrier. They can easily install the SIM. You might also make the SIM specific to individual signed config ROMs. Or send upgrade config ROMs with SIMs.

Thanks for your reply. The problem I see with this aproach - provided I understood you correctly - is that since the code in the fpga would be "open" it could be reverse engineered much easier and the sim part could be shorted as a result also. I might sound paranoid - I'm not, I just like to know what I'm dealing with.

The aproach with the Lattice PLD containing flash the other poster mentioned seems to be the best to me so far cause this means that a cracker would have to physically open the PLD and get down to this level where as "listening" on the bus is IMHO a lot easier. I might be wrong here, but at least to me the Lattice PLD aproach would be much harder to crack.

Well, I'm looking foreward to eventually hear other ideas.

Markus

The V2/V2Pro has a configuration loader which can load bitfiles encrypted with DES/3DES. The decryption keys are stored, in battery-backed-up SRAM on the FPGA.

--
Nicholas C. Weaver                                 nweaver@cs.berkeley.edu

Altera has HardCopy, not Xilinx.

Petter

--
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

One take on this is the actual value of a bitstream and how someone would/could use it in a commercial application and potential reproduction of your project. I've put a lot of thought into this and decided that, at least for the type of work I'm doing, it's not an issue. Why? Because, by the nature of the designs, if someone were to copy the bitstream with intent to clone the design (presumably for commercial gain) they'd also have to design their board exactly as mine. There isn't a court in the world that wouldn't favor the original designer when shown that evidence.

In complex designs, where a microprocessor might be running an FPGA as a peripheral, the commercial value of the bitstream might be reduced even further. You could implement all sorts of little tricks to make sure you can show a judge that the design was stolen from you. Like, a pin on the FPGA that, when connected to a PC serial port through a resistor displays a repeating "STOLEN FROM ..." message.

Without doing much thinking, the only applications that I'd think truly require bitstream protection might be government/military or when the requirement is simply dictated down to the design engineer/consultant by the employer, for whatever reasong (including ignorance). In those cases Xilinx has you covered rather well with the triple DES technology and a little $3 battery.

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Martin Euredjian

To send private email:
0_0_0_0_@pacbell.net
where
"0_0_0_0_"  =  "martineu"

of

by

intent

My belief is that for most devices, in most markets, with reasonable markups this is true.

Consider the toy/video game market. (I don't know if any use FPGA, but they could.) The markup is generally very low, using the razor model and making most of the money off selling the games (software). In that case, someone will have a hard time pricing it low enough (assuming one uses cheap foreign labor, as the cloners would). Also, the profitable lifetime is short.

Consider the high end scientific/engineering equipment market. The number of devices built will be low, and they might be sold with a high markup (to cover design cost, for example). Usually, though, support is an important part of the purchase, and buyers of clone devices wouldn't get any support. There is also the embarassment of being caught with an illegal device, especially in a public company.

If your market is primarily in places that have strong copyright laws, that is a big part of your protection. If a large part of the market is in places with weak copyright laws, then you have to consider other alternatives.

-- glen

This is an interesting subject. I guess there are two concerns:

1) Theft of the configuration bitstream so that you could clone and produce identical products. Obviously the circuitry connected to the FPGA would have to be a copy and probably not to hard to go after the bad guys in the courts with copywrite laws etc. I am more concerned about #2.

2) IP Theft. The question here is ( in the Altera/Xilinx context ) if you record the configuration bitstream what can you do with it as far as reverse engineering ? Can anyone reasonably , meaning with existing tools or software or ... how?, take this bitstream and figure out your HDL ? I wouldn't know where to start but perhaps there are some factory or other smart folks here who have a better insight into this ??

Khim Bittle

:>You are right, and it is a problem. :>

:>I have been thinking about it too. :>

:>Overall I feel there isn't much security in the FPGA chips themselves, but I :>thought it might be an idea to have a smart card chip (as used in the SIMs :>for mobile phones). Your FPGA system configures as per normal. :>

:>It then has encrypted conversation with the SIM (which is a far more secure :>device), and if it confirms the SIM is valid it works as normal, else it :>shuts down as you wish. :>

:>This transfers the problem of cracking from the FPGA to the SIM. :>

:>The FPGA config can still be ripped off of course, but without the SIM it :>will be useless. :>

:>SIMs are pretty small and the carriers are easily available. :>

:>The SIM only needs a 3.58 (or 5) MHz clock, and 5V or 3V. :>(I run my design off 14.3181 MHz, so this is easy to obtain). :>The SIM reader electronics is easy to implement. :>

:>You still have to write the verification protocol. :>Sounds easy but it is not trivial making sure it has no security holes (I've :>worked with these chips). :>But easier to make the SIM secure (that's what they were designed for) than :>the FPGA/config ROM system. :>

:>If you do manage to implement this, then it opens up a lot of possibilities. :>

:>The SIM is detachable so you can get your stuff built in say the far east :>and post the SIMs to the end user by trusted carrier. They can easily :>install the SIM. :>You might also make the SIM specific to individual signed config ROMs. :>Or send upgrade config ROMs with SIMs. : :Thanks for your reply. The problem I see with this aproach - provided :I understood you correctly - is that since the code in the fpga would :be "open" it could be reverse engineered much easier and the sim part :could be shorted as a result also. I might sound paranoid - I'm not, I :just like to know what I'm dealing with. : :The aproach with the Lattice PLD containing flash the other poster :mentioned seems to be the best to me so far cause this means that a :cracker would have to physically open the PLD and get down to this :level where as "listening" on the bus is IMHO a lot easier. I might be :wrong here, but at least to me the Lattice PLD aproach would be much :harder to crack. : :Well, I'm looking foreward to eventually hear other ideas. : :Markus

The simple answer is that it is impossible, since there is no documentation about the function of the individual config bits. The more sophisticated answer would be that is outrageously difficult and time consuming. After all the detective work figuring out what millions of individual bit are doing ( or not doing), you finally arrive at a big unstructured circuit mess. Good luck! I think it is easier to re-invent the functionality than to reverse-engineer it.

Peter Alfke

How much of a problem is that?

I'd think that major US based contract manufacturer would be very careful. It would be a serious damage to their reputation if something like that happened and word about it got out.

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

True.

I suspect most people only behave fairly because of the risks and costs of getting caught are high.

In poorer parts of the world (where much manufacturing is done) they have much to gain from 'cheating' and know the difficulty of flying lawyers there to do expensive international legal actions.

Often they don't give a mouse-sized shit - their attitude is "what are you going to do about it?"

Some people don't have a reputation to worry about.

Several years ago in an interview with a large company, a friend of mine asked how they ended up reverse engineering a product from another large company. The guy smirked and said: "We removed the top and took lots of pictures." They were working on a full-custom ASIC.

First entry on Google:

Jake

(snip)

For large designs, I would have to agree. People used to talk about disassembling software and reverse engineering from that. In the days when software was 8K bytes or so, it might have been possible. It is possible to carry around 4000 lines of disassembled code, try to follow it and comment it as one learns the functions. Consider that some programs today may be 80M, or maybe 20 million lines of disassembled code. Well, maybe some of it is tables and such. It may have been written in a high-level language, but you will get uncommented assembly code, with numeric addresses instead of symbolic ones.

It might have been possible to disassemble the code for an XC4002 and figure out the functions. You might be able to carry around the netlist for it. It will be a netlist, and likely not VHDL, or at least not readable VHDL. For a device with millions, or hundreds of millions of equivalent gates, well, you can figure out how big it might be to print.

It would probably be possible if your budget is in the tens of millions of dollars or so. Just a guess.

-- glen

Hi Peter

Thanks for your reply. This sounds like a good solution too. The battery aproach is a bit two folded. On one hand it may adds security in that if someone would tamper with the device and power would be interupted the key is lost. On the other hand there are the added costs of such a battery and also the not always so consistent livespan. In other words the user would not even be able to replace this battery or in other words, once the battery is low the product is trash - right?

Markus

"Peter Alfke" ha scritto nel messaggio news: snipped-for-privacy@xilinx.com...

Another solution (more suitable for smaller devices, even if slightly less secure) could be to use a private-public key algorithm, like PGP: you encrypt the bitfile with the public key, and the FPGA decrypts it with the private key. The private key would be the same for all the devices (or a "group" of devices), so you could "hardwire" the decode logic and save costs and space.

--
Lorenzo

No problem in the US. China is another story, where IP rip-off is business as usual. Cultural change doesn't happen overnight.

If you boot from parallel EPROM, you usually need a CPLD. If the CPLD has a little logic left over, an authentication algorithm can be implemented between the CPLD and FPGA. Ship the manufacturer enough pre-programmed CPLDs for the build.