Project 7 — The Silicon Threat Model

“Unless the LORD builds the house, those who labor to build it labor in vain.” — Psalm 127:1 (ESV)

Chapter: 7 — Trust in Silicon Week: 7 · Weight: 7% of the course grade (one of the six weekly labs) Deliverables: threat-model-report.docx · report.docx · measurements.xlsx · ai-usage.txt Submit: a link to a public repository containing all four documents plus your raw tool output. Workbench setup is in Appendix A; measurement and reporting conventions in Appendix C; the grading contract and the integrity rules in Appendix D. Workbench: every Normal-tier requirement is completable on Workbench B (browser, no install, no admin rights). A physical device is never required, at any tier. AI policy — explain, never source. You may use a language model to explain a mechanism. You may not take a number, a date, a CVE identifier, an attack name, or a key size from one. Every such figure in your submission must cite a primary document you personally opened. Per Appendix D, a fabricated figure is an integrity failure, not a deduction.

The Setup

You have been retained for two weeks by an organization that is about to buy a lot of hardware, and the person who signs the cheque has read a brochure.

Pick one of these four engagements. Each is real work; none is harder than the others; choose the one you can argue about most concretely.

1. The clinician’s tablet. A regional health system is deploying tablets to nurses who move between patient rooms, a shared charging cart, and their own cars. The tablets hold patient records locally so they keep working when the building’s Wi-Fi does not. Devices are lost at a steady, predictable rate. The compliance officer wants to know what the hardware guarantees when a device is not recovered.

2. The journalist’s phone at a border. A newsroom equips reporters who cross national borders where the device may be taken out of sight for an hour. On the phone: contact records, draft material, and credentials for the newsroom’s systems. The security editor’s question is blunt — after that hour, what can they still assume?

3. The warehouse wearable. A logistics company is deploying a wrist-worn scanner to twelve thousand workers. It holds a fleet credential that authenticates to the warehouse management system, and it is cheap, replaceable, and frequently taken home by accident. The operations director wants to know what one stolen unit is worth to an attacker.

4. The consumer headset. A headset ships with cameras that map the user’s living space, an on-device model that runs continuously, and a payment credential for the store. The product manager wants to know which of those three assets is most exposed and what changes if the model weights are considered valuable intellectual property.

Whichever you pick, the deliverable is the same, and the graded core is the same: the residual risk. Anyone can list mechanisms. Your value is knowing, for each one, exactly what it does not cover — and saying so to a person who would prefer not to hear it.

Setup (the starter)

Everything you need is in this chapter’s code/ folder:

• code/boot-chain.csv — a generic six-stage boot chain. Synthetic teaching data; it describes no vendor’s actual chain, and your report must say so where you use it.
• code/chain_check.py — injects faults into that chain and reports the first untrusted stage plus the software-attacker and physical-attacker capabilities.
• code/timing_leak.cpp — the side-channel demonstration. C++17, no dependencies, runs anywhere you have g++.
• code/pqc_budget.py and code/pqc-sizes-example.csv — the post-quantum budget worksheet. The CSV ships full of zeros on purpose (Medium tier).

The Chain of Trust Inspector widget on the chapter page is the fastest way to sanity-check your asset placements before you commit them to the report.

Learning Targets

By completing this project you will demonstrate that you can:

• Build a threat model that names specific adversaries with specific capabilities, rather than “attackers.”
• Trace a chain of trust to its anchor and state what the anchor rests on.
• Assign each asset to a security domain and defend the assignment against a stated adversary.
• State the residual risk of each mechanism — what it does not cover — without hedging.
• Measure a real hardware side channel, report it per Appendix C, and price the mitigation in the units the decision is actually made in.
• Distinguish a figure you verified in a primary source from a figure you were handed, and refuse to publish the second.

Normal Tier

Goal: produce a defensible threat-model-report.docx for one device in one scenario, backed by two measurements you took yourself.

Required work

1. Name the engagement. One paragraph: which of the four scenarios, what the device is expected to do, and — the part people skip — what would count as a bad outcome for this specific user. A stolen warehouse scanner and a seized journalist’s phone are bad in completely different ways, and every later judgment depends on which kind of bad you are preventing.

2. The asset table. At least five assets, each with: what it is, why it has value to the adversary (not to the user), and what its exposure would cost. Include at least one asset that is not data — a capability, an identity, or a credential that lets the holder act as the device.

3. The adversary table. At least three adversaries drawn from the chapter’s five categories, each with an explicit capability list. Not “a hacker” — “a person with physical possession for one hour, ordinary tools, no die-level equipment, and no ability to keep the device.” One adversary must have physical possession, because that is what makes this a mobile threat model.

4. The mechanism-and-residual-risk matrix. The core of the grade. One row per asset:

   Asset	Defending mechanism(s)	Which adversary it stops	Residual risk — what it does not cover

   Every residual-risk cell must be a specific, falsifiable statement. “Some risk remains” earns zero. “Verified boot does not prevent a live browser exploit from reading this asset while the device is unlocked and running” earns full marks.

