Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search

Messages from 142325

Article: 142325
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Tue, 4 Aug 2009 11:55:25 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 11:59=A0am, untergangsprophet <filter...@desinformation.de>
wrote:
> > Is it possible that even though I use AES encrypted bitstream, another
> > trojan/bad bitstream that mimiked my design could be loaded into FPGA?
>
> If your design can be mimiked AES encryption seems not necessary.

I don't understand this statement.  Every one have access to Xilinx/
Altera tools.  Everyone use USB, PCIe, RS232 type interfaces that are
standard.  I have guts of FPGA that are special but many inteface are
generic.  This make it easier for attacker to mimik the operation of
my FPGA perhaps enough to monitor busses in my design.  If USB link in
my product then easy for attacker to put USB design in my FPGA that
mimik the interface (like phishing website) and user of product enters
password or similar.  whole design not need mimiked.

Article: 142326
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Tue, 4 Aug 2009 12:10:38 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 1:54=A0pm, austin <aus...@xilinx.com> wrote:
> Raj,
>
> With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
> one bitstream is allowed to be entered in secure mode.
>
> That bistream's key must be the one in the battery backed key memory,
> or the device will not program.
>
> Some parts allow subsequent partial reconfiguration, again they must
> use the same key (encrypted), so the attacker would have to know your
> key in order to do this. =A0If they know your key, well, you are not
> secure, are you?
>
> At any time, you may program the device again with another bitstream,
> but that erases the previous (decrypted) bitstream.
>
> While programmed with a encrypted bitstream, JTAG readback is
> disabled, so you can not read the device out.
>
> But, if you place logic in your encrypted design to perform the
> internal configuration readback, and readback and output the values on
> a pin (for example), then you have now created your own "back - door."
>
> We do not protect against doing something this stupid, but we do
> protect the bitstream from all other attacks if you follow a few
> simple rules (like: =A0do not build a back door into your design).
>
> SInce Virtex 2, we have issued challenges to university students and
> researchers to test our security. =A0In addition to being the only
> approved FPGA =A0by the NSA for the crypto-modernization program, we
> have had no method of attack succeed to date,

Thank you experts.  Yes good for protection from decrypt my design.
but that is just for big FPGAs.
  I maybe getting Xilinx and Altera confused.  Altera non-volatile key
based Stratix accepts unencrypted bit data, I thought
Xilinx too.  Xilinx has a non-volatile key now?   I went to HOST last
week and a presenter said that it could
be done.
My CM load bit data for manufacturing tests so logistics are tricky.
prototypes i program key in myself in lab with
vendor tools no problem. large volume it is difficult to coordinate
with multiple sites the key.  CM run tests send back product to me -
key programmed in and then ship back product to CM to run functional
test with bits loaded.
Very costly.
Raj

Article: 142327
Subject: Re: AES encryption of bitstream - is my design secure?
From: gabor <gabor@alacron.com>
Date: Tue, 4 Aug 2009 12:13:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 2:49=A0pm, Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
> On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote:
>
> > On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote:
>
> > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, onl=
y
> > > one bitstream is allowed to be entered in secure mode.
>
> > > That bistream's key must be the one in the battery backed key memory,
> > > or the device will not program.
>
> > so if you remove the battery, can you program anything you want into
> > the fpga?
> > (this is what i thought the op was asking)
>
> Yes, it is related to what i ask. this is one method removing the
> battery, if that is not possible, shorting the battery terminals until
> it is drained.

I was under the impression that you could always load an unencrypted
bitstream, battery or no.  The point is that encryption protects your
bitstream from attempts to copy it.  It doesn't prevent the hardware
from being used for something else.

Article: 142328
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Tue, 4 Aug 2009 13:11:37 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 4, 3:13=A0pm, gabor <ga...@alacron.com> wrote:
> On Aug 4, 2:49=A0pm, Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
>
>
>
>
>
> > On Aug 4, 2:19=A0pm, "a...@nishioka.com" <a...@nishioka.com> wrote:
>
> > > On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote:
>
> > > > With Xilinx FPGA encryption, decryption solutions since Virtex 2, o=
nly
> > > > one bitstream is allowed to be entered in secure mode.
>
> > > > That bistream's key must be the one in the battery backed key memor=
y,
> > > > or the device will not program.
>
> > > so if you remove the battery, can you program anything you want into
> > > the fpga?
> > > (this is what i thought the op was asking)
>
> > Yes, it is related to what i ask. this is one method removing the
> > battery, if that is not possible, shorting the battery terminals until
> > it is drained.
>
> I was under the impression that you could always load an unencrypted
> bitstream, battery or no. =A0The point is that encryption protects your
> bitstream from attempts to copy it. =A0It doesn't prevent the hardware
> from being used for something else.- Hide quoted text -
>
> - Show quoted text -

Thank you for that. I got motivated to look more and V5 FPGA guide
page 36.
***********************************
Once the device has been programmed with the correct encryption key,
the device can be
configured with an encrypted bitstream. After configuration with an
encrypted bitstream,
it is not possible to read the configuration memory through JTAG or
SelectMAP readback,
regardless of the BitGen security setting.
While the device holds an encryption key, *****  a non-encrypted
bitstream can be used to
configure the device; ******** in this case the key is ignored. After
configuring with a nonencrypted
bitstream, readback is possible (if allowed by the BitGen security
setting). The
encryption key still cannot be read out of the device, preventing the
use of Trojan Horse
bitstreams to defeat the Virtex-5 encryption scheme.

