Chapter 7 — Reps

Conditioning, not grading. This week’s reps are the security reflexes: reading a chain of trust before you break it, naming what each break buys an attacker, placing assets in domains, measuring a real side channel on your own machine, and sourcing a number from a standard instead of from a confident stranger.

Ground rules:

1. Type every command yourself. No copy-paste from the chapter. Your fingers should learn chain_check.py --fault noverify:kernel and g++ -O2 -std=c++17 cold, because in a design review nobody hands you the flags.
2. Run everything. Every rep here works on Workbench L and Workbench B — a laptop or a browser dev environment with a C++17 compiler and Python 3, per Appendix A. Nothing this week requires a device.
3. Predict before you measure. Every rep that produces a number asks you to write your prediction first. The gap between your prediction and the measurement is the entire lesson; a rep where you were right teaches you almost nothing, and one where you were wrong teaches you a great deal.
4. AI policy — explain, never source. You may ask a model to explain a mechanism to you. You may not take a number, a date, a CVE identifier, an attack name, or a key size from it. Anything of that kind in your written answers must come from a primary document you personally opened, named in your answer. End each AI-touching rep with a one-line AI usage note.
5. Record measurements like a professional. Median of several runs, plus a dispersion figure and the conditions, per Appendix C. A single number is not a measurement.

The chapter’s code/ folder has everything referenced below.

Reps 1–3: The Chain of Trust

Rep 1 — Read the boot chain before you break it

Open code/boot-chain.csv and read it top to bottom — including the comment block, which explains the linearization and the meaning of the mutable column.

python3 code/chain_check.py

Predict first, on paper, before running anything: for each of the six stages, write one sentence saying what authenticates that stage. Then check your six sentences against the key_source column.

Now the question that matters. Two stages have mutable=no for completely different reasons. Which two categories are they, and which stage belongs to which? Write two sentences. If you cannot answer this, re-read §7.2 — it is the chapter’s central idea and every later rep leans on it.

Rep 2 — Break the chain with one injected fault

Inject exactly one fault at a time and read the two attacker-capability lines the tool prints:

python3 code/chain_check.py --fault noverify:bootloader_stage_1
python3 code/chain_check.py --fault mutable:trusted_os
python3 code/chain_check.py --fault rollback:kernel
python3 code/chain_check.py --fault key:boot_rom

Predict first: for each of the four, write down (a) which stage you expect to become the first untrusted one, and (b) whether you expect the software attacker and the physical attacker to get the same answer. Then run them.

Write down: the one fault above that you think buys a remote attacker the most, and the one that buys a physical attacker the most. They are not the same fault. Explain why in two sentences, naming what the attacker can now do.

Rep 3 — Sweep every fault and rank them

python3 code/chain_check.py --all

Twenty-four single-fault injections, one table. Two of them report — none (no effect).

Answer three things. First: which two have no effect, and why is that architecturally correct rather than a bug in the tool? Second: rank the four fault types (mutable, noverify, rollback, key) by how much a single instance of each buys an attacker, and defend the ranking. Third — the real one — for one fault of your choosing, write the sentence a vendor’s release notes would use to describe fixing it, without lying and without alarming anyone. That sentence is harder than it looks, and you will write several like it in your career.

Then break two links at once. Faults compose, and the tool takes --fault more than once:

python3 code/chain_check.py --fault rollback:bootloader_stage_2 --fault noverify:kernel

Write one sentence on whether two faults gave the attacker more than the worse of the two alone, or merely the same thing by two routes. Both outcomes occur in this chain; say which one you got and why.

Reps 4–6: Domains, Assets, and Isolation

Rep 4 — Place every asset in the right domain

No tools. Paper and head only. Here are your assets and your domains.

Assets: a biometric template · the disk encryption key · a payment credential · ordinary application data (photos, messages) · the weights of an on-device model your company paid to train · a device attestation key · a session cookie for a web login.

Domains: normal world · TEE (secure world) · secure element · nowhere on this device.

For each asset, write: the domain, one sentence of justification, and — this is the graded habit — one sentence naming what the placement still does not protect against. Then use the chapter’s Chain of Trust Inspector widget, Panel 2, to check yourself on the five it covers.

Then argue with yourself. Two of these assets have a defensible answer in more than one domain. Identify them and write the strongest case for each side. If you found only one, you have not thought hard enough about the model weights.

Rep 5 — Isolation by mode versus isolation by silicon

Write a short comparison — half a page, no more — that a competent engineer who has never heard of TrustZone could read once and use.

Cover, in your own words: what the NS bit does that a coprocessor cannot do; what a separate die with its own memory gives you that a mode of the shared cores cannot; and the cost of each in area, power, and flexibility. Then answer the question the chapter refuses to answer for you:

Your product must protect exactly one asset — a signing key used a handful of times per day — against an adversary with unrestricted physical possession for a week. You may add either a TEE or a discrete secure element, not both. Which, and what does your choice fail to protect?

AI usage: you may ask a model to explain the Realm Management Extension or the NS bit. You may not let it write the paragraph. Note what you asked.

Rep 6 — Draw the two axes

On one sheet of paper, draw exception levels EL0–EL3 on one axis and the security worlds on the other. Place these on your grid: a browser tab, the OS kernel, a hypervisor, secure monitor firmware, a trusted application doing biometric matching, and a trusted OS.

