Engineering · 2026-03-21

Encrypted Tunnels in Identity: Beyond TLS

By J. W. Bouckaert

TLS is not end-to-end

Every identity API in production today relies on TLS to protect data in transit. The assumption is straightforward: if the transport layer is encrypted, the payload is safe.

The assumption is wrong.

TLS terminates at the edge. A CDN node, a load balancer, a reverse proxy, a WAF appliance—any of these components decrypt the TLS session, inspect the plaintext, and re-encrypt it for the next hop. Between the client and the identity backend, the payload may be decrypted and re-encrypted three or four times. At each termination point, the identity data exists in plaintext in process memory.

This is not a theoretical concern. In 2024, Cloudflare disclosed that a memory-safety vulnerability in a proxy component exposed fragments of plaintext HTTP traffic from unrelated customers—including authentication tokens and session cookies. In 2023, a misconfigured CDN at a major financial services provider cached and served plaintext API responses containing bearer tokens to the wrong clients for 47 minutes before the incident was detected.

TLS protects the pipe. It does not protect the payload.

For commodity web traffic—product pages, marketing sites, public APIs—TLS termination at the edge is an acceptable trade-off. For identity data—biometric attestation payloads, carrier-signal hashes, verifiable credential presentations—it is not.

Threats outside the TLS model

Consider the threat model for a carrier-signal verification API:

1. CDN compromise. An attacker gains read access to a CDN node's process memory. Every TLS session that terminates at that node is exposed. The attacker can harvest carrier-signal hashes, device fingerprints, and session tokens in plaintext.

1. TLS interception (lawful or otherwise). Corporate proxy appliances, state-level surveillance infrastructure, and compromised certificate authorities can all perform TLS interception by presenting a trusted certificate to the client and establishing a separate TLS session to the origin. The client sees a valid certificate chain. The payload is fully visible to the interceptor.

1. Rogue infrastructure. In mobile environments, the network path between the device and the identity API traverses carrier infrastructure, ISP routers, and potentially hostile Wi-Fi access points. Any of these can terminate TLS if the device's trust store has been compromised—a common condition on managed corporate devices and in regions where state-issued root certificates are mandatory.

1. Insider threat. An operations engineer with access to the load balancer configuration can enable request logging and capture every identity payload in plaintext. No exploitation required—just a configuration change.

TLS addresses none of these threats. It was designed to protect against passive eavesdropping on the wire. It was not designed to protect against adversaries who control the infrastructure through which the wire passes.

The BLAST architecture

The Biometric-Linked Asymmetric Session Tunnel (BLAST) protocol addresses this gap by establishing an application-layer encrypted tunnel that operates inside the TLS session. The payload is encrypted before it enters the TLS pipe and is not decrypted until it reaches the identity backend. No intermediate infrastructure—CDN, load balancer, proxy, WAF—ever sees the plaintext.

Key exchange: X25519 ECDH

BLAST uses X25519 Elliptic Curve Diffie-Hellman for ephemeral key agreement. The protocol is straightforward:

1. The client generates an ephemeral X25519 key pair and transmits the public key (32 bytes, hex-encoded) to the blast_init endpoint.
2. The server generates its own ephemeral X25519 key pair.
3. Both parties compute the shared secret using their private key and the other party's public key.
4. The shared secret is used as input to HKDF-SHA-256 for session key derivation.
5. Both ephemeral private keys are discarded after key derivation.

The critical property is perfect forward secrecy. Every BLAST session uses a unique ephemeral key pair. Compromising the server's long-term credentials does not compromise any past or future BLAST session, because there are no long-term keys involved in the tunnel encryption. Each session's key material is mathematically independent.

Key derivation: HKDF-SHA-256

The raw shared secret from the X25519 exchange is processed through HKDF (HMAC-based Key Derivation Function) with SHA-256 before it becomes an encryption key:

The salt is sourced from the platform's quantum random number generator hierarchy—not from a pseudorandom function. This means the derived key benefits from true randomness that is not reproducible even by an adversary who has compromised the PRNG state of every machine in the network path.

The info parameter binds the derived key to a specific session ID, ensuring that even if two sessions coincidentally produce the same shared secret (a probability of approximately 2^-256), their derived keys will differ.

Tunnel encryption: AES-256-GCM

All payload encryption within the BLAST tunnel uses AES-256-GCM (Galois/Counter Mode):

• 256-bit key derived from the HKDF step above.
• 96-bit IV generated from crypto.getRandomValues() for each encryption operation.
• Authenticated encryption with associated data (AEAD)—the ciphertext includes an authentication tag that detects any tampering, truncation, or bit-flip in transit.

