Establish an Attested Secure Channel

What you will learn

This lesson covers:

  • Evidence generation
  • Verifier policy
  • Public-key binding
  • Attested TLS
  • Key Broker Services
  • Secret release
  • Replay prevention
  • Revocation

Attestation without a secure channel is incomplete

A verifier may confirm that an approved workload is running.

The next question is:

> How does the verifier send a secret to that specific workload?

If evidence and communication are not cryptographically linked, an attacker may:

1. Forward valid evidence from a real TEE. 2. Substitute the attacker's public key. 3. Receive the secret through a separate connection.

The secure channel must be bound to the attested environment.

The key-binding pattern

A common pattern is:

1. Generate an ephemeral key pair inside the TEE. 2. Hash the public key. 3. Place the hash in the evidence's user-data or report-data field. 4. Generate hardware-backed evidence. 5. Send the evidence and public key to the verifier. 6. Verify the certificate chain and evidence signature. 7. Verify freshness. 8. Verify the expected workload measurement. 9. Verify the public-key hash. 10. Establish encryption to the attested public key. 11. Release the secret.

The key pair should be generated inside the protected environment. The private key should not leave the TEE.

Attested key-binding flow showing a TEE-generated key pair bound to hardware evidence, verifier appraisal, KBS secret release, and establishment of a secure channel to the verified workload.

RATS roles in an application

The IETF RATS architecture defines:

  • Attester
  • Verifier
  • Relying Party
  • Evidence
  • Endorsements
  • Reference values
  • Appraisal policy
  • Attestation result

RFC 9334 treats these as conceptual roles and messages rather than forcing one platform-specific protocol.

RATS trust flow showing how an Attester provides evidence to a Verifier, which evaluates it and provides an attestation result used to authorize access to protected resources.

Attester

The protected workload generates evidence.

Verifier

The verifier checks evidence and applies appraisal policy.

Relying Party

The relying party decides whether to release a resource.

One service may act as both Verifier and Relying Party, but the logical roles should still be clear.

What the verifier must check

A verifier may need to check:

  • Evidence structure
  • Evidence signature
  • Root certificate
  • Intermediate certificates
  • Revocation status
  • Hardware product identity
  • Firmware security level
  • Debug flag
  • Workload measurement
  • Signer identity
  • Security version
  • Nonce
  • Evidence time
  • Bound public key
  • Configuration claims

A valid signature is only the beginning.

Verifier decision flow showing evidence validation, signature and certificate checks, freshness, policy evaluation, key binding, channel binding, and the final accept-or-reject trust decision.

Freshness

Freshness prevents replay of old evidence.

Common mechanisms include:

  • Verifier-generated nonce
  • Challenge-response
  • Short validity window
  • Monotonic counter
  • Trusted timestamp
  • One-time session identifier

A nonce should be:

  • Random
  • Unpredictable
  • Unique
  • Checked by the verifier
  • Covered by the evidence signature

Attested TLS

Attested TLS connects attestation information with a TLS session.

One implementation pattern places the TEE evidence in or beside a certificate used during TLS negotiation.

Gramine's RA-TLS tooling embeds Intel SGX attestation information in a certificate so that the remote party can verify the enclave during channel setup. Gramine also provides secret-provisioning libraries built on RA-TLS.

RA-TLS is an implementation pattern, not one universal protocol used identically by every TEE platform.

Key Broker Service

A Key Broker Service controls secret release.

The KBS may receive:

  • Evidence
  • Attestation result
  • Resource request
  • Workload identity
  • Tenant identity
  • Requested key name

The KBS applies policy such as:

`` Allow resource: model-key-v4 When: platform = approved measurement = expected debug = false security_version >= 7 tenant = research-team public_key_binding = valid evidence_age < 5 minutes ``

Confidential Containers' Trustee architecture uses a KBS as the entry point for resource requests. The KBS calls an Attestation Service, which evaluates evidence using reference values and policy before a resource is released.

