research32 min studyLesson 88 in Engineering

Confidential computing and attestation

Understand protected execution, evidence freshness, and key release while keeping hardware trust separate from application correctness.

Before you begin

On this page

The question for today

What you’ll understand

Distinguish protected memory from authorized application behavior.
Trace evidence, appraisal, and key release across an attestation protocol.
Calculate attestation service load and explain freshness assumptions.

Encryption at rest and in transit leaves a question: who can inspect data while an inference service computes on it? Confidential computing uses a trusted execution environment to reduce exposure to some infrastructure components under a specific hardware and software threat model. Remote attestation provides evidence about an environment so another party can decide whether to release a key or accept a workload. These mechanisms narrow trust; they do not remove it.

Specify the protected boundary

A trusted execution environment may protect a process or a virtual machine from classes of privileged software outside its boundary. Intel TDX is an example of hardware-isolated virtual machines with attestation support. State which memory, processor state, devices, and communication paths are covered by the chosen platform. A confidential CPU environment does not automatically protect data after it enters an ordinary accelerator, shared buffer, log collector, or external service.

Write down what remains trusted: processor implementation, firmware and relevant modules, attestation verification roots, guest software, and the key-release policy. Side-channel resistance and physical-adversary coverage are platform-specific. Availability is also separate: a hostile operator may still delay or stop a workload. Claims should point to the exact platform security model and current advisories rather than treating the word confidential as a complete security specification.

\mathrm{ReleaseKey}=\mathrm{EvidenceValid}\land\mathrm{Fresh}\land\mathrm{MeasurementAllowed}\land\mathrm{ChannelBound}

This illustrative policy requires validated evidence, freshness, approved measured state, and binding to the recipient channel. The actual evidence format and covered measurements depend on the platform and protocol.↔ Scroll wide equations horizontally.

Appraise evidence before releasing secrets

The IETF RATS architecture distinguishes an attester producing evidence, a verifier appraising it, and a relying party making a decision from results. The verifier needs endorsements, reference values, and appraisal policy. A signed report can be authentic yet describe an outdated or disallowed software version. Compare measurements to an approved release policy, and ensure the identity of the workload receiving a key is bound to the appraised environment.

Freshness often uses a verifier challenge or a carefully defined time-based policy. A fresh unpredictable nonce in newly produced evidence helps reject simple replay of an old response, provided the protocol verifies that binding. It does not prove every application input is fresh or prevent rollback of application state. Stateful services may need external monotonic state or another rollback-detection design, with its own availability and trust assumptions.

Operate the trust dependency

Attestation belongs in startup, recovery, and key-rotation planning. Decide whether an already running accepted workload may continue during a verifier outage, and for how long. Cache results only within a deliberate freshness policy. Record measurements and decisions without leaking secrets. When a platform advisory invalidates an accepted version, an operator needs an update and re-attestation path rather than a permanent emergency exception.

A measured application can still contain a bug or faithfully run a poisoned model. Bind the model-release identity and relevant configuration where the design supports it, then separately evaluate their behavior. Confidential computation also does not make data collection appropriate or supply differential privacy for released outputs. Follow the data through ingress, execution, storage, and egress so protection ends are explicit and key release has a meaningful purpose.

r_{\mathrm{attest}}\approx\frac{N}{T}+r_{\mathrm{restart}},\qquad 0\le t_{\mathrm{now}}-t_{\mathrm{verified}}\le T_{\mathrm{cache}}

N steady workloads re-attesting every T seconds generate approximate average load N/T plus restart traffic. The second inequality is a simple cache-age policy under trusted time; it is not equivalent to a nonce-based freshness proof.↔ Scroll wide equations horizontally.

Work it through

Size a verifier without changing its claim

There are 9,000 accepted workers re-attesting every 15 minutes. A restart event launches 1,200 workers over 60 seconds. Estimate verification demand and assess a verifier rated for 25 requests/s under the assumed workload.

The steady interval is 900 seconds, so average steady load is 9,000/900 = 10 attestations/s.
The restart wave adds 1,200/60 = 20 attestations/s if distributed uniformly through that minute.
The combined illustrative load is 30 attestations/s, exceeding 25 by five per second; over one minute the fluid backlog could grow by 300 requests.
Stagger restarts or add measured capacity while preserving evidence checks. Skipping verification under load would change the security policy rather than solve its capacity problem.

The result

The verifier is part of the production dependency graph. Capacity work should preserve the evidence and freshness requirements it exists to enforce.

The living notebook

Explore the model

Interactive lab

Interactive lab · reliability

Explore verifier replica availability

Change replica count n and unavailable count k to show up = n − k and majority floor(n/2) + 1. This majority-availability toy does not verify attestation evidence, establish independent trust, or prove agreement on appraisal policy and key release.

AvailableUnavailableMajority threshold

Available replicas: 4 of 5
Majority needed: 3
Majority available?: Yes

Replica count n5Unavailable replicas k1

t = 0 s

A replica count and a majority threshold, without a consensus protocol. Playback highlights fixed replica states. Having a majority alone does not establish linearizability, durability or failure independence. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.

Look forAvailable verifier replicas are operationally useful, but correct evidence appraisal and approved trust roots remain separate requirements.

Pause & reason

Check your understanding

Interactive checks need JavaScript. You can still read the explanation.

Read the checkpoint explanation

Attestation supports a scoped statement about an environment and its measured state. It does not prove application correctness, formal output privacy, device coverage beyond the stated boundary, or availability.

Your turn

Try it yourself

Twelve thousand workers re-attest every twenty minutes. A restart wave adds 600 starts over two minutes. Calculate average total demand during that wave and give one property that a nonce freshness check does not establish.

Take a moment to make a prediction or work it out on paper. Open a hint when you need one.

Give me a hint

Convert both intervals to seconds and distinguish report freshness from application-state freshness.

Compare with the solution

Steady demand is 12,000/1,200 = 10 requests/s; restarts add 600/120 = 5 requests/s, for 15 requests/s during the wave under uniform timing. A nonce check does not establish that application storage has not been rolled back, that model outputs are correct, or that external devices are protected.

Keep the idea

Take it with you

Confidential execution narrows a specified infrastructure trust boundary.
Attestation requires appraisal policy, freshness, and binding to the secret recipient.
Measured software, formal output privacy, and service availability need separate reasoning.

Read further

Original sources and deeper explanations to follow at your own pace.

Optional progress, saved in this browser when available. Revisit any lesson at any time.

Lesson not marked complete.