4 ms·

> Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? No data I can offer as such, but anecdote from several suppliers who integrate

by g_p 5y ago

> Anyone got stats on how FPGA ecosystems have fared vs. MCUs over chipageddon? No data I can offer as such, but anecdote from several suppliers who integrate some big name FPGAs into their products. They've seen supply dry up like other chips, causing several months of delays to lead times. It's not "zero supply", but a significant reduction in supply. The vendor-specific toolchains and supply chain security issues you point out are huge issues, and ones most people (even security experts) are a bit blind to. You can't verify the state of a programmer FPGA by inspection (at least not using normal techniques), so you can't easily verify the output of your bitstream compiler, which is the output of the complex design toolchain. The toolchain output and bitstream are probably encrypted (or heavily obfuscated at minimum), and this will make it near impossible to audit the component. I don't see how anyone can defend against a Solarwinds (i.e. Stuxnet style attack) in the long run, as a toolchain compromise could introduce arbitrary modification of the logic, and would be unlikely to be spotted, and very difficult to ever detect once in the field.

pclmulqdq 5y ago
Bitstream encryption is okay, but someone still has yet to make an FPGA that is truly secure. As far as I know, bitstream encryption on the Xilinx Ultrascale+ devices has been broken, so there isn't a lot of protection there against sophisticated actors.
- g_p 5y ago
  I've not had much experience with modern allegedly "secure" FPGAs, but the scenario I see here is if your synthesis tools get compromised by a bad update (or another attack), they could add a little bit of "side logic" to every design. Solarwinds style. With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected. Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.

by g_p 5y ago

pclmulqdq 5y ago

Bitstream encryption is okay, but someone still has yet to make an FPGA that is truly secure. As far as I know, bitstream encryption on the Xilinx Ultrascale+ devices has been broken, so there isn't a lot of protection there against sophisticated actors.

g_p 5y ago
I've not had much experience with modern allegedly "secure" FPGAs, but the scenario I see here is if your synthesis tools get compromised by a bad update (or another attack), they could add a little bit of "side logic" to every design. Solarwinds style. With encrypted output and what I understand to be no ability to carry out QA/evaluation on the bitstream (with encryption meaning binary comparisons shouldn't be meaningful), you can't really gain assurance that the output is as expected. Of course you could argue that you compare the encrypted bitstream with your "final version", but this only works until you need to use the field programmable aspect to update something, and now you have to take a leap of faith and flash the bitstream, and hope your build environment is good, as there's no real way to check.