H2-1 · Definition & boundary: who guarantees what

What each component is responsible for

A clean boundary avoids both “over-design” and “false confidence.” In server platforms, TPM, HSM, and RoT are best understood by the type of guarantee they provide and the evidence they can produce.

TPM (platform measurement + sealing)

• Primary role: bind secrets to platform state and export verifiable measurements.
• Key primitives: PCR extend, event log, quote/attestation, sealed storage (policy-bound unseal), protected NV indexes.
• Engineering output: “evidence that the platform booted into an expected state,” plus policies that gate key usage on that state.

HSM (high-value key isolation + audited crypto operations)

• Primary role: keep high-value keys inside a hardened boundary and perform crypto operations without key export.
• Key primitives: non-exportable key slots, signing/decryption, access control partitions, audit logs.
• Engineering output: “proof that sensitive keys never leave the protected boundary,” with auditable usage and separation of duties.

Root of Trust (RoT) (immutable anchor of the boot trust chain)

• Primary role: provide an immutable starting point for verification and/or measurement (boot ROM, immutable code, or hardened security core).
• Key primitives: first-step verification, first-step measurement, key injection/provisioning anchors, protected counters for rollback defense (implementation-dependent).
• Engineering output: “the first link in the chain is trustworthy,” enabling the rest of the chain to be meaningful.

Deployment forms and practical selection boundary

A single server can legitimately include multiple components because the guarantees differ: TPM is strongest for attestation and policy-bound sealing; HSM is strongest for high-value key isolation and audited crypto; RoT is strongest for making the first boot step trustworthy.

• dTPM vs fTPM: the most important difference is the trust boundary (physical isolation and supply-chain traceability), not raw performance.
• TPM + RoT: RoT anchors the first step; TPM carries measurements/evidence and enables sealing policies.
• TPM + HSM: TPM proves platform state; HSM protects crown-jewel keys and enforces operational separation.

Acceptance evidence for H2-1 (what “done” looks like)

• Boundary statement: a written “responsibility split” (TPM vs HSM vs RoT) for the platform.
• Evidence outputs: PCR plan + event log availability + quote verification path (for TPM), plus key non-exportability/audit posture (for HSM).
• Lifecycle hook: provisioning identity, key injection/protection method, and rollback prevention strategy ownership clearly assigned.

H2-2 · Threat model: what is protected and how it fails

Scope: what this page covers (and what it does not)

This chapter focuses on platform identity, boot integrity evidence, anti-rollback, and attestation trustworthiness. It does not cover network zero-trust architecture, application vulnerabilities, or remote console/OOB operational details.

Attacker capability tiers used for engineering decisions

• L1 (remote software): attempts to fake platform state remotely (replay, spoof, or trick verification).
• L2 (firmware-update capable): can push “legitimate-looking” but malicious firmware, or abuse recovery paths.
• L3 (physical / supply-chain): can probe, replace, or tamper with storage/components, aiming to subvert the first link of trust.

Five threat families mapped to on-platform controls

Each threat is valuable only if it maps to a control point and to verifiable evidence. Without evidence (PCR + logs + quote + freshness), “secure” becomes a belief, not an engineering property.

• Firmware tampering: attacker modifies boot components to gain early execution.
• Boot-chain hooking: attacker inserts or patches a component that still passes superficial checks.
• Rollback attacks: attacker reverts firmware to a vulnerable but signed older version.
• Key extraction attempts: attacker tries to export or misuse keys beyond intended scope.
• Fake attestation: attacker replays old evidence or forges a “healthy” report for an unhealthy platform.

Acceptance evidence for H2-2 (what “done” looks like)

• Evidence completeness: PCR plan + event log availability + quote verification + freshness (nonce/challenge) is documented and testable.
• Rollback defense: a monotonic/version counter gate exists and is exercised by a rollback test case.
• Failure taxonomy: operational failure modes are classified (signature chain failure, PCR mismatch, stale evidence, counter mismatch).

H2-3 · Secure Boot: from “who signed it” to policy governance

What Secure Boot guarantees (and what it does not)

Secure Boot is a verification gate: each stage is allowed to execute only if it matches an approved signature policy. It primarily prevents unauthorized boot code, but it does not automatically produce the full evidence package required for remote trust decisions. That evidence comes from measured boot and attestation.

Common engineering pitfalls

• DBX update breaks boot (“false kill”): a revocation list can invalidate previously-working components. A safe process requires staged validation plus a protected recovery path.
• Signature-chain drift across vendors/firmware lines: mixed platform generations and firmware baselines can diverge in policy needs. Governance must treat policy as versioned configuration, not a one-time setting.
• “Only bootloader verified” misconception: verifying an early stage does not automatically cover every later component. The verified boundary must be explicitly defined to avoid gaps being mistaken for coverage.

Acceptance evidence (what “done” looks like)

• State: Secure Boot is enabled/enforced with a documented policy owner and change process.
• Policy version: PK/KEK/DB/DBX are versioned with change logs (who/when/why).
• Disable path: documented and controlled (who can disable, under what conditions).
• Recovery: emergency recovery exists, is tested, and is protected from becoming a bypass.

