FPGA Central - World's 1st FPGA / CPLD Portal

FPGA Central

World's 1st FPGA Portal

 

Go Back   FPGA Groups > NewsGroup > FPGA

FPGA comp.arch.fpga newsgroup (usenet)

Reply
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old 10-29-2003, 12:30 PM
Markus Zingg
Guest
 
Posts: n/a
Default 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
Reply With Quote
  #2 (permalink)  
Old 10-29-2003, 12:59 PM
Peter Molesworth
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <[email protected]> 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.
Reply With Quote
  #3 (permalink)  
Old 10-29-2003, 01:22 PM
Matt North
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

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" <[email protected]> wrote in message
news[email protected]
> On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <[email protected]> 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.



Reply With Quote
  #4 (permalink)  
Old 10-29-2003, 01:51 PM
kryten_droid
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

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.



Reply With Quote
  #5 (permalink)  
Old 10-29-2003, 03:47 PM
Markus Zingg
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

>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
Reply With Quote
  #6 (permalink)  
Old 10-29-2003, 05:04 PM
Nicholas C. Weaver
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

In article <[email protected]>,
Markus Zingg <[email protected]> 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 [email protected]
Reply With Quote
  #7 (permalink)  
Old 10-29-2003, 05:18 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

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

Reply With Quote
  #8 (permalink)  
Old 10-29-2003, 05:22 PM
Petter Gustad
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

Peter Molesworth <[email protected]> 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?
Reply With Quote
  #9 (permalink)  
Old 10-29-2003, 08:10 PM
Martin Euredjian
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

"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:
[email protected]
where
"0_0_0_0_" = "martineu"


Reply With Quote
  #10 (permalink)  
Old 10-29-2003, 10:30 PM
Glen Herrmannsfeldt
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?


"Martin Euredjian" <[email protected]> wrote in message
news:[email protected] .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


Reply With Quote
  #11 (permalink)  
Old 10-29-2003, 11:47 PM
Khim Bittle
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <[email protected]>
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


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






Reply With Quote
  #12 (permalink)  
Old 10-30-2003, 12:18 AM
David R Brooks
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

As Peter Alfke has pointed out, Xilinx FPGAs can use a 3DES encrypted
bitstream, with battery-backed SRAM in the FPGA holding the key.
But if batteries are verboten for you, bear in mind that it's one
thing to *copy* a bit stream, and quite another to reverse-engineer it
to a point where one can make useful changes. So the SIM-card idea is
still useful. That idea of shipping the SIM separately to the
end-users, so that the (contract) manufacturer cannot sell units on
the side, also has merit.

Markus Zingg <[email protected]> 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

Reply With Quote
  #13 (permalink)  
Old 10-30-2003, 12:59 AM
Peter Alfke
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?



Khim Bittle wrote:
> 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 ??
>

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
Reply With Quote
  #14 (permalink)  
Old 10-30-2003, 01:27 AM
Hal Murray
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

> That idea of shipping the SIM separately to the
>end-users, so that the (contract) manufacturer cannot sell units on
>the side, also has merit.


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.

Reply With Quote
  #15 (permalink)  
Old 10-30-2003, 02:31 AM
kryten_droid
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

"Hal Murray" <[email protected]> wrote in message
news:[email protected]
> >That idea of shipping the SIM separately to the
> >end-users, so that the (contract) manufacturer cannot sell units on
> >the side, also has merit.

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


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.



Reply With Quote
  #16 (permalink)  
Old 10-30-2003, 05:06 AM
Jake Janovetz
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

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: http://www.bltinc.com

Jake


[email protected] (Khim Bittle) wrote in message news:<[email protected]>...
> On Wed, 29 Oct 2003 13:30:09 +0100, Markus Zingg <[email protected]>
> 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

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

Reply With Quote
  #17 (permalink)  
Old 10-30-2003, 07:21 AM
Glen Herrmannsfeldt
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?


"Peter Alfke" <[email protected]> wrote in message
news:[email protected]

> Khim Bittle wrote:

(snip)
> > 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 ??
> >

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


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


Reply With Quote
  #18 (permalink)  
Old 10-30-2003, 09:06 AM
Markus Zingg
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

>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


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
Reply With Quote
  #19 (permalink)  
Old 10-30-2003, 03:32 PM
Lorenzo Lutti
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

"Peter Alfke" <[email protected]> ha scritto nel messaggio
news:[email protected]

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


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


Reply With Quote
  #20 (permalink)  
Old 10-30-2003, 03:48 PM
Brad Eckert
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

