ReGDS: A Reverse Engineering Framework from GDSII to Gate-level Netlist

Rajarathnam, Rachel Selina; Lin, Yibo; Jin, Yier; Pan, David Z.

doi:10.1109/host45689.2020.9300272

Cited by 29 publications

(14 citation statements)

References 21 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…To obtain a flat netlist, the wires between standard cells are identified by connecting overlapping conductive patterns (i.e. VIAs, wires, and contacts) [12]. The rerouted flat netlist is the final step of the physical RE process RR FN .…”

Section: B Physical Re -Packaged Ic To Netlistmentioning

confidence: 99%

CRESS: Framework for Vulnerability Assessment of Attack Scenarios in Hardware Reverse Engineering

Ludwig¹,

Hepp²,

Brunner³

et al. 2022

Preprint

View full text Add to dashboard Cite

Trust and security of microelectronic systems are a major driver for game-changing trends like autonomous driving or the internet of things. These trends are endangered by threats like soft- and hardware attacks or IP tampering -- wherein often hardware reverse engineering (RE) is involved for efficient attack planning. The constant publication of new RE-related scenarios and countermeasures renders a profound rating of these extremely difficult. Researchers and practitioners have no tools or framework which aid a common, consistent classification of these scenarios. In this work, this rating framework is introduced: the common reverse engineering scoring system (CRESS). The framework allows a general classification of published settings and renders them comparable. We introduce three metrics: exploitability, impact, and a timestamp. For these metrics, attributes are defined which allow a granular assessment of RE on the one hand, and attack requirements, consequences, and potential remediation strategies on the other. The system is demonstrated in detail via five case studies and common implications are discussed. We anticipate CRESS to evaluate possible vulnerabilities and to safeguard targets more proactively.

show abstract

Section: B Physical Re -Packaged Ic To Netlistmentioning

confidence: 99%

CRESS: Framework for Vulnerability Assessment of Attack Scenarios in Hardware Reverse Engineering

Ludwig¹,

Hepp²,

Brunner³

et al. 2022

Preprint

View full text Add to dashboard Cite

show abstract

“…Even if all EDA tool computations were to be performed in such a trusted environment, the result of the hardware design flow is either a bitstream file that configures an FPGA or a layout description for an ASIC. Crucially, both a bitstream [53, 56,59] and a layout [47] contain all information about an IP core as they are simply a different gate-level netlist representation. A determined adversary can extract the high-level functionality of an IP core through netlist analysis [2,39,40,52].…”

Section: B Thoughts On Ip Protection In Practicementioning

confidence: 99%

How Not to Protect Your IP -- An Industry-Wide Break of IEEE 1735 Implementations

Speith¹,

Schweins²,

Ender³

et al. 2021

Preprint

View full text Add to dashboard Cite

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.

show abstract

“…The adversary already possesses the first two, but must generate the third and estimate the fourth input. A gate-level netlist can be extracted from the victim's layout [22], while the timing constraint can be estimated to a certain degree. Our proposed trojan insertion framework is shown in Fig.…”

Section: Threat Model and Attacker Capabilitiesmentioning

confidence: 99%

“…Netlist extraction: since the attacker only holds the layout, a gate-level netlist has to be extracted. Such effort is considered a trivial task for an expert IC designer, demonstrated in [22]. Frequency estimation: the attacker has to estimate the operating frequency of the target circuit by performing static timing analysis on the extracted gate-level netlist.…”

Section: A Side-channel Trojan Designmentioning

confidence: 99%

Hardware Trojan Insertion in Finalized Layouts: a Silicon Demonstration

Perez¹,

Pagliarini²

2021

Preprint

View full text Add to dashboard Cite

Owning a high-end semiconductor foundry is a luxury very few companies can afford. Thus, fabless design companies outsource integrated circuit fabrication to third parties. Within foundries, rogue elements may gain access to the customer's layout and perform malicious acts, including the insertion of a hardware trojan (HT). Many works focus on the structure/effects of a HT, while very few have demonstrated the viability of their HTs in silicon. Even fewer disclose how HTs are inserted or the time required for this activity. Our work details, for the first time, how effortlessly a HT can be inserted into a finalized layout by presenting an insertion framework based on the engineering change order flow. For validation, we have built an ASIC prototype in 65nm CMOS technology comprising of four trojaned cryptocores. A side-channel HT is inserted in each core with the intent of leaking the cryptokey over a power channel. Moreover, we have determined that the entire attack can be mounted in a little over one hour. We also show that the attack was successful for all tested samples. Finally, our measurements demonstrate the robustness of our SCT against skews in the manufacturing process.

show abstract

ReGDS: A Reverse Engineering Framework from GDSII to Gate-level Netlist

Cited by 29 publications

References 21 publications

CRESS: Framework for Vulnerability Assessment of Attack Scenarios in Hardware Reverse Engineering

CRESS: Framework for Vulnerability Assessment of Attack Scenarios in Hardware Reverse Engineering

How Not to Protect Your IP -- An Industry-Wide Break of IEEE 1735 Implementations

Hardware Trojan Insertion in Finalized Layouts: a Silicon Demonstration

Contact Info

Product

Resources

About