DPA vs FPGA Security?

Just read an article over at FPGA Journal about ways to bypass the
security features on FPGA designs:

http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/

A lot of scary hype and generalities, but the underlying message seems
to be that by using Differential Power Analysis it's possible to
decrypt a protected FPGA design. Basic idea is to monitor the power
consumption while loading the encrypted design, then via some kind of
magic infer what the plaintext bitstream is and then reverse engineer
it.

Sounds like someone at a security research outfit is trying to sell
some consulting hours to me, but what's the general feeling about
this? Is this a real threat, and what are the realistic barriers to
applying this attack?

Eric

On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote:
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

Sounds more like a Hype.
The attacker should not be able to monitor power when the "key is
loaded", because he could simply copy the key then.

And when a bitstream key is hidden in SRAM cells or fuses of some FPGA
it may be easier to find out what one thinks by looking at MRI images
than copying the key by ever so sophisticated power analysis.

But thinking about ways to break other protection schemes than in-
device key & encrypted bitstream may be useful.

>Just read an article over at FPGA Journal about ways to bypass the
>security features on FPGA designs:
>
>http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/
>
>A lot of scary hype and generalities, but the underlying message seems
>to be that by using Differential Power Analysis it's possible to
>decrypt a protected FPGA design. Basic idea is to monitor the power
>consumption while loading the encrypted design, then via some kind of
>magic infer what the plaintext bitstream is and then reverse engineer
>it.
>
>Sounds like someone at a security research outfit is trying to sell
>some consulting hours to me, but what's the general feeling about
>this? Is this a real threat, and what are the realistic barriers to
>applying this attack?
>
>Eric
>

Why bother reverse engineering it. Buy a product, extract the bitstream,
clone and PCB and partslist, and sell it.

Back in the 60's the  CIA dug a tunnel under the Berlin wall to tap into an
underground telephone cable on the east side. The traffic was all encrypted
but they had at one point passed next to some cable with unencrypted
traffic.
They recorded the noise spikes that were coupled over and could read the
unencryted traffic at will.

DPA is a cake walk compared to that.






	   
					
---------------------------------------		
Posted through http://www.FPGARelated.com

emeb <ebrombaugh@gmail.com> wrote:
> Just read an article over at FPGA Journal about ways to bypass the
> security features on FPGA designs:
 
> http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-fending/
 
> A lot of scary hype and generalities, but the underlying message seems
> to be that by using Differential Power Analysis it's possible to
> decrypt a protected FPGA design. Basic idea is to monitor the power
> consumption while loading the encrypted design, then via some kind of
> magic infer what the plaintext bitstream is and then reverse engineer
> it.

Well, DPA is supposed to allow you to find the key. With the key
you can then decrypt the bitstream.  I would not expect that to
be easy for an FPGA with encryption, but I don't know the details.
 
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

The usual DPA stories for smart cards (or other embedded processors)
had to do with detecting the instruction flow.  If you make branch
decisions based on partly decoded keys, then it is easy to detect.

What I had thought that FPGAs did was to decrypt through a DES key,
and send the result to the configuration register.  As has been
discussed here, loading random bits into the configuration can damage
the device, so I would expect loading the wrong encrypted bitstream
to also do that.

Assuming that no branches (state machine transitions) depend on
the decoded bitstream, it would not seem easy.  With the decryption
logic running, would the power due to the decoded bitstream going
through a shift register be noticed?  

It would seem more difficult, though, to protect against microprobes
on the chip.  In that case, if you can probe the configuration
shift register then the bits should just fall out.

-- glen

On Jan 29, 1:55=A0am, emeb <ebromba...@gmail.com> wrote:
> Just read an article over at FPGA Journal about ways to bypass the
> security features on FPGA designs:
>
> http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f...
>
> A lot of scary hype and generalities, but the underlying message seems
> to be that by using Differential Power Analysis it's possible to
> decrypt a protected FPGA design. Basic idea is to monitor the power
> consumption while loading the encrypted design, then via some kind of
> magic infer what the plaintext bitstream is and then reverse engineer
> it.
>
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?
>
> Eric

security is sure more then just crypting "some part" of the design.

a few days ago hackers did enter RING-0 on sony playstation 3
while that doesnt make the master encryption key visible it still
allows many
privileged things to be done.