**************************************
So you are correct Gabor and Mr. Austin from Xilinx is not,
respectfully, exactkt correct (although he gives us good answers other
times)   It mention Trojan and it not possible to defeat encryption
but easily possible for trojan design and JTAG to hack product, snoop
other system parts V5 is connected to, erase Flash which create Denial
of service, store alternate non-encrypted bit data in multi-boot.
I was skeptical of presentation at HOST hardware security  conference
but I believe it makes more sense now.

Article: 142329
Subject: Re: AES encryption of bitstream - is my design secure?
From: "Nial Stewart" <nial*REMOVE_THIS*@nialstewartdevelopments.co.uk>
Date: Wed, 5 Aug 2009 09:23:48 +0100
Links: << >>  << T >>  << A >>
> > If your design can be mimiked AES encryption seems not necessary.

> I don't understand this statement.

If someone can easily mimick the functionality of your FPGA why would
they bother trying to de-crypt your bit-stream, they'd just re-write
from scratch.


Nial







Article: 142330
Subject: Re: AES encryption of bitstream - is my design secure?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 5 Aug 2009 03:01:51 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 11:23=A0am, "Nial Stewart"
<nial*REMOVE_TH...@nialstewartdevelopments.co.uk> wrote:
> > > If your design can be mimiked AES encryption seems not necessary.
> > I don't understand this statement.
>
> If someone can easily mimick the functionality of your FPGA why would
> they bother trying to de-crypt your bit-stream, they'd just re-write
> from scratch.
>
> Nial

sometimes there is need to to protect the PCB and other design
elements also
so a possibility to download a unencrypted bit file into an FPGA with
AES key set
is somewhat design risc

antti


Article: 142331
Subject: Re: AES encryption of bitstream - is my design secure?
From: Brian Drummond <brian_drummond@btconnect.com>
Date: Wed, 05 Aug 2009 11:11:25 +0100
Links: << >>  << T >>  << A >>
On Wed, 5 Aug 2009 09:23:48 +0100, "Nial Stewart"
<nial*REMOVE_THIS*@nialstewartdevelopments.co.uk> wrote:

>> > If your design can be mimiked AES encryption seems not necessary.
>
>> I don't understand this statement.
>
>If someone can easily mimick the functionality of your FPGA why would
>they bother trying to de-crypt your bit-stream, they'd just re-write
>from scratch.
>
If they can mimic the functionality of the interfaces, they could learn a lot
about the system that connects to the FPGA. 

Unless that system interrogates the FPGA appropriately ("encrypt this message
with the private part of your key pair") and refuses to do anything interesting
if it gets the wrong answer.

- Brian

Article: 142332
Subject: Re: AES encryption of bitstream - is my design secure?
From: Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk>
Date: Wed, 05 Aug 2009 10:37:49 GMT
Links: << >>  << T >>  << A >>
Rajesh Gandhi <rgandhi4086@gmail.com> wrote:

>So you are correct Gabor and Mr. Austin from Xilinx is not,
>respectfully, exactkt correct (although he gives us good answers other
>times)   It mention Trojan and it not possible to defeat encryption
>but easily possible for trojan design and JTAG to hack product, snoop
>other system parts V5 is connected to, erase Flash which create Denial
>of service, store alternate non-encrypted bit data in multi-boot.
>I was skeptical of presentation at HOST hardware security  conference
>but I believe it makes more sense now.

That's what Mr. Austin said -- the bitstream is secure but the hardware
can be used for other things.

-- 
Dave Farrance

Article: 142333
Subject: dcm
From: nithin jayavarapu <nithin.j38@gmail.com>
Date: Wed, 5 Aug 2009 04:43:08 -0700 (PDT)
Links: << >>  << T >>  << A >>
sir
i am doing project in segmented digital clock manager fpga based dpwm
so i want vhdl code for dcm if u have any code please send it to me .

Article: 142334
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Wed, 5 Aug 2009 05:57:28 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 6:37=A0am, Dave Farrance
<DaveFarra...@OMiTTHiSyahooANDTHiS.co.uk> wrote:
> Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
> >So you are correct Gabor and Mr. Austin from Xilinx is not,
> >respectfully, exactkt correct (although he gives us good answers other
> >times) =A0 It mention Trojan and it not possible to defeat encryption
> >but easily possible for trojan design and JTAG to hack product, snoop
> >other system parts V5 is connected to, erase Flash which create Denial
> >of service, store alternate non-encrypted bit data in multi-boot.
> >I was skeptical of presentation at HOST hardware security =A0conference
> >but I believe it makes more sense now.
>
> That's what Mr. Austin said -- the bitstream is secure but the hardware
> can be used for other things.
>
Dear Mr.Dave,
The part said by Mr. Austin was misinformation which adds to
confusion.

>With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
>one bitstream is allowed to be entered in secure mode.
>That bistream's key must be the one in the battery backed key memory,
>or the device will not program.
The device will program when there is NO ENCRYPTION.  Hence Trojan
bitstream is easy to implement.  Trojans do not need to decrypt the
bitstream,
attacker can program a bitstream into V5 or Stratix by programming on-
board FLASH
with JTAG.  All are 'wide-open' for hacking.  FPGA can be programmed
which will assist in 1)
getting passwords from users/admin/embedded 2) getting OTHER keys (not
FPGA key) in system
3) snoop system to hack and potentially unlock unpaid-for features
(turn low end product into high end product)
4) learn enough about system to build compatible plug-ins (games,
software, songs, videos, printer cartridges) which
may not be part of economic strategy.