H2-4 · Measured Boot: PCR, event log, and provable boot facts

Three questions that define measured boot engineering

• What is measured: key boot components and security-relevant configuration facts.
• Where it is recorded: PCR extend (append-only summary) plus an event log (interpretable details).
• How it is used: remote attestation decisions, policy gating, and “unseal only when expected state is present.”

Outputs that make measured boot operational

Common engineering pitfalls and how to control them

• PCR selection chaos: measuring too much “high-churn” data causes permanent drift and false failures → classify as Strict/Window/Observe.
• Incomplete event logs: PCR changes become unexplainable “black boxes” → enforce a minimum event log set per platform baseline.
• Golden PCR drift after firmware updates: expected changes must be versioned and allowed in a controlled update window → baseline policy + allow-list window.

Acceptance evidence (what “done” looks like)

• PCR plan: documented PCR mapping with stability class and verification rule.
• Log completeness: event logs are available and interpretable for verification.
• Baseline governance: baseline versions, approved windows, and failure actions are defined (deny / quarantine / review).

H2-5 · Key storage primitives: EK/SRK, sealing, NV indexes, counters

Primitive-first view (what the hardware boundary actually provides)

Key management inside a hardware trust boundary is best understood through the primitives it exposes. Each primitive provides a specific security guarantee and a specific type of evidence that can be verified or audited. Confusing “where a key is stored” with “how a key is allowed to be used” is a common source of operational failure.

Key generation and “non-exportable” attributes

“Non-exportable” is not a marketing label; it is a strict boundary: the private key material is intended to remain inside the protected domain, while external software receives only results (signatures, decrypted payloads). This reduces the risk of keys silently spreading into disks, images, or transient host memory.

Seal / unseal: binding key usability to state and policy

Sealing binds a secret to a policy and (optionally) a platform state summary so that the secret is usable only when expected conditions hold. Overly strict binding can cause operational failures after approved updates, so seal policies should be treated as versioned configuration with an explicit allowance window.

• State binding: gate usage on “expected platform facts” rather than only on “presence of hardware.”
• Policy lifecycle: approved updates should move the platform into a new allowed baseline version.
• Failure action: define what happens when unseal fails (deny, quarantine, require review).

NV indexes: policy-protected small data anchors

NV indexes are not general storage. They are small, policy-protected slots suitable for anchoring critical metadata that must not be rewritten or replayed without authorization (for example, policy version tags, state markers, or controlled configuration facts). The critical engineering property is the permission model (read/write/lock), not the storage size.

Monotonic counters: anti-rollback gates

Anti-rollback is achieved when older states cannot become acceptable again. A monotonic counter provides a one-way progression that can be checked during verification or policy gating. The “hard part” is operational: ownership of updates, update timing, and failure handling must be explicitly defined.

• Monotonicity: counter values must not decrease under any supported lifecycle path.
• Authority: define who can advance the counter and under what approved change process.
• Enforcement: define what is rejected when the counter indicates rollback.

Operations boundary: storing keys vs using keys

Hardware boundaries change the lifecycle model. Traditional “backup and restore” assumptions may not apply to non-exportable keys. Migration and replacement policies should be defined up-front so that break/fix work does not become an accidental security bypass.

• Backup: define whether regeneration or re-provisioning is the intended recovery mechanism.
• Migration: prefer “rebuild on new platform + rebind policies” over copying secrets.
• Replacement: document which sealed objects and identity anchors must be re-established after component swap.

Acceptance evidence (what “done” looks like)

• Key attributes: non-exportable property and allowed usages (sign/decrypt) are verifiable.
• Seal policy: binding rules (state/policy) and allowance window are versioned and documented.
• NV permissions: NV index read/write/lock rights are explicit and policy-controlled.
• Counter behavior: monotonicity is tested; rollback attempts are rejected as designed.

H2-6 · TRNG & entropy: why randomness quality affects end-to-end trust

Positioning: engineering observability, not algorithm tutorials

TRNG and entropy are foundational to the trust chain because they feed key generation, nonce creation, and many security-critical operations. The practical focus is observability: where health checks sit, what failures look like, and how the platform degrades or isolates itself when entropy is not trustworthy.

Field symptoms linked to entropy health failures

• Key/certificate generation anomalies: failures or abnormal latency when generating long-term keys.
• Attestation instability: challenges/nonce-based flows behave inconsistently because freshness assumptions cannot be met reliably.
• Audit and policy blocks: critical operations are denied with explicit “health test failed / entropy insufficient” event records.

Degrade and contain (fail-safe behavior)

When health checks fail, the safe response is not to “try harder,” but to reduce trust level and prevent creation or use of sensitive material until the platform returns to a known-good entropy state.

• Block sensitive operations: prevent long-term key creation and other critical primitives when health fails.
• Isolate trust tier: mark the platform as not meeting high-trust requirements until remediated.
• Record evidence: emit timestamped events suitable for audits and fleet-wide investigations.

Acceptance evidence (what “done” looks like)

