Total Posts: 1
Joined: Jan 2010
|
While I might believe one could
While I might believe one could do DPA on something as simple as the single chip in a smart card, I'm skeptical about extracting useful information from power analysis on a big board with many parts and switching power supplies. Have you ever seen an example of this technique used in anything other than a simple test bench case? I haven't.
Posted on 2010-01-28 18:30:09 at 2010-01-28 18:30:09
|
|
Total Posts: 5
Joined: Nov 2009
|
It was my understanding that the
It was my understanding that the encryption key is loaded once,
at the factory. While you may be able to run DPA wile the
bitstream is loading, there will be a lot of switching due to
the decryption which does not seem to be particularly useful
in determining the key. It may turn out that the decrypted
bitstream creates more power glitches that the decription
process, particularly if the configuration shift registers
are large structures. However that at best gets you the
unencrypted design, not the key. Then you'd need to run the
same process again if the bitstream was updated by the
manufacturer, whereas if you had the key you could just
decrypt it.
Posted on 2010-01-29 09:54:43 at 2010-01-29 09:54:43
|
Total Posts: 14
Joined: Nov 2009
|
feasible but very difficult
Seems like in order to extract a serial bit stream from power transients one would need to need to meet the following: 1) FPGA has to have it's own supply or be the only device drawing power while it's loading its configuration image 2) the serial data clock frequency is known (I'm assuming this is serial configuration) 3) not enough DC coupling caps to filter out the serial data transients 4) the serial configuration start-up timing is known, which could vary depending on how the power circuitry was designed. Definitely possible, but would be time-consuming. Also, if the board is using switching supplies, the switching noise would have to be filtered out as well.
Then let's say you have the unencrypted bit-stream. You need to know how the image maps to the device, which seems like IP only the device manufacturer would have. I have to admit, I don't know a lot about how the image gets loaded into the FPGA so I'm just speculating here. Regardless, still appears to require a lot of time and resources.
Posted on 2010-02-15 17:34:22 at 2010-02-15 17:34:22
|
Total Posts: 84
Joined: Apr 2009
|
In-person demo of DPA attack on FPGA
Since there was a good deal of skepticism on this thread about whether FPGAs are actually vulnerable to DPA attacks (and because I'm a little bit of an engineering geek) I decided to use that as an excuse for visiting Cryptography Research labs to see for myself if DPA could be used to defeat crypto in an FPGA. (note to skeptics - Thank you! This was a perfect opportunity to exercise my inner nerd.)
News editor Amelia Dalton and I arrived at CRI in San Francisco, and after a brief chat were allowed in the lab. We walked through two scenarios - first, using DPA to extract a key from a smart card - just to show in the easy case how DPA works. Once we were up to speed on the basic process, we moved on to our nemesis - a SASEBO-G2 FPGA evaluation board running 128-bit AES. The AES was a pure hardware implementation using the LUT fabric of the device. Our goal was to use DPA to locate and extract the encryption key.
Info on the board is here:
http://www.rcis.aist.go.jp/special/SASEBO/index-en.html
The setup is very simple. We had a digital scope connected to a 1 ohm resistor across the power supply on the board (just the kind of resistor that many development boards have pre-installed specifically for measuring power to the FPGA).
The hardest part of the process is actually getting the DUT set up to repeat its sequence over and over for you - allowing you to watch for the point in time where the encryption is happening. While much of the skepticism on this and other threads has centered around the theory that there is too much noise in a typical FPGA to see what's going on using DPA, I must report that the noise isn't that much of a problem. For full disclosure - in our test setup, we had a few advantages that a real attacker might not have. First, our FPGA wasn't doing much besides the AES algorithm, and more activity would have generated more noise. Second, we knew that 128-bit AES was being used, and we knew something about the algorithm. Third, the people at CRI have done this a lot and really know what they're doing. That being said, however, in my opinion, an attacker lacking these advantages would likely be a little slower, but no less effective than we were.
Once the test setup is in place and working, we do a lot of intuitive looking around at the power signals with the scope. Amidst the noise, there are obvious one-time blocks where some repeatable computation is happening. Crypto is computationally expensive, and that expense shows up in the power profile. Looking at the various computational blocks one at a time, it's also pretty easy to spot where the crypto is likely happening - and even to spot a series of 10 very regular looking patterns - almost like processing 10 rounds of a key one at a time. Once we've established some candidate time windows where we believe the key is in play, we run the system over and over and average the waveforms of all the runs to filter out even more noise. We're left with a pretty nice looking trace.
Next, we change modes. We set up a process where we can attack one byte of the key at a time. We isolate the results of the crypto, and notice a distinct peak when the compare is successful versus when it fails. Next, we start trying to guess our one byte of the key, and watch the results waveform for the telltale peak. It turns out that the failed guesses tend to average out and show no high-amplitude peaks, while correct guesses amplify the peaks. Since we're only attacking one byte of the key, we can pretty quickly cycle through all 256 possibilities and watch the results. The photo below shows a typical "bad" guess...
Exactly one of the guesses yields a large peak (shaped like the one we saw before) as shown in this photo.
Several other guesses that were only one or two bits off from the correct answer showed some smaller peaks, but the correct guess was very easy to spot. It's a bit like playing the board game "Mastermind".
With these 8 bits of the key done, we repeat the process 15 more times to extract the entire key. Once we're in the mode of guessing and extracting, getting the entire 128-bit key probably requires less than an hour. Keep in mind that this type of side-channel attack requires almost no equipment and is completely non-invasive.
So - my conclusions (and debate is welcome):
1. Are FPGAs vulnerable to DPA? Yes. I believe they are. I believe that "payload" crypto is a different vulnerability than configuration encryption - so if you're worried about your own IP/bitstream - a different approach would be required for the attack. Having seen this attack in progress, though - I believe the same types of methods could be used. I believe that the setup we used had some artificial advantages and that a "real" attack would take a bit more time and determination, but the process would take days or (at most) weeks.
2. Are there effective countermeasures? Apparently yes. I say apparently because we didn't have time to run the same experiments with countermeasures in place. For payload crypto, the countermeasures will need to be implemented by the end designer. For bitstream security, I believe the countermeasures would have to be implemented by the FPGA vendor. Whether you need countermeasures depends completely on your application - the cost of countermeasures versus the cost of a successful attack. For the run-of-the-mill FPGA application, the bad guys don't have enough motivation to conduct such an attack. Your mileage may vary.
Posted on 2010-03-01 21:35:24 at 2010-03-01 21:35:24
|
|
Total Posts: 14
Joined: Nov 2009
|
Interesting
I didn't realize the would-be hacker could clearly (and rather easily) distinguish correct guesses from incorrect ones. If the correct guess didn't yield such a consistent and noticeable peak the attacker's job would be much harder. I can see how the FPGA chip manufacturer would have to design their AES logic to not sink so much power when the code compares are correct.
Now I'm interested to see how one decrypts "payload" configuration data.
BTW, I can't see the last two images.
Posted on 2010-03-02 12:49:46 at 2010-03-02 12:49:46
|