[Cryptech Tech] passin' through

Mon Feb 3 08:49:34 UTC 2014

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Aloha!

(Adding @tech as cc to keep these discussions in the open. I hope that
is ok - it should.)

bunnie wrote:
> Actually, I use Xilinx's ISE tools to make my FPGA designs. It
> doesn't bother me too much to use them for this. Anyways, if you
> don't trust the tools, you should also not trust the silicon, as they
> are made by one in the same entity and are intimately linked to each
> other.

At least to some degree. There are third party tools from Synopsys,
Mentor, but they usually hook into the vendor specific tools at the
lower end of the backend flow (bitstream generation, bitstream encryption).

As I see it there are several things to be vary about and some of them
we can mitigate better than others.

(1) Frontend compilation. RTL-netlist including mapping. Here there are
third party tools as well as vendor specific tools. The risks here are
either
 - Functional modification and additions. These we can try to adress by
equivalence checking, manual and automatic reviews as well as simulations.

 - Instantiation of unbalanced macros. Multipliers wide side-channel
issues for examples. These can be somewhat mitigated by control of the
mapping and compartmentalization. Avoiding hard macros for Eth MACs
(thus providing information about the design to the tools.) is one way
to trade efficiency for possible leakage resistance.

(2) Backend compilation.
  - Place & Route should be possible to review and control to avoid some
effects on side channels. For internal entropy sources we may need to do
some P&R ourselves anyway.

 - Bitstream generation. The real magic stage. Hard to see how we can
find robust ways of verifying and control this stage.

I.e. we can and should try to mitigate and control the flow where we
can. But for FPGAs there will be things we just have to trust. This is
why methods for side channel analysis as well as active tamper
protection will be important. Being able to detect the leakeage effects
of functionality in the FPGA that we can't control through the design
tools and making it hard for an attacker to gain access to these effects.

> Making FPGA designs with open tools, in a comprehensive fashion -- 
> there's some other projects that are undertaking this, which I'm not 
> involved in, and you might do better to reach out to them. Verifying 
> configurations might be a hair easier if your only fear is that some 
> trojan logic is being inserted that does X, depending on what your 
> assumption of X is. There's some baseline entropy reduction in a
> bitfile when you compile logic into it, and if you see a lot more
> switch points and LUTs being configured over what's being reported
> you would have reason to be worried. However, as I mentioned above,
> in the processes they use for FPGAs it's about the size of a bond pad
> to bury an ARM7 hard macro into the chip, and these ICs are pretty
> big, so if they wanted to it could be a single, subtle, undocumented
> change to the bitfile to turn on a JTAG scan chain spy module or
> something like that if they were really clever about it.

Yes, we really need to do a good survey of all open HW projects as well
as some research to see what the status are, what we can use and where
some support might help a project develop solutions we can use.

As you wrote, having scan chains and JTAG access may be something that
we can't trust. We simply have to make sure that access to those ports
can be disabled in a hard way. And not using macros that might open up
side channels for scan chains etc (internal MACs and PHYs mainly) might
be design requirements.

I don't know if you have seen the work done by Sergei Skorobogatov on
JTAG port knocking and failure based key extraction on FPGAs? Very scary.

http://www.cl.cam.ac.uk/~sps32/sec_news.html

- -- 
Med vänlig hälsning, Yours

Joachim Strömbergson - Alltid i harmonisk svängning.
========================================================================
 Joachim Strömbergson          Secworks AB          joachim at secworks.se
========================================================================
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.22 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQIcBAEBCAAGBQJS71geAAoJEF3cfFQkIuyN+d4P/jty6WSxnDmstr0uCc/se3Oi
mXKMbFzCN4jqEJ2lANmnKX7rU9T5Fy/yVzn+KDS3QcVrqb78wzYEnsp6COzTu/Bu
LMWZwb0otRNpnEHsvBohAMSDzeFZikiNrBvLeOWyyA2NgEsJH3r956ispv9NnqLK
GPs4x+T6ngsVSZzjrHqEykFuEYA+j/wsA9jWHDe+s0mHDgZq2JtFjoS2x3DiJoqY
N68Fk5206JjqssJc227eawf9XV625EMG7bBzFp+RPROSTt3rrRmOIA8/6ppLS+W2
zKQSApG1wus2lsEOid+M2Rst0mj5/V4pPusgxDtYG+5Jok+r4DMkkWOXrj0cNEiS
NjCNkHcR5AVwNOcdOrBfrjvOZKo/xJGikdZvlaNgvR7RZx41GN2TdkE5cDBBOwWk
HWjoXQ2A/XW+4tQe7wRzsOqi4ASsXCASN7DB7Cfj4Lo+HEDGjURYJNO1yG/iVXKi
BbSbIhCje0wMD6J58efW0+Phcgf1gU6FZmwtybbZb5JuJYSfiHXjeAVIhJQBfUYx
2GYWo2b9uS0QtYn8iwsw576nPdUWnxKtWsK0iQzv2KxnpHbVAdhf6kGBYegQIio9
c+nwZCw9cZ1yvwltbP87RSXn9vxtFXt80golVBK6nPTGQHejFYp0VordXVxLLes/
7sqwGzXdnawbs1cF41pV
=Cu/t
-----END PGP SIGNATURE-----