AES encryption of bitstream - is my design secure?

Hello,

Is it possible that even though I use AES encrypted bitstream, another
trojan/bad bitstream that mimiked my design could be loaded into FPGA?

Regards,
Raj

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

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.  If 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:  do not build a back door into your design).

SInce Virtex 2, we have issued challenges to university students and
researchers to test our security.  In addition to being the only
approved FPGA  by the NSA for the crypto-modernization program, we
have had no method of attack succeed to date,

On Aug 4, 10:54=A0am, austin <aus...@xilinx.com> wrote:
> 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.

so if you remove the battery, can you program anything you want into
the fpga?
(this is what i thought the op was asking)

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

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.

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

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.

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.

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