The Doctor <drwho@virtadpt.net> wrote:
I thought the point being made in the conversation was (and correct me if I'm wrong) that one could dump an arbitrary FPGA's contents to do a security audit on them.
Ah, I see. I thought the focus was on cold boot or evil maid attacks against FPGA-based (thus, nominally trustworthy) CPUs, and how these attacks might compare to similar attacks against a commercial CPU. As you pointed out before, one may as well just grab the configuration out of the ROM itself, and I agree---but my point was that either way, what are we getting except some information that's not really secret? So I think we're in violent agreement, at least to the extent that we're talking about the same thing :) Also: one assumes that cold boot attacks against the contents of RAM are more useful than against the SRAMs that hold the FPGA's configuration, and in that case probably it's little different from the equivalent attack against a commercial CPU (the DRAM is more or less the same whether we're talking about the commercial or the FPGA-based CPU---you're using the same DIMMs either way). On further reflection, I suppose the contents of the block RAMs inside the FPGA (little SRAMs sprinkled through the fabric) might be a prize worth chasing, since those are presumably acting as registers and cache for our CPU. It *might* be possible to do so by cold booting the FPGA with a configuration that dumps the contents of the block RAMs, assuming that those contents aren't cleared by power-on reset or the configuration process itself. To your point above about auditing the configuration actually running on an FPGA: that would be very interesting to prevent against an FPGA manufacturer going the reflections-on-trusting-trust route. Here's one way an evil FPGA manufacturer might proceed: the CAD software that the manufacturer provides with the FPGA detects that you're synthesizing a CPU. Rather than emit a flawed bitstream (which might be detectable just by examining the bitstream itself), perhaps the software would hide in the bitstream some instructions that direct the FPGA's configuration state machine to introduce flaws at config time. (FPGA config bitstreams are big, complicated, and proprietary; so it's not impossible that they contain enough redundancy that one could use stego to hide such commands in the bitstream.) (This approach also helps to get around the fact that the synthesis and fitting process does a randomized search for a configuration that meets your criteria (e.g., speed, size, etc.). In other words: the best time to detect "this guy is trying to build a CPU" is when the software is reading your Verilog, not when it's loading the bitstream into an FPGA, because it's really really hard to decide "this is a CPU" just by examining the bitstream itself.) But I suppose if I were so devious as a manufacturer of FPGAs as to detect a CPU design and introduce subtle bugs as a result, I would probably also do my best to keep you from detecting it, even if you *are* able to read out the config from a running FPGA. It's quite a large haystack for hiding such a little needle... (And regarding cold booting to read out the config SRAMs: I worry even more here than in the case of block RAMs that these have a carefully designed power-on reset scheme in place so that the FPGA fabric comes up in a known state.) -=rsw