Biblio
Filters: Author is Ender, Maik [Clear All Filters]
A Cautionary Note on Protecting Xilinx’ UltraScale(+) Bitstream Encryption and Authentication Engine. 2022 IEEE 30th Annual International Symposium on Field-Programmable Custom Computing Machines (FCCM). :1–9.
.
2022. FPGA bitstream protection schemes are often the first line of defense for secure hardware designs. In general, breaking the bitstream encryption would enable attackers to subvert the confidentiality and infringe on the IP. Or breaking the authenticity enables manipulating the design, e.g., inserting hardware Trojans. Since FPGAs see widespread use in our interconnected world, such attacks can lead to severe damages, including physical harm. Recently we [1] presented a surprising attack — Starbleed — on Xilinx 7-Series FPGAs, tricking an FPGA into acting as a decryption oracle. For their UltraScale(+) series, Xilinx independently upgraded the security features to AES-GCM, RSA signatures, and a periodic GHASH-based checksum to validate the bitstream during decryption. Hence, UltraScale(+) devices were considered not affected by Starbleed-like attacks [2], [1].We identified novel security weaknesses in Xilinx UltraScale(+) FPGAs if configured outside recommended settings. In particular, we present four attacks in this situation: two attacks on the AES encryption and novel GHASH-based checksum and two authentication downgrade attacks. As a major contribution, we show that the Starbleed attack is still possible within the UltraScale(+) series by developing an attack against the GHASH-based checksum. After describing and analyzing the attacks, we list the subtle configuration changes which can lead to security vulnerabilities and secure configurations not affected by our attacks. As Xilinx only recommends configurations not affected by our attacks, users should be largely secure. However, it is not unlikely that users employ settings outside the recommendations, given the rather large number of configuration options and the fact that Security Misconfiguration is among the leading top 10 OWASP security issues. We note that these security weaknesses shown in this paper had been unknown before.
How Not to Protect Your IP – An Industry-Wide Break of IEEE 1735 Implementations. 2022 IEEE Symposium on Security and Privacy (SP). :1656–1671.
.
2022. Modern hardware systems are composed of a variety of third-party Intellectual Property (IP) cores to implement their overall functionality. Since hardware design is a globalized process involving various (untrusted) stakeholders, a secure management of the valuable IP between authors and users is inevitable to protect them from unauthorized access and modification. To this end, the widely adopted IEEE standard 1735-2014 was created to ensure confidentiality and integrity. In this paper, we outline structural weaknesses in IEEE 1735 that cannot be fixed with cryptographic solutions (given the contemporary hardware design process) and thus render the standard inherently insecure. We practically demonstrate the weaknesses by recovering the private keys of IEEE 1735 implementations from major Electronic Design Automation (EDA) tool vendors, namely Intel, Xilinx, Cadence, Siemens, Microsemi, and Lattice, while results on a seventh case study are withheld. As a consequence, we can decrypt, modify, and re-encrypt all allegedly protected IP cores designed for the respective tools, thus leading to an industry-wide break. As part of this analysis, we are the first to publicly disclose three RSA-based white-box schemes that are used in real-world products and present cryptanalytical attacks for all of them, finally resulting in key recovery.