4 ms·

I don't quite get why they say that it's trustworthy because it uses a soft-CPU running on an FPGA. Doesn't that just shift the potential attack from one vendor

I don't quite get why they say that it's trustworthy because it uses a soft-CPU running on an FPGA. Doesn't that just shift the potential attack from one vendor to another? e.g. instead of trusting a CPU from Mediatek, now you have to trust an FPGA fabric from Xilinx

strmpnk 6y ago
This is true, but the difficulty of making a general purpose FPGA fabric manipulate generic bitstream descriptions in an undetectable way is much harder than putting hidden backdoors in well defined ISAs. What amount of hardware validation is reasonable? It depends on what you'd like to accomplish, but given that powerful FPGAs are now more affordable and plenty of great FPGA friendly libraries are emerging which work with open source tools, the barrier for Soft-CPU implementations has lowered significantly. This sort of project looks great for cases where trusting blackbox chips was questionable.
- codethief 6y ago
  > This is true, but the difficulty of making a general purpose FPGA fabric manipulate generic bitstream descriptions in an undetectable way is much harder than putting hidden backdoors in well defined ISAs. Could you (or anyone else) elaborate on this? If possible, ELI5 please because I know very little about hardware. :)
  - saagarjha 6y ago
    I think a somewhat useful analogy would be the difference in difficulty of making a backdoored compiler versus a backdoored binary. The former has to deal with a lot more things than the latter if you'd like to effectively subvert it.
- deleted 6y ago
  [deleted]
ent 6y ago
It does, but as far as I've understood, FPGA's are much simpler and more regular so hiding backdoors into those would be harder than hiding one into a hardware cpu.
- CyberRabbi 6y ago
  Is the hardware synthesizer / bitstream generator open source?
  - aDfbrtVt 6y ago
    The Xilinx chip is mostly(fully?) supported by project X-Ray + Yosys.
    - GeorgeTirebiter 6y ago
      Ultimately, we have to build our own chips. In the coming decade, getting a custom chip built will be on the same level as getting a PCB done 20 years ago. That brings many other concerns, such as slipping some snooping logic onto a corner of a chip, which is activated only when some 2048-bit string is sent to wake it up. Therefore, even when we have a Chip House build our chip, we're still going to have to knock the tops off and do something similar to what Ken Shirriff does https://www.righto.com/ https://www.righto.com/ to make sure there are no 'extra' circuits. Trust is Hard. https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html
Confiks 6y ago
Here's an excellent talk that addresses your question: Open Source is Insufficient to Solve Trust Problems in Hardware [1]. [1] https://www.youtube.com/watch?v=Hzb37RyagCQ https://www.youtube.com/watch?v=Hzb37RyagCQ
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 ago
  An 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.

strmpnk 6y ago

This is true, but the difficulty of making a general purpose FPGA fabric manipulate generic bitstream descriptions in an undetectable way is much harder than putting hidden backdoors in well defined ISAs. What amount of hardware validation is reasonable? It depends on what you'd like to accomplish, but given that powerful FPGAs are now more affordable and plenty of great FPGA friendly libraries are emerging which work with open source tools, the barrier for Soft-CPU implementations has lowered significantly. This sort of project looks great for cases where trusting blackbox chips was questionable.

codethief 6y ago
> This is true, but the difficulty of making a general purpose FPGA fabric manipulate generic bitstream descriptions in an undetectable way is much harder than putting hidden backdoors in well defined ISAs. Could you (or anyone else) elaborate on this? If possible, ELI5 please because I know very little about hardware. :)
- saagarjha 6y ago
  I think a somewhat useful analogy would be the difference in difficulty of making a backdoored compiler versus a backdoored binary. The former has to deal with a lot more things than the latter if you'd like to effectively subvert it.
deleted 6y ago
[deleted]

ent 6y ago

It does, but as far as I've understood, FPGA's are much simpler and more regular so hiding backdoors into those would be harder than hiding one into a hardware cpu.

CyberRabbi 6y ago
Is the hardware synthesizer / bitstream generator open source?
- aDfbrtVt 6y ago
  The Xilinx chip is mostly(fully?) supported by project X-Ray + Yosys.
  - GeorgeTirebiter 6y ago
    Ultimately, we have to build our own chips. In the coming decade, getting a custom chip built will be on the same level as getting a PCB done 20 years ago. That brings many other concerns, such as slipping some snooping logic onto a corner of a chip, which is activated only when some 2048-bit string is sent to wake it up. Therefore, even when we have a Chip House build our chip, we're still going to have to knock the tops off and do something similar to what Ken Shirriff does https://www.righto.com/ https://www.righto.com/ to make sure there are no 'extra' circuits. Trust is Hard. https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html https://www.win.tue.nl/~aeb/linux/hh/thompson/trust.html

Confiks 6y ago

Here's an excellent talk that addresses your question: Open Source is Insufficient to Solve Trust Problems in Hardware [1]. [1] https://www.youtube.com/watch?v=Hzb37RyagCQ https://www.youtube.com/watch?v=Hzb37RyagCQ

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 ago
An 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.