Hardware security research has evolved significantly over the past decade.

Earlier work focused heavily on discrete problems:

• Detecting hardware Trojans
• Protecting intellectual property through logic locking
• Preventing cryptographic side-channel leakage

While these topics remain important, a noticeable shift is happening.

Security is moving from isolated logic-level techniques toward architectural-level thinking.

From Add-On Security to Structural Security

Historically, security mechanisms were often treated as add-ons:

• Insert a locking mechanism
• Add a secure key block
• Detect suspicious logic after synthesis

Modern systems make this approach insufficient.

Today’s SoCs are:

• Deeply pipelined
• Highly concurrent
• Heterogeneous
• Dependent on complex memory hierarchies
• Built with shared resources across cores and accelerators

In such systems, the attack surface is not confined to malicious gates. It emerges from interactions.

Microarchitecture as the New Security Boundary

Recent academic research increasingly focuses on:

• Secure memory hierarchies
• Cache partitioning and isolation
• NoC-level security
• Information flow tracking
• Secure accelerator integration

This reflects an important realization:

Performance optimizations and architectural decisions often define the true security boundaries.

Side-channel leakage, for example, is frequently a byproduct of:

• Shared caches
• Arbitration policies
• Speculative execution
• Data-dependent timing behavior

These are architectural features, not simple logic errors.

AI Accelerators and Expanding Attack Surfaces

The rise of AI-specific hardware introduces new challenges:

• Protecting model weights stored in on-chip memory
• Preventing model extraction attacks
• Securing high-bandwidth interconnects
• Isolating workloads in heterogeneous systems

AI accelerators amplify concurrency and data movement, which in turn amplifies potential leakage surfaces.

Security research is increasingly adapting to this reality.

The Core Trend

Hardware security is becoming an architectural discipline.

It is no longer sufficient to verify functional correctness or insert defensive logic late in the design cycle.

Security must be reasoned about alongside:

• Memory design
• Resource sharing
• Interconnect topology
• Privilege separation
• Lifecycle management

As silicon complexity grows, security becomes a property of system behavior over time, not just gate-level correctness.

Looking Ahead

Future research directions likely include:

• Security-aware AI accelerators
• Chiplet and 3D integration trust models
• Runtime hardware monitoring
• Formal security verification at system scale

The most interesting work will not be isolated techniques.

It will be the integration of security principles into the architectural foundation of modern silicon.

If you read any hardware Trojan research, you will keep seeing one phrase again and again: rare nets.
They show up in Trust-Hub benchmarks, detection algorithms, research papers, and almost every Trojan insertion strategy.

This post explains:

• What rare nets actually are
• Why attackers target them
• How designers and researchers can detect Trojans using rare-net analysis
• How this connects to my ongoing experiments with switching activity and power traces

This is a beginner-friendly overview, and you can follow along even if you’re new to hardware security.

1. What Are Rare Nets?

A rare net is a signal in a digital circuit that toggles very infrequently during normal operation.

For example:

• A net that switches once every few thousand cycles
• A deep internal signal far from primary inputs
• Control logic that activates only in edge cases
• Reset or debug-related signals
• Rare combinations of internal states

In many circuits, most signals toggle frequently.
But a few remain quiet or almost never active.

These low-activity nets are the perfect hiding spots for Trojans.

2. Why Trojans Love Rare Nets

Attackers insert hardware Trojans in places where they will not be triggered accidentally during testing or normal operation.

Rare nets give them exactly what they want:

• High Stealth

Low toggle probability means test vectors rarely activate them.

• Predictable Silence

These nets almost never switch, so a Trojan tied to them is nearly invisible.

• Stable Trigger Conditions

Attackers can tie Trojan triggers to specific rare-net patterns (like A & B & C = 1), making accidental activation unlikely.

• Minimal Power Footprint

Since rare nets rarely toggle, the Trojan’s trigger circuitry also consumes very little dynamic power.

• Hard to Reach Through Testing

Functional testbenches and ATPG often fail to activate these nets because they require deep state exploration.

In summary:
Rare nets allow Trojans to hide quietly until a highly specific trigger activates them.

3. How Rare Nets Help in Detecting Trojans

Interestingly, the same property that makes rare nets good hiding spots also helps in detection.

1. Low Baseline Activity = High Sensitivity

If a net rarely toggles, any unusual activity stands out immediately.

2. Power Deviations Become Noticeable