how it was done:
1 run linux (PS3 does allow that!)
2 execute special kernel module that allocates and deallocates memory
manager tables
3 press a BUTTON on FPGA board that makes 40ns GLITCH on ext memory
data bus
4 you are at hypervisor access level

and basically there will be one memory map entry with supervisor
privileges for you to use

the story is a little bit more complex, but it only a little more
complex then the story with
nintendo WII, where the atack was done like this

1 run own app in "GC" mode (possible using other exploits)
2 short circuit one memory address bus with tweazers
3 "unvisible memory area" (protected by ASIC) is remapped into the PPC
visible area
4 copy out the stuff and analyze

--------
no DPA, no microscope no nothing, both WII and PS3 have ASIC buried
master encryption
keys that is still unknown to the hackers, but both systems are wide
open to hacks..



while simple DPA may not give the Xilinx encryption key, there are
things that have
to be done to make your system secure.

Antti

On 29 Jan., 00:55, emeb <ebromba...@gmail.com> wrote:
> Sounds like someone at a security research outfit is trying to sell
> some consulting hours to me, but what's the general feeling about
> this? Is this a real threat, and what are the realistic barriers to
> applying this attack?

DPA  should be relatively easy on FPGAs. (But still hard)
Usually an attacker using DPA has to guess the workings of the
algorithm
in the device. They use lots of statisctics to find clock cycles that
show
a small difference in power consumption when the key has a 1 or 0 at
a certain bit.

The advantage of an attack an on FPGA is, that the attacker can buy an
identical FPGA and start experimenting with his own keys and own
bitstreams
to see how the individual key bits change the power consumption.
For an attack on a smartcard you can only attack a given unknown key.

On the other hand, as I understand it, parallel hardware
implementations are a lot harder
to attack using DPA than serial microcontroller implementations.

Kolja Sulimma

On Jan 28, 10:57=A0pm, "jt_eaton" <z3qmtr45@n_o_s_p_a_m.gmail.com>
wrote:
> >Just read an article over at FPGA Journal about ways to bypass the
> >security features on FPGA designs:
>
> >http://www.techfocusmedia.net/fpgajournal/feature_articles/20100126-f...
>
> >A lot of scary hype and generalities, but the underlying message seems
> >to be that by using Differential Power Analysis it's possible to
> >decrypt a protected FPGA design. Basic idea is to monitor the power
> >consumption while loading the encrypted design, then via some kind of
> >magic infer what the plaintext bitstream is and then reverse engineer
> >it.
>
> >Sounds like someone at a security research outfit is trying to sell
> >some consulting hours to me, but what's the general feeling about
> >this? Is this a real threat, and what are the realistic barriers to
> >applying this attack?
>
> >Eric
>
> Why bother reverse engineering it. Buy a product, extract the bitstream,
> clone and PCB and partslist, and sell it.
>

The point of encrypted bitstreams is that they only work on that
one copy of the part, or on parts that have been loaded with the
correct key.  For Xilinx the key is stored in volatile SRAM and
backed up with a battery.  It would be pretty hard to take the
chip top off for probing while keeping the backup power active,
but of course not impossible.  Also flip-chip packaging makes
this sort of probing even harder.

So you can copy the board, bitstream and all, but presumably not the
key to make that bitstream work.

> Back in the 60's the =A0CIA dug a tunnel under the Berlin wall to tap int=
o an
> underground telephone cable on the east side. The traffic was all encrypt=
ed
> but they had at one point passed next to some cable with unencrypted
> traffic.
> They recorded the noise spikes that were coupled over and could read the
> unencryted traffic at will.
>
> DPA is a cake walk compared to that.
>
> --------------------------------------- =A0 =A0 =A0 =A0
> Posted throughhttp://www.FPGARelated.com

On 29 Jan., 15:39, Gabor <ga...@alacron.com> wrote:

> The point of encrypted bitstreams is that they only work on that
> one copy of the part, or on parts that have been loaded with the
> correct key. =A0For Xilinx the key is stored in volatile SRAM and
> backed up with a battery. =A0It would be pretty hard to take the
> chip top off for probing while keeping the backup power active,
> but of course not impossible. =A0Also flip-chip packaging makes
> this sort of probing even harder.
>
> So you can copy the board, bitstream and all, but presumably not the
> key to make that bitstream work.

