notes-computer-systems-hardwareSecurity

* buy a bunch of chips, randomly select some of them, destructively tear apart those to double-check the circuit they implement, then if they're good use other ones from that batch ** refinement: fingerprint each chip base on characteristics as power consumption, temperature, and electromagnetic emission; this can gives you confidence that you may be avoiding the scenario where the chips you happen to test are not tampered with but the one you actually use is ** note that it can be hard to detect changes to circuitry, even with a microscope [https://ece.umass.edu/news/paper-stealthy-trojans-attracting-international-attention

• split manufacturing (IARPA's trusted integrated chips): split the manufacturing into two stages, one in which transistors and a few wires are laid down, and a second stage in which the circuit is created by connecting these transistors; you can double-check the first stage, and then do the second stage in-house (or at a very trusted foundry)
• concurrent error detection: do something like duplicate all of the calculations on the chips but only with parities (a concurrent parity check) (now you have to have a way to non-destructively verify that the parity checker circuit is not subverted, though). RRAM is suggested for this by [1]
  • a clever trojan could alter the result without altering parity, so do randomized parity: only compute the parity on a random subset of the bits. Select the random subset using hardware jumpers that you can set in-house after receiving the chip from the untrusted foundry.
• use FPGAs (and then use concurrent error detection too)
• "But we think that whatever strategy is used to protect against changes—even one that combines split manufacturing, testing, and destructive imaging—it will be very hard to definitively rule out the possibility that a chip contains a hardware Trojan before it’s sent on its way. Small circuits are simply too easy to hide."
• have at least 3 chips with different hardware designs and manufacturers which run similar algorithms and agree via voting

Note that detecting changes via behavior may be very difficult if the behavior only triggers in certain cases, or if the component being subverted is a random number generator [2]

(and there's also toolchain security, like preventing compiler subversion. One weapon here is writing your own self-hosting compiler and then compiling it -- hopefully the attack in 'reflections on trusting trust' wouldn't recognize it as a compiler -- better, compile it on paper and then type in the machine code yourself)

---