[jacquesm]

> How do you insert a backdoor in an FPGA at the supply chain if you don't know what is the exact logic that is going to be uploaded?

Popularity of certain open core designs might be one way to gain advance knowledge of how an FPGA might be used.

That suggests an interesting option: to scramble the input to an FPGA in such a way that the device will still work but that it is even more unpredictable how its internal connections will be used (otherwise you could take a number of open core designs and arrange for your attack to work with those configurations, which might be detectable in hardware or in the toolchain).

Better yet, scramble the bitstream on every boot (but what would do the scrambling?).

[fanf2]

TFA says “We rely on logic placement randomization to mitigate the threat of fixed silicon backdoors“ and goes on to talk about the tools they are working on, but there is still some way to go.

[jacquesm]

Ah good catch. I must have picked it up while skimming, but it also seems kind of obvious.

[cbsks]

From the article:

> The placement of logic with an FPGA can be trivially randomized by incorporating a random seed in the source code. This means it is not practically useful for an adversary to backdoor a few logic cells within an FPGA. A broadly effective silicon-level attack on an FPGA would lead to gross size changes in the silicon die that can be readily quantified non-destructively through X-rays. The efficacy of this mitigation is analogous to ASLR: it’s not bulletproof, but it’s cheap to execute with a significant payout in complicating potential attacks.

[Cyph0n]

There is active research around the topics of logic locking and logic obfuscation. You can get a feel for the state-of-the-art by following HOST: http://www.hostsymposium.org/

[klhugo]

Yep. Great times are coming :D

I think if you can enforce that the user will resynthesize the design on his own, and you make sure the synthesis/placement is different, you are way ahead of any other AISC alternative in terms of trust.

[jacquesm]

But that would automatically limit the deployment to a very, very small portion of the public, those tech savvy enough to do that. A few thousand to tens of thousands of people worldwide. Unless they would become ambassadors of sort - and assuming anybody else would even care - that would still leave the rest wide open.

Cracking that is a difficult problem, you would have non-tech savvy consumers who need - or at least, that's what we think, your average consumer doesn't care at all - to gain access to secure devices. It would require a very large, visible and super embarrassing event to change the typical 'privacy is dead, get over it' mindset to switch to 'give me that secure hardware'.

Right now the only people who would be interested are those that rightfully have something to fear from nation state level actors (spies, dissidents, politicians, would-be whistleblowers). And using a device like this would make them stand out like sore thumbs.

[kragen]

> that would automatically limit the deployment to a very, very small portion of the public, those tech savvy enough to [resynthesize their CPU from source]

Every time someone opens the Facebook web page, their browser recompiles the Facebook application from JS source, typically using ASLR. Facebook's user interface is vastly more complex than a CPU. Yet Facebook is not limited to a very, very small tech savvy portion of the public.

[mentat]

Facebook's user interface is at least a few orders of magnitude less complex than a CPU. What would lead you to think otherwise?

[kragen]

Simple measures of complexity lead me to think otherwise. For example, the size of the 6502 design team (8 people, four of them circuit designers (several of them were doing things like design rule checks) from August 1974 to June 1975, 10 months) versus the size of Facebook's frontend team (within a factor of 3 of 1000 people, with 15 years of work behind them), the number of transistors in the 6502 (3,510) versus the number of bits in Facebook's minified frontend code (on the order of 100 million), and the line count of the Verilog designs for James Bowman's J1A CPU and Chuck Thacker's thing for STEPS (both under 100 lines of code) versus the line count of just React (a small part of Facebook's code).

You can try to convince people that software that has had 250 times as many people working on it for 18 times as long is "a few orders of magnitude less complex than" the 6502, but I think you're going to have an uphill battle. Three orders of magnitude less complex than the 6502 would be four transistors, a single CMOS NAND or NOR gate.

[mentat]

That's when you could do layout by hand. I thought you meant a modern CPU which is what that UI runs on. Good luck using Facebook on a 6502 which really brings up the rest of the subsystems that collaborate with the CPU.

[nickik]

Not really. The complexity of a basic open source CPU can easily be less far less code then a massive UI application.