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

# COMP6420 Week 9 – IC Camouflage and Physically Unclonable Functions (PUFs)

Part A — IC Camouflage

1. Reverse engineering is both a defensive tool and an attack enabler

Reverse engineering can identify device technology, functionality, and design intent. It can be used to detect piracy and Trojan insertion, but it also enables copying designs and planning targeted Trojan insertions.

2. Positioning: logic locking vs camouflage

Logic locking primarily targets untrusted foundries/factories (prevent overbuilding/unauthorized use when manufacturing is the threat). IC camouflage targets untrusted end users (prevent reverse engineering after chips are in the market).

3. IC camouflage: break the “layout → function” link

Traditional standard cells have layout patterns that map cleanly to gate functionality, which makes imaging-based reverse engineering straightforward.

Camouflage uses look-alike cells so that multiple functions share similar-looking layouts, making it hard to distinguish (e.g., NAND vs NOR) from top-down imagery.

A concrete mechanism is dummy contacts: true and dummy contacts look identical from above but behave differently electrically.

4. Practicality and trade-offs (security vs PPA)

Camouflaged gates tend to have higher power, delay, and area than normal gates. Full-chip camouflage is usually impractical; selective camouflage is more realistic.

There is market use, with an estimate of >140M camouflaged ICs produced, suggesting it is feasible in some contexts despite overheads.

The core defender trade-off is security vs PPA (power/performance/area): more camo gates increase ambiguity for attackers but raise overhead.

5. Threat model for camouflage

An attacker may have:

• a camouflaged netlist obtained by reverse engineering (they know which gates are camouflaged but not what each one does),
• the camouflaged cell library (from vendor sources),
• a golden IC purchased from the market (a working oracle device).

6. “De-camouflaging” attack shape: identify some gates, brute-force the rest

A typical defeat strategy uses two copies:

1. Use the reverse-engineered netlist to learn structure and identify camo locations.
2. Use the golden IC to test discriminating inputs that reveal the function of particular camo gates.
3. Brute-force whatever camo gates remain unresolved.

Two important pattern types drive gate identification:

• Differentiating Patterns (DP): inputs that cause different outputs for different candidate gate functions (useful for distinguishing).
• Common Patterns (CP): inputs that produce the same output regardless of candidate function (useful for “muting” non-target camo gates while testing a target).

7. When camo gates are easy vs hard to resolve

Camo gates fall into categories depending on whether they can be:

• justified to a DP at their inputs, and

• sensitized to a primary output without interference.

• Isolated/resolvable gates: little interference; targeted testing can resolve them efficiently.

• Resolvable but interfering gates: on each other’s paths or converging; use CP to neutralize non-target gates while applying DP to the target.

• Non-resolvable + interfering gates: cannot be driven to DP and propagated cleanly; these force brute force.

An interference graph models this: nodes are non-resolvable camo gates and edges represent interference. Attack cost grows:

• roughly linearly with the number of cliques,
• exponentially with the size of the largest clique.

8. Choosing which gates to camouflage: “output corruptability” matters

Wrong functional assignment of camo gates does not necessarily produce wrong primary outputs, so camouflaging “random” gates can be weaker than expected.

“Output corruptability” captures two ideas:

• Activation: ambiguity should trigger under many input patterns (DP-like activation).
• Propagation: ambiguity should be sensitized to many outputs (avoid masking by side inputs).

Selecting non-resolvable gates with high output corruptability increases both attacker brute-force effort and output ambiguity.

A desirable metric is ~50% Hamming distance between outputs across different camo-gate functionality assignments (maximum ambiguity). Random selection can underperform; output-corruptability-aware selection can approach the 50% target.

9. Overheads and “camouflage only what matters”

Camouflage cells can be power hungry (example: ~5×), and even camouflaging ~5% of gates can induce very large power overhead (example figure: ~105%).

Controllers can be a small fraction of overall design size (≤1%), so camouflaging control logic can yield strong leverage: the datapath may become useless without correct control, while overhead remains relatively contained.

