3 ms·
You're correct, but from my understanding shifting the trust to the FPGA is a productive move as an potential attack is much more difficult to execute. Bunnie e
by bibabaloo 6y ago
You're correct, but from my understanding shifting the trust to the FPGA is a productive move as an potential attack is much more difficult to execute. Bunnie explains on his blog [1] better than I can:
> The CPU is, of course, the most problematic piece. I’ve put some thought into methods for the non-destructive inspection of chips. While it may be possible, I estimate it would cost tens of millions of dollars and a couple years to execute a proof of concept system. Unfortunately, funding such an effort would entail chasing venture capital, which would probably lead to a solution that’s closed-source. While this may be an opportunity to get rich selling services and licensing patented technology to governments and corporations, I am concerned that it may not effectively empower everyday people.
> The TL;DR is that the near-term compromise solution is to use an FPGA. We rely on logic placement randomization to mitigate the threat of fixed silicon backdoors, and we rely on bitstream introspection to facilitate trust transfer from designers to user. If you don’t care about the technical details, skip to the next section.
[1] https://www.bunniestudios.com/blog/?p=5706 https://www.bunniestudios.com/blog/?p=5706
- ThrowawayR2 6y agoAn attacker would go after the weakest link. Does this device provide any way of verifying that a bitstream loaded onto the device during development is the same one being run when it's actually in use in the field? That would be the simplest way to compromise it. It would be detectable of course but anyone going to these lengths can compromise the unprotected device programmer hardware or workstation that reads the bitstream back out too.