<div dir="ltr"><div class="gmail_quote"><div>Sorry for the delayed response. I have been falling behind on my personal email.</div><div dir="ltr"><br></div><div dir="ltr">On Wed, Jul 29, 2015 at 12:32 PM Riad S. Wahby <<a href="mailto:rsw@jfet.org">rsw@jfet.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">The Doctor <<a href="mailto:drwho@virtadpt.net" target="_blank">drwho@virtadpt.net</a>> wrote:<br>
> I thought the point being made in the conversation was (and correct me<br>
> if I'm wrong) that one could dump an arbitrary FPGA's contents to do a<br>
> security audit on them.<br>
<br>
Ah, I see. I thought the focus was on cold boot or evil maid attacks<br>
against FPGA-based (thus, nominally trustworthy) CPUs, and how these<br>
attacks might compare to similar attacks against a commercial CPU.<br></blockquote><div><br></div><div>This is what *I* meant. I was assuming an open source CPU design, which would make dumping the configuration ROM pointless.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As you pointed out before, one may as well just grab the configuration<br>
out of the ROM itself, and I agree---but my point was that either way,<br>
what are we getting except some information that's not really secret?<br>
So I think we're in violent agreement, at least to the extent that<br>
we're talking about the same thing :)<br>
<br>
Also: one assumes that cold boot attacks against the contents of<br>
RAM are more useful than against the SRAMs that hold the FPGA's<br>
configuration, and in that case probably it's little different from<br>
the equivalent attack against a commercial CPU (the DRAM is more<br>
or less the same whether we're talking about the commercial or the<br>
FPGA-based CPU---you're using the same DIMMs either way).</blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
On further reflection, I suppose the contents of the block RAMs inside<br>
the FPGA (little SRAMs sprinkled through the fabric) might be a prize<br>
worth chasing, since those are presumably acting as registers and<br>
cache for our CPU. It *might* be possible to do so by cold booting the<br>
FPGA with a configuration that dumps the contents of the block RAMs,<br>
assuming that those contents aren't cleared by power-on reset or the<br>
configuration process itself.<br></blockquote><div><br></div><div>This is what I was thinking of, though the terminology had escaped me for the moment.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
To your point above about auditing the configuration actually running<br>
on an FPGA: that would be very interesting to prevent against an FPGA<br>
manufacturer going the reflections-on-trusting-trust route.<br>
<br>
Here's one way an evil FPGA manufacturer might proceed: the CAD<br>
software that the manufacturer provides with the FPGA detects that<br>
you're synthesizing a CPU. Rather than emit a flawed bitstream<br>
(which might be detectable just by examining the bitstream itself),<br>
perhaps the software would hide in the bitstream some instructions<br>
that direct the FPGA's configuration state machine to introduce flaws<br>
at config time. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
(FPGA config bitstreams are big, complicated, and proprietary; so<br>
it's not impossible that they contain enough redundancy that one<br>
could use stego to hide such commands in the bitstream.)<br>
<br>
(This approach also helps to get around the fact that the synthesis<br>
and fitting process does a randomized search for a configuration<br>
that meets your criteria (e.g., speed, size, etc.). In other words:<br>
the best time to detect "this guy is trying to build a CPU" is when<br>
the software is reading your Verilog, not when it's loading the<br>
bitstream into an FPGA, because it's really really hard to decide<br>
"this is a CPU" just by examining the bitstream itself.)</blockquote><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
But I suppose if I were so devious as a manufacturer of FPGAs as to<br>
detect a CPU design and introduce subtle bugs as a result, I would<br>
probably also do my best to keep you from detecting it, even if you<br>
*are* able to read out the config from a running FPGA. It's quite a<br>
large haystack for hiding such a little needle...<br>
<br></blockquote><div><br></div><div>Sounds possible but much harder to do and with lower impact than backdooring a widely used CPU, at least until a bunch of people the government considers threats start using soft cores.</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
(And regarding cold booting to read out the config SRAMs: I worry even<br>
more here than in the case of block RAMs that these have a carefully<br>
designed power-on reset scheme in place so that the FPGA fabric comes<br>
up in a known state.)<br></blockquote><div><br></div><div>Might it be possible to use a glitch attack to prevent this from happening? I guess the question is, would you trust an FPGA's block RAM more than you would TXT and L1 cache on an Intel CPU to protect sensitive data? </div><div><br></div></div></div>