Papers
Topics
Authors
Recent
Search
2000 character limit reached

Zero-Overhead Flow for Security Closure

Updated 7 July 2026
  • The paper introduces a security-aware flow that integrates post-route ECO transformations to harden ASIC layouts against Trojan insertion and front-side probing without affecting design quality.
  • The methodology uses localized cell movements and per-net routing adjustments within a commercial place-and-route engine to maintain zero DRC, positive slack, and near-baseline power, performance, and area.
  • Evaluation on ISPD’22 benchmarks confirmed the elimination of vulnerable regions and demonstrated negligible overhead, validating the approach as both practical and design-agnostic.

“Zero-Overhead Flow for Security Closure” denotes a security-aware ASIC physical-synthesis methodology in which security is treated as a closure target alongside timing, but without degrading conventional Quality of Results. In the formulation introduced for commercial place-and-route, “security closure” means hardening the physical layout against two specific threat classes—fabrication-time hardware Trojan insertion and post-silicon front-side probing/fault injection—while preserving zero DRC, positive slack, and essentially unchanged power, performance, and area behavior. The flow is executed entirely inside a commercial place-and-route engine, is design-agnostic, and was evaluated on the ISPD’22 benchmark set with negligible design overheads due to security-related strategies (Eslami et al., 23 Jul 2025).

1. Security closure as a physical-design objective

In conventional ASIC implementation, timing closure is the condition under which physical synthesis converges so that the design meets a target frequency under area and power budgets, with no signoff violations. “Security closure” extends this notion to post-design hardening of the physical layout. The central claim is not that commercial place-and-route tools natively optimize security, but rather that security objectives can be introduced through scripted constraints and ECO-style transformations that preserve ordinary signoff requirements (Eslami et al., 23 Jul 2025).

The flow adopts the ISPD’22 scoring model. The overall score is

Score=DES×(TI+FSPFI)2\text{Score} = \text{DES} \times \frac{(\text{TI} + \text{FSPFI})}{2}

where DES is the normalized design-quality term and the security term is the average of TI and FSPFI. The paper specifies the corresponding weights as follows: DesignQuality == 0.1×0.1 \times power ++ 0.3×0.3 \times performance ++ 0.3×0.3 \times area ++ 0.3×0.3 \times DRC issues, all normalized against the baseline layouts; Security == ==0 FSPFI ==1 ==2 TI; TI itself weights exploitable placement sites and free routing tracks as ==3 and ==4, while FSPFI weights exposed cell-asset area and net-asset area equally. Lower scores are better (Eslami et al., 23 Jul 2025).

A common misconception is to read “zero-overhead” as meaning that no security-driven layout changes occur. The paper instead uses the term to denote that the security-aware flow maintains zero or negligible overhead in DES while enforcing stricter physical-security objectives. The hard constraints remain zero DRC and positive slack throughout the flow (Eslami et al., 23 Jul 2025).

2. Threat models and security metrics

The first threat model is hardware Trojan insertion at fabrication time. The attacker exploits continuous empty placement sites to place malicious circuitry and available routing tracks to connect it. The TI metric therefore targets “vulnerable regions,” defined as contiguous empty placement sites of size at least ==5 sites, together with the free routing tracks around them. The stated TI objective is to eliminate such regions so that Trojan insertion becomes physically infeasible under the contest model (Eslami et al., 23 Jul 2025).

The second threat model is front-side probing and fault injection. The adversary is post-silicon and accesses metal layers from the front side using tools such as focused ion beam or microprobing. The paper explicitly notes that backside techniques exist, but the protected threat surface and scoring model concern front-side exposure. In the ISPD formulation, FSP and FI are co-scored through the “exposed area” of declared cell and net assets accessible from the front metal stack. Reducing that exposed area is the operational definition of FSPFI hardening (Eslami et al., 23 Jul 2025).

