1. 10
  1.  

  2. 5

    This is pretty interesting, TEMPEST omg, all that, but… questionable choice of target. They start by mentioning that this is entirely feasible against a network encryption appliance, but then they target some weird underpowered FPGA thing? Their target, as I understand it, is a software T-table implementation (which has other side channel leaks as well). But a real network appliance would be using a hardware implementation, no? Can you demo this attack against some more common hardware, like a MacBook, which would be using AES-NI on the CPU?

    1. 4

      I think we did mix too many attack models, especially since we/I tried to keep the paper readable for a general technical audience (which made it hard to concisely define these things). The following are indeed two distinct points:

      • The “network encryption appliance” scenario is intended to show that many-trace chosen-input attacks are feasible in at least one relevant(-to-us) threat model.

      • As discussed in https://news.ycombinator.com/item?id=14618916, “the contribution of this work is mostly in showing that you can break realistic-but-not-great implementations very quickly, cheaply, and without needing to open most enclosures.” We attack a MicroSemi SmartFusion 2’s ARM core (arguably a “weird underpowered FPGA thing”), a Xilinx Zynq’s ARM core (not a bad model for an IoT-ish device), and a naive hardware implementation (that mostly didn’t make it into the blog). The internship was mostly run on what one of our FPGA experts had lying on his desk. ;-)

      A specialized network crypto definitely needs (and has) a better crypto core than the “realistic-but-not-great” cores we attacked here. (At least, ours do. No promises about today’s model of cheap Linux router. ;-) )

      1. 2

        Oh, nice, thanks for clarifying. Good work.