ECE 4040/5040: Introduction to Hardware Security
Department of Electrical and Computer Engineering, University of Idaho
Semester: Fall 2026
Instructor: Prof. Zain Ul Abideen (zabideen@uidaho.edu)
Class pattern: Tuesday and Thursday, two 75-minute meetings
Location: Janssen Engineering Building, Room 025
Office hours: Monday and Friday, 2:00–5:00 p.m., GJ 205
Digital systems depend on hardware to protect software, data, device identities, and cryptographic keys. Hardware can also leak information, fail under deliberate manipulation, or be modified at different points in the integrated-circuit supply chain. This course examines how secure hardware is designed, evaluated, attacked, and improved.
Download the locked Fall 2026 syllabus (PDF) University academic calendar
Canvas: The official announcements, assignment files, grades, protected datasets, recordings, and any deadline changes are maintained in Canvas.
Course Approach
This is a hardware-first course. Students work with synthesizable Verilog or SystemVerilog, simulation, synthesis, Python analysis, measured traces, silicon data, fault campaigns, and gate-level security experiments.
- Build: cryptographic blocks and secure hardware subsystems.
- Attack: side channels, deliberate faults, malicious modifications, reverse engineering, and logic locking.
- Measure: security outcomes together with area, timing, latency, and power.
- Explain: the threat model, evidence, limitations, and residual risk.
Recommended Background and Tools
Students should have completed a digital-logic course such as ECE 2400 and should be able to read and write basic Verilog or SystemVerilog. ECE 4450 or equivalent RTL experience is recommended. Prior coursework in cryptography is not required.
Tools: Cadence Xcelium, Cadence Genus, Python, NumPy, Jupyter, Git, course-provided power traces and fault logs, a real-silicon SRAM-PUF dataset, logic-locking scripts, benchmark circuits, a functional oracle, and a SAT-attack driver.
Core references:
- Z. U. Abideen and S. Pagliarini, Reconfigurable Obfuscation Techniques for the IC Supply Chain.
- S. Bhunia and M. Tehranipoor, Hardware Security: A Hands-on Learning Approach.
- C. Paar and J. Pelzl, Understanding Cryptography.
No single textbook is required. Assigned readings come from course notes, research papers, and standards.
Learning Outcomes
By the end of the course, students will be able to:
- Explain major hardware-security threats across design, fabrication, test, deployment, and end-of-life stages.
- Define a threat model that identifies assets, trusted and untrusted parties, attacker access, assumptions, and security goals.
- Implement and verify a cryptographic hardware block in synthesizable Verilog and evaluate correctness, latency, throughput, area, and timing.
- Explain the roles and limitations of PRNGs, TRNGs, DRBGs, and physically unclonable functions.
- Perform basic timing or power side-channel analysis and evaluate common countermeasures.
- Model deliberate faults, conduct an RTL- or gate-level fault campaign, and assess fault-detection or fault-tolerance methods.
- Analyze hardware Trojans, reverse engineering, counterfeiting, scan and debug exposure, logic locking, and reconfigurable obfuscation.
- Apply introductory security-verification methods such as assertions, information-flow reasoning, reachability analysis, or equivalence checking.
- Design and evaluate a small secure hardware subsystem, including a measured comparison before and after a security improvement.
- Present technical results clearly, support conclusions with evidence, and describe limitations and residual risks.
Assessment and Grading
| Assessment | Weight |
|---|---|
| Homework 1: Cryptographic Hardware | 10% |
| Homework 2: PUF as a Security Primitive or Silicon Fingerprint | 10% |
| Homework 3: Side-Channel Analysis | 10% |
| Homework 4: Fault and Trojan Assurance | 10% |
| Homework 5: Logic Locking and SAT-Attack Evaluation | 10% |
| Midsemester Project Presentation and Design Review | 10% |
| Final Project: Implementation, Evaluation, Report, and Presentation | 40% |
| Total | 100% |
There is no separate written midterm or final examination. The midsemester presentation is the formal proposal and design review for the final project. The graded final presentation and demonstration take place during the Registrar-assigned final-examination period.
Major Assessment Dates
| Assessment | Release or activity | Due |
|---|---|---|
| Homework 1 | September 10 | September 20 |
| Homework 2 | September 24 | October 8 |
| Midsemester project presentation | October 13 and 15 | Assigned presentation day |
| Homework 3 | October 29 | November 12 |
| Homework 4 | November 12 | November 19 |
| Homework 5 | November 19 | December 6 |
| Final project materials and report | Final-examination period | December 14 |
| Final project presentation and demonstration | Registrar-assigned final period | December 14–18 |
Homework Assignments
Homework 1: Cryptographic Hardware
Implement and verify an AES component or compact cryptographic core. Required evidence includes known-answer tests, cycle count, latency, throughput, synthesis results, and an explanation of constant-time behavior. ECE 5040 students compare an additional architecture or implementation choice.
Homework 2: SRAM-Based PUF Characterization and Analysis
Analyze a real-silicon dataset from 50 fabricated 65 nm chips. Each chip contains eleven SRAM macro instances and was measured after ten power cycles. Students evaluate bias, reliability, uniqueness, environmental variation, device identity, and the limits of statistical testing, including relevant NIST SP 800-22 concepts. ECE 5040 students perform a deeper uncertainty, entropy, or stabilization analysis.
Dataset paper: “Impact of Orientation on the Bias of SRAM-Based PUFs.”
Homework 3: Side-Channel Analysis
Use supplied or simulated traces to perform correlation power analysis against an AES intermediate value. Report the leakage model, key hypotheses, correlation, key rank, trace count, and one countermeasure evaluation. ECE 5040 students compare two models, preprocessing methods, statistical tests, or countermeasures.
Homework 4: Fault and Trojan Assurance
Complete one fault-injection or hardware-Trojan track using a small RTL design. Evaluate a fault model and protection method, or a Trojan trigger, payload, activation condition, and detection method. Report attack success, coverage, overhead, and residual weaknesses. ECE 5040 students compare two defenses, fault models, Trojan structures, or detection methods.
Homework 5: Logic Locking and SAT-Attack Evaluation
Insert XOR/XNOR-based logic locking into a supplied design, verify correct- and incorrect-key behavior, measure output corruption, and compare area, timing, and power. Use a functional oracle and SAT-attack driver to recover the key and report distinguishing inputs, oracle queries, solver iterations, runtime, and attack outcome. ECE 5040 students compare a second locking or obfuscation method and evaluate multiple key sizes, seeds, or benchmarks.
Final Project
The final project requires students to specify, implement, test, attack, improve, and reassess a hardware-security design. Teams normally include two or three students; individual projects may be approved. A two-page proposal is due October 10, 2026.
Suitable directions include AES or Ascon implementation security, a PUF-based identity subsystem, a fault-resistant core, secure boot or a root of trust, logic locking or LUT/eFPGA obfuscation, Trojan insertion and detection, reverse engineering, secure scan or JTAG, information-flow or equivalence analysis, and ML-KEM, ML-DSA, or HQC hardware security.
The final submission includes the threat model, architecture, synthesizable RTL, testbench, attack or security evaluation, countermeasure, before-and-after evidence, area and timing results, source code, reproducibility instructions, report, presentation, and demonstration. A successful project states what remains unprotected rather than claiming complete security.
ECE 5040 Graduate Requirements
- Complete the graduate extension in every homework.
- Lead or co-lead one research-paper discussion.
- Define a stronger final-project threat model and compare with published work.
- Implement a research-level extension or additional evaluation.
- Submit a 6–7 page IEEE-style paper with measured results, limitations, and individual contributions.
Regular and Engineering Outreach Delivery
The regular and Engineering Outreach sections use the same lectures, outcomes, assignments, deadlines, grading criteria, and final-project expectations. Students share a common Canvas site, repository, software environment, starter files, scripts, and datasets. Remote code reviews, project meetings, oral checks, and approved recorded demonstrations provide equivalent access when specialized laboratory equipment is unavailable.
Professional, Ethical, and Academic Expectations
- Perform security experiments only on course-provided or explicitly authorized designs, data, equipment, and systems.
- State assumptions honestly, report negative results, preserve code and data, and distinguish measurements from speculation.
- Disclose meaningful use of generative AI tools. Every student remains responsible for every submitted line of code, result, and claim and must be able to explain the work during a code review or oral check.
Accessibility and Accommodations
The University of Idaho is committed to equal and integrated access for students with disabilities. Students who need disability-related accommodations should contact the Center for Disability Access and Resources as early as possible and provide the approved accommodation notice to the instructor. CDAR may be reached at cdar@uidaho.edu or 208-885-6307. Course materials can be provided in an alternate format upon request.
Fall 2026 Schedule and Paper Readings
Topic order may be adjusted slightly to match student progress, tool availability, guest-lecture confirmation, or the official section schedule. Any assessment change will be announced in Canvas. The linked papers provide a stable record for Canvas and the course website; Canvas will identify whether the full paper or selected sections are required.
Module 1: Hardware Security and Cryptographic Foundations
-
Session 1 : Course orientation and HW Sec practice
Course organization, ethical limits, regular and Engineering Outreach delivery, tools, RTL expectations, assessments, and the cumulative final project. Students distinguish hardware security from software security, reliability, safety, and functional correctness.
Primary paper: M. Rostami, F. Koushanfar, and R. Karri, “A Primer on Hardware Security: Models, Methods, and Metrics,” Proceedings of the IEEE, 2014.
-
Session 2 : The integrated circuit lifecycle and threat modeling
Protected assets, trust boundaries, attacker capabilities, third-party IP, design and fabrication stages, test facilities, end users, overproduction, counterfeits, and supply-chain exposure. Students prepare a complete asset–adversary–access–objective threat model.
Primary paper: M. Rostami, F. Koushanfar, J. Rajendran, and R. Karri, “Hardware Security: Threat Models and Metrics,” ICCAD, 2013.
-
Session 3 : Cryptography for hardware engineers
Confidentiality, integrity, authentication, hashing, signatures, symmetric and asymmetric cryptography, key exchange, key-encapsulation mechanisms, nonces, and the role of hardware acceleration.
Primary paper: W. Diffie and M. E. Hellman, “New Directions in Cryptography,” IEEE Transactions on Information Theory, 1976.
-
Session 4 : AES algorithm and hardware datapath
State representation, rounds, SubBytes, ShiftRows, MixColumns, AddRoundKey, finite-field operations, and key expansion. Students translate the algorithm into datapath and control blocks.
Primary paper: J. Nechvatal et al., “Report on the Development of the Advanced Encryption Standard (AES),” Journal of Research of NIST, 2001.
-
Session 5 : AES architectures and secure use
Iterative, partially unrolled, and pipelined implementations; latency, throughput, area, and timing tradeoffs; constant-time behavior; modes of operation; authenticated encryption; a brief Ascon example; and self-checking verification.
Primary paper: A. Satoh, S. Morioka, K. Takano, and S. Munetoh, “A Compact Rijndael Hardware Architecture with S-Box Optimization,” ASIACRYPT, 2001.
-
Session 6 : Recap 1 and Homework 1 launch
The first half reviews threat models, cryptographic goals, AES operations, architectural choices, test vectors, and constant-time design. The second half demonstrates the starter design, submission flow, required measurements, rubric, and ECE 5040 extension for Homework 1.
Primary paper: D. Canright, “A Very Compact S-Box for AES,” CHES, 2005.
Module 2: Post-Quantum Hardware, Entropy, Identity, and Roots of Trust
-
Session 7 : Post-quantum cryptographic hardware architecture
The quantum threat to RSA and ECC; KEMs and signatures; ML-KEM and ML-DSA operations; polynomial arithmetic; the number-theoretic transform; sampling; hashing; memory organization; constant-time control; and area, timing, energy, and bandwidth tradeoffs. HQC is introduced as a contrasting code-based design.
-
Session 8 : Random-number generation and entropy
PRNGs, LFSRs, TRNGs, ring oscillators, metastability, DRBGs, seeding, reseeding, conditioning, entropy estimation, online health tests, and active manipulation of entropy sources.
-
Session 9 : Physically unclonable functions and evaluation
Process variation; strong and weak PUFs; ring-oscillator, arbiter, and SRAM PUFs; enrollment and verification; reliability, uniqueness, uniformity, bit aliasing, helper data, environmental effects, physical-design choices, and modeling attacks.
-
Session 10 : Recap 2 and Homework 2 launch
The first half reviews PRNG, TRNG, and DRBG distinctions, entropy paths, PUF structures, enrollment, quality metrics, and threat assumptions. The second half explains the 50-chip SRAM-PUF dataset, analysis scripts, required plots and tables, rubric, and ECE 5040 extension for Homework 2.
-
Session 11 : Roots of trust and the key lifecycle
Hardware trust anchors, immutable first code, isolated execution, device identity, key provisioning, derivation, storage, use, zeroization, lifecycle states, anti-rollback protection, and the boundary between trusted and untrusted components.
Primary paper: F. Brasser, B. El Mahjoub, A.-R. Sadeghi, C. Wachsmann, and P. Koeberl, “TyTAN: Tiny Trust Anchor for Tiny Devices,” DAC, 2015.
-
Session 12 : Secure boot, measured boot, and remote attestation
Firmware authentication, measurements and event logs, authenticated updates, rollback protection, attestation protocols, verifier assumptions, freshness, reset behavior, and the hardware/software boundary of a small root of trust.
-
Session 13 : Final-project proposal workshop
Team formation, literature selection, protected assets, threat models, architecture review, division of work, preliminary experiments, Engineering Outreach logistics, measurable success criteria, and preparation of the midsemester presentation.
Primary paper: S. Keshav, “How to Read a Paper,” ACM SIGCOMM Computer Communication Review, 2007.
-
Session 14 : Project design review and presentation preparation
Students receive feedback on project scope, threat models, block diagrams, baselines, evaluation plans, evidence, security metrics, hardware metrics, reproducibility, and technical risks. Homework 2 is due before class.
Primary paper: H. Salmani, M. Tehranipoor, and R. Karri, “On Design Vulnerability Analysis and Trust Benchmarks Development,” IEEE ICCD, 2013.
Module 3: Midsemester Project Presentations
-
Session 15 : Midsemester project presentations I
Teams present the security problem, threat model, related work, proposed architecture, attack or evaluation method, countermeasure, preliminary evidence, schedule, and technical risks.
Primary paper: P. E. Bourne, “Ten Simple Rules for Making Good Oral Presentations,” PLOS Computational Biology, 2007.
-
Session 16 : Midsemester project presentations II
Remaining presentations, technical questions, scope corrections, final project approval, and written feedback. Graduate students identify the research question and research-level extension.
Module 4: Side-Channel Analysis and Countermeasures
-
Session 17 : Physical side channels
Timing, power, and electromagnetic leakage; CMOS switching activity; constant-time and constant-power distinctions; trace acquisition; simple power analysis; and Hamming-weight and Hamming-distance leakage models.
Primary paper: P. Kocher, J. Jaffe, and B. Jun, “Differential Power Analysis,” CRYPTO, 1999.
-
Session 18 : Differential and correlation power analysis
Difference-of-means analysis, Pearson correlation, hypothetical intermediate values, byte-wise key hypotheses, points of interest, trace alignment, noise, trace count, correlation evolution, and key rank.
Primary paper: E. Brier, C. Clavier, and F. Olivier, “Correlation Power Analysis with a Leakage Model,” CHES, 2004.
-
Session 19 : Side-channel countermeasures and leakage assessment
Boolean masking, hiding, shuffling, random delays, balanced logic, dual-rail concepts, precharge, glitch effects, signal-to-noise ratio, Test Vector Leakage Assessment, and the limits of a pass/fail leakage claim.
Primary paper: S. Nikova, C. Rechberger, and V. Rijmen, “Threshold Implementations Against Side-Channel Attacks and Glitches,” ICICS, 2006.
-
Session 20 : Recap 3 and Homework 3 launch
The first half reviews leakage models, SPA, DPA, CPA, correlation, key ranking, trace count, and countermeasure assumptions. The second half introduces the supplied traces, scripts, required figures, success criteria, defense comparison, rubric, and ECE 5040 extension for Homework 3.
Primary paper: C. O’Flynn and Z. D. Chen, “ChipWhisperer: An Open-Source Platform for Hardware Embedded Security Research,” COSADE, 2014.
Module 5: Fault Injection and Malicious Hardware
-
Session 21 : Fault attacks and fault models
Fault, error, and failure; transient and permanent faults; stuck-at, bit-flip, instruction-skip, and random-byte models; voltage and clock glitching; electromagnetic, optical, and laser injection; fault propagation; and differential fault analysis.
Primary paper: D. Boneh, R. A. DeMillo, and R. J. Lipton, “On the Importance of Checking Cryptographic Protocols for Faults,” EUROCRYPT, 1997.
-
Session 22 : Fault countermeasures and verification
DMR, TMR, time redundancy, error-detecting codes, protected finite-state machines, sensors, instruction duplication, infective computation, fault coverage, false alarms, common-mode failures, and verification of countermeasure coverage.
-
Session 23 : Hardware Trojan horses
Design-time and fabrication-time insertion; trigger and payload; functional and leakage Trojans; additive, subtractive, and parametric changes; activation probability; stealth; area, power, and timing effects; physical insertion; and detection limits.
-
Session 24 : Recap 4 and Homework 4 launch
The first half reviews fault models, injection mechanisms, differential fault analysis, redundancy, Trojan structures, stealth, and detection assumptions. The second half demonstrates the attack interface, starter RTL, defense requirements, required measurements, rubric, and ECE 5040 extension. Homework 3 is due before class.
Primary paper: J. Breier and X. Hou, “How Practical Are Fault Injection Attacks, Really?,” IEEE Access, 2022.
Module 6: Reverse Engineering, Logic Locking, and Design Assurance
-
Session 25 : Physical and logical reverse engineering, intellectual-property threats, and logic-locking foundations
Board, chip, GDS, and netlist starting points; imaging and layer reconstruction; netlist recovery; graph representation; partitioning; register grouping; finite-state-machine recovery; lost design assumptions; IP piracy and overproduction; the logic-locking threat model; key gates; correct-key and incorrect-key behavior; oracle access; and security-versus-area, power, and timing tradeoffs.
Primary paper: R. Torrance and D. James, “The State-of-the-Art in IC Reverse Engineering,” CHES, 2009.
Companion paper: P. Subramanyan, S. Ray, and S. Malik, “Evaluating the Security of Logic Encryption Algorithms,” IEEE HOST, 2015.
-
Session 26 : Recap 5 and Homework 5 launch
The first half reviews the reverse-engineering threat model, intellectual-property threats, key-gate insertion, correct-key behavior, wrong-key corruption, oracle access, and the difference between key size and attack resistance. The second half demonstrates the locking script, benchmark design, functional oracle, SAT-attack driver, synthesis flow, required measurements, submission format, grading rubric, and ECE 5040 extension. Homework 4 is due before class.
Primary paper: P. Subramanyan, S. Ray, and S. Malik, “Evaluating the Security of Logic Encryption Algorithms,” IEEE HOST, 2015.
-
Session 27 : SAT attacks and reconfigurable obfuscation
Distinguishing input patterns; oracle-guided key recovery; SAT-attack iterations; attack assumptions and limitations; output corruption; structural leakage; camouflaging; split manufacturing; LUT-based protection; eFPGA redaction; reconfigurable obfuscation; hASIC concepts; and the relationship between attack resistance and area, timing, power, routing, and testability.
Companion paper: P. Subramanyan, S. Ray, and S. Malik, “Evaluating the Security of Logic Encryption Algorithms,” IEEE HOST, 2015.
-
Session 28 : Secure test, debug, and security verification
Scan-chain observability and controllability; scan-based key recovery; secure-scan architectures; boundary scan and JTAG; lifecycle-controlled debug; security assertions; information-flow reasoning; taint propagation; finite-state-machine reachability; and equivalence after locking, obfuscation, or countermeasure insertion. The final-project design is frozen.
Primary paper: B. Yang, K. Wu, and R. Karri, “Secure Scan: A Design-for-Test Architecture for Crypto Chips,” IEEE TCAD, 2006.
Companion paper: D. Zhang, Y. Wang, G. E. Suh, and A. C. Myers, “A Hardware Design Language for Timing-Sensitive Information-Flow Security,” ASPLOS, 2015.
Module 7: No Exam Week and Final Project Completion
-
Session 29 : Final-project guidance session
Formative RTL and code reviews, attack validation, countermeasure checks, interpretation of results, report organization, repository review, reproducibility checks, and individual Engineering Outreach consultations. No quiz, examination, graded presentation, or new major material is scheduled.
-
Session 30 : Final rehearsal and course synthesis
Demonstration dry runs, timing checks, backup plans, accessible slide review, repository and artifact checks, presentation feedback, and a review of the semester’s design, attack, improvement, and reassessment process. No graded assessment is scheduled.
Primary paper: K. M. Naegle, “Ten Simple Rules for Effective Presentation Slides,” PLOS Computational Biology, 2021.