4 ms·
You have to trust the FPGA, its toolchain, and any peripheral hardware and firmware with priveleged access.
by nickpsecurity 7y ago
You have to trust the FPGA, its toolchain, and any peripheral hardware and firmware with priveleged access.
- jacquesm 7y agoThat's true in a technical way but it is false in a practical one. An effective attack using compromised FPGAs or toolchains would be super hard to carry out undetected because of the decree of scrutiny the output would receive, besides, the attack itself would have to make substantial assumptions about the way the FPGA would be wired into the resulting circuit. I'm not saying it can't be done but it would extremely hard to carry out and I'm not aware of any such attacks ever being discovered in the wild. > any peripheral hardware and firmware with priveleged access. That would be a more feasible vector. But it all still will be much more secure than your average computer with a BMC.
- nickpsecurity 7y ago"An effective attack using compromised FPGAs or toolchains would be super hard to carry out undetected because of the decree of scrutiny the output would receive" FOSS vulnerabilities countered the many eyeballs argument a long time ago. There's even fewer people who know how to review hardware for flaws. I'm assuming it would be a targeted attack by default. That raises the bar. However, they could also leave a trigger that looks like a hardware flaw in the I/O interface. Intel has basically been doing that subversion with their ME flaws for some time now. Then, the only targeted part is just how to aim what's already there. "That would be a more feasible vector. But it all still will be much more secure than your average computer with a BMC. " True. Especially if you use an architecture like crash-safe.org or Cambrige's CHERI. I already advocate secure CPU's on FPGA's with dumb-as-allowed hardware if one can't get actual silicon. Also lets you throw in extra reliability features, too.