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

81–90 of 93 posts

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

#81

Post by black_puppydog »

bb88 wrote: post #79
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 bas…

Woah, from what I undeddtand, the bitstream is the fpga equivalent of the compiler output? Then selling something as "secure" because nobody can know what code it is running would be security through obscurity no? How would vendors get away with that sort of BS?

To be clear: just talking about the confidentiality requirement here. Authenticity (ie code signing, right?) is obviously something very useful especially in these cases.

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

#82

Post by detaro »

bb88 wrote: post #79
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 bas…

Not really helping 2). The encryption is an optional feature, so you can work on reversing and generating your own bitstream as you wish without this.

Being able to fake the signature might help people wanting to backdoor devices in the wild.

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

#83

Post by chapplap »

black_puppydog wrote: post #81
bb88 wrote: post #79

Earlier quoted context omitted.

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 bas…

Woah, from what I undeddtand, the bitstream is the fpga equivalent of the compiler output? Then selling something as "secure" because nobody can know what code it is running would be security through obscurity no? How would vendors get away with that sort of BS? To be clear: just talking about the confidentiality requirement here. Authenticity (ie code signing, right?) is obviously something very useful especially in…

This is about bitstream encryption, so there is an expectation of confidentiality. The keys needed to decrypt the bitstream are stored in nonvolatile memory on the FPGA itself. Assuming that it is implemented correctly (evidently not in this case), it is impossible to decrypt the bitstream without analyzing the FPGA die itself, using tools that are usually beyond what a casual attacker might have. It probably won't stop a nation-state from figuring out how to read out your FPGA design, but it will probably slow down your competitors.

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

#84

Post by black_puppydog »

chapplap wrote: post #83
black_puppydog wrote: post #81

Earlier quoted context omitted.

Woah, from what I undeddtand, the bitstream is the fpga equivalent of the compiler output? Then selling something as "secure" because nobody can know what code it is running would be security through obscurity no? How would vendors get away with that sort of BS? To be clear: just talking about the confidentiality requirement here. Authenticity (ie code signing, right?) is obviously something very useful especially in…

This is about bitstream encryption , so there is an expectation of confidentiality. The keys needed to decrypt the bitstream are stored in nonvolatile memory on the FPGA itself. Assuming that it is implemented correctly (evidently not in this case), it is impossible to decrypt the bitstream without analyzing the FPGA die itself, using tools that are usually beyond what a casual attacker might have. It probably won't…

Yes, for IP protection I get why that's interesting. But crucially, it's the vendor's interest. For a hospital or such, the interest is actually opposed to this. They should be looking for secure software that is as open as possible to allow for audit and servicing if needed. So selling DRM as something that somehow makes the customer more secure is BS.

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

#85

Post by CamperBob2 »

amelius wrote: post #68
ATsch wrote: post #67

Earlier quoted context omitted.

Vendor lock-in is the primary way in which these companies make money

But wouldn't an open specification be a much better value proposition for engineers?

Not directly. Much of the value in a modern FPGA lies in the specialized proprietary hardware provided by the manufacturer -- transceivers, memory controllers, clock management, dozens of other things -- and in the IP cores that can either be inferred or generated through wizards.

So knowing the bitstream format by itself is only a small step forward, if your goal is to take full advantage of the hardware and IP available. You'd need to reverse-engineer all of the specialized hardware and IP support as well. Opening the bitstream format would still be very worthwhile, but it's not the game-changer that many believe it would be.

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

#86

Post by CamperBob2 »

ATsch wrote: post #69
Nokinside wrote: post #7

Earlier quoted context omitted.

If the FPGA can be updated, attacker can take over the hardware and reprogram it. If attacker gets access to the bitstream, the has complete control over the FPGA.

This isn't a worry over device security. It's a worry about cloning. Most of the serious FPGA market is low-volume speciality devices that cost upwards 10-100k per unit, with yearly support contracts of that magnitude on top. Seismology, medical research, telecommunications... many of those products will be a raving success if they sell 1000 units. R&D is almost all of the cost and the hardware design is nothing spec…

You could clone highly specialized devices, but it's not clear who you're going to sell them to. I'd like to think that most of my small, specialized customer base would turn up their noses at an obvious clone of my own product.

The people who need to worry about this are the Ciscos and Keysights and John Deeres and other 800-pound gorillas whose products have a broad user base that includes cost-sensitive customers.

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

#87

Post by brokenmachine »

loeg wrote: post #25
ATsch wrote: post #17

Earlier quoted context omitted.

This is another example of what Moxie Marlinspike calls the "cryptographic doom principle". If you do anything, anything with a ciphertext before checking authenticity, doom is inevitable.

For others following along: https://moxie.org/blog/the-cryptographic-doom-principle/ (2011)

That was really interesting, thanks for that.

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

#88

Post by grogenaut »

pmiller2 wrote: post #64
Teknoman117 wrote: post #62

Earlier quoted context omitted.

The DRM only has to function during the time where most sales occur for it to be worth it.

Except that piracy doesn’t hurt sales and may actually help: https://www.engadget.com/2017-09-22-eu-suppressed-study-pira...

Your facts have zero bearing on the decision to use from.

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

#89

Post by analognoise »

throwaway2048 wrote: post #77
analognoise wrote: post #72

Earlier quoted context omitted.

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.

The company spent a billion dollars over 4 years developing their new chips which, again, no professional has problems with.

So if you spent a billion dollars and had the livelihood of a few thousand people on your mind, would you protect that investment?

Let their "wisdom of the crowd" come up with a competitive chip that took a thousand highly trained engineers 4 years of 100% time and a billion dollars come up with their own version.

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

#90

Post by Ballas »

lnsru wrote: post #61
duskwuff wrote: post #50

Earlier quoted context omitted.

A lot of flash-based FPGAs are actually an SRAM FPGA with an internal flash die bonded to the configuration pins. The bitstream is harder to get to, but it's still available to a determined attacker.

Actel/Microsemi are very real Flash FPGAs while Altera/Intel MAX10 is SRAM FPGA with configuration Flash inside. Very nice and highly integrated chip, comfy development with it.

I'd rather start from sand than use Microsemi again...
Post reply on HN