Week 1 - Introduction

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

1. Course Logistics & Administration

See the details at the syllabus.

A note on the Tools, Languages, and Hardware in Labs

In labs you will mostly use:

• Verilog as the hardware description language. Verilog is chosen because the open-source FPGA toolchain (Yosys/icestorm, etc.) has strong support for it. If you come from a VHDL background, the patterns you learn will be largely transferable.
• MicroPython on a microcontroller. It is used instead of C here because it is easier and faster to work with. Performance is not the focus; the goal is to explore hardware-security concepts.

You will work on a custom Hackster board, which has an FPGA and a microcontroller, each with its own USB connection. The 2026 revision of the board is on the way; initially you may be using last year’s hardware.

Lab submissions are a mix of code and documentation. Labs are typically released in a given week and due at 5 pm on the Friday of the following week.

2. Motivation: Why Hardware Security?

Most security courses focus on software: finding exploitable bugs, preserving privacy, enforcing access control, and keeping systems available. Techniques include static analysis, penetration testing, secure development practices, and careful use of third-party libraries.

All of that rests on a largely unspoken assumption: the hardware is trustworthy. We assume that:

• The CPU only executes the instructions we provide.
• Manufacturers build exactly the circuit they were given, and nothing extra.
• The physical device matches our abstract mathematical model, without side effects in timing, power, or electromagnetic behaviour.

This course questions that assumption. It looks at what happens when the underlying hardware, or the supply chain that produces it, cannot be fully trusted.

3. Globalisation and the Hardware Supply Chain

From Vertical Integration to Global Supply Chains

Historically, many companies did everything in-house: design, fabrication, testing, packaging, and assembly. Today, these steps are often spread across different companies and countries. This global, horizontally-distributed model is driven by cost and scale.

A separate but related trend is the rise of fabless semiconductor companies (e.g., NVIDIA, AMD, Apple, ARM, Qualcomm, Broadcom). These companies design chips but outsource fabrication to large foundries. As a result, a single chip might involve:

• Design in one country,
• IP blocks sourced from multiple vendors,
• Fabrication in another country,
• Packaging and testing elsewhere,
• Integration onto boards and into products by yet another firm.

Each hand-off is a potential security risk.

The IC Design Flow and Third-Party Exposure

The integrated circuit (IC) design flow runs from system-level specification through register-transfer level (RTL), logic synthesis, place-and-route, mask generation, fabrication, packaging, and test. Third parties may contribute IP cores, design tools, or the entire fabrication process.

Hardware security concerns include:

• Malicious or buggy IP blocks,
• Compromised EDA tools that insert hidden structures,
• Foundries that alter designs or overbuild components.

PCBs and System Integration

Beyond the chip, the printed circuit board (PCB) and system integration introduce even more actors: PCB designers, board manufacturers, assembly houses, firmware developers, and system integrators. Each stage can introduce:

• Counterfeit or substituted components,
• Malicious modifications at board level,
• Tampered firmware or configuration.

The central question emerges: how do we build trusted systems on untrusted manufacturing and supply chains?

4. Course Content and Goals

For this course, “hardware” primarily means:

• Integrated circuits (ICs) – chips implementing logic, memory, and peripherals.
• Printed circuit boards (PCBs) – the boards on which ICs and other components are mounted.

The course aims to:

• Survey state-of-the-art methods in hardware security and their real-world use.
• Treat security as a design metric, not an afterthought.
• Study both attacks (e.g., side-channel attacks, fault injection, hardware Trojans, IP theft, counterfeiting) and defenses (e.g., design techniques, detection, and supply-chain controls).

5. Hardware Security Risks and Threat Categories

The CIA Triad Applied to Hardware

Hardware security is framed around the familiar Confidentiality, Integrity, and Availability (CIA) triad:

• Confidentiality: Preventing leakage of secrets (e.g., cryptographic keys) via side channels, debug ports, or malicious extra circuitry.
• Integrity: Ensuring computations, stored data, and device configurations cannot be altered by an attacker.
• Availability: Ensuring the device cannot be trivially disabled or rendered unreliable (e.g., by a hidden kill switch or faulty counterfeit component).

Hardware Trojans

A hardware Trojan is a deliberate, malicious modification in a hardware design or implementation. It can aim to:

• Provide hidden control over a system,
• Modify outputs or execution flow,
• Disable a system under certain conditions,
• Steal or leak sensitive information.

Potential insertion points include third-party IP providers, compromised foundries, and integration/assembly stages. Well-known cases and allegations, such as the Clipper chip backdoor or reported military and telecom incidents, show how damaging such modifications can be.

Supply-Chain Attacks, IP Theft, and Overbuilding

The lecture also introduces several other threat types:

• Supply-chain Trojan attacks: Small additions or modifications in components, boards, or systems that create backdoors, often invisible at software level.
• Reverse engineering and IP theft: Delayering and imaging chips to reconstruct designs, either to clone them or to identify attack points.
• IC/IP piracy and overbuilding: Foundries or partners producing more chips than ordered and selling the surplus, or outright stealing design files and commercialising them.

Counterfeit Components

Counterfeit parts are components that are relabelled, reused, or produced outside the authorised supply chain. They may be:

• Old parts that have been cleaned and re-marked,
• Incompatible devices sold under a false identity,
• Low-quality clones.

In mission-critical systems (aircraft, military platforms, core networking infrastructure) these can lead to serious failures, because they may behave unpredictably under stress, temperature, or over time. The lecture includes examples of counterfeit parts discovered in aircraft and communication systems, and large seizures of fake networking equipment.

6. Real-World Hardware Security Case Studies

The lecture uses a series of case studies to illustrate how hardware security issues arise in the real world. A few notable ones:

• IP piracy in DSP design: A high-profile case where a “domestic” chip design was later found to be stolen from a major vendor, showing that even national flagship projects may rest on IP theft.
• Smart electricity meters: Even when communication is encrypted with AES, poor hardware design (e.g., unprotected buses) allowed attackers to extract keys physically and tamper with billing.
• Hotel keycard locks (Onity): A simple, cheap device could open many hotel locks due to weaknesses in the embedded controller’s security.
• Electronic voting machines (India and other countries): Researchers showed that replacing internal boards or attaching small external devices could silently change recorded votes, challenging claims of “perfect” or “infallible” systems.
• Sony PlayStation security: Across PS2 and later consoles, there was an arms race between console makers and modchip designers, illustrating the dynamics of hardware-based DRM and its bypass.
• US electronic voting machines (e.g., Sequoia AVC Advantage): Insecure locks, easily removable panels, and unsealed ROMs made it trivial to replace firmware without detection.

Together, these (and other) examples show that hardware security problems appear in contexts ranging from consumer gadgets to national elections and telecommunications.

7. A Moving Target

Hardware security is not static. New technologies create new attack surfaces (e.g., IoT, BCIs, complex SoCs), and attackers continue to exploit implementation details and supply-chain weaknesses. Defensive techniques are also evolving, including more secure design flows, stronger physical hardening, and better supply-chain oversight.

You should expect that some of what they learn will continue to change; the value lies in understanding the principles and the attacker mindset.