These two metrics intentionally reflect different physical mechanisms. TI is placement-centric: it attacks unused spatial slack in the standard-cell rows and nearby routing resources. FSPFI is routing-centric: it attacks the visibility of assets through the metal stack. This separation explains the structure of the methodology, which first removes vulnerable regions through localized placement changes and then reduces exposure through routing-layer manipulation and shielding (Eslami et al., 23 Jul 2025).

The scope is deliberately limited. The paper acknowledges backside probing but does not directly mitigate it in the scoring framework. It also depends on declared assets: if sensitive nets or cells are incomplete or misdeclared, the optimization may leave relevant signals unprotected. This suggests that “security closure” in this setting is precise with respect to the ISPD’22 threat models rather than a universal physical-security guarantee (Eslami et al., 23 Jul 2025).

3. Commercial P&R flow and algorithmic structure

The implementation uses Cadence Innovus v21.16 with the Nangate 45 nm Open Cell Library on the ISPD’22 benchmarks. The reported server platform is a Xeon Silver 4208 with 128 GB RAM. The methodology is fully embedded in the commercial place-and-route engine rather than layered on top of exported DEF or GDSII transformations (Eslami et al., 23 Jul 2025).

The flow begins with an implementation stage focused on conventional PPA. Its steps are: technology and tool settings without per-design customization; floorplan and power plan with minimum feasible area that still meets timing without DRC; placement and pre-CTS optimization; if setup is violated, increase setup effort margin by ==6 ps and re-optimize; CTS and post-CTS optimization; routing, with rerouting if DRCs remain; slack check, followed by power optimization if slack is positive or timing-oriented post-route optimization otherwise; then post-route optimization is iterated until no further improvement. The resulting routed design becomes the input to the security steps (Eslami et al., 23 Jul 2025).

The TI strategy is an iterative post-route ECO procedure. It identifies vulnerable regions and removes them through local cell movements toward the center of each region. Horizontal “nudges” move cells within the same row by one site. Vertical “pushes” move cells by one site height and are followed by legalization through eco_place. A final opt_design is used for cleanup. The movement policy alternates between nudges and pushes with a stuck counter to avoid oscillation (Eslami et al., 23 Jul 2025).

The FSPFI strategy is divided into two routing-centric phases. Phase A computes exposure, ranks net assets by factor = net.area × net.exp_perc, and for the top NETS_PER_RD assets per round sets preferred_layers.bot = M1 and preferred_layers.top = M_TOP, followed by route_detail. Exposure is recomputed, and the process stops when no further improvement occurs. Phase B starts from TOP_METAL and progressively widens non-asset nets with NDRs on the current layer, subject to DRC. When check_drc fails, the flow returns the last DRC-clean layout (Eslami et al., 23 Jul 2025).

The following implementation constants are explicitly reported:

Parameter Value
SITE_SIZE 0.19 μm
SITE_HEIGHT 1.4 μm
STUCK_MAX 3
NETS_PER_RD 0.05% of total nets
M_TOP 4 (AES) / 3 (others)
TOP_METAL 10 (AES) / 6 (others)

These parameters are integral to the “design-agnostic” character of the methodology: a single set of settings is used across all 12 benchmarks without per-design retuning (Eslami et al., 23 Jul 2025).

4. Mechanisms that realize the zero-overhead claim

The TI mechanism hardens against Trojan insertion by removing the physical substrate on which the attacker depends. Instead of adding fillers, decaps, guard rings, or buffers, it performs localized cell movements and legalization. The paper explicitly states that no fillers/decaps or guard rings are required, no added buffering is introduced, and no area inflation is needed. Because these are ECO-style local modifications applied after routing, the perturbation to timing and routing is limited (Eslami et al., 23 Jul 2025).

The FSPFI mechanism combines two routing effects. Asset demotion to lower metals increases the chance that non-asset routing above those assets will cover them. Non-asset widening on upper metals then consumes routing tracks in a way that can shield underlying assets. The implementation uses per-net preferred-layer constraints and per-net NDR widths, applied incrementally and checked continuously with route_detail and check_drc (Eslami et al., 23 Jul 2025).

