skip to content

A posture document carries a TPM quote plus agent-reported fields. Which facts does the quote vouch for once an attacker has post-boot code execution?

level: middleimportance: should knowfreq 46%

answer

  1. boot measurements, not runtime state
  2. nonce for freshness, hardware key for origin
  3. attested, inferred, claimed
  4. the quote stays true while the blob lies
  5. measured boot records, secure boot refuses

basics

~20 s

Only the boot-time measurements it signed, freshly, with a key that cannot leave the hardware. It says nothing about what is running now, so an implant loaded after boot leaves the quote valid and every other field still a claim.

solid answer

~50 s

A quote is a hardware-held key signing a digest of measurements recorded while the machine booted, over a nonce the verifier supplied so the answer cannot be an old one replayed. That gives you two provable facts: this is the device whose attestation key you bound at enrolment, and its firmware, bootloader and kernel measured to these values at boot. Everything else in the document — patch level, encryption on, agent running, lock timeout — is still the endpoint's own word, because no hardware root observes user-space state. So an attacker who lands after boot inherits a device that can keep producing genuinely valid quotes. The payoff is that your attestable schema is much smaller than your posture schema, and the price is that the remaining signals have to be either designed into an architectural implication, re-measured on a schedule, or dropped from the decision.

code

json · 15 lines
json
{
  "device": "laptop-4471",
  "attestation": {
    "nonce": "9f2c... (issued by the verifier for this request)",
    "signing_key": "attestation key bound to this TPM at enrolment",
    "boot_measurement_digest": "sha256:1a4b...",
    "signature": "..."
  },
  "reported": {
    "disk_encryption": "on",
    "os_patch_level": "2026-08",
    "edr_service": "running",
    "screen_lock_seconds": 300
  }
}

go deeper

for a junior

Know that a hardware root can sign a fingerprint of what loaded at boot, and that a private key which never leaves the chip is what makes that signature mean anything.

for a middle

Explain the mechanics: measurements extended during boot, a verifier nonce for freshness, and why nothing extends those registers once user space is running.

for a senior

Sort a real posture schema into attested, inferred and claimed in front of the interviewer, and say what you would change in the design for each bucket.

for a principal

Be ready to argue what a smaller attestable schema is worth against what it costs — sealing designs that break on firmware updates, re-attestation traffic, and hardware you have to fund.

## The three things a quote contains A remote-attestation quote is not a health certificate. Broken down: - **A set of measurements.** During boot, each stage hashes the next before handing control over, and the hashes are extended into registers inside the hardware root of trust. The register values are a fingerprint of what loaded, in what order. - **A signature by a key that cannot be exported.** The attestation key lives inside the hardware; the private part never appears in memory the operating system can read. The verifier bound that key to a device identity when the device was enrolled. - **A verifier-supplied nonce.** Without it, a quote is just a recording and can be replayed. With it, the verifier knows the signature was produced now, in response to this challenge. So the honest statement is: *this specific hardware root asserts that this boot chain measured to these values, and it is saying so right now.* ## What it therefore does not cover Measurement stops when the measured chain stops measuring. Nothing extends a register when a user-space process starts, when a service is killed, when a driver is loaded later, or when an implant is injected into a running process. An attacker who achieves code execution after boot changes none of the values the quote signs — the quote stays valid and stays true. That is the sentence the question is aimed at, because the common senior-level wrong answer is that attestation means the device is clean. It means the device *started* in a known state and that the thing answering is the hardware you enrolled. ## Attested, inferred, claimed The useful discipline is to sort every posture field into three buckets: - **Attested** — boot-chain measurements, and possession of a hardware-held key. Survives a compromised operating system for the fact it asserts. - **Inferred** — facts implied by an architectural design rather than reported. The strongest common example: if the volume key is sealed to the boot measurements, then the volume unlocking at all implies the boot chain was unmodified. You did not read a field; you arranged for the system not to work otherwise. - **Claimed** — patch level, whether a security service is running, screen-lock configuration, installed software inventory. Composed by an agent, on the suspect machine, always. Most real posture schemas are 80% claimed, and the interview value is in saying so without flinching. ## Secure boot and measured boot are different tools Secure boot **enforces locally**: unsigned or untrusted components are refused at load time, and if enforcement works, no evidence leaves the machine. Measured boot **records**, then lets a remote verifier decide. Zero-trust enforcement needs the second, because the verifier is not on the device and must be able to judge for itself. Candidates who use the two words interchangeably lose the point. ## Borrowing versus lying Two distinct attacks, two distinct answers: - **Borrowing (relay).** A compromised machine presents a quote captured from a healthy one. The nonce stops the stale replay; binding the attestation to the key or channel used for the actual connection stops the live relay, so a quote authorises only the session whose key it was bound to. - **Lying.** The attacker is on the attesting device itself, and simply asks the hardware for a fresh, correctly bound quote. Nothing stops this, and nothing is meant to — the quote is true. It is the *other* fields in the document that are the lie. Only the first has a cryptographic answer. The second has a design answer. ## The price you pay for a smaller attestable schema Once the claimed bucket is named, the design has to absorb it: | Choice | What it costs | | --- | --- | | Re-attest periodically during a session | more challenge traffic, and a window that is never zero | | Convert a claim into an inference (seal keys to measurements) | design work, and devices that stop booting when a legitimate firmware update changes measurements | | Keep the claim but shrink what it authorises | user friction on the tier that relies on it | | Require attesting hardware for a cohort | capital spend and a refresh cycle somebody funds | That last row is where the whole conversation usually ends up, and the sealing row carries the operational sting people forget: measurements legitimately change when firmware is updated, so a sealed-key design needs a re-sealing path or a fleet of laptops will refuse to unlock the morning after an update.

  • How do you stop a healthy device's quote being relayed for a compromised one?
    Bind it. The verifier's nonce kills the stale replay, and binding the attestation to the key or channel used for the actual connection means a quote authorises only that session, so it cannot be collected on one machine and presented from another. Note what this does not do: an attacker sitting on the attesting device gets a fresh, correctly bound quote of their own. Binding stops borrowing, never lying.
  • Can disk encryption ever be more than a claim?
    Indirectly, yes. If the volume key is sealed to boot-time measurements, the volume only unlocks under an unmodified boot chain, so the machine working at all implies something a report cannot. The strength comes from the sealing design, not from the field that says encryption is on. The operational cost is that a legitimate firmware update changes the measurements and you need a re-sealing path.
  • What does measured boot give you that secure boot does not?
    Evidence that leaves the device. Secure boot refuses to load components that fail a local signature check, and when it works it produces nothing a remote verifier can inspect. Measured boot records what loaded into hardware registers so an off-device verifier can judge for itself. Zero-trust enforcement needs the second because the decision point is not on the endpoint.

saying these in an interview costs you the question

  • Says a TPM quote proves the security agent is running
  • Treats a device certificate in a software keystore as attestation
  • Believes attestation is continuous rather than point-in-time
  • Uses secure boot and measured boot as synonyms
  • Concludes a passed quote means the device is not compromised

context

resolving links…