"cant prevent hardware from being used for other things" sounds like
simple statement but many hardware products
are sold at loss or break-even or very low margin in order to make
market share.  Printers for example. Company
makes money on consumables or plug-ins to the platform.  Xbox is
example  - which is really just Intel PC sold at loss
to get market to sell games and internet service.  Was Hacked to run
linux which is embarassment for Microsoft
but also a loss of $200 for each xbox purchased to run linux.  Cisco
low end router can be made into high end router with hack patch - loss
of revenue for Cisco.

Reader who say 'if simple to mimik then u don't need encryption,
engineer will build from scratch' maybe missing the point. They are to
build a bit data by scratch that is their intent, to have their design
in place to do bad things. steal user password (not fpga key), monitor
keyboard input, monitor USB connection, insert 'time bomb' to stop
system functioning at critical time of need.
if I have embedded powerpc based fpga it maybe quiet easy for attacker
to get it to boot linux and have design which monitor keyboard input
for admin logins and store or send over internet.  The interfaces are
all standard so easy to develop.

And in end only virtex/stratix are secure, others are not.  system
security maybe not xilinx/altera problem, just mine, but i have to
develop.
Am I only one in FPGA area for this concern?



Article: 142335
Subject: Driving Multiple FPGAs and Fanout (Cyclone III)
From: "snowball67" <wtiong@singnet.com.sg>
Date: Wed, 05 Aug 2009 08:18:09 -0500
Links: << >>  << T >>  << A >>
Hi,

I have a design that will comprise of 11 FPGA boards: 10 slaves and 1
master and each board is having one cyclone III FPGA. The communication
between master and slaves is via a simple SRAM protocol (with addr, data,
WR/RD and CS). All boards will be interconnected together on a backplane
board, with about 1 inch apart.

According to the electrical specifications, the input leakage current of
each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive
strength, theoretically one master could drive up to 400 slaves? Is this
too good to believe? Also, overshoot voltage could be a problem if signals
are not terminated. Altera recommended 33R series resistor on each line.
Does anyone have similar experience on this?

I also would like to know what is the real benefit of using LVCMOS apart
from LVTTL.

Any recommendation is much appreciated.



Article: 142336
Subject: Re: AES encryption of bitstream - is my design secure?
From: gabor <gabor@alacron.com>
Date: Wed, 5 Aug 2009 06:24:36 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 8:57=A0am, Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
> On Aug 5, 6:37=A0am, Dave Farrance<DaveFarra...@OMiTTHiSyahooANDTHiS.co.u=
k> wrote:
> > Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
> > >So you are correct Gabor and Mr. Austin from Xilinx is not,
> > >respectfully, exactkt correct (although he gives us good answers other
> > >times) =A0 It mention Trojan and it not possible to defeat encryption
> > >but easily possible for trojan design and JTAG to hack product, snoop
> > >other system parts V5 is connected to, erase Flash which create Denial
> > >of service, store alternate non-encrypted bit data in multi-boot.
> > >I was skeptical of presentation at HOST hardware security =A0conferenc=
e
> > >but I believe it makes more sense now.
>
> > That's what Mr. Austin said -- the bitstream is secure but the hardware
> > can be used for other things.
>
> Dear Mr.Dave,
> The part said by Mr. Austin was misinformation which adds to
> confusion.
>
> >With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
> >one bitstream is allowed to be entered in secure mode.
> >That bistream's key must be the one in the battery backed key memory,
> >or the device will not program.
>

I think Austin did not lie here, he said only one bitstream is allowed
to be entered "in secure mode".  There was no representation of
the prevention of non-secured bitstreams.

> The device will program when there is NO ENCRYPTION. =A0Hence Trojan
> bitstream is easy to implement. =A0Trojans do not need to decrypt the
> bitstream,
> attacker can program a bitstream into V5 or Stratix by programming on-
> board FLASH
> with JTAG. =A0All are 'wide-open' for hacking. =A0FPGA can be programmed
> which will assist in 1)
> getting passwords from users/admin/embedded 2) getting OTHER keys (not
> FPGA key) in system
> 3) snoop system to hack and potentially unlock unpaid-for features
> (turn low end product into high end product)
> 4) learn enough about system to build compatible plug-ins (games,
> software, songs, videos, printer cartridges) which
> may not be part of economic strategy.
>
> "cant prevent hardware from being used for other things" sounds like
> simple statement but many hardware products
> are sold at loss or break-even or very low margin in order to make
> market share. =A0Printers for example. Company
> makes money on consumables or plug-ins to the platform. =A0Xbox is
> example =A0- which is really just Intel PC sold at loss
> to get market to sell games and internet service. =A0Was Hacked to run
> linux which is embarassment for Microsoft
> but also a loss of $200 for each xbox purchased to run linux. =A0Cisco
> low end router can be made into high end router with hack patch - loss
> of revenue for Cisco.
>
> Reader who say 'if simple to mimik then u don't need encryption,
> engineer will build from scratch' maybe missing the point. They are to
> build a bit data by scratch that is their intent, to have their design
> in place to do bad things. steal user password (not fpga key), monitor
> keyboard input, monitor USB connection, insert 'time bomb' to stop
> system functioning at critical time of need.
> if I have embedded powerpc based fpga it maybe quiet easy for attacker
> to get it to boot linux and have design which monitor keyboard input
> for admin logins and store or send over internet. =A0The interfaces are
> all standard so easy to develop.
>
> And in end only virtex/stratix are secure, others are not. =A0system
> security maybe not xilinx/altera problem, just mine, but i have to
> develop.
> Am I only one in FPGA area for this concern?