Even small Trojan-induced switching creates measurable transient spikes.

3. Useful for Switching Activity Comparison

Comparing toggle density before and after Trojan insertion highlights suspicious nets.

4. Enable Structural Analysis

Tools can mark nets with VS (Very Small) toggle probability and examine logic cones around them.

5. Combine Well with Logic Locking

Logic locking further reduces random switching, which amplifies anomalies in rare nets (based on the paper I summarized).

4. How to Identify Rare Nets

You can identify rare nets using:

• Simulation-Based Analysis

Generate VCD or SAIF files and compute toggle counts.

• ATPG and Signal Probability Tools

Use probabilistic models to detect rarely activated internal nodes.

• Test Vector Analysis

Compare switching activity under different workloads.

• Structural Metrics

Deep logic cones and unreachable states correlate with rare nets. —

5. How Attackers Use Rare Nets

Attackers typically attach Trojan triggers to:

• Deep combinational nodes
• Low-frequency control paths
• Unused internal states
• FSM states that never occur in normal operation
• Signals tied to debug or test modes

A simple Trojan example:

if (rare_net1 & rare_net2) begin
    payload_reg <= payload_reg ^ 1'b1;
end

6. How Rare-Nets Factor Into My Research

Rare-net analysis is central to the experiments I am running:

• Inserting Trojans into rare nets
• Comparing switching activity in locked vs unlocked designs
• Analyzing toggle differences in clean vs Trojan versions
• Measuring power trace deviations
• Understanding how logic locking reshapes switching cones

This aligns directly with research papers on:

• Switching-activity-based detection
• Transient power signatures
• Structural Trojan detection
• Logic locking + Trojan interactions

I will be publishing these experiments in my GitHub repository soon.

If you’re interested in hardware Trojans, switching activity, or logic locking, follow my Research Notes section here: 👉 research notes

Thanks for reading! Feel free to reach out if you have questions or want a post on a specific topic. —

Strengthening integrated circuits against untrusted manufacturing and Trojan insertion.

1. Introduction

As semiconductor manufacturing becomes more global, securing the design and fabrication flow has become an important concern. Most design companies use the fabless model, which means fabrication happens in external foundries. This introduces two risks:

1. Unauthorized overproduction or IP theft
2. Hardware Trojan insertion during mask preparation or ECO steps

Logic locking introduces key controlled gates into an ASIC so the chip works correctly only when the correct key is applied. It protects IP and increases the difficulty of malicious modification.

2. What is Logic Locking

Logic locking adds extra gates into a circuit that depend on a secret key. Without the key, the circuit produces incorrect outputs.

Common key gate types

• XOR or XNOR gates
• MUX based key gates
• Anti SAT blocks
• SFLL (Stripped Functionality Logic Locking)

3. Simple XOR Based Locking Example

Original RTL:

assign Y = A ^ B;

If Key[0] is zero, the circuit behaves normally. If Key[0] is one, the output is flipped and downstream behavior is corrupted.

Even this small modification breaks straightforward cloning and reverse engineering.

4. Structural Impact of Locking

Adding locking logic affects several structural properties of the netlist:

1. fan out of selected signals
2. depth of some logic cones
3. switching patterns on internal nodes
4. placement of new gates in critical or non critical paths

These structural changes:

1. make reverse engineering harder
2. change where an attacker might try to insert a Trojan
3. can be used as additional signals in detection

5. How Locking Helps Detect Hardware Trojans

Hardware Trojans often rely on:

• rare internal trigger conditions
• very low switching activity when inactive
• payloads that blend into existing logic
• predictable and stable structure
• Logic locking disrupts these assumptions.

Locking can:

• increase switching entropy around key controlled regions
• make power signatures less predictable for attackers
• force Trojans to interact with key logic to remain effective
• expose malicious structures when the wrong key is applied

When combined with switching activity localization or power analysis, this improves Trojan detectability.

6. Power Analysis Overview

Power based detection uses the fact that Trojans cause small but measurable changes in switching activity.

A simplified power model:

P_total = P_static + P_dynamic P_dynamic ∝ C_load * V^2 * f * switching_activity

Locked circuits already modify switching activity. When a Trojan activates, the deviation from the locked baseline can stand out more clearly.

Typical analysis flow:

1. Run simulation on a golden (Trojan free) design
2. Run simulation on a design under test
3. Generate VCD or SAIF files with switching activity
4. Convert toggles into power traces using synthesis or gate level tools
5. Compare traces across test vectors
6. Localize suspicious regions or time windows