5. The chain analysis. Run chain_check.py on the nominal chain and on at least three single-fault injections you chose because they matter to your scenario. Paste the raw output. For each fault, state in one sentence what your named adversary gains. Then state plainly that boot-chain.csv is synthetic teaching data and what that limits about your conclusions.

6. The side-channel measurement. Build and run timing_leak.cpp. Report in measurements.xlsx per Appendix C: the machine, the compiler and optimization level, the repetition count, the median and dispersion for both compares, and the naive-versus-constant-time spread. Then, in report.docx, one paragraph relating that result to your threat model: is there a comparison of this shape anywhere in your device’s story, and if not, say so honestly rather than inventing one.

7. The one-sentence verdict. End threat-model-report.docx with a single sentence, addressed to the person paying you, stating what this device can and cannot promise in this scenario. One sentence. If it takes three, you have not decided anything yet.

8. ai-usage.txt. Where a model helped you understand, what you asked, and — explicitly — a statement that no figure, date, identifier, or attack name in this submission came from a model. If one did and you verified it afterwards, say which and where you verified it.

Normal-tier rubric (out of 100)

Medium Tier (+up to 25% extra credit)

M1 — The post-quantum migration budget

Your organization has been told it must have a “PQC migration plan.” Give them one that is three pages and true rather than thirty pages and borrowed.

Copy code/pqc-sizes-example.csv, fill in every row from the primary standards — FIPS 203, FIPS 204, FIPS 205, and the specification for whichever classical scheme you compare against — set verified=yes on each, and record the document plus the table or section number in the source column. Then run:

python3 code/pqc_budget.py --sizes my-pqc-sizes.csv --handshakes-per-day <your number>
python3 code/pqc_budget.py --sizes my-pqc-sizes.csv --handshakes-per-day <your number> --se-bytes <your budget>

Add a section to report.docx containing:

• Your filled CSV, committed, with every source cell populated. An unsourced cell scores zero for the row; a wrong number with a citation scores partial credit, because it is correctable. A right number with no citation scores nothing, because nobody can check it.
• The handshake rate you chose for your device and why. A warehouse scanner and a journalist’s phone do not handshake at the same rate; defend yours.
• The monthly byte delta per device and across the fleet, arithmetic shown.
• Whether the private key material fits your stated secure-element budget, and what you would do if it did not.
• The tool’s model, criticized. pqc_budget.py documents its handshake model at the top of the file. Name the assumption you think most distorts your answer and say in which direction.

M2 — Before-and-after on the AI

In the same section, report the experiment from Rep 10: what a language model told you the sizes were before you looked them up, how many it got right, and whether you could tell the wrong ones from the right ones by tone. Two short paragraphs. This is graded on honesty and specificity, not on the model’s score.

Hard Tier (+up to 25% additional extra credit)

H1 — The mitigation you would decline

Write report.docx’s closing memo — one page, addressed to the engineering director — recommending one specific security mitigation that you would not enable on this device, in this scenario.

The memo must contain, in this order:

1. The mitigation, named precisely, and the class of attack it defends against.
2. The measured cost. Use your own numbers. The constant-time-versus-early-exit measurement from the Normal tier is a legitimate and sufficient proxy if you argue the analogy explicitly; if you measure something else, say what and how. A cost you did not measure cannot appear in this memo.
3. The adversary you are accepting. Name them, from your own adversary table, and state what they gain from your decision. Do not soften this. If your recommendation means a physical-possession adversary can do something they otherwise could not, write that sentence.
4. Who bears the risk. The user, the organization, or a third party — and whether they are in a position to know they are bearing it. This is the sentence most memos omit and the one an ethics review reads first.
5. The condition that would reverse your decision. A concrete, checkable trigger: a threat-intelligence change, a measured cost falling below a stated threshold, a change in the deployment population. “If circumstances change” is not a trigger.

What fails this tier: a memo that recommends declining everything (“security theater, all of it”), a memo that recommends declining nothing (“enable it all, safety first”), and a memo whose cost figure has no measurement behind it. All three are positions taken instead of decisions made.

Why this is the Hard tier. A model can enumerate mitigations, and it will do so faster and more completely than you. What it cannot do is decide, for a named product serving named people against a named adversary, which protection is not worth its price — and then sign its name to that. Chapter 7’s law says the tradeoff cannot be engineered away, only decided. This memo is you deciding.

Submission

Submit one URL: a public repository containing:

1. threat-model-report.docx — assets, adversaries, mechanism-and-residual-risk matrix, chain analysis, verdict.
2. report.docx — the narrative: scenario, methodology, side-channel discussion, the Medium PQC section if attempted, the Hard memo if attempted.
3. measurements.xlsx — the measurement log per Appendix C: every run, the conditions, medians and dispersion.
4. ai-usage.txt — the honest disclosure.
5. raw/ — unmodified tool output: every chain_check.py run, every timing_leak run, every pqc_budget.py run, and your filled my-pqc-sizes.csv if you attempted Medium.
6. A short README.txt naming your scenario and the tier you targeted.

