Sorry for the delayed response. I have been falling behind on my
   personal email.
   On Wed, Jul 29, 2015 at 12:32 PM Riad S. Wahby <[1]rsw@jfet.org> wrote:

     The Doctor <[2]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.

   This is what *I* meant. I was assuming an open source CPU design, which
   would make dumping the configuration ROM pointless.

     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.

   This is what I was thinking of, though the terminology had escaped me
   for the moment.

     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...

   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.

     (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.)

   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?

References

   1. mailto:rsw@jfet.org
   2. mailto:drwho@virtadpt.net