What is session binding
Session binding cryptographically ties an attestation report to a specific TLS connection. This prevents relay attacks where an attacker with a compromised private key could reuse attestations from a genuine TEE across different TLS sessions.Session binding is always enabled in Atlas and requires no configuration. It works automatically with all aTLS connections.
How it prevents relay attacks
Consider this attack scenario without session binding:- Attacker compromises the TLS private key
- Attacker establishes a TLS connection with a client
- Attacker requests a quote from a genuine TEE over a separate connection
- Attacker relays that quote to the client
- Client accepts the quote (it’s validly signed) and sends sensitive data
- Attacker intercepts the data
EKM session binding (RFC 9266)
Atlas implements session binding using Exported Keying Material (EKM) as specified in:- RFC 5705 - Keying Material Exporters for TLS
- RFC 8446 Section 7.5 - Exporters (TLS 1.3)
- RFC 9266 - Channel Bindings for TLS 1.3
How EKM works
After the TLS handshake completes, both client and server can derive keying material using the TLS exporter interface:- Session-specific - Derived from the TLS master secret, unique per connection
- Deterministic - Both peers compute the same value
- Unforgeable - Cannot be computed without the TLS master secret
- Collision-resistant - Different sessions produce different EKM values
Session binding protocol
Atlas binds attestations to TLS sessions using this protocol:1. TLS handshake completes
Both client and server have established a TLS 1.3 connection.2. Client generates nonce and computes report data
The client:- Extracts the session EKM:
session_ekm = export_keying_material(32, "EXPORTER-Channel-Binding", None) - Generates a random 32-byte nonce for freshness
- Computes
report_data = SHA512(nonce || session_ekm) - Sends the nonce to the server
3. Server computes report data and generates quote
The server:- Extracts its session EKM (identical to the client’s)
- Receives the nonce from the client
- Computes
report_data = SHA512(nonce || server_ekm) - Requests a TDX quote with this report data
- Returns the quote to the client
4. Client verifies session binding
The client:- Receives the quote from the server
- Extracts the
report_datafield from the quote - Verifies that
quote.report_data == SHA512(nonce || session_ekm)
- The quote was generated during this specific TLS session
- The TEE has access to the TLS master secret (owns the private key)
- The attestation cannot be replayed on a different connection
The nonce adds freshness to ensure the quote was generated in response to this specific request, not pre-computed.
Defense in depth
Session binding provides protection even if:- The TLS private key is compromised
- An attacker has network access to a genuine TEE
- The attacker can intercept and relay network traffic
- Compute the correct EKM for their malicious connection
- Relay a quote from a different connection (the report data won’t match)
- Pre-generate quotes (the nonce ensures freshness)
Key properties
Atlas session binding guarantees:- Always enabled - No configuration needed, works automatically
- Transparent - No impact on application code
- Standards-based - Uses RFC 9266 channel binding for TLS 1.3
- Attack-resistant - Prevents relay, replay, and key compromise attacks
Session binding is part of the core aTLS protocol and cannot be disabled. Every quote verification includes session binding checks.