Suggested front matter for threat-model-report.docx:

# Threat Model — <device> in <scenario>

**Bad outcome for this user:**  (one sentence)
**Adversaries modeled:**  (three or more, with capabilities)
**Assets:**  (five or more)
**The single largest residual risk:**  (one sentence, no hedging)
**Verdict:**  (one sentence, addressed to the decision-maker)
**Synthetic data used:**  boot-chain.csv (teaching dataset, not any vendor's chain)
**AI usage:**  see ai-usage.txt

Hints (Read Before You Begin)

• Write the adversary table before the mechanism table. Every year, half the submissions list mechanisms first and then reverse-engineer adversaries to justify them. It shows immediately, because the adversaries end up being exactly the ones the mechanisms happen to stop.
• The residual-risk column is a test of nerve, not of knowledge. You already know that verified boot does not stop a live exploit. The difficulty is writing it down in a document someone is paying for. Write it down.
• Distinguish “the mechanism failed” from “the asset was never behind it.” Most real losses are the second. Ask of every asset: is there a copy of this outside the domain I assigned it to? Caches, logs, backups, and screenshots are where assets go to escape their boundary.
• Run timing_leak.cpp more than once and on an idle machine. A single run on a busy laptop is noise. Report the median and the spread, state the conditions, and never compare two runs taken under different conditions — Chapter 8 grades exactly this.
• Say “synthetic” out loud. boot-chain.csv is a teaching dataset. Using it as evidence without labeling it is the same error as citing an invented number, and Week 8 grades the distinction directly.
• On the physical adversary, think in cost, not in yes/no. “A physical adversary can extract this” is almost always true given infinite resources. The useful statement is “extracting this requires die-level work on a destroyed unit, which is above what we model for a lost-device population, and below what we would model for a targeted one.”
• When you catch yourself writing “secure,” stop and write the narrow sentence instead. Secure against whom, holding what, for how long. Every time.

What Mastery Looks Like (Beyond the Rubric)

A great Project 7 reads like something a security architect would put their name on. The adversaries are specific enough that you could argue with them. The asset table values things from the attacker’s side, which is the shift most students never make. The residual-risk column is uncomfortable to read and impossible to dispute, because every cell says one concrete thing that one named adversary can still do. The measurement is real, taken more than once, reported with its conditions, and used for something rather than decorating the appendix.

And the verdict is a single sentence that a non-specialist could act on. Not “the device implements multiple layers of hardware-backed protection.” Something more like: “If this tablet leaves the building and is not recovered, patient records at rest are protected against everything short of die-level attack, and any session the nurse left unlocked is not protected at all.” That sentence took a whole project to earn, and it is the only part of the report the person paying you will remember.

Coach’s Note — The temptation in every threat model is to write toward reassurance, because the person who hired you wants to be reassured and you want to be hired again. Resist it precisely and cheerfully. Your value is not that you make people feel safe; it is that you tell them, accurately, what they are safe from — which is the only information that lets them decide anything. Reassurance is free and worth what it costs.

When You’re Done

1. Read every cell of the residual-risk column aloud. Any cell that could apply to a different device is too vague — rewrite it until it names this asset, this mechanism, and this adversary.
2. Check that every external figure — a date, a standard number, a CVE identifier, an attack name, a key size — has a primary-source citation next to it. Delete any that does not. Deleting it is always the correct move; it is never the expensive one.
3. Confirm measurements.xlsx states the machine, the compiler, the optimization level, the repetition count, and the dispersion. A median with no dispersion is half a measurement.
4. Confirm you labeled boot-chain.csv as synthetic wherever you used it as evidence.
5. (Hard) Re-read your memo and find the sentence where you name the adversary you are accepting. If there is no such sentence, you wrote a recommendation, not a decision. Add it.
6. Commit, push, submit the URL.
7. Read Chapter 8. Next week is honest measurement — including the honest measurement of exactly what your mitigations cost, which is the number this project asked you to reason about and next week asks you to produce.

A theological footnote. “Unless the LORD builds the house, those who labor to build it labor in vain” (Psalm 127:1, ESV). The verse goes on to the watchman who stays awake in vain, and this week you learned what that looks like in silicon: a chain of trust whose anchor is unsound still validates every signature, still shows a green boot state, still convinces a remote server. The watchman is not merely useless then — he is generating confidence, which is worse, because people sleep on it. Your work here is the alternative. You did not lay this foundation; you cannot fully inspect it; and the honest response is neither despair nor the pretense that you can. It is to verify what you can verify, to say plainly what you are taking on trust, and to refuse to manufacture assurance you have not earned. That is the whole of the residual-risk column, and it is the whole of the watchman’s honest work.

See you next week.