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

COMP6420 Week 7 – PCB Attacks and Hardware Trojans

1. Hardware security includes PCBs, not just chips

Hardware includes both integrated circuits and printed circuit boards (PCBs) that connect and host them. PCBs have their own long supply chain (spec → circuit design → BOM → layout → fab → component sourcing → assembly/PCBA → firmware installation → system integration → user adoption), and every stage is an opportunity for tampering.

Many attack types are plausible along this chain: malicious design modifications, BOM component changes, layout alterations (trace widths/shorts), counterfeit parts, component substitution, firmware backdoors, and installation/integration tampering.

2. PCB attack model: who attacks and what they can do

A PCB-focused threat model includes malicious:

• vendors,
• factories,
• shippers.

Typical capabilities include:

• substituting or adding components (counterfeits, Trojans, modchips),
• altering PCB layouts,
• installing alternative firmware.

A concrete example is counterfeit Cisco hardware using a modchip added to the counterfeit PCB to bypass authentication checks.

3. Board-level hardware Trojans: taxonomy and impact

PCB alterations can enable full system compromise because a Trojan can sit between legitimate subsystems and observe, leak, or edit traffic/behavior.

A useful taxonomy breaks board-level Trojans down by:

• Modification type: addition, removal, component alteration, PCB tamper
• Location: surface, covered, inner routing, substrate
• Integration style: snoop, participate, interpose, override, replace, parasitic, inject faults
• Trigger: always-on, external, internal, environmental
• Effect: leak information, modify function, denial of service, degrade performance

4. Why board-level attacks are so feasible in real systems

Most systems can’t fit everything onto one chip (cost and specialization), so they use multiple reusable component ICs and lots of peripherals. That implies many inter-chip links on the PCB, and those links become natural points for interception or modification.

Peripherals communicate with a “main” device using hardware-level protocols such as GPIO, analog wires, or serial buses (USB/UART/CAN/I2C/SPI/Ethernet). The focus is the physical signaling and protocol behavior, because that’s what PCB modifications can target.

5. Attacking wires: the simplest PCB Trojan building block

Even a single digital wire can be modified in many ways, ranging from crude to sophisticated:

• Logic-level edits: insert logic to conditionally flip/force a signal (e.g., gate with a trigger).
• Inversion: insert an inverter.
• Analog shaping: add RC elements to slow edges or alter thresholds.
• Rerouting / extra path length: add delay or coupling.
• Full interposition: cut the net and route through “Trojan logic” with explicit in/out pins.

These ideas generalize: analog wires can be altered similarly, and bus wires can be altered too—but targeted bus edits are trickier because you must avoid obvious corruption while still changing meaning.

6. Protocols as attack surfaces

6.1 UART / RS-232 (asynchronous serial)

UART has practical framing features (idle high, start/stop bits, optional parity/extra stop bits) that help with sync and broken-wire detection. However:

• there is no built-in clock (sync depends on baud agreement),
• parity is not encryption,
• request/response timing can be exploited,
• man-in-the-middle (MitM) insertion is conceptually straightforward by interposing on TX/RX lines.

Other UART attacks include denial-of-service via stuck-at behavior, noise/EMI leakage, signal rerouting, trace-width changes, and component value changes that affect speed/reliability.

6.2 SPI (high bandwidth, simple, but “no protection”)

SPI is a 4-wire (plus select) bus with a single main and many secondaries; it’s full-duplex and common for memory/cameras. Key security-relevant properties:

• no built-in data protection (must be implemented above SPI),
• no built-in receipt acknowledgement,
• select pins are an obvious leverage point (MitM on chip-select and/or data lines).

Other SPI attacks resemble UART: stuck-at faults, electrical interference, and blocking/altering request pins.

6.3 I2C (two-wire, addressed, acked—and clock stretching enables MitM)

I2C is two-wire, half-duplex, supports hot-plugging, and begins transactions with a device address (typically 7-bit + R/W). Each byte is acknowledged by the peripheral. Weak points include:

• no protection against any device behaving like a “main,”
• the ability for devices to hold the clock low (clock stretching) can enable a very effective MitM Trojan.

A clock-stretch MitM pattern looks like this: a Trojan cuts SDA/SCL, acknowledges the main while holding the main’s clock low, relays requests to the real peripheral(s), potentially edits or replays data, and repeatedly stretches clocks to keep timing consistent.

A concrete example scenario: a main microcontroller asks an EEPROM for the value at address 0x1234, and a Trojan can cause the reply to become a different value (e.g., returning 9999 instead of 5678) without the main realizing.

7. Detecting PCB Trojans is hard (and different from IC/IP Trojan detection)

Most Trojan detection research focuses on IC/IP-level insertion; many of those techniques don’t directly apply to PCB-level modifications.

Two broad detection families exist:

7.1 Static inspection

X-ray / imagery approaches can constrain handling and production, but require access and impose operational overhead.

7.2 Dynamic (run-time) detection via side channels

Run-time operational tests aim to detect anomalies compared to an expected model:

• timing delays,
• bus arbitration errors,
• electrical side channels (slew, power, etc.).

One core challenge: some protocols naturally tolerate timing flexibility (I2C clock stretching), which can hide MitM-induced delays; others (like SPI) don’t permit timing delays in the same way, so different detection cues apply.

8. Closed-loop Trojan detection: “excite, observe, classify”

A practical dynamic strategy is closed-loop detection: generate software-driven excitations (including fuzzing-like inputs), observe all I/O and side channels, and look for deviations from normal behavior. The simplest case is a direct connection (e.g., GPIO loopback).

A concrete testbed example is an “OpenPLC Trojan Edition” platform with:

• a Trojan module (RP2040),
• a main controller (Raspberry Pi Zero W),
• defensive monitoring (power + sensors like magnetometer/accelerometer),
• and configurable rewiring/jumpers.

9. What types of PCB Trojans are detectable with side-channel loopbacks?

Trojan behaviors can be grouped into:

• Snoop trojans: observe but do not alter traffic.
• Edit trojans: modify traffic (invert, delay, replay, etc.).

Edit trojans are often detectable because they inevitably introduce measurable artifacts:

• Delay (extra propagation / buffering / processing),
• electrical changes (edge shape, power signature),
• or protocol anomalies (arbitration/ack timing).

A GPIO MitM example shows delay-based detection working with repeated loop-back cycles; even a “lightweight” trojan introduces additional per-cycle delay that can be statistically identified.

Faster implementations (e.g., FPGA-based edit trojans) can reduce—but not necessarily eliminate—detectable delay because I/O buffers and protection circuits still impose non-zero overhead.

Anomaly-based detection can combine multiple side-channel features and use ML classifiers (e.g., random forests) to separate “no trojan” vs “invert trojan” vs other behaviors.

A key conclusion: loopback-based side-channel detection appears viable for a broad class of edit trojans, and “golden models” help but are not strictly necessary if you have specifications and/or simulator models to define expected behavior.

(Reference included in slides: Pearce et al., “Detecting Hardware Trojans in PCBs Using Side Channel Loopbacks,” IEEE TVLSI, 2022.)