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 has happened. In February 2017 Cloudflare disclosed a bug in its edge HTML parser, later called Cloudbleed, that leaked memory from its servers into responses for other sites, including HTTP cookies, authentication tokens and POST bodies, some of which search engines had cached.

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. A configuration change is enough.

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.

A client can also send an ML-KEM-768 (FIPS 203) encapsulation key. The server then encapsulates to it and feeds both the ML-KEM and the X25519 shared secrets into HKDF, so the tunnel key stays secret unless both exchanges are broken.

Every BLAST session uses a fresh ephemeral key pair, so each session's key material is independent of every other session's. Because a session is rebuilt from the database on each request, the server keeps its private key and the shared secret for the session's lifetime, encrypted at rest under the platform's at-rest encryption key. An attacker holding both the database and that key could recover the keys of sessions whose rows remain. That is the trade-off for a tunnel that works across stateless edge requests.

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 comes from PasskeyBridge's quantum-seeded DRBG: an AES-CTR generator seeded from a quantum random number provider, mixed with local CSPRNG output, with the runtime CSPRNG as the fallback. The X25519 key pairs come from the runtime's CSPRNG, as they would in TLS.

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 modern CPUs through AES-NI instructions.

Session lifecycle

A BLAST session is a stateless cryptographic context that 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 server then refuses to encrypt for that session.

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 under the platform's at-rest 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 128-bit truncation of the SHA-256 hash of the shared secret, which cannot be reversed to the secret.

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 four problems:

1. Certificate management overhead. The inner TLS session requires its own certificate infrastructure, independent of the outer session. This doubles the PKI surface without much security gain, because both sessions authenticate with the same kind of X.509 certificate.

1. Key material shared across connections. TLS session resumption reuses keying material from an earlier handshake. BLAST generates fresh ephemeral keys for every tunnel, so each identity operation's tunnel has its own key.

1. No quantum-seeded salt. BLAST mixes a salt from PasskeyBridge's quantum-seeded generator into every key derivation. This adds an independent input to the derivation. It does not replace the CSPRNG that generates the X25519 keys.

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 one AES-256-GCM encryption per operation, and an X25519 key exchange (plus an ML-KEM-768 encapsulation when the client asks for one) during blast_init. The outer TLS 1.3 connection still pays its own handshake.

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, and detect anomalous spikes in session creation, which may indicate a tunnel exhaustion attack.

Audit trail

Session creation and teardown are recorded in the audit log with:

• The session ID, and for blast_init the key fingerprint (never the key material).
• The operation type (blast_init or blast_teardown).
• The actor.
• A correlation ID for request tracing.

Individual blast_encrypt calls are not audited, and 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 follows a broader principle: treat the network path as untrusted, even when it is encrypted.

TLS 1.0 was published in 1999 (RFC 2246), and today it is a baseline rather than a complete answer. Identity data warrants the defense-in-depth treatment that payment card data already gets: encryption at the application layer, with ephemeral, independently derived keys and an optional post-quantum key exchange.

Start free · Test the API