10. Broader view: other obfuscation directions

Camouflage is one form of design obfuscation. Alternatives include using embedded FPGA-like structures (eFPGAs), but challenges include large area/cost overheads, frequency reduction, and deciding what to redact.

Attacks analogous to SAT-style attacks exist for camouflage (“De-Camo” attacks). A major open problem is achieving provably secure IC camouflaging.

Part B — Physically Unclonable Functions (PUFs)

11. The key storage problem (and why PUFs exist)

Securely storing digital secrets on a device in a physically attack-resistant way is difficult and expensive. Keys in non-volatile memory can be extracted, and secure key programming requires a trusted manufacturing step. EEPROM also adds manufacturing complexity. Some devices (e.g., RFIDs) are too resource constrained for heavyweight cryptography, and commodity platforms (like FPGAs) may lack convenient secure NVM.

PUFs aim to provide secrets without storing them explicitly, by using inherent physical variation.

12. PUF definition (properties)

A PUF is a physical function that:

• maps a challenge → response,
• is easy to evaluate on the real device,
• behaves like a random function,
• is unpredictable even to an attacker with physical access.

13. Manufacturing variation as the entropy source

Even chips from the same lot exhibit random process variation (mask/laser variation, temperature-related variation, etc.), producing measurable differences such as propagation delays (magnitude can be ~5% or more). As technology scales, relative variations become larger.

These delay differences can be used to generate device-unique secret bits.

14. Ring oscillator PUFs (canonical construction)

Ring oscillators can be built from standard digital logic as combinational loops. Each ring oscillator has a slightly different frequency due to process variation. Comparing two oscillators’ frequencies yields a bit (which oscillator is faster).

Implementation constraints are attractive:

• everything is standard digital logic,
• minimal placement/routing constraints beyond the oscillators,
• implementable even on standard FPGAs (“soft PUF”).

15. How many bits can you get?

With N oscillators, there are N! possible orderings by frequency. If orderings are roughly equally likely, this yields about log2(N!) independent bits. Example figures:

• 35 oscillators → ~133 bits
• 128 oscillators → ~716 bits
• 256 oscillators → ~1687 bits

16. Challenge–response security (and the “lookup table clone” problem)

If an attacker can collect and store all challenge–response pairs (CRPs), they can emulate the PUF with memory. Defenses include having a very large CRP space (many possible challenges), enabled by configurable delay paths (ASICs) or exploiting configurability on FPGAs.

17. Validating PUFs: uniqueness vs reliability

Two key validation properties:

• Inter-chip variation (uniqueness): how different are two chips’ responses? Target is ~50% difference.
• Intra-chip variation (reliability): how stable is one chip over time/conditions? Target is ~0% flips, but voltage/temperature changes can cause bit flips.

Error tolerance affects authentication outcomes:

• False positive: one chip accepted as another.
• False negative: correct chip rejected due to instability.
  Example numbers show extremely low false positive rates with modest error tolerance (e.g., allowing 10 bit differences out of 128), while keeping false negative rates very low.

18. Making PUF outputs usable: ECC + hashing

Reliability and security are improved by adding logic:

• Error Correcting Codes (ECC): correct measurement noise; store a syndrome/error mask (public info) to reconstruct the same reference response later. Example: BCH(127,64,21) corrects up to 10 errors with very low failure probability.
• Hashing (e.g., SHA-x): helps prevent model-building attacks by forcing an attacker to invert a one-way function to predict outputs.

A stable reconstructed PUF output can be used directly as a symmetric key, and similar constructions can support public/private key generation.

19. Other PUF families

Other common PUF types include:

• Arbiter PUFs (delay-race based),
• SRAM PUFs (power-up state of SRAM cells: random but repeatable bias).

20. Main challenge: instability can be attacked

PUFs are inherently somewhat unstable; attackers can exploit environmental manipulation (e.g., temperature shifts) to cause authentication failures by inducing too many bit flips for ECC tolerance.