How to protect fpga based design against cloning?

Hi all

I don't know too much about fpga's yet so bear with me if this sounds
too silly. I'm quite interested from what I heard so far and intend to
dig deeper into the topic.

While reading diverse articles about fpga's I got the impression that
they have to be programmed out of a prom or through a microprocessor
etc. However, this means that it would be very easy to "catch" this
code in a finished design and abuse it to clone/copy such a design.

So, my question is, is my impression right, and if so what common
protection mechanisms are available? Or are there fpga's available
that contain flash memory for the purpose of progrmming them on chip
or such? Some scheme similar to what's available with most
microcontrollers that contain on chip flash?

TIA

Markus

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote:

> Hi all
>
> I don't know too much about fpga's yet so bear with me if this sounds
> too silly. I'm quite interested from what I heard so far and intend to
> dig deeper into the topic.
>
> While reading diverse articles about fpga's I got the impression that
> they have to be programmed out of a prom or through a microprocessor
> etc. However, this means that it would be very easy to "catch" this
> code in a finished design and abuse it to clone/copy such a design.
>
> So, my question is, is my impression right, and if so what common
> protection mechanisms are available? Or are there fpga's available
> that contain flash memory for the purpose of progrmming them on chip
> or such? Some scheme similar to what's available with most
> microcontrollers that contain on chip flash?
>
> TIA
>
> Markus

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

"Peter Molesworth" <noemail@anonymous.net> wrote in message
news:oprxs2d9yz0ve4v7@news.tiscali.co.uk...
> On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <m.zingg@nct.ch> wrote:
>
> > Hi all
> >
> > I don't know too much about fpga's yet so bear with me if this sounds
> > too silly. I'm quite interested from what I heard so far and intend to
> > dig deeper into the topic.
> >
> > While reading diverse articles about fpga's I got the impression that
> > they have to be programmed out of a prom or through a microprocessor
> > etc. However, this means that it would be very easy to "catch" this
> > code in a finished design and abuse it to clone/copy such a design.
> >
> > So, my question is, is my impression right, and if so what common
> > protection mechanisms are available? Or are there fpga's available
> > that contain flash memory for the purpose of progrmming them on chip
> > or such? Some scheme similar to what's available with most
> > microcontrollers that contain on chip flash?
> >
> > TIA
> >
> > Markus
>
> 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.

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.

>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

In article <l9cvpv4fb6dssvm0u6pn4t84di2cn0op9p@4ax.com>,
Markus Zingg  <m.zingg@nct.ch> wrote:
>So, my question is, is my impression right, and if so what common
>protection mechanisms are available? Or are there fpga's available
>that contain flash memory for the purpose of progrmming them on chip
>or such? Some scheme similar to what's available with most
>microcontrollers that contain on chip flash?

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

This discussion has not mentioned the best protection in any FPGA:
All Xilinx Virtex-II devices have an on-chip decryptor that can decrypt
a triple-DES encoded bitstream, using an on-chip stored 3x56-bit key.
This key is kept alive with a small external battery. A small price to
pay for the best security in a wide range of high-performance FPGAs...
Peter Alfke, Xilinx Applications
==================
Markus Zingg wrote:
> 
> >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

Peter Molesworth <noemail@anonymous.net> writes:

> antifuse. Also Xilinx do what are called 'Hardcopy' devices which are
> basically the same as the original FPGA but with hardwired logic

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?

"Markus Zingg" wrote:

> While reading diverse articles about fpga's I got the impression that
> they have to be programmed out of a prom or through a microprocessor
> etc. However, this means that it would be very easy to "catch" this
> code in a finished design and abuse it to clone/copy such a design.

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"

"Martin Euredjian" <0_0_0_0_@pacbell.net> wrote in message
news:J8Vnb.151$t45.14067905@newssvr21.news.prodigy.com...
> "Markus Zingg" wrote:

> > While reading diverse articles about fpga's I got the impression that
> > they have to be programmed out of a prom or through a microprocessor
> > etc. However, this means that it would be very easy to "catch" this
> > code in a finished design and abuse it to clone/copy such a design.

> 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.

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