This combination explains the paper’s use of “zero-overhead.” No explicit multi-objective cost function is injected into the commercial optimizer. Instead, the method uses security-oriented constraints and bounded ECO transformations that are stopped by physical-design signoff conditions. Phase A terminates when exposure ceases to improve, preventing asset nets from competing excessively for lower-metal resources. Phase B terminates at the first DRC appearance and returns the last clean layout, preventing the shielding process from turning into a routability regression (Eslami et al., 23 Jul 2025).

A second misconception is that the flow trades power, performance, or area for security and merely hides the loss inside a security metric. The methodology is designed precisely to avoid that outcome: zero DRC and positive slack are maintained, and DES changes are tracked relative to the implementation baseline after the PPA-focused stage. The claim is therefore not “security at any cost,” but security under the existing signoff discipline (Eslami et al., 23 Jul 2025).

5. Evaluation on ISPD’22 benchmarks

The evaluation covers 12 benchmark designs: AES_1, AES_2, AES_3, CAMELLIA, CAST, MISTY, OMSP430_1, OMSP430_2, PRESENT, SEED, SPARX, and TDEA. The central validation result is that all vulnerable regions are eliminated for all 12 designs, meaning the final VR count is ==7 in every reported case (Eslami et al., 23 Jul 2025).

The DES overhead results are the quantitative basis for the “zero-overhead” terminology. Across all 12 benchmarks, the average overhead after the TI strategy is ==8, indicating a slight average improvement, and the average overhead after the FSPFI strategy is ==9. The worst case is 0.1×0.1 \times0 for AES_3 after FSPFI, identified as an outlier. The paper also notes that negative overhead cases reflect heuristic variability in the place-and-route engine (Eslami et al., 23 Jul 2025).

Against the ISPD’22 contest winner, the reported average area is lower by 0.1×0.1 \times1 and the reported average total power is lower by 0.1×0.1 \times2. Concrete examples include AES_1 with area reduced by 0.1×0.1 \times3 and total power reduced by 0.1×0.1 \times4, CAST with area reduced by 0.1×0.1 \times5 and total power reduced by 0.1×0.1 \times6, and MISTY with area reduced by 0.1×0.1 \times7 and total power reduced by 0.1×0.1 \times8. The overall average DES score is 0.1×0.1 \times9, compared with ++0 for the contest winner; lower is better (Eslami et al., 23 Jul 2025).

The FSPFI reductions are likewise reported per design. Examples include AES_1 from ++1 to ++2, AES_2 from ++3 to ++4, AES_3 from ++5 to ++6, SPARX from ++7 to ++8, and PRESENT from ++9 to 0.3×0.3 \times0. Density remains nearly unchanged; SPARX, for example, moves from 0.3×0.3 \times1 to 0.3×0.3 \times2 after TI and 0.3×0.3 \times3 after FSPFI (Eslami et al., 23 Jul 2025).

The paper also reports intermediate structural effects. For AES_2, TI barely changes metal usage across layers, whereas FSPFI redistributes wirelength and vias: middle-layer wirelengths increase modestly, such as 0.3×0.3 \times4, while upper layers decrease strongly, such as 0.3×0.3 \times5; via counts shift toward middle layers, with 0.3×0.3 \times6 from 0.3×0.3 \times7 to 0.3×0.3 \times8. Runtime is dominated by the implementation stage: for AES_2, IMP takes 0.3×0.3 \times9 s, TI ++0 s, and FSPFI ++1 s; for SPARX, TI takes ++2 s (Eslami et al., 23 Jul 2025).

6. Limitations, assumptions, and practical adoption

The protection scope follows the ISPD’22 contest formulation. Front-side probing and fault injection are modeled through exposed area, but backside probing is only acknowledged, not incorporated into the hardening objective. Asset protection depends on the organizer-declared asset list. Phase A may stop while some assets remain partly exposed if lower-metal resources are scarce, and Phase B is bounded by track availability because it halts at the first DRC violation (Eslami et al., 23 Jul 2025).