Secret envelope

A secret should not be sent as plaintext to the host.

A basic envelope flow is:

`` data_key = random() ciphertext = AEAD_Encrypt(data_key, secret) wrapped_key = Encrypt(attested_public_key, data_key) ``

The TEE receives:

  • ciphertext
  • wrapped_key

Inside the TEE:

1. Decrypt the data key. 2. Authenticate and decrypt the secret. 3. Clear temporary key material when no longer needed.

Resource-specific authorization

Do not use one broad rule that releases every secret to every approved workload.

Bind policy to:

  • Resource
  • Tenant
  • Workload
  • Environment
  • Version
  • Purpose
  • Expiration

Example:

`` The analytics enclave may receive dataset key A. It may not receive payroll-signing key B. ``

Revocation

An accepted workload may need to be rejected later because of:

  • Vulnerability
  • Compromised signing key
  • Unsafe dependency
  • Leaked secret
  • Firmware issue
  • Hardware advisory
  • Incorrect configuration

The verifier must support:

  • Measurement revocation
  • Signer revocation
  • Certificate revocation
  • Minimum security-version update
  • Platform revocation
  • Emergency denylist
  • Secret rotation

Failure behaviour

When attestation fails, the system should:

  • Refuse secret release
  • Return a generic error
  • Record non-sensitive diagnostic information
  • Avoid falling back to an unattested connection
  • Avoid accepting stale evidence
  • Avoid silently disabling certificate checks
⚠
A failed verifier should fail closed for sensitive secret release. Never fall back silently to an unattested channel when attestation fails.
Verification failure flow showing that failed attestation checks result in rejection, blocked secret release, and re-attestation when required.

Example: Private document service

1. Document processor starts inside a confidential VM. 2. It generates a session key pair. 3. It requests an attestation report containing the public-key hash. 4. The verifier checks the image, firmware, debug status, and nonce. 5. The KBS releases the document key to the attested public key. 6. The application decrypts the document inside the protected environment. 7. The output is encrypted to the user.

Private document service flow showing workload attestation, key-bound secret release, protected document access inside the confidential workload, and encrypted delivery to the client.

Developer exercise

Design a KBS policy for an AI model service.

The policy must check:

  • Workload measurement
  • Minimum security version
  • Debug mode
  • Model identity
  • Tenant
  • Evidence freshness
  • Public-key binding

Add:

  • One revocation rule
  • One emergency shutdown rule
  • One key-rotation rule

Common mistakes

⚠
**Verifying only the evidence signature** — A valid signature does not mean the workload is approved. **Failing to check the measurement** — The signature proves authenticity of the evidence; the measurement proves which code is running. **Failing to check freshness** — A replay attack can reuse valid old evidence. **Sending a secret through a channel not bound to evidence** — Always bind the communication key to the attestation report. **Using one secret policy for every workload** — Policies must be resource-specific and workload-specific. **Accepting debug workloads** — Debug evidence may carry zeroed or stub measurements. **Ignoring revocation** — Accepted measurements must be removable. **Falling back to ordinary TLS when attestation fails** — Failures must close the resource, not downgrade the channel.

Key takeaways

  • Attestation must be connected to the communication key.
  • Evidence authenticity and policy acceptance are separate checks.
  • Freshness prevents replay.
  • A KBS should apply resource-specific policy.
  • Secret release must fail closed.
  • Revocation and rotation are normal operational requirements.

Check your understanding

1. What attack is possible when the TLS key is not bound to evidence? 2. What is the difference between a Verifier and a Relying Party? 3. Why is a nonce needed? 4. Why should KBS policies be resource-specific? 5. What should happen when a measurement is revoked?

Answer the quiz correctly to continue →

Quiz · Multiple Choice1 / 3

A verifier confirms a valid attestation report and checks the expected workload measurement, then encrypts a secret to a public key provided separately by the cloud operator. Which attack does this enable?