Fending Off Evil
Protecting Your FPGA Against DPA
It's 3AM, and you wake unexpectedly. They're out there... the Evildoers. You can almost feel them. They're out there right now holding a copy of your latest board - with the FPGA sitting right in the middle. It's the same one you put in your design. Reverse-engineering the board is easy - or heck, they may just have a way to sneak a few off the assembly line where they're being made. You know the place - you were nervous when purchasing made the deal. The prices were a little too low and the opacity was a bit too high. That's why you have it set up so your FPGA bitstream doesn't get loaded until the product gets back to your facility.
Nonetheless, they're out there. They're looking at your board right now, and they're trying to figure out how they can steal your design - or your customers' data. You took precautions, of course. Maybe your bitstream is encrypted with the FPGA-vendor's security features. Your customers' data is definitely encrypted. You can go back to sleep now, right? They won't be able to get your encryption keys.
As you try to fall back asleep again, you remember what they're probably doing. You've heard about Differential Power Analysis (DPA) attacks at some conference one time. Maybe you didn't stay for the whole talk. They were analyzing the power supply, finding the exact point where the encryption keys are loaded, running some DSP on them, and gradually decoding the encryption keys with clever filtering. That wouldn't work with a complicated design in a device like an FPGA would it?
Oh yes. It would.
Cryptography Research has been thinking about DPA attacks for a long time now. In fact, they apparently invented the attacks themselves, back in 1997. (They prefer to use the euphemism "discovered" DPA.) Now, before you start your rant about how people shouldn't be inventing dangerous things just so they can sell you a defense against them, remember that "security by obscurity" doesn't work. If they didn't "discover" DPA, somebody else would. (In fact, there are rumored to be others that knew about DPA even before Cryptography Research went about patenting their defenses.) What's more - they weren't doing it to help people jack your FPGA design - honest. They had bigger fish to fry. You know the smart cards that are used in financial transactions all over the world? Yeah. If you were a bad guy - would you rather crack those or somebody's FPGA-based automotive infotainment system?
DPA is about as clever and devious a scheme as you can imagine. It doesn't require disassembly of the circuit. It doesn't require fancy equipment - a digital scope and a decent PC will get you up and running. All it requires is a working copy of the system. Using a divide-and-conquer approach, you find the time where the encryption keys are being loaded, run a few experiments, and the bits start dropping out like one of those TV-show scenes where the hacker is getting the secret password character-by-character and all of us in the audience with any technical background are rolling our eyes in disdain.
DPA is actually the "middle-child" of power-analysis attacks. There is also simple power analysis (SPA) and high-order differential power analysis (HO-DPA). For most real-world designs, SPA is too primitive to get results easily, and HO-DPA is too complicated to manage efficiently. DPA, on the other hand, is just right.
Power analysis attacks are also more sinister because we generally cannot detect them and because physical barriers are ineffective in stopping them. The only effective countermeasures are those that logically interfere with the analysis process.
Countermeasures include things you might expect - such as injecting additional noise into the operation, randomizing sequences of events, altering timing, and changing the algorithm - all of which are designed to increase the signal-to-noise ratio and make the attack more difficult. The problem is - you can't create effective countermeasures against DPA unless you are an expert at doing DPA. (No, just sticking a big capacitor on your power pins to smooth out the noise won't work. The bad guys thought of that already.)
Cryptography research has a variety of countermeasures available in various forms - most of which boil down to licensing you some specialized IP or consulting with you on your particular project. If you were counting on the fact that you have an FPGA in your design making it safer - you were mostly right. FPGAs can be used to mitigate many of the known techniques for stealing your and your customers' IP. Side-channel attacks such as DPA, however, are intriguing and dangerous beasts. If your design needs to be safe from these threats, your only two options are really 1) become an expert in security yourself (not a viable option for most of us that have other things to do with our career - like design stuff) or 2) enlist the services of security experts such as Cryptography Research.
As with any engineering decision, the effort you put into security is a trade-off - balancing the consequences of a successful attack against the cost of preventing one. In most cases, it also pays to understand the motivation level of a likely attacker. If your likely attackers are two guys in a basement with an oscilloscope trying to see if they can crack your design for fun, you might invest a different amount than if the likely attacker is a government with immense resources available to break your circuit for national security reasons. The starting point for this decision, however, is awareness of the threat in the first place, and thusly - our work here is done.
You can go back to sleep now.
Comments:
|
|
|
|
|
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
|
|
|