7. MUX Based Lock Example

To avoid simple attacks that target XOR structures, many schemes use MUX based locking.

Example:

assign Y = Key[i] ? real_signal : dummy_signal;

• Correct key selects real_signal and the design behaves correctly.
• Incorrect key selects dummy_signal and the behavior is corrupted.

Properties of MUX based locking:

1. harder for SAT solvers to simplify in some cases
2. creates more structural ambiguity
3. can be aligned with existing multiplexed datapaths

8. SAT Attack Notes

SAT attacks try to recover the secret key by generating discriminating input patterns that eliminate incorrect keys.

Basic idea:

1. Treat the locked circuit as a black box with key inputs.
2. Use a SAT solver to search for input patterns that behave differently under different keys.
3. Iteratively narrow down the key space until the correct key is found
4. Ways to strengthen locking against SAT attacks
5. deeper and more distributed locking
6. Anti SAT and SARLock style blocks
7. SFLL mechanisms with rare corruptibility
8. structural transformations after locking
9. removal of obvious XOR key patterns
10. mixing multiple locking styles

The goal is to make the search space and solver effort impractical.

9. RTL Example of a Locked Module

Below is a small example that shows how key bits can corrupt internal nodes.

module locked_and4(
    input  wire [3:0] A,
    input  wire [3:0] Key,
    output wire Y
);
    wire temp0, temp1;

    assign temp0 = A[0] & A[1];
    assign temp1 = A[2] & A[3];

    // Insert XOR based key gates
    assign Y = (temp0 ^ Key[0]) & (temp1 ^ Key[1]);
endmodule

This design:

• behaves correctly only when Key[0] and Key[1] match the intended values
• corrupts the output for incorrect keys
• introduces new logic cones and switching patterns

10. Engineering Guidelines for Logic Locking

Some practical guidelines when applying locking in real flows:

1. distribute key gates across different blocks instead of clustering them
2. avoid adding locks only at outputs, which is easier to attack
3. combine logic locking with scan chain obfuscation and secure test
4. use synthesis remapping to hide simple locking patterns
5. avoid locking the most timing critical paths
6. evaluate area, power, and timing overhead for each scheme
7. test golden versus locked designs with realistic workloads

11. Tools and Frameworks

Common tools used for logic locking and evaluation include:

1. Yosys for open source synthesis and simple flows
2. Commercial tools like Synopsys Design Compiler and Cadence Genus
3. TrustHub benchmarks for hardware Trojan evaluation
4. SAT attack frameworks for key recovery experiments
5. PrimeTime PX or similar tools for power estimation
6. Python scripts for VCD parsing and trace analysis

These can be combined into reproducible experiments in a public GitHub repository.

12. Conclusion

Logic locking is a practical and flexible method for protecting integrated circuits built in untrusted environments. It raises the difficulty of cloning and reverse engineering and can improve hardware Trojan detection when combined with structural and power based analysis.

As semiconductor supply chains remain globally distributed, design for trust techniques like logic locking will continue to be an important part of secure hardware design.

This page is part of a larger set of hardware security and ASIC design notes.

The key idea is simple. The original design is correct, but an extra piece of logic is inserted that only activates under rare conditions. Under normal tests, the chip seems fine. Under a special trigger, that extra logic can leak data, change outputs, or weaken security checks.

In practice, a hardware Trojan often has two parts:

1. A trigger that watches for a rare event, such as a specific input pattern or internal state.
2. A payload that changes behavior, for example by flipping a bit, opening a backdoor, or bypassing a check.

Because the trigger is rarely activated, normal testing and functional verification may never see the Trojan fire. This is what makes these attacks interesting and hard to catch.

In my Hardware Trojan Lab series I work with very small RTL examples that show how this looks in code. A baseline module behaves as expected, and a Trojan version adds a few lines of Verilog that implement a rare trigger and a small payload. By running both through simulation and comparing waveforms, you can see exactly when the Trojan activates.

If you want a starting point to explore these ideas, you can:

• Look at the baseline and Trojan inserted designs in my lab repo.
• Compare their simulation behavior and switching activity.
• Read the companion logic locking guide to see how designers can try to protect against untrusted modifications.

Hardware Trojans are a deep research area, but even simple examples are enough to build intuition about how hardware can be attacked and how we might defend it.