Electronics > FPGA

Xilinx Artix 7 Bitstream Encryption Fix?

(1/2) > >>

hal9001:
I read a flaw was found for the bitstream encryption for the 7 series FPGA defeating it. Does any one know if Xilinx plans to roll out a fix for it?
 Is there another way to protect the bitstream on Xilinx 7 series FPGAs or maybe prevent the bitstream from working on other hardware if copied?

filssavi:
In my opinion there in no chance in hell Xilinx will do a revision for this, as while series 7 is not obsolete, it is a fairly old product, and re-spinning the mask set would not make that much economic sense.

Also I read the paper describing the attack, and it does seem to rely on JTAG/selectMAP interface access, thus a valid countermeasure might simply be not breaking out these to the pcb, that would substantially raise the cost of an attack

Also I would not rely on the built in encryption in general Purpose MCU/FPGAs for anything truly critical, as I suspect (I have no way of proving it though) that those features are put in more for marketing than anything else (as they say in the paper the hardware implementation of the crypto is fine and working correctly and mostly secure, however the integration in the overall system not so much)

In the end I think there is a reason why Truly security critical stuff (think EMV payments) use their own secure silicon

NorthGuy:
There are two methods. One method uses power consumption. People reduce bypassing and measure power consumption, or they use high speed EMI probes with FPGA left in place. By trying to program various "cooked" bitstreams, this method can reveal the AES key in a matter of hours. There's practically no defence against this.

Another method uses a flaw in bitstream encryption which doesn't allow you to sniff the key, but the attacker can use the FPGA to decrypt the bitstream, or to configure FPGA with his own bitstream. This requires JTAG and works really fast. You can protect against this by not routing JTAG. Or you can detect the attack and take some destructive measures, such as disconnecting the battery. Or you can change the structure of the bitstream hoping that the attackers are not good enough to modify the sniffing software they use.

Either way, they can unsolder your FPGA and get access either to the bitstream or the AES key. Either one of these is enough to replicate your device and sell it. You can resist de-soldering by storing the key in a battery powered CMOS within FPGA (as opposed to fuses). This way they will have to unsolder without disconnecting the battery, which makes it more difficult. Or you can make access to FPGA more difficult, such as with potting.

Overall, I don't think there are any measures that can deter a skilled attaker.

hal9001:

--- Quote from: NorthGuy on July 03, 2021, 02:00:25 pm ---There are two methods. One method uses power consumption. People reduce bypassing and measure power consumption, or they use high speed EMI probes with FPGA left in place. By trying to program various "cooked" bitstreams, this method can reveal the AES key in a matter of hours. There's practically no defence against this.

Another method uses a flaw in bitstream encryption which doesn't allow you to sniff the key, but the attacker can use the FPGA to decrypt the bitstream, or to configure FPGA with his own bitstream. This requires JTAG and works really fast. You can protect against this by not routing JTAG. Or you can detect the attack and take some destructive measures, such as disconnecting the battery. Or you can change the structure of the bitstream hoping that the attackers are not good enough to modify the sniffing software they use.

Either way, they can unsolder your FPGA and get access either to the bitstream or the AES key. Either one of these is enough to replicate your device and sell it. You can resist de-soldering by storing the key in a battery powered CMOS within FPGA (as opposed to fuses). This way they will have to unsolder without disconnecting the battery, which makes it more difficult. Or you can make access to FPGA more difficult, such as with potting.

Overall, I don't think there are any measures that can deter a skilled attaker.


--- End quote ---

--- Quote from: filssavi on July 03, 2021, 10:55:33 am ---In my opinion there in no chance in hell Xilinx will do a revision for this, as while series 7 is not obsolete, it is a fairly old product, and re-spinning the mask set would not make that much economic sense.

Also I read the paper describing the attack, and it does seem to rely on JTAG/selectMAP interface access, thus a valid countermeasure might simply be not breaking out these to the pcb, that would substantially raise the cost of an attack

Also I would not rely on the built in encryption in general Purpose MCU/FPGAs for anything truly critical, as I suspect (I have no way of proving it though) that those features are put in more for marketing than anything else (as they say in the paper the hardware implementation of the crypto is fine and working correctly and mostly secure, however the integration in the overall system not so much)

In the end I think there is a reason why Truly security critical stuff (think EMV payments) use their own secure silicon

--- End quote ---
Thanks. Thats surprising that there is no real way to protect bitstreams from being duplicated and run on unauthorized hardware. Spartan 3AN came with internal configuration memory.  I wonder why they dont do that with new FPGA families and if that was a more secure way to program the FPGA.

petersanch:

--- Quote from: hal9001 on July 03, 2021, 10:11:18 am ---I read a flaw was found for the bitstream encryption for the 7 series FPGA defeating it. Does any one know if Xilinx plans to roll out a fix for it?
 Is there another way to protect the bitstream on Xilinx 7 series FPGAs or maybe prevent the bitstream from working on other hardware if copied?

--- End quote ---
Spartan 6 larger parts offer bitstream encryption too. Does that have the same JTAG flaw as the 7 Series?

Navigation

[0] Message Index

[#] Next page

There was an error while thanking
Thanking...
Go to full version