Design Secure Boot and Platform Attestation

System and boundaries

Start with a relying-party question. Example: before issuing a production workload credential, require a registered node that booted approved firmware, boot loader, kernel, and workload launcher with current security configuration.

Map:

• Hardware or immutable root and its manufacturing and ownership state.
• Verification keys, policy, revocation, and recovery authority.
• Firmware, devices, boot loader, kernel, initial filesystem, modules, configuration, and late-loaded code.
• Measurement registers, event log, attestation key, evidence format, and freshness mechanism.
• Endorsers, reference values, verifier, appraisal policy, attestation result, and relying party.
• Update, rollback, compromise, ownership transfer, privacy, and end-of-life.

State exclusions. A node claim may omit application data, runtime behavior, peripherals, management processor, late-loaded plugin, or physical location. Do not let a consumer infer those properties from a green status.

Request and decision flow

1. The root verifies or measures the first stage.
2. Each stage verifies or measures the next component and records ordered events.
3. The relying flow supplies a fresh challenge or another accepted freshness value.
4. The attester signs protected measurement state and sends evidence with the event log and needed identity claims.
5. The verifier validates key trust, freshness, evidence structure, log consistency, reference values, revocation, and appraisal policy.
6. The verifier produces a bounded result with time, evidence scope, policy version, and reason.
7. The relying party combines that result with workload or user identity, resource, action, and risk policy.

Keep the attestation result short-lived. Bind issued workload credentials to the appraised identity and purpose. Reappraise on boot, material state change, credential renewal, or risk signal according to the threat.

Failure domains

Test these shared failures:

• The same vendor controls root keys, firmware, reference values, and verifier software.
• The event log omits a component but final register values still appear plausible.
• A verifier accepts a known measurement after the version is revoked.
• A platform replays evidence from before compromise or rollback.
• A recovery key authorizes arbitrary firmware outside measurement policy.
• The verifier and access service share one outage or administrator.
• An attestation identifier tracks a user or device beyond the stated purpose.

Update, revocation, and recovery design

Publish authenticated reference values before a staged update. Define overlap for old and new approved versions. Limit rollback and expire old reference values. Rotate verification and attestation keys without accepting attacker-selected algorithms or key sources.

On compromise, revoke affected component versions, keys, devices, and attestation results. Decide whether access denies, degrades to a lower-risk resource set, or uses a separate emergency path during verifier outage. Never silently convert missing evidence into good evidence.

Recovery must protect, detect, and restore firmware and platform data. Test corrupt image, interrupted update, lost key, stale reference values, failed clock, and replacement motherboard or TPM. Ownership transfer must remove prior owner keys and identifiers without breaking required provenance.

Assurance evidence

Collect the root and key provisioning design, firmware and component provenance, measurement specifications, reference-value provenance, verifier implementation tests, appraisal-policy review, evidence samples, replay tests, omitted-component tests, revocation timing, update rollout, and recovery exercise.

Validate the complete claim through the relying party. A verifier unit test does not prove that the access service checks the correct result, freshness, device identity, resource, and policy version.

Design tradeoffs and residual risk

More measured components increase coverage and reference-value churn. Strict version allowlists improve control and can make emergency recovery unavailable. Device-unique attestation improves binding and can harm privacy. Central verification simplifies policy and creates a high-value availability and integrity dependency.

Residual risks include supply-chain trust, hardware and firmware flaws, side channels, runtime compromise after measurement, unmeasured devices or configuration, valid but vulnerable software, and misuse by an authorized workload.

Pomerium boundary

Pomerium can apply documented device and identity context to route decisions. It is not a general TPM or firmware verifier. An external verifier and device system must produce trustworthy, fresh, privacy-appropriate results. Operators must map those results into policy without confusing platform state with user identity, application authorization, or current behavior.

Exercise

Design the flow for one node or managed device. Produce the component and measurement scope, root and key hierarchy, event-log format, freshness mechanism, reference-value authority, appraisal policy, result schema, relying-party rule, update plan, revocation plan, privacy analysis, and recovery procedure.

Test valid current boot, one modified event, one omitted component, replay, stale approved version, interrupted update, verifier outage, replaced hardware, and recovery image. Prove that each result matches the documented access outcome and creates usable evidence.

Evaluation checklist

• Are boot authorization, measurement, evidence appraisal, and final access policy separate and explicit?
• Does evidence cover the expected ordered components and bind to a fresh authenticated platform identity?
• Can reference values, keys, versions, devices, and results be updated and revoked without unsafe rollback?
• Does verifier or recovery failure deny or degrade according to a tested policy rather than bypass the control?
• Does the relying party use only the bounded platform claim and still check identity, resource, action, and application policy?