Secure Hardware Design¶

Course Overview¶

• Institution: MIT
• Course code: 6.5950
• Track: Hardware Security
• Tier: A
• Role: Mainline
• Level: Not standardized by provider (use prerequisites)
• Last reviewed: 2026-07-28

MIT's Secure Hardware Design builds a modern hardware-security spine from an open text, CTF, labs, and code, with exercises targeting real processors whose availability must be checked.

Why choose this course

Mainline course. A reliable option that can serve as a main course or strong alternative.

Before you start

• Recommended foundation: Digital Logic and Computation Structures
• Recommended foundation: Computer Architecture

Verifiable learning outcomes

• Explain the core models in Hardware Security, including their assumptions and limits
• Solve representative derivations and problems, checking units, limiting cases, or numerical results
• Complete a reproducible experiment or implementation with raw data, parameters, versions, and verification

Workload and pacing

13 weeks at 11 hours/week. This maintainer planning estimate is derived from course role and the density of public practice and labs; it is not a provider workload promise. Pilot two weeks while logging instruction, practice, lab, and review time, then adjust the remaining plan when actual effort differs by more than 25%.

Safety level

Low energy. Keep work isolated, current-limited, and low energy; verify ratings, grounding, short-circuit risk, and emergency shutdown before power-up.

Course Resources¶

Software, hardware, and cost

Software

• Maintainer-suggested open-source/free verification path: Verilator, Yosys, GTKWave, Python 3, and Jupyter
• The resource inventory lists public code coverage; pin interpreter, dependencies, toolchain, datasets, and PDK versions where applicable

Hardware

• The resource inventory lists lab coverage; use compliant institutional access to the following borrowed or shared equipment: a course-supported test board, isolated/current-limited power, and logic analyzer; use side-channel equipment only in a compliant lab. Verify ratings, authorization, and safety conditions only after the provider lab manual explicitly calls for them

Cost note

Prefer open-source/free simulation tools; this is not a provider equipment requirement. Access specialized instruments or facilities through a compliant institution rather than personal purchase; access, consumable, and license costs vary by provider, region, and institution.

Public resource coverage

Resources and access

“Listed by official page” means the link was discovered on a successfully fetched official source on the verification date; it does not guarantee that every region or account can open the target directly. Access does not grant redistribution rights. Re-check the provider page, target link, and third-party notices before downloading, adapting, or publishing material.

Practice and Verification¶

Practice loop

Secure Hardware Design · MIT 6.5950: Auditable Hardware Threat Model and Mitigation Experiment

This is a maintainer-suggested self-study project for Secure Hardware Design · MIT 6.5950, not an official course assignment. Define an authorized threat for a self-authored RTL model in Hardware Security, simulate a timing side channel or fault, and evaluate constant-time or redundancy mitigations without targeting third-party devices.

Origin: Maintainer-suggested project

Deliverables

• A threat model defining assets, attacker capability, trust boundaries, authorization, and unacceptable impact
• Self-authored RTL or software model, attack simulation, baseline, and mitigation sources
• At least 1,000 baseline, attack, and mitigated traces with raw leakage or fault-success data
• A defensive report comparing security benefit, area or latency cost, and residual risk

Verification

• Show the baseline attack exceeds random guessing on synthetic traces with confidence intervals, not a single run
• Reduce attack advantage by at least 80% after mitigation or explain the shortfall and remaining leakage
• Cover all-zero and all-one secrets, repeated inputs, reset-time behavior, and faults that do not trigger
• Cross-check conclusions with a second statistical test or independent fault checker

Reproducibility

• Commit the self-authored model, attack and mitigation code, tests, threat model, and a README
• Pin tool versions, synthesis parameters, seeds, and every experiment configuration
• Preserve sanitized synthetic raw traces, checksums, and the generated report

Safety boundary: Simulation only — Test only self-authored, explicitly authorized simulation models; do not provide exploitation steps for third-party devices, real keys, or access-control bypasses.

Risks, gaps, and boundaries

The open text, CTF, and laboratories are modern, but exercises target real processors and require checking hardware availability.

Completion evidence

• Weekly learning log with time, questions, corrected errors, decisions, next steps, and links to that week's reproducible artifacts
• Design-review package with requirements and constraints, trade-offs, editable sources, applicable ERC/DRC/timing/stability checks, exports, and a reproduction test
• Code repository with pinned dependencies and toolchain, a minimal run command, tests or waveform/benchmark checks, expected output, and license notes
• Experiment package with schematic/setup, calibration record, raw data, uncertainty, safety checks, failed runs, and steps to rebuild plots from raw data