[email protected] (Hal Murray) wrote in message news:<[email protected]>...
> > That idea of shipping the SIM separately to the
> >end-users, so that the (contract) manufacturer cannot sell units on
> >the side, also has merit.

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


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.
Reply With Quote
  #21 (permalink)  
Old 10-30-2003, 05:10 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?



Markus Zingg wrote:
> 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?
>

It's much better:
The battery, including its holder is <$2.
And you can remove the battery and exchange it for a new one anytime
normal Vccint powers the chip. The battery comes into play only when
Vccint is low or zero.

Peter Alfke
Reply With Quote
  #22 (permalink)  
Old 10-30-2003, 05:19 PM
Peter Alfke
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?



Lorenzo Lutti wrote:

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


Why would this be better for small devices, when the Virtex-II
triple-DES decoder is free. It really is, since it is implemented in
every device in a chip area you cannot use for anything else. That's
what I call "free", you gain nothing by not using it.
Well, you need a $1.00 watch battery...
Peter Alfke
Reply With Quote
  #23 (permalink)  
Old 10-30-2003, 05:49 PM
Erik Widding
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

"Peter Alfke" <[email protected]> wrote...
> It's much better:
> The battery, including its holder is <$2.
> And you can remove the battery and exchange it for a new one anytime
> normal Vccint powers the chip. The battery comes into play only when
> Vccint is low or zero.


We have been using a rechargeable lithium battery ($1.25 / 4mAh)
that is soldered directly to the PCB. Add a low leakage diode and
a current limiting resistor for a recharger circuit and you do not
need to worry about replacement. The only requirement is that the
board be powered up for a few hours every couple of years. The
only issue that we have with this is that the batteries can't tolerate
the oven, and must be hand soldered.


Regards,
Erik Widding.


---
Birger Engineering, Inc. -------------------------------- 617.695.9233
100 Boylston St #1070; Boston, MA 02116 -------- http://www.birger.com


Reply With Quote
  #24 (permalink)  
Old 10-30-2003, 06:08 PM
Nicholas C. Weaver
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?

In article <[email protected]>,
Peter Alfke <[email protected]> wrote:
>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.


Uh, sorry peter. Give me a normal bitfile and $200k to write the
software the first time (overpay me) and I'll be able to back-annotate
it at least to the placed EDIF netlist, as long as the architecture is
supported by Jbits.

Why reverse engineer the bitstream when Xilinx has already given a
tool which can go from a bitstream to a model of the device at the PIP
level, which can then be programmatically run back to the connection
and LUT functionality level.
--
Nicholas C. Weaver [email protected]
Reply With Quote
  #25 (permalink)  
Old 10-31-2003, 02:19 AM
Glen Herrmannsfeldt
Guest
 
Posts: n/a
Default Re: How to protect fpga based design against cloning?


"Nicholas C. Weaver" <[email protected]> wrote in message
news:[email protected]
> In article <[email protected]>,
> Peter Alfke <[email protected]> wrote:
> >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.

>
> Uh, sorry peter. Give me a normal bitfile and $200k to write the
> software the first time (overpay me) and I'll be able to back-annotate
> it at least to the placed EDIF netlist, as long as the architecture is
> supported by Jbits.


Consider that, (from the Xilinx web site) there are Virtex2 devices with
125136 logic cells, and over 8 megabytes of configuration information. A
hex dump of the configuration file, 80 characters per line, 60 lines per
page, would be over 3000 pages long, and not readable by anyone.

The netlist might be 100 times as long, or 300,000 pages. That is a stack
of paper about 100feet (30m) tall. Now, say you print that out, and maybe
wear out a few printers while doing it. Now you want to change one node.
How long will it take to find that node?

There are smaller devices, and maybe one could work their way through the
netlist. I think, though, for anything bigger than an XC4002 it would be
hard to get much useful information out of even a netlist.

-- glen


Reply With Quote
Reply

Bookmarks

Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On


Similar Threads
Thread Thread Starter Forum Replies Last Post
Verilog based PCB design flow? Petter Gustad Verilog 5 04-14-2010 06:24 PM
FSM based digital design chetan Verilog 0 03-15-2008 05:05 PM
Timing analysis for latch-based design in Design Compiler. [email protected] Verilog 1 12-02-2005 04:06 AM
interfacing a PC based program with a FPGA Srinivas Verilog 10 10-26-2004 08:14 AM


All times are GMT +1. The time now is 06:31 PM.


Powered by vBulletin® Version 3.8.0
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
Search Engine Friendly URLs by vBSEO 3.2.0
Copyright 2008 @ FPGA Central. All rights reserved