Then answer three questions. Is EL3 “more privileged” than the Secure world’s EL1, and is that even the right question? What stops a Normal-world EL1 kernel — which is genuinely privileged, and owns every page table in its world — from reading Secure-world memory? And where on your grid does a DMA-capable device with no exception level at all belong? Two sentences each. Most students get the second one wrong on the first attempt by answering “the MMU,” which is exactly why it is a rep and not a footnote.

Reps 7–9: A Side Channel You Can Measure

Rep 7 — Measure the timing leak

Build it and run it:

g++ -O2 -std=c++17 -o timing_leak code/timing_leak.cpp
./timing_leak

Predict before you look at the output. Sketch, by hand, the shape you expect for the naive column as the matching prefix grows (flat? linear? a step?) and the shape you expect for the constant-time column. Commit to it in writing.

Now run it three times and record the median and the spread per Appendix C. Write down: the naive spread, the constant-time spread, and the ratio between them. Was your predicted shape right? What in the source code produces that shape — quote the line.

Rep 8 — Make it harder, and price the fix

Two variations. First, shrink the buffer to a realistic MAC size:

./timing_leak --bytes 32 --reps 200000 --trials 9

Predict: does the leak disappear, or does it merely get smaller? Run it and answer with numbers.

Second, price the mitigation from your own data. In the 4096-byte run, compare the naive compare’s best case (zero matching bytes) against the constant-time compare’s single time. Write down the factor by which the mitigation slowed the common case, and then the sentence a product manager needs to hear: what you gave up, what you bought, and for which adversary. That sentence is the shape of the Hard tier memo in the project.

Optional, go further: rebuild at -O0 and at -O3 and record whether the leak’s magnitude changes. Note in your log that optimization level is now part of your stated conditions — because it is.

Rep 9 — Turn the leak into an attack, on paper

No code. Write the algorithm.

Given only (a) the ability to submit a candidate buffer and (b) a timing measurement of the check, describe how you would recover a 32-byte secret using the naive comparison. State the number of candidate submissions your approach needs as a function of the secret length and the alphabet size, and compare it to brute force.

Then the honest part: name two real-world conditions that would make your attack fail in practice — network jitter, rate limiting, whatever you can defend — and say what an attacker would do about each. An attack you cannot criticize is an attack you do not understand.

Finally, generalize it. Your algorithm depended on one property of the implementation: that time varied with a secret. Name two other observable quantities on a mobile device that could carry the same information if they varied the same way, and for each say what an architect would have to give up to make it stop varying. This is the chapter’s law in your own words, and you will need it for the project’s Hard tier.

Reps 10–11: The Post-Quantum Budget

Rep 10 — Fill in the post-quantum size table from a primary source

Run the tool as shipped and read what it refuses to tell you:

python3 code/pqc_budget.py

Now copy the template and fill it in:

cp code/pqc-sizes-example.csv my-pqc-sizes.csv

Open my-pqc-sizes.csv. For each row: choose a parameter set, look the size up in the primary standard — FIPS 203 for ML-KEM, FIPS 204 for ML-DSA, FIPS 205 for SLH-DSA, and the relevant specification for whichever classical scheme you compare against — replace the 0, set verified=yes, and record the document and the table or section number in the source column.

Before you look anything up, do this: ask a language model for all fifteen numbers and save its answer to a file. Then look them up yourself. Write down how many the model got right, how many it got wrong, and whether its tone differed between the two. This is the single most important rep in the chapter, and it takes ten minutes.

AI usage: required, and the point of the exercise. Name the model and version.

Rep 11 — Price the migration on a metered radio

With your verified file:

python3 code/pqc_budget.py --sizes my-pqc-sizes.csv --handshakes-per-day 200
python3 code/pqc_budget.py --sizes my-pqc-sizes.csv --handshakes-per-day 1000 --se-bytes 32768

Predict first: before running, estimate the per-handshake byte ratio between your classical and your lattice post-quantum configuration to the nearest whole number. Then check.

Write down three things. (1) The extra bytes per device per month at 1000 handshakes/day, with the arithmetic shown. (2) Whether the private key material fits a 32 KiB secure element, and how many key pairs of that kind do fit. (3) The one assumption in the tool’s handshake model that you think most distorts the answer — the model is documented at the top of code/pqc_budget.py precisely so you can attack it. Read the model before you criticize it.

Done? One Last Thing.

This is the project in miniature — the threat model on one page.

Pick one device in one scenario: a clinician’s tablet on a hospital network, a journalist’s phone crossing a border, a warehouse wearable, or a consumer headset. Then produce a single page with four columns:

Fill in exactly three rows — three assets, three adversaries, three mechanisms, three residual risks. Three is the constraint that makes this hard: you must choose the assets that actually matter and defend leaving the others out.

Then write two sentences below the table:

1. The one thing this device cannot protect against, stated plainly, with no hedging and no marketing.
2. The one change you would make to the hardware or the deployment if you were allowed exactly one — and what it would cost.

Keep this page. It is the skeleton of the threat-model-report.docx the project asks for, and you have just drafted it.

Up next: Project 7 — Project 7: The Silicon Threat Model.