Your requirements for security are different from many others
who simply want their bitstream copy protected.  If you have
requirements to prevent your system from being used for other
purposes, your best bet is to make sure the part you use cannot
be re-programmed.  I believe Actel has some good solutions for
this.  Also if your volume is adequate you could consider a
part like the eASIC "structured ASIC" which straddles the
fence between FPGA and ASIC.  Altera also has their hard
wired versions of FPGA's if you prefer to start with an SRAM
FPGA and then move to a non-reprogrammable version.  At
the moment Xilinx has no similar products.

Regards,
Gabor

Article: 142337
Subject: Re: Driving Multiple FPGAs and Fanout (Cyclone III)
From: gabor <gabor@alacron.com>
Date: Wed, 5 Aug 2009 07:35:20 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 9:18=A0am, "snowball67" <wti...@singnet.com.sg> wrote:
> Hi,
>
> I have a design that will comprise of 11 FPGA boards: 10 slaves and 1
> master and each board is having one cyclone III FPGA. The communication
> between master and slaves is via a simple SRAM protocol (with addr, data,
> WR/RD and CS). All boards will be interconnected together on a backplane
> board, with about 1 inch apart.
>
> According to the electrical specifications, the input leakage current of
> each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive
> strength, theoretically one master could drive up to 400 slaves? Is this
> too good to believe? Also, overshoot voltage could be a problem if signal=
s
> are not terminated. Altera recommended 33R series resistor on each line.
> Does anyone have similar experience on this?
>
> I also would like to know what is the real benefit of using LVCMOS apart
> from LVTTL.
>
> Any recommendation is much appreciated.

Since the days of bipolar TTL logic, the DC loading has never been
the limiting factor for fanout.  With CMOS, your load is essentially
a capacitor.  400 10pF loads becomes 4 nF.  Think of the rise and
fall times your LVTTL or LVCMOS signal can achieve under these
conditions!

Series termination is a bad idea when driving a backplane.  And
driving the clocks, or asynchronous command signals if there
is no clock, requires incident wave switching.  Unless you want
to run your "simple" SRAM interface at a fairly low speed, I
would suggest re-thinking your interconnect.  Perhaps with
the same number of wires, but arranged as point-to-point
connections in a loop, you could run at many times the data
rate while easily achieving good signal integrity.

Just my 2 cents,
Gabor

Article: 142338
Subject: Re: AES encryption of bitstream - is my design secure?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 5 Aug 2009 07:54:01 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 4:24=A0pm, gabor <ga...@alacron.com> wrote:
> On Aug 5, 8:57=A0am, Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
>
>
>
>
>
> > On Aug 5, 6:37=A0am, Dave Farrance<DaveFarra...@OMiTTHiSyahooANDTHiS.co=
.uk> wrote:
> > > Rajesh Gandhi <rgandhi4...@gmail.com> wrote:
> > > >So you are correct Gabor and Mr. Austin from Xilinx is not,
> > > >respectfully, exactkt correct (although he gives us good answers oth=
er
> > > >times) =A0 It mention Trojan and it not possible to defeat encryptio=
n
> > > >but easily possible for trojan design and JTAG to hack product, snoo=
p
> > > >other system parts V5 is connected to, erase Flash which create Deni=
al
> > > >of service, store alternate non-encrypted bit data in multi-boot.
> > > >I was skeptical of presentation at HOST hardware security =A0confere=
nce
> > > >but I believe it makes more sense now.
>
> > > That's what Mr. Austin said -- the bitstream is secure but the hardwa=
re
> > > can be used for other things.
>
> > Dear Mr.Dave,
> > The part said by Mr. Austin was misinformation which adds to
> > confusion.
>
> > >With Xilinx FPGA encryption, decryption solutions since Virtex 2, only
> > >one bitstream is allowed to be entered in secure mode.
> > >That bistream's key must be the one in the battery backed key memory,
> > >or the device will not program.
>
> I think Austin did not lie here, he said only one bitstream is allowed
> to be entered "in secure mode". =A0There was no representation of
> the prevention of non-secured bitstreams.
>
>
>
>
>
> > The device will program when there is NO ENCRYPTION. =A0Hence Trojan
> > bitstream is easy to implement. =A0Trojans do not need to decrypt the
> > bitstream,
> > attacker can program a bitstream into V5 or Stratix by programming on-
> > board FLASH
> > with JTAG. =A0All are 'wide-open' for hacking. =A0FPGA can be programme=
d
> > which will assist in 1)
> > getting passwords from users/admin/embedded 2) getting OTHER keys (not
> > FPGA key) in system
> > 3) snoop system to hack and potentially unlock unpaid-for features
> > (turn low end product into high end product)
> > 4) learn enough about system to build compatible plug-ins (games,
> > software, songs, videos, printer cartridges) which
> > may not be part of economic strategy.
>
> > "cant prevent hardware from being used for other things" sounds like
> > simple statement but many hardware products
> > are sold at loss or break-even or very low margin in order to make
> > market share. =A0Printers for example. Company
> > makes money on consumables or plug-ins to the platform. =A0Xbox is
> > example =A0- which is really just Intel PC sold at loss
> > to get market to sell games and internet service. =A0Was Hacked to run
> > linux which is embarassment for Microsoft
> > but also a loss of $200 for each xbox purchased to run linux. =A0Cisco
> > low end router can be made into high end router with hack patch - loss
> > of revenue for Cisco.
>
> > Reader who say 'if simple to mimik then u don't need encryption,
> > engineer will build from scratch' maybe missing the point. They are to
> > build a bit data by scratch that is their intent, to have their design
> > in place to do bad things. steal user password (not fpga key), monitor
> > keyboard input, monitor USB connection, insert 'time bomb' to stop
> > system functioning at critical time of need.
> > if I have embedded powerpc based fpga it maybe quiet easy for attacker
> > to get it to boot linux and have design which monitor keyboard input
> > for admin logins and store or send over internet. =A0The interfaces are
> > all standard so easy to develop.
>
> > And in end only virtex/stratix are secure, others are not. =A0system
> > security maybe not xilinx/altera problem, just mine, but i have to
> > develop.
> > Am I only one in FPGA area for this concern?
>
> Your requirements for security are different from many others
> who simply want their bitstream copy protected. =A0If you have
> requirements to prevent your system from being used for other
> purposes, your best bet is to make sure the part you use cannot
> be re-programmed. =A0I believe Actel has some good solutions for
> this. =A0Also if your volume is adequate you could consider a
> part like the eASIC "structured ASIC" which straddles the
> fence between FPGA and ASIC. =A0Altera also has their hard
> wired versions of FPGA's if you prefer to start with an SRAM
> FPGA and then move to a non-reprogrammable version. =A0At
> the moment Xilinx has no similar products.
>
> Regards,
> Gabor- Hide quoted text -
>
> - Show quoted text -- Hide quoted text -
>
> - Show quoted text -