From a deployment perspective, the required environment is a commercial place-and-route engine with ECO place/route support, per-net preferred-layer constraints, and per-net NDR assignment APIs. The paper uses Innovus v21.16 and Nangate 45 nm, but the prescribed start points remain the reported parameters: SITE_SIZE and SITE_HEIGHT from the PDK site definition, NETS_PER_RD = 0.05% of total nets, M_TOP = 3–4 depending on the metal stack, and TOP_METAL as the top routing layer. The mandatory signoff checks are final DRC = 0 and slack > 0, with additional revalidation of STA and IR drop/EM after each security phase (Eslami et al., 23 Jul 2025).

The methodology is open sourced as the Security Closure Repository at https://github.com/Centre-for-Hardware-Security/security_closure, including TCL scripts, methodology, and protected design databases for the ISPD’22 benchmarks. The stated dependencies are a commercial Innovus installation and the ISPD scoring binaries for TI and FSPFI metrics (Eslami et al., 23 Jul 2025).

These constraints clarify what the paper means by scalability. The claim is not unlimited generality, but a design-agnostic flow that uses localized ECO transformations and avoids global replanning. This suggests a practical hardening path for commercial ASIC implementation flows in which security can be introduced without logic-level redesign or systematic PPA loss (Eslami et al., 23 Jul 2025).

7. Broader uses of the term in security research

The phrase “zero-overhead flow for security closure” also resonates with a broader class of results in which security invariants are preserved under composition or execution while added cost is reduced to zero or near zero. In serverless IFC, static labels on function activations combined with dynamic faceted labeling of persistent data are used to close high-bandwidth termination and storage covert channels while keeping runtime overhead low in practice; the security property is termination-sensitive non-interference (Alpernas et al., 2018).

In software-based fault isolation, the analogous concept is “zero-cost transitions”: ordinary function calls replace springboards and trampolines when local structural conditions such as callee-save restoration, well-bracketed control flow, type-directed forward-edge CFI, and local stack-frame encapsulation are satisfied. The result is described as a compositional notion of security closure, with VeriZero providing static verification that compiled binaries satisfy those conditions (Kolosick et al., 2021).

At the hardware level, a Variable Record Table unifies spatial memory safety, back-edge CFI, and speculative execution attack detection by checking runtime addresses and control transfers in parallel with the normal pipeline, with zero additional instruction overhead and zero-cycle overhead for legitimate paths in the evaluated 5-stage in-order pipeline (Sah et al., 14 Dec 2025). PAGURUS pursues a related near-zero-overhead objective for DIFT across loosely coupled accelerators through a coarse-grain shell, though it explicitly states that strictly zero overhead is unattainable because tags still have to be moved and checked (Piccolboni et al., 2019).

Other work draws the boundary of the concept more sharply. Hardware-assisted complete DFI reduces the overhead of original DFI from ++3 to ++4 on average on SPEC CPU2006 while preserving the full criterion, but does not claim zero overhead (Feng et al., 2021). Transparent IFC enforcement proves a stronger impossibility result: transparent enforcement is polynomial-time equivalent to multi-execution, and black-box enforcement is exponential in the number of principals, so truly zero-overhead transparent enforcement is unattainable in general (Algehed et al., 2020). By contrast, Filament attains zero runtime overhead for Denning-style static IFC in Rust because labels are phantom types erased at compile time, while compile-time overhead is reported as negligible in practice (Ching et al., 15 Apr 2026).

Taken together, these uses suggest that “security closure” has become a cross-domain term for preservation of security invariants under realistic composition rules, while “zero-overhead” denotes either literal elimination of wrapper-induced or runtime cost, or a negligibly small delta under a specified workload and threat model. In the ASIC setting, the phrase has a particularly concrete meaning: closure against HT insertion and FSP/FI within a commercial place-and-route flow, under zero DRC, positive slack, and essentially unchanged DES (Eslami et al., 23 Jul 2025).

Topic to Video (Beta)

No one has generated a video about this topic yet.

Whiteboard

No one has generated a whiteboard explanation for this topic yet.

Follow Topic

Get notified by email when new papers are published related to Zero-Overhead Flow for Security Closure.