Live data from Hacker News

A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

usenix.org

31–40 of 93 posts

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#31

Earlier quoted context omitted.

Attacker needs physical access to just one device in the whole product line that uses the same encryption key. After that, all you need is to get the device to update using the bitstream you made. In some cases this could be remote attack.

I'm not sure this is true. This attack allows reading the encrypted bitstream, but it doesn't say anything about allowing you to sign modified bitstreams.

> In this paper, we introduce novel low-cost attacks against the Xilinx 7-Series (and Virtex-6) bitstream encryption, resulting in the total loss of authenticity and confidentiality

This seems to be saying that it's possible

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#32
post #26
post #18

Earlier quoted context omitted.

Security through obscurity? Nah.

This was security through a cryptographic design. It was just a broken design. If you consider confidential symmetric or privkeys "obscurity," sure, all crypto is obscurity.

There's no need to encrypt the keys as you hardcode them into the FPGA, if you control the hardware as you do this.

I certainly don't see how anything FOSS would be affected, and would appreciate concrete examples.

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#33

Earlier quoted context omitted.

No. It means people will be able to copy FPGA's like was possible in the 2000's. It also means that the design in an FPGA could be altered by an unauthorized 3rd party without having to physically replace the device.

Some FPGA's require bitstream encryption. On those devices, breaking this encryption is the first of many steps to making an opensource toolchain

And is also the first of many steps to making a rootkit toolchain that can infect your devices when they’re in the possession of an attacker.

Any device that allows an anonymous third party to modify it is a device that cannot be trusted once it’s been handed to a third party.

Would you be willing to register for an identity certificate to make use of an open source toolchain with your registered device, so that you could be certain others had not silently rootkit’d it and were spying on your work?

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#34

Earlier quoted context omitted.

No. It means people will be able to copy FPGA's like was possible in the 2000's. It also means that the design in an FPGA could be altered by an unauthorized 3rd party without having to physically replace the device.

Some FPGA's require bitstream encryption. On those devices, breaking this encryption is the first of many steps to making an opensource toolchain

This is not the case for the FPGAs targeted here. Encryption is optional on Xilinx 7-Series. Also there already is an open source toolchain coming up for them.

http://www.clifford.at/yosys/

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#35
I don't know what the best prctices are now, but it used to be best practice to blow the CFG_AES_Only eFUSE when using bitstream protection, which prevents the loading of a bitstream which isn't authenticated, and thus foils this attack. If a manufacturer went to the trouble of encrypting the FPGA but then allowed loading of plaintext bitstreams they probably didn't really understand what they were doing.

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#36
This isn't bad for "security" or "secure microcontrollers." It is in fact good for security. Designs running on these FPGAs can now be analyzed and inspected for accidental or intentional security issues. Mind you: the security issues are there whether you know about them or not. The function that the FPGA implements can (and should) still be secure - since the security of its algorithms should never rely on the secrecy thereof. (And to protect secrecy of private key material, it comes down to physical security either way.)

What it's bad for is vendors relying on DRM to protect their assets. Which is normally diametrically opposed to user freedom.

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#37
Is there any way that the breaking of the Xlinix bitstream encryption opens the door to documenting and reverse engineering that bitstream in the same way that was done with Project IceStorm[0] for the Lattice iCE40 FPGAs?

[0] Project IceStorm - http://www.clifford.at/icestorm/

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#38

It's not just an issue for big corporations and their proprietary software and DRM, but also has serious implications for the free and open source hardware community, especially the infosec hackers. To begin with: While it's not realistic to make secure hardware (let's say, a OpenPGP/X.509/Bitcoin Wallet security token) that can be 100% independently verified and free from all backdoors, but still, relatively speakin…

The way to protect secure hardware tokens is not bitstream encryption, it's tamper protection. You store the key material in SRAM that is erased when the device detects any attempt at manipulating.

If your Bitcoin Wallet or whatever token is affected by this, it was IMHO badly designed to begin with, since apparently it was relying on an AES-CBC bitstream encryption scheme. That should've been a red flag even if it wasn't broken.

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#39
post #37

Is there any way that the breaking of the Xlinix bitstream encryption opens the door to documenting and reverse engineering that bitstream in the same way that was done with Project IceStorm[0] for the Lattice iCE40 FPGAs? [0] Project IceStorm - http://www.clifford.at/icestorm/

It's an optional feature, so I don't think so.

Re: A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs

#40
post #37

Is there any way that the breaking of the Xlinix bitstream encryption opens the door to documenting and reverse engineering that bitstream in the same way that was done with Project IceStorm[0] for the Lattice iCE40 FPGAs? [0] Project IceStorm - http://www.clifford.at/icestorm/

No. This is pretty much useless for that.

Project X-Ray [1] has been working on reverse engineering the Series 7 bitstream format for a while now, and Dave Shah has an experimental fork [2] of nextpnr that targets some devices using the X-Ray database.

[1] - https://github.com/SymbiFlow/prjxray

[2] - https://github.com/daveshah1/nextpnr-xilinx

Post reply on HN