How to protect fpga based design against cloning?

[Peter Alfke]

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

 

[Peter Alfke]

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

 

[Erik Widding]

"Peter Alfke" <peter@xilinx.com> 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

 

[Nicholas C. Weaver]

In article <3FA06256.3B3F612B@xilinx.com>,
Peter Alfke <peter@xilinx.com> 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 nweaver@cs.berkeley.edu

 

[Glen Herrmannsfeldt]

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bnrk3l$1pgu$1@agate.berkeley.edu...

In article <3FA06256.3B3F612B@xilinx.com>,
Peter Alfke <peter@xilinx.com> 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

 

[Uwe Bonnes]

Brad Eckert <brad@tinyboot.com> wrote:

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

If I look at US patents, espexially those Internet relates, there's no
difference...
--
Uwe Bonnes bon@elektron.ikp.physik.tu-darmstadt.de

Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------

 

[Nial Stewart]

Erik Widding <widding@birger.com> wrote in message
news:Racob.28628$294.15708@nwrdny03.gnilink.net...

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

Erik, are you not in danger of over charging the battery?

Don't phone batterys degrade fairly quickly if they're
constantly trickle charged rather than being fully
discharged then re-charged? Are the characteristics
of your batterys different?
Have you done any long term tests with this set up?

Are your boards only likely to be powered up every now and
then to stop this happening?

I'm not trying to pick holes, just interested.


Nial

 

[Austin Lesea]

Nial,

You will not damage or over-charge the battery if you follow the
manufacturer's recommendations.

It is amazing how few engineers have even looked at, read, and used the data
sheets for a battery.

It is a component just like any other: study it, learn its characteristics,
and then design it in.

You can blow out any component you want, caps, resistors, transistors, and
batteries, too if you do not read the datasheet.

Go look thru the design guides for the battery chemistry you want to use:
you will be glad you did.

Austin

Nial Stewart wrote:

Erik Widding <widding@birger.com> wrote in message
news:Racob.28628$294.15708@nwrdny03.gnilink.net...
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.
Erik Widding.

Erik, are you not in danger of over charging the battery?

Don't phone batterys degrade fairly quickly if they're
constantly trickle charged rather than being fully
discharged then re-charged? Are the characteristics
of your batterys different?
Have you done any long term tests with this set up?

Are your boards only likely to be powered up every now and
then to stop this happening?

I'm not trying to pick holes, just interested.

Nial

 

[Glen Herrmannsfeldt]

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA28A84.AAA1FE7A@xilinx.com...

Nial,

You will not damage or over-charge the battery if you follow the
manufacturer's recommendations.

It is amazing how few engineers have even looked at, read, and used the
data
sheets for a battery.

It is a component just like any other: study it, learn its
characteristics,
and then design it in.

I don't know the details, but Li ion is very different from NiCd. Some
years ago all we had was NiCd, charged at 0.1C (take the milliamp-hour
rating, divide by 10, and charge at that many milliamps) for 14 hours. That
was all anyone needed to know.

Now there are so many different battery chemistries, each with its own
charging characteristics and discharge characteristics.

-- glen

 

[Austin Lesea]

Glen,

http://www.panasonic.com/industrial/battery/oem/images/pdf/Panasonic_LiIon_Charging.pdf

As I said, just look it up.

Austin

Glen Herrmannsfeldt wrote:

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA28A84.AAA1FE7A@xilinx.com...
Nial,

You will not damage or over-charge the battery if you follow the
manufacturer's recommendations.

It is amazing how few engineers have even looked at, read, and used the
data
sheets for a battery.

It is a component just like any other: study it, learn its
characteristics,
and then design it in.

I don't know the details, but Li ion is very different from NiCd. Some
years ago all we had was NiCd, charged at 0.1C (take the milliamp-hour
rating, divide by 10, and charge at that many milliamps) for 14 hours. That
was all anyone needed to know.

Now there are so many different battery chemistries, each with its own
charging characteristics and discharge characteristics.

-- glen

 

[Nicholas C. Weaver]

In article <LEjob.66337$e01.231913@attbi_s02>,
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:

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.

