Download the lecture slides for this week here: COMP6420_2026T1_Week8_RE_LL.pdf

COMP6420 Week 8 – Reverse Engineering and Logic Locking

1. Motivation: why protect hardware IP?

Modern IC supply chains are global, fragmented, and cost-driven, which introduces both economic and security risk (time-to-market pressure, high design complexity, many third parties).

Hardware IP exists in multiple forms, all valuable:

• Soft IP: RTL, ready for synthesis
• Firm IP: gate-level netlist
• Hard IP: physical layout (GDSII)
  Reusable, pre-verified IP costs real effort and money to create, so piracy and cloning have strong incentives.

Impacts include significant revenue loss (order-of-billions annually), loss of trust, and unreliable/unsafe consumer electronics.

2. Threats across the IC lifecycle

A convenient way to reason about piracy is to track a design as it moves through: Design → Synthesis → Netlist → Physical design → Layout/GDSII → Fabrication → Silicon → Testing.

Different attackers sit at different points:

• Foundry / manufacturing can overbuild (produce more chips than authorized).
• End users (or downstream adversaries) can use the functional chip as an oracle (apply inputs, observe outputs) and/or reverse engineer it physically.
• Reverse engineering can transform a physical chip back into a netlist through depackaging, delayering, imaging, and schematic/netlist reconstruction.

Design-for-test (DfT) is also relevant: many circuits effectively reduce to a scan chain + combinational netlist, and scan access can be enough to recover truth tables and duplicate functionality.

3. “Logic encryption” / logic locking: make the design useless without a key

Logic encryption (logic locking) inserts key gates so the circuit behaves correctly only when the correct key is applied; wrong keys intentionally corrupt outputs.

A basic pipeline:

• IP owner locks the netlist,
• fabrication produces non-functional chips (without correct activation),
• chips are activated by loading the key, becoming functional.

A practical key distribution/control question follows naturally:

• how keys reach customers,
• and how activation can control the number of usable ICs (metering).

EPIC-style activation framing

An activation approach includes multiple key types:

• CK: common key
• MK: master key
• RCK: random chip key
• IK: input key (chip-specific)

This supports scenarios such as:

• customers cannot activate extra chips beyond what they purchased (chip-specific keys differ),
• foundries cannot overbuild usable chips (no activation keys),
• stolen common keys alone are insufficient without the right master/private key process.

4. What “good” locking should achieve (metrics)

Two key security/quality objectives show up:

1. Outputs under wrong keys should look maximally corrupted
   A common metric is ~50% Hamming distance between correct-key and wrong-key outputs across inputs (roughly maximum uncertainty/entropy).

2. The key shouldn’t be learnable efficiently
   Key recovery should not be possible using only polynomially-many input/output pairs (i.e., it shouldn’t be easy to treat the chip as a black-box oracle and solve for the key).

5. Gate insertion strategies (and why placement matters)

Two representative insertion styles:

• Random Logic Encryption (RLE): place key gates to minimize delay overhead; security placement is effectively random.
• Fault-analysis based Logic Encryption (FLE): place key gates at highly influential locations so wrong-key effects propagate widely; key gates can cluster/back-to-back.

Fault-impact based insertion aims for:

• key gates inserted where “faults” (wrong-key effects) can be excited and observed at outputs,
• enough gates inserted until outputs are ~50% corrupted for random wrong keys.

A key subtlety: wrong-key effects can be blocked or self-cancel through logic structure, similar to fault masking in test. A single bad key bit may not flip outputs for many inputs if its effect is blocked downstream.

6. Attacker models against logic locking

Two broad attacker angles matter:

6.1 Oracle-based attacks (functional IC available)

An attacker can:

• apply chosen inputs to a working chip,
• observe outputs,
• and use input-output pairs plus the encrypted netlist to infer the key (potentially combining brute force with side-channel help).

6.2 Locked-netlist analysis (design extraction / removal)

If an attacker can reverse engineer the netlist (from GDSII or silicon), they can:

• try to isolate “key logic” and solve it,
• or attempt to remove/bypass key logic to recover usable IP.

7. Three canonical attacks on logic encryption (and the matching defenses)

A “threat model map” ties each attack to what the attacker has, how the attack works, and which defense targets it.

7.1 Sensitization attack → Strong Logic Encryption (SLE)

Idea: Find input patterns that “sensitize” (propagate) the effect of a specific key bit to a primary output, then query the oracle to learn that bit.

Defense concept (SLE): Make individual key-bit sensitization infeasible by creating pairwise dependencies among key gates, pushing the attack toward exponential brute force.

7.2 SAT attack

SAT attack overview: Use Boolean satisfiability to iteratively eliminate incorrect keys using distinguishing input patterns (DIPs).

Core components:

• Build a miter circuit: two copies of the encrypted circuit share inputs but have independent keys; XOR outputs to detect disagreement.
• A SAT solver finds an input where the two copies differ (a DIP).
• Apply that DIP to the real chip to get the correct output, then constrain the solver to eliminate keys that disagree with the oracle.
• Repeat until only the correct key remains.

Why it works: each DIP prunes the key space; practical success depends on how efficiently DIPs distinguish incorrect keys.

Example:

See the following videos where we walk though a SAT attack on a small locked circuit using the logictools.org website.

Part 1: Introducing the tool.

Part 2: Running a SAT attack.

7.3 Defending against SAT attack with SARLock (+ combinations)

SAT-resistance key idea: Make each DIP eliminate as little key space as possible; ideally, require an exponential number of DIPs.

SARLock: A SAT-resistant structure that flips output only under very specific key/input conditions (“diagonal” behavior), causing the number of DIPs to blow up (approximately 2^|K| - 1).

But SARLock alone isn’t enough: it can be vulnerable to “removal” style attacks, so it’s combined with stronger locking.

Two-layer locking (SARLock + SLE):

• Add a “scrambler” (e.g., hash-like) to create key dependencies and resist removal,
• Combine SARLock’s SAT resistance with SLE’s resistance to sensitization/removal.

Cost/benefit framing:

• Attack effort can increase exponentially (huge DIP count and time),
• Overheads rise (area/power), with representative comparisons given for RLE vs SLE vs SARLock+SLE.

7.3 Test-data mining attack → Post-test activation

Background: Every IC is tested in manufacturing using ATE and ATPG-generated test patterns; test quality is measured by fault coverage.

Two activation models:

• Pre-test activation: load the correct key before manufacturing test; ATPG is constrained by the correct key.
• Post-test activation: test without the key; apply the key only after test; ATPG is oblivious to the correct key.

Why pre-test activation leaks: If ATPG is run with the correct key as a constraint, test data can embed information that helps infer the key.

Test-data mining attack: Given an encrypted netlist and the test stimuli/responses, an attacker solves for the key that satisfies the test constraints and maximizes fault coverage (framed using ATPG/SAT/ILP approaches).

Empirical results shown:

• the proposed test-data mining approach succeeds broadly, including against RLE/FLE/SLE, and can succeed even with partial test data (e.g., 30% for certain SLE cases).

Defense: post-test activation
Applying the key after test prevents ATPG patterns from embedding key information, making test-data mining inapplicable in this model.