Session Attestation for Unmodified TLS Services in Confidential Virtual Machines

1 Introduction

• A valid TLS identity and valid attestation can authenticate different endpoints, allowing an adversary to read requests at a substituted endpoint while relaying them to preserve correct behavior.Operational credentials and routing controls can be compromised independently of the production CVM.Source: §1 · p. 1
• Endpoint-Substitution Relay (ESR) models an adversary-readable, client-accepted receiver that relays requests to the genuine service to preserve expected behavior.The framework develops two sufficient constructions and characterizes the identity, protected-environment, receiving-state resources, and reuse scope they require.Source: §1 · pp. 1–2
• TLSLatch attests the protected origin of the server’s current TLS key share and gates outbound traffic until verification succeeds, then returns communication to the native TLS data path.It adds session attestation without changing applications, TLS libraries, certificates, or application protocols, and without an additional payload-encryption layer.Source: §1 · p. 2
• The implementation uses a hardware-backed Hygon CSV CVM server and clients on Linux, Windows, and macOS, and also supports mutual attestation and TLSLatch-Batch.TLSLatch-Batch delays confirmation to amortize attestation across connections.Source: §1 · p. 2
• The evaluation measures authentication latency, transfer overhead, resource costs, mutual attestation, and batch confirmation against native TLS and four attested-channel configurations.The supplied introduction passage describes the evaluation scope but does not report its results.Source: §1 · p. 2

2.1 TEEs and Remote Attestation

• Confidential VMs isolate the guest OS and applications while preserving conventional interfaces; remote attestation evaluates signed evidence about the protected environment, but channel authentication must bind that environment to the data-receiving endpoint.The evidence may bind a fresh challenge to software measurements, platform identity, security version, and configuration.Source: §2.1 · p. 2

2.2 TLS 1.3

• In TLS 1.3, CertificateVerify authenticates service identity with a certificate key, while fresh ECDHE shares derive session keys that remain undisclosed by compromise of that reusable key alone.Finished confirms the resulting handshake state.Source: §2.2 · p. 2

2.3 Confidential Cloud Services and Deployment Models

• Confidential-service deployments either terminate TLS in the protected worker or use a gateway for outer TLS while an inner encrypted channel delivers the request for decryption in that worker.CMaaS follows the gateway pattern through application-key establishment and payload encryption.Source: §2.3 · pp. 2–3, Figure 1 · p. 3

3 Endpoint-Substitution Relays and Compromise Robustness

• ESR occurs when a client accepts a substitute receiver that exposes the request to an adversary, who relays it to the genuine service to preserve expected behavior.Two sufficient constructions realize this outcome: a live policy-accepted protected environment, or an attestation-endorsed receiving capability reproduced elsewhere.Source: §3 · p. 3

3.1 Participants and Adversarial Capabilities

• The adversary can redirect client traffic and invoke the production service through ordinary interfaces, while access to credentials, protected environments, and receiving state is modeled separately.The model assumes correct client verification and an unforgeable attestation accepted by the fixed configuration’s policy.Source: §3.1 · p. 3

3.2 ESR Goal and Resource Model

• The resource model separates service-authentication capability (TΠ), access to an accepted live protected environment (RΠ), and acquisition of protected receiving state (BΠ).It distinguishes freely generated, enterprise, and service-restricted identities, as well as ordinary, vendor-attested, and provider-authorized environments.Source: §3.2 · p. 4

3.3 Attested-Environment Path

• A substitute receiver with the required service identity and accepted live protected environment can recover the request, relay it to the genuine service, and return its result.The path may terminate the client interaction inside that environment or combine an ordinary front end with remotely accessible protected operations; it does not require copied receiving state.Source: §3.3 · p. 4

3.4 Receiving-State Copying Path

• The receiving-state copying path succeeds when protected source state can reproduce the endorsed receiving operation elsewhere and applicable evidence remains valid for the new interaction.For shared authentication-key binding, the reusable private key serves as receiving state; an attacker-chosen ephemeral exchange yields client-facing keys for recovering and relaying the request. The two paths are sufficient, not exhaustive, characterizations of confidentiality failures.Source: §3.4 · pp. 4–5

3.5 Mapping Existing Designs

• The design mapping compares required service identity, protected environment, receiving state, credential-state overlap, and how long the attestation binding remains applicable.Binding scope is classified as long-lived, periodic, or per-session; periodic renewal is policy-driven rather than intrinsically tied to each session.Source: §3.5 · p. 5
• Mapped designs vary in whether service credentials overlap with receiving state and whether bindings are reusable, periodic, or per-session.TLS+RA binds to current-session ECDHE state; typical RA-TLS binds evidence to reusable authentication state, while TNG-nested retains the application’s original TLS as a separate protection layer.Source: §3.5 · pp. 5–6

3.6 Design Implications

• Designs should keep service authentication independent of receiving state, bound the reuse scope of attestation, and verify the receiving capability before releasing sensitive data.Hardware attestation alone does not establish service authorization; TLSLatch applies these implications by binding attestation to the current TLS connection’s receiving state while preserving independent service authentication.Source: §3.6 · p. 7

4 TLSLatch Design

• TLSLatch preserves applications, TLS stacks, certificates, and protocols by adding session attestation around an existing TLS connection and returning traffic to the native TLS path after authentication.This also fits TLS-passthrough deployments, where intermediate load balancers continue forwarding the encrypted connection without participating in attestation.Source: §4 · p. 7

4.1 Bind Attestation to the Current TLS Receiver

• The server’s ephemeral TLS 1.3 share is bound through a role-tagged digest of the negotiated group and share, which the client recomputes from its own ServerHello.The observer associates the share with an active local flow, while the approved kernel and TLS implementation supply its protected key-generation and key-use semantics.Source: §4.1 · p. 7

