Open Fabs

Sean Lynch seanl at literati.org
Thu Aug 13 15:13:56 PDT 2015


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 <rsw at jfet.org> wrote:

> The Doctor <drwho at 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?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 5682 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks/attachments/20150813/a73f62a4/attachment-0002.txt>


More information about the cypherpunks mailing list