actually Austin did make a statemented that can be understood
diferently,
he said:

"That bistream's key must be the one in the battery backed key
memory,
or the device will not program. "

this is true, if the key is WRONG,
but if the bitstream has NO KEY then the device will configure ok.
and the all other on-board components are wide open for attack...

this is different for Actel where AES secure parts can not be accessed
without the AES key at all

Antti









Article: 142339
Subject: Re: AES encryption of bitstream - is my design secure?
From: austin <austin@xilinx.com>
Date: Wed, 5 Aug 2009 08:04:29 -0700 (PDT)
Links: << >>  << T >>  << A >>
All,

Perhaps what Raj is referring to is "one-armed bandit" mode (named
because gambling machines must have this feature).

This is when once a key is programmed into the part, the part no
longer will accept any bitstream, only a bitstream encrypted with that
key (which we do not support today for any family).

The problem with this is that once programmed with the key, the device
will never be able to be sent back for test (how do you test a part
when you don't know the key?  how do you encrypt 10,000 test bitstream
to test such a part? etc.).  How do you test it at the CM if you don't
want to tell them the key? (Cm's are known for over-building ...)

The poly efuse keys have been in V5 since day one, where we have been
evaluating the technology and planning what support is required.  We
use some of the bits for inventory.

Spartan 3A has poly efuses blown at the factory for "DeviceDNA."

Virtex 6 might be the first product where AES poly efuse key, and "one-
arm bandit mode" is supported:  but not yet!

Supporting all these features requires assurance that they all work,
the software works to program them, and the customer has the means to
do the programming.

Stay tuned:  yes;  what you hear in conferences may be true, but it
will be after we are sure these things deliver as promised.

If Raj wants to prevent "improper use by a third party," or "over-
build by contract manufacturer," or reverse engineering (cloning),
these are different problems, which require different solutions.
Encryption/Decryption may be used to solve some, but not all of them.

Thanks to those who tried to clarify what I said,  I suspect I will
need more 'clarification' for this post, too.

Austin


Article: 142340
Subject: Re: Driving Multiple FPGAs and Fanout (Cyclone III)
From: "BobW" <nimby_GIMME_SOME_SPAM@roadrunner.com>
Date: Wed, 5 Aug 2009 08:37:44 -0700
Links: << >>  << T >>  << A >>

"snowball67" <wtiong@singnet.com.sg> wrote in message 
news:Vr2dndTtLoMMG-TXnZ2dnUVZ_jGdnZ2d@giganews.com...
> Hi,
>
> I have a design that will comprise of 11 FPGA boards: 10 slaves and 1
> master and each board is having one cyclone III FPGA. The communication
> between master and slaves is via a simple SRAM protocol (with addr, data,
> WR/RD and CS). All boards will be interconnected together on a backplane
> board, with about 1 inch apart.
>
> According to the electrical specifications, the input leakage current of
> each pin is only 10uA. Therefore, in the case of LVTTL with 4mA drive
> strength, theoretically one master could drive up to 400 slaves? Is this
> too good to believe? Also, overshoot voltage could be a problem if signals
> are not terminated. Altera recommended 33R series resistor on each line.
> Does anyone have similar experience on this?
>
> I also would like to know what is the real benefit of using LVCMOS apart
> from LVTTL.
>
> Any recommendation is much appreciated.
>
>

There is more to consider than just the input leakage current of each 
receiver as it only indicates what is possible for static signals. If all 
your signals never change state then, yes, each driver can drive 400 
receivers. Of course, this isn't the reality of your situation.

The input capacitance of each receiver, the rise/fall time of the driver, 
the characteristic impedance of all the traces, and the termination scheme 
used will determine whether the setup and hold times for data lines are met, 
whether the edge requirements for the clock lines are met, and whether the 
undershoot/overshoot specs for all signals are met.

Unless your rise/fall times are very long with respect to all the trace 
propagation times, you'll need to get someone else involved that can guide 
you through these "signal integrity" issues. You can, to some degree, 
control the rise/fall times of FPGA output drivers. However, slower edge 
rates mean lower data rates (must always meet setup and hold reqs on data 
lines and dv/dt reqs on clock lines).

The main advantage of LVCMOS over LVTTL is that LVCMOS input switching 
thresholds are farther from their associated outputs' nominal signal level. 
This allows for more "noise" (signal distortion) at the receiver while still 
meeting input logic level requirements.

Bob
-- 
== All google group posts are automatically deleted due to spam == 



Article: 142341
Subject: Re: AES encryption of bitstream - is my design secure?
From: "Antti.Lukats@googlemail.com" <Antti.Lukats@googlemail.com>
Date: Wed, 5 Aug 2009 08:45:57 -0700 (PDT)
Links: << >>  << T >>  << A >>
On Aug 5, 6:04=A0pm, austin <aus...@xilinx.com> wrote:
> All,
>
> Perhaps what Raj is referring to is "one-armed bandit" mode (named
> because gambling machines must have this feature).
>
> This is when once a key is programmed into the part, the part no
> longer will accept any bitstream, only a bitstream encrypted with that
> key (which we do not support today for any family).
>
> The problem with this is that once programmed with the key, the device
> will never be able to be sent back for test (how do you test a part
> when you don't know the key? =A0how do you encrypt 10,000 test bitstream
> to test such a part? etc.). =A0How do you test it at the CM if you don't
> want to tell them the key? (Cm's are known for over-building ...)
>
> The poly efuse keys have been in V5 since day one, where we have been
> evaluating the technology and planning what support is required. =A0We
> use some of the bits for inventory.
>
> Spartan 3A has poly efuses blown at the factory for "DeviceDNA."
>
> Virtex 6 might be the first product where AES poly efuse key, and "one-
> arm bandit mode" is supported: =A0but not yet!
>
> Supporting all these features requires assurance that they all work,
> the software works to program them, and the customer has the means to
> do the programming.
>
> Stay tuned: =A0yes; =A0what you hear in conferences may be true, but it
> will be after we are sure these things deliver as promised.
>
> If Raj wants to prevent "improper use by a third party," or "over-
> build by contract manufacturer," or reverse engineering (cloning),
> these are different problems, which require different solutions.
> Encryption/Decryption may be used to solve some, but not all of them.
>
> Thanks to those who tried to clarify what I said, =A0I suspect I will
> need more 'clarification' for this post, too.
>
> Austin

Austin

Actel has Flash based AES key, not one time AES so there
is no problem with testing

with the efuse its different story of course

its about time for Xilinx to get the efuses actually working
i have wondering this since the V5 where some early
schematic and docu did show the efuse pins

but xilinx decided to not release V5 efuses to the customers
probably because there are some bugs?

ok, time have elapsed so maybe it all fixed in V6

Antti








Article: 142342
Subject: Re: AES encryption of bitstream - is my design secure?
From: Rajesh Gandhi <rgandhi4086@gmail.com>
Date: Wed, 5 Aug 2009 10:04:22 -0700 (PDT)
Links: << >>  << T >>  << A >>

It may not be easy for an organization using Xilinx/Altera, with
commitments in the
infrastructure of Xilinx/Altera to switch to Actel.   One needing
SERDES and PCIe
etc and other IP may not be able to go to Actel if the IC doesn't
support it or the
IP is not freely available in the tools.

I will continue my investigation.  At the moment there doesn't seem to
be a solution for
bit data (bitstream) authentication and anti-hacking.  I read these
which maybe of help

http://mae.pennnet.com/articles/article_display.cfm?article_id=309174
http://online.wsj.com/article/SB124027491029837401.html
Altera announced this but I suspect it is no different than
Spartan3AN.
http://mae.pennnet.com/whitepapers/wp.cfm?id=1400

Those work great if I do my entire design in Spartan3AN or the Altera,
but that is not likely.

Perhaps it is perceived as Military problem only, however, I see just
as much problem for
many products in commercial area too.  But maybe the volumes of FPGA
based products are
not like Xbox, iphone, linksys router or other previous hacked
products.

Thanks for all your input, I learned a lot.  And no offence to Mr.
Austin for providing information, perhaps
my words were too strict of 'incorrect', perhaps miscommunication on
my part.  In the
end I thnk we are in fair agreement.  These are different problems
that AES/Encrypt/decrypt
does not solve.   the perception by the fpga designers, however, I
think is that it does solve
these problems.
 >If Raj wants to prevent "improper use by a third party," or "over-
>build by contract manufacturer," or reverse engineering (cloning),
>these are different problems, which require different solutions.
>Encryption/Decryption may be used to solve some, but not all of them.

But absolutely in concurrence with Mr. Austin, it does not prevent
overbuilding,
reverse engineering, cloning.  To that I add 'trojan bitstreams' used
to compromise software security.
The marketing material and articles from Xilinx/Altera (please do not
take offense) do use the
words protection from overbuilding and cloning with respect to AES
encrypted bitstreams however
that is only  the case when you program the keys yourself or have a
trusted third party program them.
  Practical on small scale of 10 or so but not practical for a 1000.
I further agree Mr. Austin that the unencrypted bitstreams are
necessary to be loaded for the CM to test my PCB with JTAG
and related methods. I Understand why, just pointing out that is the
hole in the security which enables trojans and unauthenticated
bistreams that a  system designer should address in commercial space
not just military.

Best Wishes,
Raj









Article: 142343
Subject: Re: AES encryption of bitstream - is my design secure?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 5 Aug 2009 17:18:48 +0000 (UTC)
Links: << >>  << T >>  << A >>
Antti.Lukats@googlemail.com <Antti.Lukats@googlemail.com> wrote:
(snip)
 
> sometimes there is need to to protect the PCB and other design
> elements also
> so a possibility to download a unencrypted bit file into an FPGA with
> AES key set is somewhat design risc

If it sells more hardware, even though the use is different,
it doesn't seem bad.  Assuming that the hardware sale price
includes the price for the FPGA design, then it isn't likely
that someone will find an affordable use for the hardware.

One possibility, though, would be in a design with good economy
of scale, someone might find a way to use it for something that
didn't have the economy of scale to produce the hardware.

If someone copies the PCB, then sue for copyright infringement.

-- glen

Article: 142344
Subject: Re: AES encryption of bitstream - is my design secure?
From: Dave Farrance <DaveFarrance@OMiTTHiSyahooANDTHiS.co.uk>
Date: Wed, 05 Aug 2009 17:22:20 GMT
Links: << >>  << T >>  << A >>
Rajesh Gandhi <rgandhi4086@gmail.com> wrote:

>But absolutely in concurrence with Mr. Austin, it does not prevent
>overbuilding,reverse engineering, cloning.

However, the FPGA design that is encapsulated in the encrypted bitstream
*is* secure.  Expecting it to protect the rest of the system is analogous
to expecting that the firmware protection in your PC's disk drive should
protect the firmware of your PC's graphics card.  If you want to secure
your system, then you need system security.

-- 
Dave Farrance

Article: 142345
Subject: xilinx ise verilog constraint with concatenated string name
From: nachum <nachumk@gmail.com>
Date: Wed, 5 Aug 2009 10:42:12 -0700 (PDT)
Links: << >>  << T >>  << A >>
I would like to understand how to create a concatenated string that
would be accepted for constraints in Verilog.

I have code like this:

genvar g;
generate
 for(g = 0; g < 8; g = g + 1) begin : a_gen
  (* U_SET = {"a",g} *)
  (* RLOC = X0Y0 *)
  //dsp 0 inst
  (* RLOC = X0Y1 *)
  //dsp 1 inst
 end
 for(g = 0; g < 8; g = g + 1) begin : b_gen
  (* U_SET = {"b",g} *)
  (* RLOC = X0Y0 *)
  //dsp 0 inst
  (* RLOC = X0Y1 *)
  //dsp 1 inst
 end
endgenerate

The issue is that I can't set the U_SET string to a concatenated
string:
(* U_SET = {"a",g} *)
is invalid.
This causes conflicts in my RLOC assignments as I want them
constrained only to a specific U_SET that is either a0, a1 ... to a7,
or b0, b1 ... to b7.
How would I do this? I can't find any information on this at all!!!
And ISE refuses to view this as a string valid for an attribute.

I have also tried
reg [8*32:0] my_name;
//gen code
assign my_name = {{"a"},g};
(* U_SET = my_name *)
which is also not considered valid by ISE.

Thanx
Nachum Kanovsky

Article: 142346
Subject: Re: AES encryption of bitstream - is my design secure?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 5 Aug 2009 17:50:01 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rajesh Gandhi <rgandhi4086@gmail.com> wrote:
(snip)

< The device will program when there is NO ENCRYPTION.  Hence Trojan
< bitstream is easy to implement.  Trojans do not need to decrypt the
< bitstream, attacker can program a bitstream into V5 or Stratix 
< by programming on-board FLASH with JTAG.  All are 'wide-open' 
< for hacking.  FPGA can be programmed which will assist in 

< 1) getting passwords from users/admin/embedded 
< 2) getting OTHER keys (not FPGA key) in system
< 3) snoop system to hack and potentially unlock unpaid-for features
< (turn low end product into high end product)
< 4) learn enough about system to build compatible plug-ins (games,
< software, songs, videos, printer cartridges) which
< may not be part of economic strategy.

