Start with a device that asks to connect
A factory gateway wants permission to perform maintenance. The service recognizes its identity, but cannot see how it just started: did it load approved firmware, or a replaced component? This classroom follows that question through local startup checks, recorded measurements, and evidence a remote verifier can appraise.
The service needs more than a recognized device name. It checks measurements, their trusted source and freshness, then applies its own access policy. PCRs and signed quotes provide one common implementation example; familiarity with TPMs is not required.
A device says it is safe. Should the service believe it?
A factory gateway asks a management service for permission to perform maintenance. The service recognizes its device identity, but it did not watch the gateway start. Did it load approved firmware, or a version that was replaced? “I am this device” and “I am in an acceptable state right now” are different claims.
Start by naming three things: what needs protection, who is deciding, and what the remote side cannot see. Here, the management service is deciding whether to grant maintenance access. It cannot look inside the gateway during startup, so it needs a way to check which components the gateway loaded.
That is the threat-model question. An attacker might replace firmware, but a normal update or a configuration fault could also produce a different startup state. A different measurement is a reason to investigate; it is not proof of an attack. The service still needs evidence before handing out a high-privilege operation. [1]
Now separate “which device is connecting?” from “what state did it start in?” Device identity helps answer the first question. Startup evidence describes selected components measured during a particular boot. Remote attestation gives another party a way to appraise that evidence before the service makes its decision.
Pause here: if you managed this service, what evidence would you ask the gateway to provide?
Can the same device identity hide different startup states?
The same gateway can install an approved update today and load a different version tomorrow. It might also have had a component replaced. Its serial number and network credential can stay the same while its startup state changes.
Think of a device certificate as a checkable identity credential. It can help show that the other side holds a key associated with a registered device. It does not tell the service which firmware that device loaded five seconds ago.
Startup measurements answer a different question. They describe selected software or settings observed during a particular boot, and they cover only what the platform measures. The service needs both kinds of evidence: identity tells it which device is asking; measurements help it assess the state that device is reporting. [1]
Secure Boot checked locally. Why does the remote service still need evidence?
Secure Boot is primarily a local execution control. In a protected startup path, the device checks the next stage against local trust material and policy; an item that fails can be rejected before it receives control. This reduces the chance that unauthorized code runs early in the boot process.
Follow the boot chain one handoff at a time. An earlier protected stage checks the next stage against local trust material and policy, then decides whether to let it run. Exactly which code is covered depends on the product's design and configuration.
That local decision does not automatically give the management service a record it can verify. A gateway saying “Secure Boot is enabled” is still a statement from the gateway. The service must know who produced the evidence, what it covers, and whether the response answers this connection's request. [1][2]
Measured Boot can leave selected startup measurements for a remote verifier to examine; Secure Boot can enforce a local allow-or-block decision. The two can work together, but neither replaces the other's job.
What does Measured Boot record?
Measured Boot records selected startup events. Depending on the platform, those events can include firmware, a boot manager, an operating-system loader, or configuration data. A verifier can later inspect the record and ask whether the reported startup path matches an expected one.
A measurement is usually a cryptographic digest of the selected content, not a copy of the entire firmware file. The event log may also carry an event type and descriptive information so a verifier can tell which component a measurement is meant to represent. A digest is a fingerprint to compare; by itself, it does not label the component approved or unsafe.
In a staged startup, an earlier stage may measure the next component before handing over control. For example, firmware may measure a boot manager, which may then measure the operating-system loader. The exact stages, event formats, and configuration data included depend on the platform; a PC profile is one implementation example, not a universal boot sequence. [2][3]
Keep the distinction clear: recording a measurement does not itself block the measured code. Secure Boot can make the local execution decision; Measured Boot leaves information for later review. To know what the evidence means, the verifier still needs trusted reference values and a policy. [2][3]
Why does the order of the measurements matter?
Picture a TPM Platform Configuration Register (PCR) as a small, protected field that accumulates measurements. An extend operation combines its current value with the new measurement and hashes the result back into the register. A simplified form is `new = Hash(old || measurement)`. The previous value stays part of every next step. [2]
That is why order matters. Extending firmware and then the boot manager usually produces a different final value from extending the boot manager first. It works more like a running calculation than a checklist: the final value carries information about the sequence, not just the set of filenames.
A verifier can replay the event log in order and compare its result with the PCR value. But that only checks events that were actually sent into the register. If a component was never measured, it will not appear in the evidence just because the surrounding stages did leave a record. [2]
If an event log can be changed, how can it still help?
The event log is useful because it shows the steps behind an accumulated PCR value. It is often stored where software can read it, so the verifier should not assume that the log itself is impossible to edit. The TPM's job is different: protect selected PCR state and produce a signed quote over chosen values.
The quote is signed with an Attestation Key (AK) associated with the TPM. The verifier can check that signature against the expected key, then replay the event log in order: extend each logged measurement and see whether the calculated PCR values match those in the quote. A changed, removed, or reordered entry will usually break that match. [2][3]
The log and quote answer complementary questions. The log gives a readable account of events; the quote gives signed evidence of the accumulated PCR state. Comparing them can reveal changes to the log, even when the log was not signed separately. RFC 9683 describes one network-device implementation using TPMs; other platforms may use different PCR assignments and event formats. [2][3]
A match still does not say that the measured software is safe. It says the event sequence in the log is consistent with the PCR values in the quote. The verifier must also trust the key and measurement path, then compare the measurements with reference values and policy.
How can we stop an old, good report from posing as a current one?
Suppose the gateway passed its check last month and an attacker recorded the response. If the management service asks only “send your evidence,” that old response may look like a current one. The service needs a way to tie its request to the reply it receives.
A common method is a nonce: the verifier generates a fresh, unpredictable random value and sends it as a challenge. The device includes that value in the signed quote along with the requested PCR values. The verifier checks the signature and confirms that the returned nonce is the one it just sent. [1][2]
A quote recorded last month contains last month's challenge, not today's. It therefore cannot be copied unchanged as a reply to the new request. But the nonce only ties the signed response to the challenge; it does not prove that every underlying measurement was collected at that same moment. [1]
For example, measurements collected at boot might be saved until the device reaches a network and receives a nonce. The verifier still needs a trusted design that tells it whether those saved measurements remain relevant to the state it wants to assess. RFC 9334 also describes timestamps and epoch IDs as other freshness approaches. [1]
Who supplies the evidence, who checks it, and who grants access?
Three roles help explain the handoff. The attester supplies claims and evidence about the device. The verifier appraises that evidence using trust information, reference values, and policy. The relying party, which controls the requested service, uses the result to make an access decision. [1]
The attester can include both the TPM and the platform software that collects startup events. A TPM does not necessarily discover every component on its own; in common designs, another trusted stage feeds measurements into its PCRs. The verifier must therefore assess the evidence-producing path, not just see a signature and stop asking questions. [1][2]
The verifier checks the quote, the event log, freshness, and the policy's reference data, then returns an attestation result. The relying party makes the service-specific choice: allow maintenance, restrict it, or deny it. The verifier's assessment and the service's authorization are separate decisions, even when one server performs both jobs. [1]
These are responsibilities, not necessarily three boxes in a network diagram. A small deployment can combine verifier and relying party in one service. A larger one can separate them. Either way, the design needs to say who produces the evidence, who evaluates it, and who is accountable for granting access. [1]
What does the verifier compare the evidence against?
A digest has no built-in label saying “approved firmware.” The verifier needs trusted reference information that connects a measured value to a component, version, or configuration. It also needs a policy that says which of those states are acceptable for this device and this request. Freshness matters, or correct evidence from an earlier boot could be mistaken for the current state. [1]
Consider a firmware update. The new image will usually produce a different measurement, so the reference information must identify whether that version was approved for this product. The verifier should not accept an unfamiliar digest just because the device reports it confidently.
Policy can be more specific than exact equality with one digest. It may accept a defined set of versions, a permitted range, or a relationship between several claims. What is allowed for a routine status check may not be enough for an operation that can change a production line. [1]
Reference values need their own protected approval, distribution, and retirement process. Stale data can cause false alarms; data that an unauthorized person can alter can make an unsafe state look acceptable. The verifier has to trust both the device evidence and the source of its comparison rules. [1]
What should happen when the evidence does not match?
When evidence differs from the current reference, the service has a decision to make. It might pause a high-risk maintenance command while allowing a lower-risk diagnostic connection. It can preserve the event log and quote, then compare them with the device's approved update and configuration records.
That pause matters. If the difference came from a legitimate update, an operator can confirm the release and update the reference data through the approved process. If the change is unexpected, the service can isolate the gateway, investigate it, or move it into a controlled recovery path. Those actions belong to the service's policy; attestation supplies evidence for the decision.
A mismatch is a warning, not proof of an attack. A new but legitimate firmware release may not yet be in the reference set, or the policy may not match that model. At the same time, automatically trusting every new value would give an attacker a way to bless a replacement. [1]
It helps to keep “approved,” “unknown,” and “verification failed” as separate outcomes. Each can have a different response: limited access, operator review, or isolation. Define those responses before an incident, and keep a safe recovery route that does not silently turn off verification. [1]
Does a passing attestation mean the device has no vulnerabilities?
A passing result means the verifier accepted the evidence it received under a particular set of rules, for this check. It does not certify the whole device as vulnerability-free, and it says nothing about a component that was outside the measurement scope. [1]
There are more limits. A measured value can match its reference while the software still contains a vulnerability. The result also depends on trusting the path that collected and protected the measurements. If that path is bypassed or the reference data is wrong, a neat-looking quote cannot repair the design. [1][2]
Timing matters too. The quote represents measured state at a point in the process; software can change after the quote is created. A fresh nonce helps prevent replay of an old signed response, but it does not freeze the device or prove that no change occurred after measurement. [1]
Remote Attestation is one input to risk and access policy, not a permanent safety certificate. A real fleet still needs patch management, vulnerability response, runtime monitoring, and network controls for problems that startup measurements do not cover. [1]
Return to the gateway's access request
The factory gateway asks to connect again. The service first checks the device identity, then sends a fresh challenge. The gateway returns a signed quote and the event log; the verifier checks the signature and nonce, replays the measurements, and compares the result with trusted references and policy. The service now has evidence to use—not a reason to skip its own authorization decision. [1][2]
If the maintenance policy is satisfied, the service can grant only the access needed for this job and only for the required period. If the evidence is incomplete or unknown, it can choose a more limited response. Narrow access reduces the damage if a device account or later software is compromised.
The pieces answer different questions. Secure Boot locally controls whether covered startup code may run. Measured Boot records selected startup measurements. Remote Attestation lets a verifier appraise evidence, and the service decides what access follows. No single step certifies the entire device. [1][2]
One operational question remains: when approved firmware changes the measurements, who confirms the release, when are reference values updated, and how does the device prevent a return to an older version? Those decisions determine whether a fleet can keep trusting its checks after the first deployment.
References
- RFC 9334: Remote ATtestation procedureS (RATS) Architecture: Attester, verifier, relying-party roles and the evidence-appraisal architecture.
- RFC 9683: Remote Integrity Verification of Network Devices Containing Trusted Platform Modules: One TPM-based example of remote integrity verification for network devices.
- Trusted Computing Group, PC Client Platform Firmware Profile Specification: PC Client firmware measurement and event-log profile.
Does replaying the event log reproduce the quoted PCR?
Compute PCR=SHA256(old PCR || SHA256(event)) step by step. Reorder the log and compare it with the quote. Next change the OS while keeping a consistent log and inspect reference rejection. Finally replay an old nonce: the signature can remain valid while freshness fails.
SHA-256 and ECDSA operate on a custom quote; PCR begins with 32 zero bytes. There is no TPM, TPM Quote encoding or real event format. Trusted-key and reference policy are supplied conditions. A fresh nonce binds the response; it neither proves recent measurement nor freezes subsequent runtime state.
Learning guide
How Trust Is Built Inside a Chip
Open the course outline → · Progress counts published lessons only
Prerequisites
- Secure Boot and digital signatures are helpful background
What I learned
- Separate startup enforcement from recorded measurements
- Explain how event logs and protected measurements can be checked together
- Limit remote-attestation conclusions to the evidence and policy checked