Standardizing Bad Cryptographic Practice: A Teardown of the IEEE Standard for Protecting Electronic-design Intellectual Property
Animesh Chhotaray, Adib Nahiyan, Thomas Shrimpton, Domenic Forte, Mark Tehranipoor
Abstract
We provide an analysis of IEEE standard P1735, which describes methods for encrypting electronic-design intellectual property (IP), as well as the management of access rights for such IP. We find a surprising number of cryptographic mistakes in the standard. In the most egregious cases, these mistakes enable attack vectors that allow us to recover the entire underlying plaintext IP. Some of these attack vectors are well-known, e.g. padding-oracle attacks. Others are new, and are made possible by the need to support the typical uses of the underlying IP; in particular, the need for commercial system-on-chip (SoC) tools to synthesize multiple pieces of IP into a fully specified chip design and to provide syntax errors. We exploit these mistakes in a variety of ways, leveraging a commercial SoC tool as a black-box oracle. In addition to being able to recover entire plaintext IP, we show how to produce standard-compliant ciphertexts of IP that have been modified to include targeted hardware Trojans. For example, IP that correctly implements the AES block cipher on all but one (arbitrary) plaintext that induces the block cipher to return the secret key. We outline a number of other attacks that the standard allows, including on the cryptographic mechanism for IP licensing. Unfortunately, we show that obvious "quick fixes" to the standard (and the tools that support it) do not stop all of our attacks. This suggests that the standard requires a significant overhaul, and that IP-authors using P1735 encryption should consider themselves at risk.
Ask about this paper
Your agent reads all of it.
Lune indexed this paper to the last equation, along with the top-tier papers that cite it. Ask a question and the answer quotes them.
Cited by top-tier papers1
Ask how each one uses itBuilds on1
Related papers
- FuncTeller: How Well Does eFPGA Hide Functionality?Zhaokun Han, Mohammed Shayan, Aneesh Dixit, Mustafa M. Shihab et al.USENIX Security 2023
- Fortifying RTL Locking Against Oracle-Less (Untrusted Foundry) and Oracle-Guided AttacksNimisha Limaye, Animesh Basak Chowdhury, Christian Pilato, Mohammed Thari Nabeel et al.DAC 2021 · 28 citations
- Provably-Secure Logic Locking: From Theory To PracticeMuhammad Yasin, Abhrajit Sengupta, Mohammed Thari Nabeel, Mohammed Ashraf et al.CCS 2017 · 323 citations
- On the Power of Optical Contactless Probing: Attacking Bitstream Encryption of FPGAsShahin Tajik, Heiko Lohrke, Jean-Pierre Seifert, Christian BoitCCS 2017 · 116 citations
- O'clock: lock the clock via clock-gating for SoC IP protectionM. Sazadur Rahman, Rui Guo, Hadi Mardani Kamali, Fahim Rahman et al.DAC 2022 · 20 citations