Maybe, but are these really easier with a new bitstream attack?

If one can float the I/O pins and put logic probes on the
device, it might be about as easy.  Otherwise, they are design
failures of some kind.  
 
< "cant prevent hardware from being used for other things" sounds 
< like simple statement but many hardware products are sold at 
< loss or break-even or very low margin in order to make
< market share.  Printers for example. Company makes money on 
< consumables or plug-ins to the platform.  

I have seen many printers that sell for less than the cost
of the ink cartridges included.  If someone can find a use
for that printer, even not requiring any modifications, it
would seem to be a loss to the manufacturer.  

< Xbox is example  - which is really just Intel PC sold at loss
< to get market to sell games and internet service.  Was Hacked 
< to run linux which is embarassment for Microsoft
< but also a loss of $200 for each xbox purchased to run linux.  

As far as I know, there hasn't been a rush to buy them as
linux systems.  It may be $200 loss to MS, but it may still
be more than it would cost to buy a similar PC.

< Cisco low end router can be made into high end router with 
< hack patch - loss of revenue for Cisco.

The software can check for some feature in the FPGA code.
Otherwise, it is a normal software copyright question.

Well, there is a story about an IBM computer (I believe System/3)
that came in 32K and 64K models, the difference was the position
of a switch.  People learned about this and turned the switch,
but had to remember to turn it back when the machine was being
serviced.  (They were usually leased, not sold.)  

