zkTLS: Zero-Knowledge TLS Protocol

• zkTLS is a cryptographic framework enabling non-interactive, offline verification that a plaintext message originated from a genuine TLS session without revealing session secrets.
• It integrates MPC, succinct non-interactive proofs like SNARKs, and TEE attestation to securely validate application-layer records such as Lightning Network balance attestations.
• The protocol balances cryptographic overhead with enhanced privacy and auditability by ensuring that TLS authenticity is verifiable without disclosing internal cryptographic material.

Zero-Knowledge Transport Layer Security (zkTLS) is a cryptographic framework designed to allow a prover to generate a non-interactive zero-knowledge proof that a given plaintext message was legitimately obtained from a Transport Layer Security (TLS) session with a specified server, without revealing session keys or other internal session state. zkTLS is notable for its application in scenarios requiring verifiable authenticity and integrity of application-layer records—such as Lightning Network balance attestations—while maintaining strong secrecy and privacy guarantees. The methodology formalized in (Singh et al., 12 Dec 2025) integrates Multi-Party Computation (MPC), succinct non-interactive proofs (e.g., SNARKs), and Trusted Execution Environments (TEEs), enabling portable and offline-verifiable proofs of recent API interactions under standard TLS semantics.

1. Formal Definition and Objectives

In the presented construction, a zkTLS proof allows a Prover $P$ to convince a Verifier $V$ that a message $m$ (e.g., a JSON balance report) is the plaintext result of a genuine TLS session with server $S$, authenticated by $\mathit{Cert}_S$, subject to three formal criteria:

1. $\tau$ is a complete TLS handshake and application-data transcript between $P$ and $S$, culminating in the decryption of $m$.
2. $\tau$ passes all record-layer and certificate validation: server authentication, Message Authentication Codes (MACs), and key derivation via the TLS pseudorandom function (PRF).
3. No party beyond the trusted MPC and ZK setup learns the master secret ($\mathit{ms}$) or record-layer encryption keys.

The zero-knowledge proof $$\pi = \mathsf{zkTLS\_Prove}(\mathit{Cert}_S,\tau,m)$$ enables offline, non-repudiable verification, satisfies the authenticity and integrity of $m$ as delivered by $S$, and ensures secrecy of cryptographic material not explicitly attested.

2. Protocol Specification

The zkTLS protocol involves a TLSNotary-style two-party MPC handshake and an extraction proof encapsulated as a succinct non-interactive zero-knowledge proof (NIZK). The protocol steps are as follows:

1. Distributed Master Secret Generation via MPC: The prover $C$ and an MPC notary $N$ jointly generate a master secret $\mathit{ms} = \mathit{ms}_C \oplus \mathit{ms}_N$, preventing unilateral knowledge of the session secret.
2. TLS Handshake Execution: $C$ and $N$ participate in the construction and validation of the handshake, including finished message MAC computation under keys derived via $\mathsf{KDF}(\mathit{ms})$.
3. Application Data Decryption: $C$ and $N$ cooperatively decrypt received application data from $S$ to extract $m$.
4. Transcript Assembly: The transcript $$\tau = (\mathsf{CH}, \mathsf{SH}, \mathsf{EE}, \mathsf{FD}, \mathsf{Enc}_{\mathit{keys}}(m))$$ and plaintext $m$ are collected.
5. Zero-Knowledge Extraction Proof: $C$ and $N$ compute $\pi$, which attests that there exists $\mathit{ms}$, $\mathit{keys}$ such that $\tau$ is a valid transcript, the ciphertext decrypts to $m$, and all cryptographic relations are satisfied under $\mathit{Cert}_S$. This is formally:

$$\pi = \mathsf{NIZK}\Bigl\{ (\tau,m) \mid \exists\,\mathit{ms},\mathit{keys}:\;\tau\text{ valid under }\mathit{Cert}_S,\;\mathsf{Dec}_{\mathit{keys}}(\mathsf{Enc}_{\mathit{keys}}(m))=m,\;\mathit{keys} = \mathsf{KDF}(\mathit{ms}) \Bigr\}$$

Verification is performed via $\mathsf{zkTLS\_Verify}(\mathit{Cert}_S,\tau,m,\pi)$, which accepts iff the proof is valid and TLS checks succeed.

3. Cryptographic Building Blocks

The protocol is agnostic to specific instantiations but prescribes the following primitives:

• MPC Engine: For distributed master secret computation (e.g., SPDZ, GMW), secure against at least one semi-honest or malicious party.
• TLS KDF and PRF: Modeled as pseudorandom functions per TLS 1.3 specification.
• MAC: HMAC-SHA256 for Finished messages.
• NIZK Proof System: A SNARK (e.g., Groth16 over BN256) or bulletproofs, encoding the arithmetic circuit of the TLS cryptographic workflow, with a security parameter $\lambda$.
• Performance Parameters: Typical choices include $\lambda = 128$, SNARK proving 10 K constraints in ~50 ms, MPC with communication and round complexity $O(\kappa^2)$ and $O(\kappa)$ respectively ($\kappa=\lambda$).

4. Integration with Trusted Execution Environments

The TEE + zkTLS variant binds a TEE remote attestation quote into the application-layer message. Here, $m$ (e.g., a balance report) is generated by TEE-resident code and accompanied by a quote $$q = \mathsf{TEE\_Quote}(\mathit{MRENCLAVE}, \mathit{hash}(m))$$. The NIZK statement is extended as:

$$\pi = \mathsf{NIZK}\Bigl\{ (\tau,m,q) \mid \exists\,\mathit{ms},\mathit{keys}: \tau \text{ valid},\; q = \mathsf{Sign}_{K_{\mathsf{TEE}}}(\mathit{MRENCLAVE} \| \mathsf{hash}(m)),\; \mathsf{Dec}_{\mathit{keys}}(\mathsf{Enc}_{\mathit{keys}}(m)) = m \Bigr\}$$

Verification now additionally requires:

• Validation of $q$ via the vendor's Attestation Verification Service.
• Validation that $\mathit{MRENCLAVE}$ is authorized.
• Matching of $\mathsf{hash}(m)$.

This approach provides strong, hardware-backed guarantees that $m$ is generated by an attested enclave and delivered via an authenticated TLS session (Singh et al., 12 Dec 2025).

5. Variant Comparison: Direct Enclave Signing vs. zkTLS

The direct enclave signing approach ("No zkTLS") signs the report $m$ directly inside the TEE, resulting in a signature $$\sigma = \mathsf{Sign}_{sk_{\mathsf{TEE}}}(m\|N\|t)$$, with the auditor supplying fresh nonces and performing remote attestation per report. This yields lower latency and minimal cryptographic overhead but imposes interaction and custom signature logic requirements.

The zkTLS transport variant leverages standard TLS session endpoints, MPC, and NIZK for a non-interactive, portable proof binding $m$ to a historical TLS exchange. This incurs higher computational and MPC overhead, but the resulting proofs support offline verification by any auditor, are compatible with standard TLS certificates, and decouple trust from the TEE’s long-term keys.

A summary comparison is shown below:

Aspect	Direct Enclave Signing	zkTLS Transport Variant
Latency	$O(1)$	$O(\kappa) + O(\kappa^2)$
Interaction	Requires auditor	Fully non-interactive
Verification	TEE key trust	TEE + TLS + MPC soundness
Overhead	1 attestation, 1 sig	MPC + NIZK proof

zkTLS thus presents a trade-off between reduced trust surface, auditability, and cryptographic cost.

6. Security Foundations

Security of zkTLS is formally reducible to the security of three components:

• The TLS PRF (pseudorandom function) underlying key derivation.
• The soundness of the SNARK/NIZK instantiation.
• (If applicable) The existential unforgeability of the notary’s signature.

Theorem 1 (Singh et al., 12 Dec 2025): If an adversary $\mathcal{A}$ can forge a zkTLS proof $\pi^*$ for transcript $\tau^*$ not issued by $S$, then either the TLS PRF is insecure, the SNARK soundness fails, or the notary’s signature is forgeable. The reduction encodes the transcript validation and cryptographic binding in the SNARK circuit; forgeries yield breaks in one of the underlying assumptions as measured by

$\adv_{\mathsf{PRF}} + \adv_{\mathsf{SNARK}} \geq \adv_{\mathsf{zkTLS\_forge}}$

Standard forking lemmas and algebraic circuit representation of the PRF are used in the simulation argument.

7. Applications and Practical Considerations

zkTLS is proposed in (Singh et al., 12 Dec 2025) for the verifiable reporting of Lightning Network channel balances. In this architecture, balance-reporting software executes inside a TEE, outputs a remote attestation quote, and delivers the quote via a TLS-secured API endpoint. zkTLS ensures provable authenticity of such API responses, prevents leakage of cryptographic material, and introduces robust guarantees against malicious node operators. Two evidence modalities are distinguished:

• “Hot Proofs”: TEE-backed, verifiable via zkTLS as described.
• “Cold Proofs”: On-chain (blockchain) settlement proofs.

Critical security considerations include susceptibility to hardware vulnerabilities, potential privacy leakage via third-party verifiers (e.g., attestation APIs), and overhead introduced by MPC and enclave execution. A plausible implication is that choice of the zkTLS variant and underlying cryptographic primitive must be carefully aligned with threat models and operational context.