7 ms·
A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs
- Nokinside 6y agoThis is not small issue. Up to 10% of FPGA's in the market can be affected. RAID-, SATA-, NIC- controllers, Industrial control systems, mobile base stations, data centers, devices like encrypted USB sticks and HDD's. In some cases it's possible to carry the attack remotely.
- REPLicated2 6y agoDepending on your viewpoint, this may actually be a boon for reverse engineering efforts to counter planned obsolescence.
- segfaultbuserr 6y agoYes. Unfortunately, it's a double-edged sword. The same technology is needed for the FOSS community to create secure hardware.
- snvzz 6y agoSecurity through obscurity? Nah.
- loeg 6y agoThis 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.
- snvzz 6y agoThere'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.
- johncolanduoni 6y agoThis mechanism also included an HMAC, responsible for authenticating the bitstream. That's useful even if the bitstream is public knowledge.
- baybal2 6y agoOnly ones who need to keep firmwares secret will be affected. There are few companies I knew who transitioned from MCUs to FPGAs solely for their obsession of keeping their "IP" from leaking, hoping that FPGA will provide more obscuration than simple encrypted MCU firmware.
- Nokinside 6y agoIf 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.
- firmnoodle 6y agoIt's more like access to replace the bitsteam. It's a complicated and expensive new attack vector.
- DarkmSparks 6y agoyeah, with a cheap and easy attack vector like this especially with a remote option this is one of the worst hardware compromises Ive seen in a while.
- alexdowad 6y agoBut if an attacker is already "inside" your system and is able to access the interface for configuring the FPGA, I think you have already lost...
- DarkmSparks 6y agoHe bought the FPGA, modified it, and sold you a compromised one.
- Nokinside 6y agoAttacker 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.
- stragies 6y agoCan your post be read as "In the near future, we might have the possibility of inspecting/re-programming a bunch of DMA--capable devices commonly found in systems"? That would be great. I shudder to think what horrors may await us in USB-/Wifi-/Network-controller bit-streams/firmwares. But the sooner these things get opened, the better.
- jtaft 6y agoFrom the paper: > On these devices, the bitstream encryption provides authenticity by using an SHA-256 based HMAC and also provides confidentiality by using CBC-AES-256 for encryption > We identified two roots leading to the attacks. First, the decrypted bitstream data are interpreted by the configuration logic before the HMAC validates them. Second, the HMAC key is stored inside the encrypted bitstream
- lallysingh 6y agoSo can I use this hack to use open source tools on these FPGAs?
- firmnoodle 6y agoNo. 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.
- londons_explore 6y agoSome FPGA's require bitstream encryption. On those devices, breaking this encryption is the first of many steps to making an opensource toolchain
- floatingatoll 6y agoAnd 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?
- eqvinox 6y agoThis 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/ http://www.clifford.at/yosys/
- lnsru 6y agoIf I would really care about security, I would not pick SRAM FPGA in the first place. The are nice Flash based FPGAs out there for projects with high security requirements. They don’t need configuration devices leaking bitstream all over the place. On the other hand is somehow sad, that popular 7 series is compromised. Though I never saw a company, that cared about bitstream security. It was best case “nice to have” feature, usually being completely ignored.
- duskwuff 6y agoA 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.
- segfaultbuserr 6y agoIt'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 speaking, FPGAs are generally a better and more secure option as a hardware platform than microcontrollers (for example, see the talk [0] by Peter Todd on Bitcoin hardware wallet and pitfalls of general-purpose microcontrolles), because of three advantages: * It's possible to implement custom security protections at a lower level than accepting whatever is provided by a microcontroller or implementing it in more vulnerable software. * Many microcontrollers can be copied easily, but FPGAs are often used to run sensitive bitstream that contains proprietary hardware/software, manufacturers generally provide better security protections, such as verification and encryption, against data extraction (read: OpenPGP private key) and manipulation attacks. * Most "secure" microcontrollers are guarded under heavy NDAs, while they are commercially available (and widely used in DRM systems), but it's essentially useless for the FOSS community. On the other hand, because the extensive use of FPGA in commercial systems, security is NDA-free for many FPGAs. It's often the best (or the only option) that provides the maximum transparency - not everything can be audited, sure, but the other option is using a "secure" blackbox ASIC, which is a total blackbox. Unfortunately, nothing is foolproof, manufacturers leave secret debug interfaces, cryptographic implementations have vulnerabilities, etc. Hardware security is a hard problem - 100% security and independent verification is impossible, making it harder to attack is the objective, but it's worse than software - once a bug is discovered and published, the cost of an attack immediately becomes 0, and it cannot be patched. We can only hope that the increased independent verification, like the researchers behind this paper, can somewhat reduce these problems systematically. [0] https://www.youtube.com/watch?v=r1qBuj_sco4 https://www.youtube.com/watch?v=r1qBuj_sco4
- eqvinox 6y agoThe 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.
- deleted 6y ago[deleted]
- LeifCarrotson 6y agoWhile this does open up the code (sans descriptive text) to external attacks, I rather feel that once you have a logic analyzer or compromised microcontroller on the logic bus of your secure device you've got the attacker on the wrong side of the airtight hatchway. I'm personally much more interested in what it means for 'attackers' who wish to use it to open up their own hardware. Perhaps that might not align with the goals of Xilinx or the OEM, but it's great for their customers!
- Nokinside 6y agoAttacker 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.
- IshKebab 6y agoI'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.
- nebulous1 6y ago> 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
- teraflop 6y agoAs 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 that this attack doesn't appear to actually let someone extract the AES encryption key. But they can use an FPGA that has the key programmed as a decryption oracle. And a weakness of CBC mode is that a decryption oracle can be used for encryption as well.
- Nokinside 6y ago>3.5 Wrap-Up: What Went Wrong? >These two attacks show again that nowadays, cryptographic primitives hold their security assumptions, but their embedding in a real-world protocol is often a pitfall. Two issues lead to the success of our attacks: First, the decrypted data are interpreted by the configuration logic before the HMAC validates them. Generally, a malicious bitstream crafted by the attacker is checked at the end of the bitstream, which would prevent an altered bitstream content from running on the fabric. Nevertheless, the attack runs only inside the configuration logic, where the command execution is not secured by the HMAC. Second, the HMAC key K_HMAC is stored inside the encrypted bitstream. Hence, an attacker who can circumvent the encryption mechanism can read K_HMAC and thus calculate the HMAC tag for a modified bitstream. Further, they can change K_HMAC, as the security of the key depends solely on the confidentiality of the bitstream. The HMAC key is not secured by other means. Therefore, an attacker who can circumvent the encryption mechanism can also bypass the HMAC validation
- ATsch 6y agoThis 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.
- loeg 6y agoFor others following along: https://moxie.org/blog/the-cryptographic-doom-principle/ https://moxie.org/blog/the-cryptographic-doom-principle/ (2011)
- brokenmachine 6y agoThat was really interesting, thanks for that.
- alexdowad 6y agoOnce 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 about $10,000 per job. They listed the chips they knew how to crack, but the one my employer was using was not on the list... I feel that trying to prevent reverse-engineering by adversaries with unlimited physical access is a fool's errand. So this break of Xilinx FPGAs is interesting... But kind of a shoulder shrug.
- WrtCdEvrydy 6y agoI wonder if classic chip-off methods would work (they no longer work on mobile devices due to encryption advances)
- grogenaut 6y agoHaving evaluated implemting game drm many times this nuance may or may not matter to the business. Most drm is a house of cards that a determined attacker can take out. It's still very widely used for good and bad reasons. And a lot of those reasons are not closely tied to the strength of a given implementation.
- Teknoman117 6y agoThe DRM only has to function during the time where most sales occur for it to be worth it.
- pmiller2 6y agoExcept that piracy doesn’t hurt sales and may actually help: https://www.engadget.com/2017-09-22-eu-suppressed-study-piracy-no-sales-impact.html https://www.engadget.com/2017-09-22-eu-suppressed-study-pira...
- 6y ago
- SlowRobotAhead 6y agoThe number of people glossing over his to take a bitstream which is the gate configuration of the fabric and read it back to human logic like Verilog is extremely few people and always a lot of time. This is a big issue for cloning though. Oh AES CBC, when will you stop disappointing!?
- krilovsky 6y agoI 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.
- Nokinside 6y agoThis attack breaks the encrypted and authenticated bitstream. I thought that the title "A Full Break of the Bitstream Encryption of Xilinx 7-Series FPGAs" would give some information even for those who don't want to read the article before commenting. :)
- teraflop 6y agoAs the paper explains, the attack requires alternately tampering with the encrypted bitstream (to write one word of the decrypted data at a time to a non-volatile register) and then resetting the FPGA and loading a separate, attacker-created, unencrypted bitstream to read that register's contents. I don't know enough about Xilinx FPGAs to definitively say whether setting the fuse that OP mentions would prevent the attack, but it seems plausible.
- Nokinside 6y agoAttack can be used to encrypt bitstreams also. >3.4 Attack 2: Breaking Authenticity >Therefore the attacker can encrypt an arbitrary bitstream by means of the FPGA as a decryption oracle. The valid HMAC tag can also be created by the attacker, as the HMAC key is part of the encrypted bitstream. Hence, the attacker can set his own HMAC key inside the encrypted bitstream and calculate the corresponding valid tag. Thus, the attacker is capable of creating a valid encrypted bitstream, meaning the authenticity of the bitstream is broken as well
- krilovsky 6y ago
- eqvinox 6y agoThis 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.
- pmorici 6y agoThis 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.
- eqvinox 6y agoThe 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 checks on a batch of devices you receive, since it prevents the end user from verifying bitstream integrity. (The keys are device specific AFAIK, so the bitstream is device specific too, and signature public keys aren't known.) To establish trust, you ideally need an unencrypted, verifiable, signed bitstream. (An encrypted, signed bitstream with the keys available does not protect against manufacturer collusion; they can cooperate in sending you a tampered device. An unencrypted bitstream allows comparing a device you received against other devices around the planet.)
- pmorici 6y agoOn 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.
- voxadam 6y agoIs 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/ http://www.clifford.at/icestorm/
- detaro 6y agoIt's an optional feature, so I don't think so.
- q3k 6y agoNo. 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 https://github.com/SymbiFlow/prjxray [2] - https://github.com/daveshah1/nextpnr-xilinx https://github.com/daveshah1/nextpnr-xilinx
- deleted 6y ago[deleted]
- amelius 6y agoIt's such a sad situation. Why can't companies just provide all the necessary hardware info in the datasheet?
- nabla9 6y agoI don't know much about FPGA's but I tried to read the paper. Maybe someone can tell me if this is correct: Getting your hands to raw gate configuration helps with cloning. It's pita to reverse engineer. Any device that uses Xilinx 7 or Virtex 6 SPI or BPI Flash remote update is potentially fucked. There is HMAC in bitstream and no other authentication.
- nomanlagharipq 6y agoare ok with this mod ? please visit http://ntechappspk.blogspot.com/2020/04/boo-video-status-maker-apk-mod-all.html http://ntechappspk.blogspot.com/2020/04/boo-video-status-mak...
- userbinator 6y agoI 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?
- bb88 6y agoSo 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)
- black_puppydog 6y agoWoah, 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.
- chapplap 6y agoThis 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.