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

COMP6420 Week 3 – Scan Attacks

1. Recap: why we build crypto hardware in the first place

Why is cryptography often implemented in custom hardware?

It can accelerate crypto operations and can help protect secrets (e.g., keeping round keys in ROM or otherwise off the “normal” software-visible pathway). Common deployment examples include smart/chip credit cards and TV/satellite decoders, and most modern CPUs have dedicated crypto acceleration instructions (e.g., AES-NI, ARMv8 crypto extensions, and RISC-V crypto extensions).

However, the same hardware features that make chips testable and maintainable can undermine crypto secrecy if exposed.

2. Why testing exists

Integrated circuits require systematic testing to:

• reduce the risk of malfunctions once devices ship,
• detect manufacturing defects early (saving packaging cost on faulty dies),
• and reduce security risks (since faults or access to internals can enable reverse engineering or other attacks). :contentReference[oaicite:1]{index=1}

Traditional testing approaches include:

• Built-in self-test (BIST): self-contained but potentially low coverage and high area overhead, and you still have to trust the self-test
• Post-silicon functional testing: also often low coverage; it’s hard to target specific internal wires/bits or localize failures.

This motivates a more powerful approach: design-for-test (DFT) infrastructure that makes internal state observable/controllable.

3. DFT basics: scan chains as a test backdoor

Digital circuits are a mix of registers (state) and combinational logic (functions), and the test challenge is: how do we efficiently test internal state and internal wires, not just primary inputs/outputs?

3.1 The scan chain idea

A scan chain is a DFT technique that effectively turns many internal flip-flops into a long shift register, so you can:

• scan in a desired internal state (control),
• clock the circuit in normal mode for some cycles (compute),
• then scan out the resulting internal state (observe).

Scan is extremely widely deployed (slides cite “~80% of ICs”), heavily supported by industrial EDA DFT flows, and conceptually similar infrastructure exists in FPGAs for configuration readback/debug.

4. The security conflict: scan vs cryptographic design principles

Once scan gives broad internal visibility, there is a direct conflict with cryptography’s “don’t leak internals” mindset. Crypto guidance (as framed in the slides) includes:

• never permit access to intermediate round values,
• never expose any part of the secret key,
• detect failures or unauthorized access attempts quickly.

This is tied back to Kerckhoffs’ principle: attackers may know the algorithm and design, but must not learn the key—scan can break that assumption if it reveals key-dependent internal state.

5. Scan attacks: the high-level attacker workflow

Scan attacks are a two-part problem:

Step 1: Get access to the scan chain

Options include:

• “Get lucky”: scan is exposed with no protections.
• Bypass test authentication: exploit a weakness, malfunction, or insider path that enables test mode.
• Physical activation: force scan_enable or related signals via invasive probing (requires expertise/equipment and modest IC modification).

Step 2: Use scan to leak secrets

Two major styles:

• Observe-only: run in normal mode, then scan out internal state.
• Control + observe: scan in a chosen state, run normal mode briefly, then scan out.

6. Concrete example: scan attacks on AES (high-level)

Case study: Breaking AES via scan chain in practice.

6.1 Threat model

The attacker typically knows:

• the block cipher algorithm,
• details of the IP core (timing, number of flip-flops, possibly even the netlist).
  What they may not know initially:
• the scan-chain ordering/structure,
• and of course the secret key.

6.2 Two-step attack on AES

1. Identify the scan chain structure:
   The core trick is to reset the chip, apply controlled plaintext differences (often 1-bit or 1-byte changes), run for a minimal number of cycles, then scan out and look for which bits in the scan stream change consistently. This allows you to map portions of the scan stream to meaningful internal registers (input/output, control, AES state/round register).

2. Extract round key material (especially RK0):
   Once you can reliably scan out the AES state after a controlled partial execution, you can set up equations relating plaintext, scanned state, and unknown key bytes. We look at Yang et al.’s approach where carefully chosen plaintext pairs produce constraints that narrow each key byte to two possibilities, and then a small brute-force search over the remaining ambiguity becomes feasible (e.g., reducing the search from 2^128 to something like 2^16 after “pairwise” narrowing).

Big-picture: scan access can collapse a multi-round cipher into something closer to a “single-round” problem, because the attacker can directly observe intermediate state that should never be exposed.

Scan-style attacks exist for public-key schemes (RSA, ECC) and get more complex in modern SoCs with scan compression/compaction, but the fundamental issue remains.

7. Countermeasures: making DFT less dangerous (trade-offs everywhere)

DFT is valuable and widely used, so defenses must preserve testability while reducing leakage.

7.1 Unbound scan chains

One extreme is leaving scan chains “unbound” (not connected in a convenient way), which can improve security but hurts maintenance and in-field debug.

7.2 Test locks

Another common idea is locking/unlocking test mode. The slides note this can be brute-forced or bypassed depending on implementation and threat model.

7.3 “Secure Scan” (mirror key approach)

The lecture presents Secure Scan (Yang, Wu, Karri) as a more crypto-aware DFT architecture:

• Use two keys:
  • the real secret key for normal operation,
  • a mirror key used only for test mode (stored in a mirror key register).
• When switching from normal to test mode:
  • isolate the real secret key,
  • load the mirror key,
  • enable scan/test functionality.

Physical attacks on scan control signals are a risk, and propose integrity checking and buffering as part of hardening.

No defense is “perfect”; rather, it increases attacker cost (time, expertise, equipment) even if full design knowledge is assumed.

7.4 Scramble the scan chain

A different line of defense is scan chain scrambling:

• scan requires configuration,
• the segment ordering is unpredictable and changes randomly,
• correct ordering is used only in test mode.

The slides include an example cost figure (for a ~3K flip-flop design) with overhead around ~12%, reflecting that security features tend to cost area/complexity.

7.5 Flipped scan

Another lightweight method is “flipped scan,” inserting inverters on a random subset of scan inputs:

• it makes scan layouts harder to interpret and hides simple relationships,
• it has low overhead,
• but since the defense is static, it can eventually be brute-forced.

7.6 Overall trade-off statement

Secure DFT usually requires modifications to:

• the test controller, and/or
• the scan/DFT implementation itself,

and inevitably involves trade-offs between security, power/area overhead, and testability.

8. Week 3 assessment focus (what you’re expected to do)

The Week 3 lab is Lab 1: Scan Attack on AES. Each student is given a unique AES core (with variations like randomized key and randomized scan chain order), and the task is to perform the scan attack to extract key material and derive the secret key. The required hand-in includes your discovered scan chain layout and the extracted/derived key information. The due date is Friday of Week 4.

Appendix: DES scan attack mechanics

There is also an appendix that walks through DES scan attack mechanics for your own reference.