Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

usenix.org

Post reply on HN
Print view View original

71–80 of 93 posts

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

#71

Post by userbinator »

alexdowad wrote: post #20

Once I worked at a place which was very interested in protecting the IP inherent in their firmware. They gave me a research assignment to get an idea of how difficult it would be for an attacker to extract it as a binary given unlimited physical access to a sample device. Since I read and write Chinese, I did some searching on Chinese-language sites and found a company advertising their ability to do just that... for…

There are quite a few Chinese (and Russian, not surprisingly...) companies who will do "MCU breaks". $10k (USD) is near the high end of the price range; price depends on complexity and newness --- less than $1k for some of the common and older parts. Mikatech is one of the better-known and older ones.

They are great for maintaining legacy equipment where the original company has either discontinued support or disappeared completely.

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

#72

Post by analognoise »

amelius wrote: post #65
voxadam wrote: 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 such a sad situation. Why can't companies just provide all the necessary hardware info in the datasheet?

Tens of thousands of engineers successfully use these chips already without this data.

Divulging this data ends a revenue stream (which funds tooling development) and prevents competitors from potentially extracting useful information.

There's zero reason to open the chips up at that level.

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

#73

Post by pmorici »

eqvinox wrote: post #59
pmorici wrote: post #43

Earlier quoted context omitted.

This encryption is the only way that you can ensure the integrity of the firmware at the chip level so anything relying on that as part of their chain of trust is going to have to redesign their device now. Firmware is loaded from an external eeprom on these devices DRM wasn't the sole use of this feature.

The chain of trust could already be attacked by replacing the entire FPGA chip with an unkeyed/open one, and then loading you own malicious bitstream. Also, encryption never ensures integrity; it ensures confidentiality. Integrity would've come from the accompanying signature scheme, which apparently was badly implemented and broken at the same time. If anything, the encryption makes it impossible to conduct spot che…

On these chips the encryption and integrity checking feature is one and the same you can't turn on one without the other.

Whether or not you use the same key over every device in a product line or a per device key is up to the oem. So you can still verify firmware in the former instance.

Replacing the FPGA chip is a lot harder than re-flashing an eeprom and they would also have to put a lot of effort in to replicating your firmware just to insert their change.

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

#74

Post by userbinator »

I wonder if everyone who works on stuff like this is pro-DRM/anti-freedom, because while I've seen plenty of DRM-breaking papers which paint a very negative view of their findings (this one included), I can't recall seeing a single one which takes the opposite view that this is another step forward for freedom and right-to-repair. Are the researchers really believing that this is a bad thing, or is it because they're afraid of taking that position since others could disapprove and reject their paper?

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

#75

Post by IshKebab »

teraflop wrote: post #46
IshKebab wrote: post #28

Earlier quoted context omitted.

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.

As the paper explains, there is no "signing" involved (in the sense of a public-key cryptosystem). Each encrypted bitstream includes an HMAC, but because the HMAC key is part of the encrypted bitstream itself, it basically only acts like a non-cryptographic checksum. An attacker who knows the encryption key can simply choose an arbitrary HMAC key and generate a valid HMAC for arbitrary data. EDIT: I should clarify th…

Ah interesting, thanks!

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

#76

Post by johncolanduoni »

snvzz wrote: post #32
loeg wrote: post #26

Earlier quoted context omitted.

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.

This mechanism also included an HMAC, responsible for authenticating the bitstream. That's useful even if the bitstream is public knowledge.

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

#77

Post by throwaway2048 »

analognoise wrote: post #72
amelius wrote: post #65

Earlier quoted context omitted.

It's such a sad situation. Why can't companies just provide all the necessary hardware info in the datasheet?

Tens of thousands of engineers successfully use these chips already without this data. Divulging this data ends a revenue stream (which funds tooling development) and prevents competitors from potentially extracting useful information. There's zero reason to open the chips up at that level.

zero reason for the company selling them, plenty of reason for the users.

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

#78

Post by CamperBob2 »

amelius wrote: post #65
voxadam wrote: 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 such a sad situation. Why can't companies just provide all the necessary hardware info in the datasheet?

Their competitors would treat it as an illustrated guide for patent infringement suits, for one thing. Security through obscurity still works for that purpose to a great extent.

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

#79

Post by bb88 »

userbinator wrote: post #74

I wonder if everyone who works on stuff like this is pro-DRM/anti-freedom, because while I've seen plenty of DRM-breaking papers which paint a very negative view of their findings (this one included), I can't recall seeing a single one which takes the opposite view that this is another step forward for freedom and right-to-repair. Are the researchers really believing that this is a bad thing, or is it because they're…

So this will help:

1. Security researchers, so they can see what malware may be lurking in FPGA bitstreams.

2. Open source developers working on FPGA bitstream compilers.

3. People who want to steal proprietary IP cores.

It hurts:

1. People who chose the part because of the closed bitstream particularly. In part because they made security decisions that the bitstream wasn't open.

2. Anyone who bought the products based upon the marketed security claims of the product (Hopitals/DoD/etc)

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

#80

Post by opus132 »

amelius wrote: post #65
voxadam wrote: 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 such a sad situation. Why can't companies just provide all the necessary hardware info in the datasheet?

In addition to the other reasons already mentioned, this would likely reveal a lot of small details about the underlying microarchitecture of the FPGA fabric which is a (highly valuable) trade secret.
Post reply on HN