A Zero-overhead Flow for Security Closure

TL;DR

The paper addresses the lack of security-aware optimization in traditional ASIC design flows by proposing a zero-overhead security-closure methodology that preserves QoR while mitigating Hardware Trojan insertion and front-side probing/fault injection threats. The authors implement a three-stage flow—IMP (initial optimization), TI (Trojan-insertion mitigation), and FSPFI (front-side probing and fault injection mitigation)—as TCL scripts within Cadence Innovus, designed to work with commercial P&R tools. Their approach yields competitive or best-known results on ISPD’22 benchmarks with negligible PPA overhead and full DRC compliance, demonstrated across both small benchmarks and a large 64-node MSP430 array. The work is complemented by open-source tooling and protected-design databases, underscoring practical applicability and community impact for hardware security in industry settings.

Abstract

In the traditional Application-Specific Integrated Circuit (ASIC) design flow, the concept of timing closure implies to reach convergence during physical synthesis such that, under a given area and power budget, the design works at the targeted frequency. However, security has been largely neglected when evaluating the Quality of Results (QoR) from physical synthesis. In general, commercial place & route tools do not understand security goals. In this work, we propose a modified ASIC design flow that is security-aware and, differently from prior research, does not degrade QoR for the sake of security improvement. Therefore, we propose a first-of-its-kind zero-overhead flow for security closure. Our flow is concerned with two distinct threat models: (i) insertion of Hardware Trojans (HTs) and (ii) physical probing/fault injection. Importantly, the flow is entirely executed within a commercial place & route engine and is scalable. In several metrics, our security-aware flow achieves the best-known results for the ISPD`22 set of benchmark circuits while incurring negligible design overheads due to security-related strategies. Finally, we open source the entire methodology (as a set of scripts) and also share the protected circuits (as design databases) for the benefit of the hardware security community.

Figures (10)

• Figure 1: Implementation flow utilized in this work along with the security-aware steps.
• Figure 2: DES scores as the design evolves.
• Figure 3: Layouts for SPARX, measuring 140.4 µm by 143.4 µm. Wires are omitted for clarity. Red areas are empty regions that are vulnerable to the TI threat. Brown cells are nudged horizontally. Blue cells are pushed vertically. (a) Layout before TI strategy; (b) Layout after TI strategy, containing zero TI vulnerable zones
• Figure 4: Layouts for AES_2, measuring 191.6 µm by 192.4 µm. (a) Layout before FSPFI strategy; (c) Layout after FSPFI strategy. Except for M10 and M9, all other layers are omitted. (b) Routing congestion before FSPFI strategy; (d) Routing congestion after FSPFI strategy. Rectangles correspond to grid cells measuring 1.4µm by 1.4µm and are colored according to routing resource availability: -5, -4, -3, -2, -1, -0.
• Figure 5: Wirelength per metal layer for the AES_2 benchmark.