Is this possible to protect FPGAs from Differential Power Analysis ?

Hi,

In Differential Power Analysis, the attacker send lots of plaintext (bits) to the FPGA, which will decrypt them accordingly, and meanwhile the attacker will be measuring the power traces, trying to get the cryptography algorithm key (using statistical techniques and knowledge of the CMOS power model).

Now, if we can limit the number of bits that can enter to the FPGA to those equivalent to the size of the bitstream (stored on an external memory chip), then we can almost overcome the DPA attack, since it is known that DPA attack require large number of measurements (on the order of thousands) to obtain a good correlation...

I am thinking of using something like the Xilinx Zynq SoC, which has a standalone microprocessor, which will read, say, only 20 thousands bits from the external memory (the size of the bitsream) and then disable the decryption process.

In case the design is being used by an attacker, he or she will be able to do a limited number of measurements on the FPGA, after which the microprocessor will disable further decryption.

Is this feasible? Does it make sense at all?

Hi Ali8. Actel/Microsemi make a big deal of DPA and it would be worth you reading some of their white papers on the subject. It appears at first sight to me, however that the DPA "hit" occurs when a match is found, so hiding the encryption key amongst a flood of other data probably isn't going to help a great deal if the IP theft was considered worthwhile.

Your suggestion has some merit, but I suspect it is a little simplistic in approach, perhaps by collating the bit stream fron multiple sources and using multiple independent task handlers to decrypt a part of it followed by some form of reassembly. I don't know, its just a guess, but search DPA on the Actel website and read what they have to say.

chipseller said:

Hi Ali8. Actel/Microsemi make a big deal of DPA and it would be worth you reading some of their white papers on the subject. It appears at first sight to me, however that the DPA "hit" occurs when a match is found, so hiding the encryption key amongst a flood of other data probably isn't going to help a great deal if the IP theft was considered worthwhile.

Your suggestion has some merit, but I suspect it is a little simplistic in approach, perhaps by collating the bit stream fron multiple sources and using multiple independent task handlers to decrypt a part of it followed by some form of reassembly. I don't know, its just a guess, but search DPA on the Actel website and read what they have to say.

Click to expand...

I have already read all of Actel (now microsemi) papers. Basically they use proprietary ip cores from Cryptography Research, Inc. Thus what they do is useless for me, I do not want proprietary cores.

Also, I do not plan to hide the key in any special way, I will simply use whatever capabilities Xilinx has to offer, the point is that before the attacker do enough power trace measurements to deduce the key, I would have been disabled any further decryption operations.

As I said, your plan has some merit, but looking at the lengths Crypto/Microsemi have gone to, i suspect it is a little too simple. Don't forget, most crypto keys are not continuously accessed, usually once at startup then at quasi-random time intervals after that, if at all.

I am not aware of any special features within the Xilinx architecture that can help you with this.

chipseller said:

As I said, your plan has some merit, but looking at the lengths Crypto/Microsemi have gone to, i suspect it is a little too simple. Don't forget, most crypto keys are not continuously accessed, usually once at startup then at quasi-random time intervals after that, if at all.

I am not aware of any special features within the Xilinx architecture that can help you with this.

Click to expand...

Thanks, I got your point.

The new Xilinx Zynq series has a built in INDEPENDENT microprocessor, i.e. it can run at start up alone and acts as a master the FPGA. I want to use it to monitor the I/O port between the FPGA and the external bitstream memory...

But I agree with you, it is probably too simple...

if they have physical access, they might find some way to power cycle the unit. This might give the 1k+ samples.

also, if the attacker knows the data that was sent to the unit and stores it, then they could decrypt it later if they gain access to the key.

The data is encrypted using AES 256, which is computationally unfeasible to *****.

I am not sure about how they power cycle in any different way. Maybe he/she can repeatedly reset the unit and send that small amount of bits each time, but this should be unpractical.

but not comparatively impractical.

Keep in mind that it would be MUCH faster to power cycle the unit for the purpose of DPA than a direct attack on AES. 60*24 = 1440 attempts per unit per day assuming 1 attempt per minute. If this is mass produced, you might be able to get 100 units running in parallel and some algorithmic magic to get 144,000k attempts per day, or around 1M at the end of a year. Creativity might yet allow for significant gains in terms of side channel attacks.

Of course, if you can get the key between power cycles in some other method, then you only need to power cycle once..

The final design will not be mass produced. So probably this is a plus on my side.

But still, 1440 attempts per day is too much (~half a million attempts in a year).

I should think of another way. Thanks anyway.