• Health checks: defined insertion points and clear pass/fail interpretation.
• Policy response: explicit degrade rules for keygen/nonce/signing consumers.
• Audit records: minimum event fields exist (type, time, scope, blocked operations).

H2-7 · Attestation: what “trust evidence package” is actually delivered

Two halves: evidence package vs verifier decision

Remote attestation is not a single “quote.” It is a trust evidence package assembled by the device and a policy decision made by the verifier. The package must be (1) signed, (2) fresh, (3) interpretable, and (4) rooted in a valid trust chain—otherwise the result is not operationally usable at scale.

Baseline versioning: firmware updates are inevitable

PCR baselines should be treated as versioned artifacts, not a single “golden value.” An operational model typically includes a platform family tag and a baseline identifier, plus an approved window during controlled rollouts. Without versioned baselines, routine updates will be indistinguishable from tampering and will drive false denials.

Multi-role attestation: layering without mixing device details

In complex systems, trust can be expressed as layered evidence: a primary platform evidence package may be combined with additional evidence from dependent components. The verifier’s policy should support hierarchical decisions (accept, deny, quarantine) without requiring component-specific implementation details in the evidence model.

Acceptance evidence (what “done” looks like)

Failure codes (minimum useful set)

• CERT_CHAIN_FAIL: signing identity cannot be validated or is not acceptable.
• NONCE_REPLAY_OR_MISMATCH: evidence is not bound to the current challenge.
• PCR_BASELINE_MISMATCH: PCRs do not match the strict set or approved window.
• EVENTLOG_INCOMPLETE_OR_UNPARSABLE: evidence cannot be explained consistently.

H2-8 · Secure update & anti-rollback: updates are normal, rollbacks are dangerous

The trusted update triad

A secure update is trusted only when three controls hold together: signature verification, version binding, and rollback blocking. Treating updates as “just install the new image” breaks trust because it ignores recovery consistency and the possibility of reintroducing older vulnerable states.

Recovery consistency: power loss must not create split-brain state

The main operational risk is inconsistency between “image staged,” “image committed,” and “version state advanced.” A robust model uses an explicit commit point and ensures that state transitions are recoverable under power loss without accidentally allowing an older image to pass validation.

• Stage: write new image into a staging area with integrity checks.
• Commit: switch activation pointer only after verification succeeds.
• Advance: increment version gate only when commit is complete.
• Record: emit event logs that prove the transition and support audits.

Key rotation: preventing “old chain still works” rollback bypass

Rotating signing keys is not sufficient if older chains remain accepted. Rotation must be paired with revocation or policy tightening so that older signed images are rejected after the transition window closes. Otherwise, rollback becomes a practical bypass of the rotation intent.

Acceptance evidence (what “done” looks like)

H2-9 · Integration on server boards: interfaces, topology, and isolation boundaries

This section focuses on board-level integration points that are directly related to TPM / Root of Trust behavior: form factor choice (dTPM vs fTPM), interface trade-offs (SPI / LPC / eSPI), and the isolation + write-protect boundaries that decide whether trust remains intact under real physical access pressure.

dTPM vs fTPM: isolation boundary and supply chain trust

SPI vs LPC vs eSPI: trade-offs are more about exposure than speed

Interface selection should be justified by how it changes reachability, attack surface, and auditability. Faster transport does not automatically mean lower risk; board accessibility and observability typically dominate.

Isolation & write protection: control points that must be explicit

Acceptance evidence (what “done” looks like)

• Interface rationale: why SPI/LPC/eSPI is chosen and which exposures are accepted or mitigated.
• Write-protect strategy: unlock owner, unlock conditions, and failure recovery posture.
• Physical protection: protected-zone definition and reachability assumptions (service/test boundaries).
• Manufacturing hooks: traceable checkpoints for identity injection / enrollment prerequisites.

H2-10 · Lifecycle & operations: provisioning, rotation, replacement, and decommission

Trust is operational only if identity, policy, and evidence remain consistent through the full lifecycle: factory → rack deployment → steady-state operations → rotation → replacement/RMA → decommission. This section defines lifecycle states, what cryptographic actions are allowed in each state, and what audit events are mandatory to prove correct handling.

Provisioning / enrollment: identity establishment with traceable hooks

Rotation: keys and policies move together (avoid “old chain still works”)

Rotation must be treated as a controlled transition window. Policies should tighten after the window closes: old acceptance paths are revoked, baseline identifiers advance, and verification rules are updated in lockstep. Otherwise, rollback or legacy paths can silently bypass the intent of rotation.

Replacement / RMA: a new device must not inherit the old identity

Replacement requires an explicit rule: identity cannot be inherited. The old identity is revoked and the new device is enrolled with a new identity chain. Migration may carry configuration context (policy version references), but not the identity itself. This prevents “ghost devices” where an old identity remains valid after hardware changes.

Decommission: making trust expire on purpose

Decommissioning is complete only when revocation is effective and the system can prove that the retired identity is no longer acceptable. Record the decommission reason, the time, the identity identifiers, and the revocation outcome.

Acceptance evidence (minimum required artifacts)