4.2 Verify Before Release

• ClientHello and the normal TLS handshake proceed while a client gate holds later outbound records until the share’s evidence is verified; failure drops the records.Attestation overlaps handshake processing, and authorized traffic subsequently bypasses the gate on the native TLS path.Source: §4.2 · pp. 7–8, Figure 3 · p. 8

4.3 Security Argument

• The security argument assumes authentic evidence, protected share provenance and secret confinement, session-local gating, and TLS 1.3 key and record security.Under these assumptions, released requests use a share endorsed by a policy-accepted protected endpoint, except for negligible evidence-forgery or binding-hash failure.Source: §4.3.1 · p. 8

4.3.2 Binding and Disclosure Properties.

• Possession of the reusable service signing credential alone does not enable receiving-state copying ESR against an independent secret request under the stated assumptions.The argument relies on the endorsed share’s protected provenance and TLS confidentiality; relaying the genuine handshake and ciphertext does not provide plaintext to the relay.Source: §4.3.2 · p. 9
• The formal proposition covers full ECDHE handshakes with resumption and 0-RTT disabled; requests and KeyUpdate inherit the connection’s decision without refreshing attestation.Batch confirmation is different: its evidence may arrive after requests complete and establishes manifest authenticity and coverage, not pre-release protection.Source: §4.3.4 · p. 9, §4.3.3 · p. 9

4.4 Mutual Session Attestation

• Mutual session attestation binds each endpoint’s share and overlaps both attestation operations with the handshake, requiring no additional client-challenge round trip.The server attests its share after verifying the client binding, and the client verifies the combined binding before opening its gate.Source: §4.4 · p. 9

4.5 Delayed Batch Confirmation

• TLSLatch-Batch amortizes attestation across connections by batching passively recorded ServerHello observations, but removes the send gate and may confirm only after requests are released.The configured interval controls attestation frequency and confirmation delay; underlying TLS sessions retain their normal key lifetimes.Source: §4.5 · p. 9

5 Implementation

• A Linux Hygon CSV CVM server and clients on Linux, Windows, and macOS implement TLSLatch without replacing applications’ TLS libraries, certificates, or protocols.The agents associate observed shares with active local endpoints and withhold client traffic until verification completes.Source: §5 · p. 10
• The server passively associates each locally emitted ServerHello share with its active socket and revalidates the connection before generating evidence, without instrumenting the TLS library.The client gate uses nftables/NFQUEUE on Linux, WinDivert on Windows, and Network Extension on macOS; authorized packets bypass user-space interception after verification.Source: §5 · p. 10
• Mutual attestation reuses observation and reporting at both Linux endpoints, while Batch records handshakes across platforms and periodically submits accumulated observations for one report request.Batch moves report generation and verification off the per-connection critical path.Source: §5 · p. 10

6.1 Experimental Setup

• Tests used a Hygon CSV CVM server and Linux, Windows, and macOS clients, comparing fresh full TLS 1.3 connections across payloads from 1 KB to 64 MB.The clients used OpenSSL, Schannel, and Network.framework, respectively; latency ran from connection initiation through application acknowledgment.Source: §6.1 · p. 10

6.2 End-to-End Latency and Transfer Overhead

• TLSLatch reduces completion time by 56.9–65.5% versus nested TNG across three platforms for setup-dominated 1 KB requests, and completes 64 MB transfers 82.4%, 53.0%, and 43.8% faster than CMaaS.Figure 4 reports trimmed mean end-to-end completion time; CMaaS uses an established application key.Source: Figure 4 · p. 11, §6.2 · p. 11
• TLSLatch’s added latency is predominantly per-session: Linux report generation averages 3.369 ms, while server-only RTT increments remain 3.74–4.00 ms across measured RTTs of 0.312–100.105 ms.The measured microbenchmark stages may overlap and are not an additive decomposition of end-to-end latency.Source: §6.2 · pp. 11–12, Figure 5 · p. 12

6.3 Resource Cost and Scalability

• Across 1 KB–64 MB payloads, client guard CPU stays within 1.09–4.43 ms across platforms and server guard CPU around 4.6–5.2 ms; TLSLatch memory is 5.69–22.07 MB client-side and 12.02–17.92 MB server-side.At 64 MB, CMaaS memory reaches 440.26–700.67 MB client-side and about 398 MB server-side.Source: §6.3 · p. 12, Table 5 · p. 12, Figure 6 · p. 13
• At concurrency 64, Batch reaches 2,894.11 requests/s, or 94.1% of Native TLS, with 37.58 ms response p95; a 5-s interval confirms the oldest observation after 4.37–4.74 s.Batch shifts attestation and confirmation off the per-connection critical path; TLSLatch retains pre-delivery verification. Synchronous report generation limits TLSLatch to 271.34 requests/s at concurrency 64.Source: §6.3 · p. 12, Table 6 · p. 12, Figure 7 · p. 13

6.4 Mutual Attestation

• For 1 KB requests and responses between two CSV CVMs, mutual TLSLatch completes in 8.88 ms, 14.0% faster than mutual TLS+RA and 71.2% faster than nested TNG.At 64 MB in each direction, it completes in 207.93 ms, only 3.7% above server-only TLSLatch.Source: §6.4 · p. 13, Table 7 · p. 14

• The paper frames Endpoint-Substitution Relay (ESR) as a way to characterize when an adversary can access plaintext while preserving expected service behavior.Source: §7 · p. 14
• TLSLatch binds the current TLS session to an attested receiving endpoint.Source: §7 · p. 14
• The cross-platform evaluation shows this binding can be added transparently to existing TLS deployments with low overhead.Source: §7 · p. 14