Well, you've already greatly abstracted things once you go through the
Jbits model, you really DO have the functional, LUT-mapped netlist
when you are done with the pushbutton.

What one wants to do AFTER that is up for debate, but it is
machine-readable at that point, so one could start to build higher
level tools to go from there. Give enough money and reason, and the
tools would get written.

What my point is is that one doesn't have to reverse engineer the
bitstream: Xilinx has done that already.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Glen Herrmannsfeldt]

"Austin Lesea" <Austin.Lesea@xilinx.com> wrote in message
news:3FA2AF12.D47B0806@xilinx.com...

Glen,


http://www.panasonic.com/industrial/battery/oem/images/pdf/Panasonic_LiIon_C

harging.pdf

As I said, just look it up.

Probably the one who wants to build the thing should look it up. Though I
might want to know why my cell phone battery died.

-- glen

 

[Glen Herrmannsfeldt]

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> wrote in message
news:bnucoo$2ka9$1@agate.berkeley.edu...

In article <LEjob.66337$e01.231913@attbi_s02>,
Glen Herrmannsfeldt <gah@ugcs.caltech.edu> wrote:
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.

Well, you've already greatly abstracted things once you go through the
Jbits model, you really DO have the functional, LUT-mapped netlist
when you are done with the pushbutton.

What one wants to do AFTER that is up for debate, but it is
machine-readable at that point, so one could start to build higher
level tools to go from there. Give enough money and reason, and the
tools would get written.

So how much money to get from 8 megabytes of configuration to commented VHDL
code?

-- glen

 

[H. Peter Anvin]

Followup to: <3fa24caf$0$12666$fa0fcedb@lovejoy.zen.co.uk>
By author: "Nial Stewart" <nial@spamno.nialstewart.co.uk>
In newsgroup: comp.arch.fpga

Don't phone batterys degrade fairly quickly if they're
constantly trickle charged rather than being fully
discharged then re-charged? Are the characteristics
of your batterys different?

The much-hyped "memory effect" of certain battery technologies have
actually been disproven in quite a few tests -- what it really is all
about is overcharging. Some chargers would simply give full power for
X amount of time, and if the battery wasn't fully discharged at the
start of the cycle it would get overcharged.

Overcharging causes massive heat dissipation inside the battery, and
can cause the battery matrix to crack, thus causing the battery to
degrade.

-hpa



--
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

 

[Lorenzo Lutti]

"Peter Alfke" <peter@xilinx.com> ha scritto nel messaggio
news:3FA14829.68001BC7@xilinx.com...

Why would this be better for small devices

Because batteries are big, expensive and unreliable.

Well, you need a $1.00 watch battery...

$1 watch battery doesn't last much at 85 degrees C. And when it's
finished (hopefully without exploding or corroding the circuit with his
acid), the customer needs to send back the device to me, because the key
is lost.

I think the public/protected key technique is far more reliable and
simple.

--
Lorenzo

 

[Nicholas C. Weaver]

In article <Z9Rob.83415$vO5.3037135@twister1.libero.it>,
Lorenzo Lutti <lorenzol@despammed.com> wrote:

Why would this be better for small devices

Because batteries are big, expensive and unreliable.

Well, you need a $1.00 watch battery...

$1 watch battery doesn't last much at 85 degrees C. And when it's
finished (hopefully without exploding or corroding the circuit with his
acid), the customer needs to send back the device to me, because the key
is lost.

I think the public/protected key technique is far more reliable and
simple.

How do you PROTCET the secret in the FPGA. THAT is the key.

Once you can get a secret in the FPGA, the rest is easy, and private
key (eg DES) is actually better for that. AS for keeping the secret
in the FPGA, the two options are antifuze/EEPROM style or battery
style. And battery -backup is much more effective/easy as it doesn't
require process changes.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Lorenzo Lutti]

"Nicholas C. Weaver" <nweaver@ribbit.CS.Berkeley.EDU> ha scritto nel
messaggio news:bo0pgq$bpr$1@agate.berkeley.edu...

How do you PROTCET the secret in the FPGA. THAT is the
key.

You will have the same security problems with a key stored into an
internal RAM:

-Are you going to do a brute force attack? Then the way the key is
stored is irrilevant;
-Are you going to open the chip, put a probe after the decrypt circuit
and read the unencrypted bitstream? Then the algorithm (as well as the
key) is irrilevant;
-Are you going to open the chip and reverse-engineer the decrypt
circuit? Then it's more easy to read a key stored into a SRAM, rather
than figure out how works a decrypt circuit with an hardwired key.

The only security problem with the "hardwired private key" is that if
someone manages to to steal the secrey key to the manufacturer, he will
be able to decrypt all the bitfiles encrypted with its public key. But
this is a matter of enterprise security and social engineering, not a
technical issue.

--
Lorenzo

 

[Erik Widding]

"Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote...

Erik, are you not in danger of over charging the battery?

Don't phone batterys degrade fairly quickly if they're
constantly trickle charged rather than being fully
discharged then re-charged? Are the characteristics
of your batterys different?
Have you done any long term tests with this set up?

The battery that we use is a Niobium-Lithium (NBL) from Panasonic.
More information:
http://www.panasonic.com/industrial/battery/oem/chem/lith/niobium.htm

Austin's post that parallels this one, makes the very important
point that few engineers bother to understand battery chemistry
or even read the data sheets (Nial - this is not directed at you).

The major point is Lithium-Ion batteries have a bunch of problems
that are a trade off against the extremely high energy per unit
volume, and the capability of providing high currents (discharge
entire battery in 1 hour), that makes them desireable for cell
phones for example.

NBL batteries are basically everything that a LiIon battery isn't.
Very low self discharge (2%/year), not capable of providing much
current (discharge the entire battery in no less than 400 hours) and
with probably the crappiest energy per unit volume rating of
any commercially viable battery on the market. This is the perfect
(or as perfect as was available two years ago when we qualified it
for design use) battery chemistry for this application.

There are a lot of battery chemistries available. No single
chemistry is right for every application. With fuel cells on the
way shortly, we will soon have yet another option to understand.



Regards,
Erik Widding.

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

 

[Nicholas C. Weaver]

In article <c2cpb.85603$vO5.3153434@twister1.libero.it>,
Lorenzo Lutti <lorenzol@despammed.com> wrote:

-Are you going to do a brute force attack? Then the way the key is
stored is irrilevant;

Barring a MAJOR breakthrough in cryptanalysis, you CAN'T brute force
3DES or AES. A 112/128 bit keysize (3DES, AES 128-bit) is so large
that anything short of lots of sci-fi nanotech are not gonna cut it.
--
Nicholas C. Weaver nweaver@cs.berkeley.edu

 

[Simon Peacock]

Actually the main problem with that batter is the word lithium something
about the quantity allowed on airplanes

Simon

"Erik Widding" <widding@birger.com> wrote in message
news:Fkcpb.66878$1C5.30471@nwrdny02.gnilink.net...

"Nial Stewart" <nial@spamno.nialstewart.co.uk> wrote...

Erik, are you not in danger of over charging the battery?

Don't phone batterys degrade fairly quickly if they're
constantly trickle charged rather than being fully
discharged then re-charged? Are the characteristics
of your batterys different?
Have you done any long term tests with this set up?

The battery that we use is a Niobium-Lithium (NBL) from Panasonic.
More information:
http://www.panasonic.com/industrial/battery/oem/chem/lith/niobium.htm

Austin's post that parallels this one, makes the very important
point that few engineers bother to understand battery chemistry
or even read the data sheets (Nial - this is not directed at you).

The major point is Lithium-Ion batteries have a bunch of problems
that are a trade off against the extremely high energy per unit
volume, and the capability of providing high currents (discharge
entire battery in 1 hour), that makes them desireable for cell
phones for example.

NBL batteries are basically everything that a LiIon battery isn't.
Very low self discharge (2%/year), not capable of providing much
current (discharge the entire battery in no less than 400 hours) and
with probably the crappiest energy per unit volume rating of
any commercially viable battery on the market. This is the perfect
(or as perfect as was available two years ago when we qualified it
for design use) battery chemistry for this application.

There are a lot of battery chemistries available. No single
chemistry is right for every application. With fuel cells on the
way shortly, we will soon have yet another option to understand.



Regards,
Erik Widding.

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