Arg. I'm actually considering the problem of a secure design that's secure both through being transparently open source, and by using a super-simple architecture. And unfortunately these two properties mean that a) well, everyone has the GDSII, and b) the architecture is super-easy to hack. It makes perfect sense that a fab would need time to mount an attack on a closed and complex design though.
Very good point about process differences. That totally makes sense, and would likely require human verification to handle, which for big chips would be, at the very least, hilariously expensive.
"Instead of adding additional cir-
cuitry to the target design, we insert our hardware Trojans by changing
the dopant polarity of existing transistors. Since the modified circuit ap-
pears legitimate on all wiring layers (including all metal and polysilicon),
our family of Trojans is resistant to most detection techniques, includ-
ing fine-grain optical inspection and checking against “golden chips”.
We demonstrate the effectiveness of our approach by inserting Trojans
into two designs — a digital post-processing derived from Intel’s cryp-
tographically secure RNG design used in the Ivy Bridge processors and
a side-channel resistant SBox implementation — and by exploring their
detectability and their effects on security"
Thanks. But ugh. That is both absolutely amazing and... well, what did I expect. Of course there are going to be process attacks :)
Hmmm. I guess the only defenses against this are
- trying to design the layout to get good "route coverage" via test routines (sounds hard)
- aiming for super-simple designs that make it difficult to constructively alter the design (pathological simplicity is one part of my idea; yet to determine viability)
- trusting the fab (ha!)
I wonder if using a huge process like ~30nm (or even bigger) would mitigate at all.
It's much easier to just trust the fab. TSMC do not care about backdooring your hobby project.
If you really want to carry on down this route, I would say the most effective approach would be to regard fab interference as a strange form of "single event upset", and borrow high-availability techniques such as lock-step mode across duplicated processors or subsystems.
Interesting. I'm curious, what sort of cost level would someone need to be looking at to mount an attack like the BECKER-CHES one? It would be really cool to be able to say "this would be secure until an attacker starts spending $(X?)XXX,XXX." Everything's vulnerable, step 1 is to have a good idea of how vulnerable.
Lock-step sounds interesting but really really hard - the basis of my idea is security through simplicity, and packing everything onto the one chip so only signed encrypted data comes out. Breaking the design down so that lock-stepped processors would reveal tampering would probably violate integrity and likely have blind spots too.
Very good point about process differences. That totally makes sense, and would likely require human verification to handle, which for big chips would be, at the very least, hilariously expensive.