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

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

>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

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.

But 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...