DPA is a technique successfully used to read out the key from
smartcards
that are specifically designed to protect the key. There is no need to
take the top off. DPA looks at the power supply of the chip.
The differences seen on the power are very small, but with enough
averaging
you can differntiate any signal from the noise, so they repeat the
operation
many times until they see differences in power surge from cycle to
cyle.

With knowledge of the crypto algorithm - which they have in case of
the FPGA
- they can now simulate what the power consumption pattern for a 1 in
the
position X of the key would be compared to a 0 at that position.

This is still hard work but in many cases a lot faster than a brute
force attack.

Also: At least for smart cards it is the case that once you learned
how to get the
key from a given type of smart card you can repeat this automated
within a few
minutes for another card of the same type.
This means if XC5V keys are attacked successfully with this method you
can build
a device that cracks any other XC5V design quickly.

Kolja Sulimma

On Jan 29, 9:16=A0am, Kolja Sulimma <ksuli...@googlemail.com> wrote:

> With knowledge of the crypto algorithm - which they have in case of
> the FPGA
> - they can now simulate what the power consumption pattern for a 1 in
> the
> position X of the key would be compared to a 0 at that position.
>
> This is still hard work but in many cases a lot faster than a brute
> force attack.

Based on your explanation it seems fairly trivial:
* hook a fast V/I meter to the power supplies of an FPGA
* via JTAG load various known keys into the FPGA
* via the configuration interface load various known bitstreams into
the FPGA
* Average over many trials, look for differences in V/I with key
changes.

This whole process can be automated. The loading process is quick, and
assuming a small FPGA probably completes in a few seconds. Using a
fast CPU the required analysis is equally quick. So, with some common
lab equipment and a few days unattended processing time it's a cinch.
As you note, if you can break one FPGA in a family, you've probably
broken them all, so once you've got the initial analysis worked out
you can probably crack any device with similar architecture from a few
averaged samples of the configuration process.

Given that we've solved that problem, what measures have the FPGA
vendors taken to prevent any schmoe with time on his hands from going
into the reverse engineering business? Seems like their security
measures are fundamentally broken unless there is something else going
on we don't know about.

Eric

Differential Power Attack has been known (and used) for many years
now, (it is not new at all)


DPA was originally used to hack credit cards in Europe, and there are
many other recorded (successful) attacks, as well.

CRI is making a lot of noise about their alleged crack of one Virtex
II Pro, 3DES key (168 bits), on one platform designed to facilitate
just such attacks.  Is this claim confirmed?  By whom?  If I loaded
the "secret" key, and I know the value, and then I claim I
"discovered" its value ... seems that the real "key" here is to
authentication:  who do you believe, and how can you be sure?  The
'motivation' for this seems unusually coincidental, as well...

They also own a lot of IP, for the express purpose of countering
DPA .... and making money.  They are looking for business.  If you
want to protect yourself from DPA (and you think their methods might
work), and you are very rich, give them a call.  Seems they need
money.  Don't we all!  See 'motivation', above.

The job of preventing ALL attacks, is known as anti tamper:  detect an
attack, and remove all information of value (prevent the attack).

Anti-tamper is not "owned" by CRI, and anyone can implement AT
techniques, and, in any system that is supposed to be secure, AT is
required.

"Denial of Service" is another attack to worry about, and if you have
physical access to a device, then a hammer is sufficient to conclude
an effective "denial of service."  Removing the batteries, or
unplugging the system can also be very effective.

So, security is a big field, with many things to think (anticipate)
about.  DPA is just one attack, of many.

Like I said, if you are worried about DPA, then you should also be
worried about DoS, AT, and many other forms of attack.  By itself, DPA
might be the least of your concerns.

If you already work in this field, you already know that there are
existing solutions for all of these attacks.  Attackers have a natural
advantage:  they can think up new attacks all day long.  Defenders
have it tough:  they must defend against ALL present, and future
attacks, right now.


And, there are not only threats to your systems, there are threats to
your way of doing business:  If you are unfortunate enough to have
implemented a defense that someone else has a patent on, then you will
face an entirely different threat:  someone demanding money!

I wish CRI all the best in their endeavors,

Austin