Xilinx Artix 7 Bitstream Encryption Fix?

[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]

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.

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

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]

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?

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

[BrianHG]

Or you can make access to FPGA more difficult, such as with potting.

I went the potting route.  Also had my own separate programming port for updating the encapsulated bootprom & FPGA through an Ethernet port I had in the design.  Though, if the primary bootprom was ever corrupted through a firmware update, the board was trashed.  An older design of mine had a software-firmware key to turn on the JTag port, which actually worked through the JTag port.  Though, with X-Ray, both potting solutions could possibly be defeated with some fine drilling and needle probes, or the right chemical bath.

Another solution is to make your design dependent on a separate secure MCU which the FPGA cannot operate or do anything useful without.

[petersanch]

Or you can make access to FPGA more difficult, such as with potting.

I went the potting route.  Also had my own separate programming port for updating the encapsulated bootprom & FPGA through an Ethernet port I had in the design.  Though, if the primary bootprom was ever corrupted through a firmware update, the board was trashed.  An older design of mine had a software-firmware key to turn on the JTag port, which actually worked through the JTag port.  Though, with X-Ray, both potting solutions could possibly be defeated with some fine drilling and needle probes, or the right chemical bath.

Another solution is to make your design dependent on a separate secure MCU which the FPGA cannot operate or do anything useful without.

Thanks. For the separate secure MCU , do you mean to control some parts on the PCB with the MCU instead of FPGA so if the MCU is not there then those parts wont work?

[BrianHG]

I mean that the MCU communicates with the FPGA directly and provides a function which makes the FPGA useless without it.  It can be an encrypted lock and key, but, better if the MCU handles say for example your projects COM ports or for example runs your projects motor's PWM and encoders for the FPGA.  Remember, getting a source bitstream from a MCU can mean disassembly and potential code manipulation.  Getting a source bitstream from a FPGA usually means an identical copy, nothing else.

[asmi]

MCUs are just as useless for security. The most secure way is to store the key in the FPGA's battery powered memory. Although depending on a battery's chemistry in might create additional headaches for logistics. For less elaborate protection most FPGAs offer some type of OTP or unique serial number, which you can use in your design to make transplanting your bitstream harder (they will have to reverse-engineer it which is time consuming). This obviously creates headaches for production, as you will have to create unique bitstreams for each board, also bitstream upgrade is going to be problematic.

I personally don't bother with any of this for my customer's boards as they use them internally and so it makes no sense for them to try breaking.

[petersanch]

MCUs are just as useless for security. The most secure way is to store the key in the FPGA's battery powered memory. Although depending on a battery's chemistry in might create additional headaches for logistics. For less elaborate protection most FPGAs offer some type of OTP or unique serial number, which you can use in your design to make transplanting your bitstream harder (they will have to reverse-engineer it which is time consuming). This obviously creates headaches for production, as you will have to create unique bitstreams for each board, also bitstream upgrade is going to be problematic.

I personally don't bother with any of this for my customer's boards as they use them internally and so it makes no sense for them to try breaking.

Wonder if this causes some industries to stay away from Xilinx FPGAs for high security products like in defense. If the encryption can be defeated over JTAG interface and unencrypted bitstreams can be reverse-engineered to remove unique serial number validation then it sounds very flawed for secure products.