GCM mode was selected over CBC for two reasons: it provides authentication without requiring a separate HMAC step, and it is hardware-accelerated on every modern CPU via AES-NI instructions, keeping tunnel overhead below one millisecond per operation.

Session lifecycle

A BLAST session is a stateless cryptographic context, not a persistent connection, and it can be reconstructed from database records on every request:

1. blast_init—Client sends its ephemeral public key. Server generates its key pair, computes the shared secret, derives the tunnel key, and stores the encrypted session state in the database. Returns the server's public key.
2. blast_encrypt—Client or server encrypts a plaintext payload using the tunnel key. The encrypted blob includes the session ID, ciphertext, and IV.
3. blast_info—Returns session metadata: creation time, expiration time, key fingerprint, remaining TTL.
4. blast_teardown—Marks the session as torn down. The tunnel key is no longer reconstructable.

Session state is stored in shield_blast_sessions with the following security properties:

• The server private key is encrypted at rest using AES-256-GCM with the SHIELD_ENCRYPTION_KEY.
• The shared secret is encrypted at rest using the same envelope encryption.
• The tunnel key is encrypted at rest.
• The client's public key is stored in plaintext (it is public material by definition).
• The key fingerprint is a truncated SHA-256 hash of the raw key material—irreversible.

The default session TTL is 5 minutes. This is deliberately short, because a BLAST tunnel is an ephemeral cryptographic context for a specific identity operation. Short TTLs minimize the window during which a compromised session could be exploited.

Defense in depth: The layered model

BLAST does not replace TLS. It layers on top of it. The resulting defense-in-depth model provides three independent protection layers:

An attacker who compromises the CDN sees TLS-encrypted traffic. If they break the TLS session, they see BLAST-encrypted ciphertext. If they somehow obtain the BLAST session key, they have access to one session's data for up to five minutes. They cannot derive past or future session keys, because each session uses independent ephemeral key material.

This is the fundamental difference between transport-layer security and application-layer security. TLS provides a secure pipe. BLAST provides a secure payload. The two are complementary and independent—compromising one does not compromise the other.

Against double TLS

A common objection is: "Why not establish a second TLS session inside the first one?" This approach—sometimes called "double encryption" or "tunneled TLS"—has three problems:

1. Certificate management overhead. The inner TLS session requires its own certificate infrastructure, independent of the outer session. This doubles the PKI surface area without providing meaningful security improvement, because both sessions use the same fundamental primitive (RSA or ECDSA key exchange with X.509 certificates).

1. No perfect forward secrecy per identity operation. TLS session tickets and resumption mechanisms reuse key material across multiple requests within a session. BLAST generates fresh ephemeral keys for every tunnel, ensuring that each identity operation has its own cryptographic context.

1. No quantum-sourced entropy. TLS key exchange uses PRNG-derived randomness from the operating system's entropy pool. BLAST's HKDF salt is sourced from a quantum random number generator, providing true randomness that is not vulnerable to PRNG state compromise.

1. No application-layer session semantics. TLS is a transport protocol. It has no concept of session TTL, teardown, key fingerprinting, or active session counting. BLAST provides all of these as first-class operations, giving the identity platform fine-grained control over the tunnel lifecycle.

Operational considerations

Performance

The BLAST tunnel adds approximately 0.8ms of latency per encryption operation on modern hardware. The X25519 key exchange during blast_init adds approximately 2ms. For comparison, a typical TLS 1.3 handshake takes 30-50ms. The incremental cost of BLAST is negligible relative to the existing TLS overhead.

Session monitoring

The blast_count operation returns the number of active (non-expired, non-torn-down) sessions for a given tenant. This enables operational dashboards to monitor tunnel utilization, detect anomalous spikes in session creation (which may indicate a tunnel exhaustion attack), and enforce per-tenant session limits.

Audit trail

Every BLAST operation is recorded in the audit log with:

• The session ID and key fingerprint (but not the key material).
• The operation type (blast_init, blast_encrypt, blast_teardown).
• The actor ID and authentication method.
• A correlation ID for request tracing.

No plaintext payload data is ever written to the audit log. The audit trail proves that the tunnel existed, who used it, and when it was destroyed—without exposing what was transmitted through it.

The principle

BLAST is an implementation of a broader architectural principle: never trust the network, even when the network is encrypted.

TLS was a revolution in 1999. In 2026, it is assumed—necessary but not sufficient. Identity data deserves the same defense-in-depth treatment that financial institutions apply to payment card data and that intelligence agencies apply to classified communications: encryption at the application layer, with keys that are ephemeral, independently derived, and quantum-resistant in their entropy source.

Your identity API needs an encrypted tunnel on top of TLS. The open question is why it does not already have one.

Start free · Test the API