In the case of the Cisco router, it would normally require different
software (ROM) for the high end router.  If someone can get that
ROM contents, unencrypted FPGA code isn't likely to help, and
it is a copyright violation in any case.  
 
< Reader who say 'if simple to mimik then u don't need encryption,
< engineer will build from scratch' maybe missing the point. They are to
< build a bit data by scratch that is their intent, to have their design
< in place to do bad things. steal user password (not fpga key), monitor
< keyboard input, monitor USB connection, insert 'time bomb' to stop
< system functioning at critical time of need.

Possible, but how likely?  The encrypted FPGA code stops (for this
discussion) reverse engineering of that code.  It doesn't stop one
from removing the FPGA and splicing into the pads.  In the case of
password stealing, it doesn't stop one from making a similar looking
box that steals passwords but with completely different content.

Monitoring keyboard input or USB signals is much easier than writing
new code for the FPGA.  No-one will pick your expensive door lock
if you leave the windows open.

< if I have embedded powerpc based fpga it maybe quiet easy for attacker
< to get it to boot linux and have design which monitor keyboard input
< for admin logins and store or send over internet.  The interfaces are
< all standard so easy to develop.

If you can do that without access to the box, then it is a design
failure.  If I have access to the box, then there are too many
other ways to attack the system.
 
< And in end only virtex/stratix are secure, others are not.  system
< security maybe not xilinx/altera problem, just mine, but i have to
< develop.   Am I only one in FPGA area for this concern?

-- glen
 

Article: 142347
Subject: Re: AES encryption of bitstream - is my design secure?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 5 Aug 2009 18:02:06 +0000 (UTC)
Links: << >>  << T >>  << A >>
austin <austin@xilinx.com> wrote:
 
< Perhaps what Raj is referring to is "one-armed bandit" mode (named
< because gambling machines must have this feature).

There was an episode of the TV show NUMB3RS involving an electronic
card shuffling device, with a designed in back door.  (I don't
remember the exact details now.)  Note that nothing that you do
with encryption can stop an attack in the encrypted code by
the original designer.  

This problem may also occur in electronic voting machines. 
 
< This is when once a key is programmed into the part, the part no
< longer will accept any bitstream, only a bitstream encrypted with that
< key (which we do not support today for any family).

It seems that in that case, one could always replace the FPGA with
an unkeyed one.  Yes the machinery for removing/installing BGA
devices is specialized, but if the desire is there it will be found.

If one has access to the box, there are many things to protect
against in addition to replacing the FPGA code.

-- glen

Article: 142348
Subject: Re: AES encryption of bitstream - is my design secure?
From: glen herrmannsfeldt <gah@ugcs.caltech.edu>
Date: Wed, 5 Aug 2009 18:08:55 +0000 (UTC)
Links: << >>  << T >>  << A >>
Rajesh Gandhi <rgandhi4086@gmail.com> wrote:
(snip)

< These are different problems that AES/Encrypt/decrypt
< does not solve.   the perception by the fpga designers, 
< however, I think is that it does solve these problems.

I believe that these problems are system problems, not FPGA
bitstream problems.  One has to go through the whole system
to be sure that it is secure against attack.  If there are
easier ways to attack the system, and the FPGA can't protect
against those attacks, then there is little reason to worry
about the more complicated attack.   Only after the rest of
the system is protected, and that only happens when there is
need for the protection, should one worry about this.

Now, if there is an attack involving replacing the bitstream
without physical access to the device then it needs fixing.

-- glen

Article: 142349
Subject: Re: AES encryption of bitstream - is my design secure?
From: austin <austin@xilinx.com>
Date: Wed, 5 Aug 2009 11:42:42 -0700 (PDT)
Links: << >>  << T >>  << A >>
All,

http://www.intrinsic-id.com/

Has a solution (for protecting IP and getting paid for it), and it
works.  They use many levels (both hardware, firmware) and provide a
trusted third party so that the CM asks for keys, tests, programs, and
these are all kept on a database so that you, and they, know how many
were built, and how many got 'enabled.'

If this is done with FPGAs, the bitstreams may be encrypted or
microprocessors, but preventing someone with physical access from
loading their own bitstream or code, and perhaps using the system in a
way not intended, is still not protected against.

For that (anti-tamper) type of protection, there are other methods,
mostly related to preventing physical access.

The ATM machine is a good example:  physical access is prevented by
alarms, steel plates, etc.

Austin



Site Home   Archive Home   FAQ Home   How to search the Archive   How to Navigate the Archive   
Compare FPGA features and resources   

Threads starting:
1994JulAugSepOctNovDec1994
1995JanFebMarAprMayJunJulAugSepOctNovDec1995
1996JanFebMarAprMayJunJulAugSepOctNovDec1996
1997JanFebMarAprMayJunJulAugSepOctNovDec1997
1998JanFebMarAprMayJunJulAugSepOctNovDec1998
1999JanFebMarAprMayJunJulAugSepOctNovDec1999
2000JanFebMarAprMayJunJulAugSepOctNovDec2000
2001JanFebMarAprMayJunJulAugSepOctNovDec2001
2002JanFebMarAprMayJunJulAugSepOctNovDec2002
2003JanFebMarAprMayJunJulAugSepOctNovDec2003
2004JanFebMarAprMayJunJulAugSepOctNovDec2004
2005JanFebMarAprMayJunJulAugSepOctNovDec2005
2006JanFebMarAprMayJunJulAugSepOctNovDec2006
2007JanFebMarAprMayJunJulAugSepOctNovDec2007
2008JanFebMarAprMayJunJulAugSepOctNovDec2008
2009JanFebMarAprMayJunJulAugSepOctNovDec2009
2010JanFebMarAprMayJunJulAugSepOctNovDec2010
2011JanFebMarAprMayJunJulAugSepOctNovDec2011
2012JanFebMarAprMayJunJulAugSepOctNovDec2012
2013JanFebMarAprMayJunJulAugSepOctNovDec2013
2014JanFebMarAprMayJunJulAugSepOctNovDec2014
2015JanFebMarAprMayJunJulAugSepOctNovDec2015
2016JanFebMarAprMayJunJulAugSepOctNovDec2016
2017JanFebMarAprMayJunJulAugSepOctNovDec2017
2018JanFebMarAprMayJunJulAugSepOctNovDec2018
2019JanFebMarAprMayJunJulAugSepOctNovDec2019
2020JanFebMarAprMay2020

Authors:A B C D E F G H I J K L M N O P Q R S T U V W X Y Z

Custom Search