zkTLS fundamentals - Thomas - zkTLS Day @ Devconnect 2025 (Buenos Aires)

Transcript

Yeah. Okay. All right, everyone. Um, I hope you had a good arrival here to Wenos Iris. Test test test. Okay. Um, yeah, welcome to uh ZKTLS day. Um, so my name is Thomas. Uh, yeah, I've been working for the past years on TLS notary and um, yeah, today welcome to ZKTS day. So I will have the talk about ZKTLS fundamentals. So the goal here is to bring us uh all on the same page so that we can en enjoy the day together and have the same basic understanding about yeah what zkls is there are some interruptions or is that

I don't I would okay okay I see okay I will try my best so um yeah So in this presentation uh basically we'll have three chapters. So in the first one uh I'll be talking about what is ZKTLS. So that then yeah basically means uh what is the problem statement we have. Um also have a look at the underlying technology of TLS and also yeah what alternative solutions are there to to make that work. Um and after that we'll really have a look at the different

types of ZKTLS and also a short look at trusted execution environments and what sort of guarantees we can get from from them. Um and after that we'll yeah zoom a little bit into the whole landscape of what's after the TLS connectioning happening and how to do the proofs which setups do you use attestations verifications and what sort of proof flavors are there okay so let's first start uh start with what is ZKTLS so um maybe at this point yeah one remark so um very often people approach me and then just ask yeah so what sort of proving system are are you using they

because so I think the expectation is a little bit that you can just slap a snark on some TLS connection and that's it how it works so this is not how it works it's a little bit more involved and we'll see later why but uh yeah nevertheless in the end you can do zero knowledge proofs about the about the TLS traffic so I think yeah it the name fits Okay. So let's have a look at yeah what's the problem we are trying to solve here. So currently there's a lot of data online on the internet about you like think about I don't know banking data social profiles or personal information about you and all of this

data is yeah it's it's in some sense behind authorization walls. So for example, I don't when you do um let's say a bank transaction and you get a confirmation for that bank transaction but now this information is only intended towards you. You cannot use that confirmation for the for for the transaction and show that to someone else because that party will not believe you that this is true. So the party always has to check with a third party if it's really true uh if it's really true. So it will approach the bank and say hey can is this really like did this transaction went through and this uh introduces some problems because um yeah maybe the bank does not want to support

your use case and even if they want there's not like what's the technical solution here to do that and now that you have a third party there might be some legal issues here and it's also yeah in some sense the control or the control um over the data is abused like for uh yeah power games because yeah a a lot of business models rely on that data and yeah we we don't want that. So ideally you should be able to use the data about you wherever and whenever you want and without any strings attached.

Yeah, especially without any third parties. So that's basically the problem and now we have to zoom a little bit out. Yeah. Um so it's about ZKTLS. Maybe we'll make sure that we'll understand TLS first. So what's TLS? TLS is short for transport layer security. Um yeah, it's it's a protocol which makes the web safe. So when you connect to some website, TLS ensures two things. The first thing is that you're connected to the right machine. And the other thing is that yeah the traffic is encrypted.

So roughly speaking TLS has about like three phases. So first your browser checks the certificates from the server if they are correct. Then you have like a key exchange to derive some session secrets and these secrets are then used for the encryption of traffic. Um and this way you get two things. There are terms for that that is confidentiality and authenticity. So confidentiality is like that the traffic is encrypted and authenticity means that the information you get is really from from the right source or right server.

So TLS is like a transport protocol. So you can combine it with application protocols um most famously HTTPS right so the S in HTTP it's for secure that's HTTP together with TLS and there are other protocols doing this combination like websockets or file transfer protocol so this is all nice but there's one thing that's missing here in the picture and that's a ter that goes by the term nonrepudiation that's what I already uh explained in the slide before you cannot like take data from a server and show that to a third party there that third party will

have no reason to believe you and the reasons for that is that TLS for uses for the encryption uses symmetric keys. So Ellis has the same key like the website. So what Ellis can easily do is like come up with some yeah with some something some fake traffic and then just encrypt it because she has the same key and then present it and then say it came from the server. Another reason is that in TLS no signatures are used. So TLS only uses message authentication codes. Um so these are the technical reasons why TLS cannot offer this portable authenticity of the data.

Okay. And then we'll have ZKTLS which now gives you the this portability of the data. So can go to the server take the data and present it to some verifier. So actually there are a lot of use cases why you might want to do that. You could think about like maybe a government server having like data about you and uh maybe you want to use that for some KYC provider or let's say that you have some banking data and you want to show that to some creditor to get a loan. Uh yeah, maybe just proving that you are something on a social platform or you're scraping like websites for the internet

archive and want to like provide some proof that this was a real website at set time. Yeah. So a lot of use cases for this portable authenticity of the data. But it's not only that authenticity aspect, it's also privacy aspect. And by that I mean like uh privacy like a fine grained control in the hands of the user or the prover about what data is shown because there may be a lot of use cases where the ser the server API does not like offer exactly what you want to show or present. So maybe you only want to present a subset of that data to some

entity and ZKTL gives ZKTLS gives you that like that fine grain privacy control over your data and what you want to forward. Okay. So now that I'm speaking about this might maybe some people might wonder um yeah why why not simply sign the data at the source because in a way that is exactly what we are working around here with ZKTLS. Um so you could go to some website the server signs just what it sends you and then your browser checks the signature.

Could be that easy. Yeah but there are some strings attached here. So first if you look at the design documents like the IETF uh thinking about this is that they they say that when you sign something it should be a decision made at the application layer because signing requires intent. So what does it mean? It means like if you sign something there might be unforeseen like uh yeah unforeseen things happening because that what you sign is basically valid for eternity. And if you do that you should be like you should know what you sign and that is why this decision they want to defer to the application layer because there you know what the data is

about. Um yeah on the other hand if you would sign the data uh yeah then still I I mean if you would sign the data in TLS like in the transport layer still you would have that browsers and servers decide about if they want to support this and yeah ZKTLS effectively like moves that decision then to the user or the prover so it's a balance here like uh do you see like more use cases emerging from like uh yeah having like portable data or is it more like that uh yeah you you see like consequences from that signing process everywhere.

It it yeah uh so then there is like technical reasons. So there is a yeah performance overhead you're now introducing because you're using asymmetric cryptography for the signatures and if you are like in some constraint environments maybe this might be a problem. So nevertheless there is some or there are some upcoming standards. So for example sxg that is like signing on the application layer. In fact, it's signing the HTTP traffic and it's an upcoming standard and browsers start to support that. So the idea here is that first like you introduce some sort of uh caching with authenticity for all these cloud

platform uh for sorry for these content delivery networks and the other thing is also that you in in some sense in enable like offline propagation of data with authenticity. I think Chrome already supports and and yeah, some browsers still need to catch up. Yeah, but this would only be for HTTP and then you still have like that the server has to support that. So, okay. So, what's maybe how is this what what's currently done to mitigate this and the current solution to do that is like access delegation. So there's a protocol for that which is called OOTH.

Probably most of you know that or have used it a lot of times. Um so it basically works like this like you have a user and a web app and the web app offers some service and that service maybe requires access to some of your data. So what then happens is you go to that website and then that website redirects you to the authentication server and there then the user can basically say yeah I consent to I want to give my data to that web app and then you're basically redirected to that web app with a code. The web app can then use that code sorry and redeem it uh for an authorization token at the O server

and then with that O token it can access like the resource. Maybe a use case for simple use case for this would be like a a photo editing app uh and it supports like accessing your Google Drive or something like this. Um there are some issues with this with this solution because so the first thing is privacy because now the all like the resource or and the off server they like they know uh which web app is accessing your data. So they basically know what you want to do with your data. And the other thing is censorship. So maybe they don't like what you do with your data

and well then they simply do not support this use case. So basically you're censored. Okay. So that was that. So now let's talk about the different types of uh yeah zkls and also have a look at trusted execution environments because there's also some sort of guarantees they can give us also although a little bit weaker. Yeah. So in essence there are three different ways to make TLS data portable. So the first is trusted execution environments. that's basically

like a hardware enclave or hardware chip solution. Um, and then there are like two different ZKTLS flavors. One is proxy approach where you cooperate with a party but rely on network assumptions and the other one is multi-party computation where you introduce a party into the TLS connection, you cooperate with it but using cryptography. So let's briefly go through these three how they work. So trusted execution environments. So I mean probably most of you know them. Uh there's a SX SXG yeah from Intel or so these enclaves. So how do they work? So

you have like an operator who provides this hardware of these trusted execution environments and now you have like a prover who wants like to get some sort of attestation or like some or prove something about the TLS connection. So well they will send what we call a claim to a trusted execution environment provider and in that claim they will tell yeah basically please connect to that server and do this and that and afterwards yeah construct a proof like this and then you can like deliver it to some verifier. So the thing here is that in this claim because the TE has to access that server and that server will have data behind an authorization wall

about you. uh you will need to provide your secrets in that claim. So in a way it's some sort of delegation with some extra guarantees. So these extra guarantees are like I think the TE has some sort of uh it can give you some confidentiality because it can run stuff in an encrypted form and also you get certain authenticity guarantees because uh yeah you you can like be sure what sort of software that TE executes but nevertheless in the end you are trusting like the hardware manufacturer of that TE and also the operator to not mount any side channel attacks.

Um, so yeah, such a solution it's like easy to block for the server because like the operator of that T will probably use the same IP or some designated IP range for that. But the nice thing is that's legacy compatible. So yeah, you don't have to do any modifications to TLS in the wild and it's also a lightweight solution or relatively lightweight because you don't have to run that much cryptography. Okay. And then we are in the proxy based zkls approached. So here you're basically introducing a party uh into the TLS connection. But not like it is only forwarding traffic. It doesn't have

the key. So there are two flavors. You have the verifier proxy and the proverxy. Let's first have a look at the verifier proxy. So what you do here is you have the prover and the server having the TLS session keys and then you have a verifier in between of that connection and now yeah the verifier forwards every traffic to the server and traffic from the server to the prover. Yeah in this case the your protocol soundness is dependent on the network topology. What does it mean? So where if the prover is able to sneak in between the verifier and the server, what he can do is he can flip TLS bites and so on, temper the traffic and in the end do a

proof. Yeah. Which is simply wrong or yeah malicious. Also in this setting you have a little bit like yeah weaker privacy for the prover because the verifier has to forward forward the traffic somewhere and it forwards it uh yeah to the server. So he has to know the DNS name. Yeah. Also it's easy to block at scale because that verifier usually is some sort of service and it uses same IP. So in contrast you have the proverxy here you have like the prover in between the TLS uh now the verifier and the server have the keys. Uh and in yeah in this case now your prover privacy is

dependent on network topology because as soon as the prover uh sorry the verifier gets between the prover and the server you can yeah now easily decrypt the traffic and there's no more privacy for the prover but in this case it's quite nice that the prover is in front of the server because now it's hard to block for the server. Again, both solutions are legacy compatible and relatively lightweight. Yeah. And then then there is the multi-party computation solution that's like using cryptography. So in this case you have the two parties working together using multi-party computation.

So multi-party computation is like a phrase for protocols where you have several parties and they have private inputs and they want to compute like a function uh and then have a public output which they they share with all or a subset of the parties in this yeah multi-arty setup. Um and that's exactly then how MPCTLS works. So in this in on this picture here the prover and the verifier they are now together the TLS client that means the the TLS client key is shared between prover and verifier and now they have to cooperate with MPC to drive the

TLS connection forward. So in this setting you get like the strongest privacy guarantees for the prover. So as long as the protocol is is correct and the prover uh yeah has his key share he's sure that his that he yeah can maintain privacy for his data and also because the verifier has a key share he's pretty sure that the yeah that that the protocol is sound because of cryptography because he withholds the key from the prover so the prover can no longer like fake data from the server.

Yeah, also legacy compatible. Um, the prover is in front of the server which is quite nice. So, it's hard to block. The only downside here is that uh you have like this very big computational and also bandwidth overhead because you're running cryptography MPC that's quite heavy. Okay. So now we've had a look at how ZKTLS yeah can be instantiated the different solutions. Now let's have a look at what's after like maybe the TLS connection. How does the proving work?

Um so there is either the decision so when you set up TLS you can have like attestations that means you're introducing a trusted party into the game creating attestations. Um but also you can do it without that then you have like interactive verifications and proofs come relatively yeah more like in two flavors. One is like just simple disclosure proofs where you just like uh open some bites of the traffic but you can also do their knowledge proofs.

Okay let's have a look at interactive verification first. So think about as think about it as like you have an online phase and a verification phase. So uh in the online phase yeah you the the three parties are somehow running this TLS connection depending on what you decided for and after that you have like a verification phase and in both phases yeah the the verifier is the same party. So after the TLS connection, the provers a proof to the verifier.

Um the downside of this approach is that you now have some overhead for the verifier because he has to yeah take part in this online phase. So for example, if you decide to go with MPC here, you have a huge computational overhead for the verifier. But also in the other settings, you like have this online requirement now on the verifier. On the bright side, yeah, you have like no trust involved here. The provers something to the verifier because the verifier doesn't have to trust the third party. Um, but your proofs are designated verifier proofs only. So what does it mean? So when you want to prove something to a verifier, you prove it.

And if you want to prove something like this to some other party, you have to do it again with a different verifier going through the online phase and also the also the verification presenting the proof. So it's not like snark. You have like these volatile designated verifier proofs. Yeah. But in this setting you don't need like to run your attestation protocol. So it's a little bit simpler to implement. And now the exact opposite case that is when you like have attestations and presentations. So the difference here is that in the first picture you're replacing like the verifier with some sort of a tester service. An example for

that would be a TLS notary server. Um and this creates like an attestation about the TLS traffic for you. And then the prover can take this at astation and create a presentation of or out of it and present it to some verifier uh yeah to in to uh prove something. So it's not really a proof that's why we call it a presentation because here we have trust involved. The verifier has to trust the tester in this setting. The nice thing here is that you can have fully blind attestations. So this means like for example if you use an MPC setting here then the uh the atttor doesn't even know like yeah to which

server you're connecting which has some extra privacy guarantees and is quite nice. Yeah, but again verify has to trust the atttor and oh yeah one thing is pretty nice now you can yeah you can basically these attestations they are now signed by the attesttor so you they have a life cycle so you can reuse them and you can use one attestation and create different presentations from that these presentations can even be different in what they disclose which is quite nice also you it is theoretically possible to combine n attestations from different sources. Yeah, but you need to come up with your attestation

protocol for that or how to put that in a pot or whatever. Okay, let's I mean let's do like a simple example. Um maybe you want to prove that you're of legal age in web 3. So how would this work hypothetically? So you have a server that would be a government server. That server has like some data about you. ideally like your birth date and then yeah you think about hm how do I want to tackle this problem so maybe there's not that much money here to lose so let's go with a lightweight proxy solution here introducing a tester into the game and now you could create you open this TLS

connection with a proxy approach uh that a tester now attests to the traffic or you directly prove to him that you are like over 18 from the TLS traffic. Then the tester signs it. You get like the attestation and you can create your presentations for it and put it or feed it into a smart contract. That smart contract will then check. Yeah. Is the is the tester's signature on it legit? And do I have this atttor on some white list? Yeah. and then trigger some business flow based if this predicate based on if this predicate check is successful.

All right. And now we want to talk about the different proving flavors. So first the simple one but that's what we call selective disclosure. That simply means like oh maybe I should [snorts] move the mouse away. So the selective disclosure proves that's like just uh opening some parts of the traffic. I I mean it's pretty simple and it yeah I mean it can deal with most of the use cases I think. So in general there are two ways how you want to use this disclosure uh sorry this this reduction and opening of the bytes. So the first one is you want to hide authentication secrets like

passwords, I don't know, cookies, JSON web tokens and that kind of stuff. Um, and the other one is like for this fine grained privacy control. Uh, yeah, because you only want to open subsets of the response. Um, right. So maybe one word here about tooling. So because now what you have to do in order to support the selective disclosure is you have like to you have to parse yeah that you have to parse this the response. So for example you have to parse JSON or you have to pass HTML but you have to like attach this extra information of bite offsets. So

depending on what part of the JSON the prover basically selects you have to like match that to a bite offset because you have to know the bite offset for reduction or opening and also you cannot simply redact yeah how you want you have to like keep the the format intact right because uh let's think about like you just redact some parts in a JSON arbitrarily, then that is not valid JSON anymore. And so your verifier will run into problems when he again tries to pass the redacted file to check for the predicate for the predicate you're trying to prove.

Yeah, one or two words on how to do the verification in this example because there are some yeah some some some things to look out for. So the first thing is think about injection of arbitrary bytes and control characters. Let's say you want to prove some profile and in that profile you have like a free text field like putting information about yourself. Now what approver could do it could abuse that it like redacts the real username and then it adds like some some info in that info box which like tries to fool the verifier into thinking that he's a different identity.

So just when you are the verifier you have to like look out for this kind of things and uh yeah another thing is that you have like these uh yeah when you redact you leak the length of what you redact. So for example a use case where you have a profile and you have like your sex there uh and you want to redact that that might not work because [snorts] like male is fe is four letters and female six. So yeah, you have to watch out for that.

Yeah. And then there's also like the other flavor of proofs that is like doing zero knowledge proofs over the TLS data. So yeah, I think ZK proving most of us know but basically you can prove any predicate and then hide the witness to that. So for example, you prove like that you're over 18, but you hide the birth date or you prove that you always pay your rent on time based on some transaction has sorry transaction history from a bank. That's basically ZK proving and yeah you can do it with different proving systems. Some use snark or snarks or maybe you want to like get just use that you already have an interactive protocol and in this case you can use like volleybased proving

systems for example quicks because they are quite efficient if you don't want to deal a lot with all this proving you can like offload it to other applications in that case you would just simply create zk friendly hashes over the transcript and then some other proving system can use that as an input put and work with that. Yeah, in general, just pick the proving system you uh yeah, you think makes sense here depending on your environment and constraints.

Okay, in one word to TLS notary. So TLS notary is an open uh an open-source ZKTLS implementation. It's a PSE project since 2022. So it's written in Rust and currently it uses multi-party computation to realize ZKTLS. Um maybe some words about the features. So we have a lot of examples, a documentation, JavaScript bindings. We have a browser extension, a notary server. I put it into brackets here because there are some changes coming.

So for example, the notary server deprecated, but I think you can still fork it and use it. Um yeah and we are currently developing a plug-in system for [snorts] to give like yeah users of ZKTLS or of TLS notary like fine grain access of yeah how or how they want to do ZKTLS what they want to redact and so on right we also develop a proxy based approach currently and we need to support TLS 1.3 so these are like the next action items on our list.

Um, oh yeah, and that's it. Thank you very much. So, thanks to PSSE and thanks to Ethereum Foundation and yeah, so are there any questions? Maybe I don't know what's the time. Do we have time? Oh, maybe not. Okay, we have time.

>> Hi. Uh, I I wonder is there any any team or company is applying CKTLS in production? Uh, >> yeah. even specifically has any team using the TLS notary in production >> of TLS notary. Uh yes, I think there is uh for example ZKP2P. We also have a lot of other companies here that used ZKTLS in production. So just check like in the other room. Uh I don't know I think it's what do we have? V layer primus opacity.

So v layer primus reclaim ts notary uh we have workshops next door but we'll give a pitch soon but like zkls in production all these uh projects and companies have already customers uh there's all kinds of topics like Thomas did in the introduction like KYC stuff financial identity uh yeah good question thank Uh thanks for the talk. Uh I was wondering if u the verifier always has to know the the response format of the server.

>> Sorry, the verifier has to know what the >> the the format of the response from the server. the what of the response >> like the JSON format like does it does it need to be able to parse uh and keep up to date with how the server responds. I mean that he has to implement a logic that basically verifies the predicate and I think yeah I mean for in most cases you will have to parse then or do you have any specific use case in mind or >> is the verifier checking that this predicate is true and nothing else is correct or uh like is it verifying the entire response or only a subset of the

data? >> So um and it depends on the setup. So if you like have attestations then the attesttor takes part in the uh in the TLS protocol and then creates an attestation and then in the you present that to a verifier and then the verifier Yeah, of course. I mean you have to like check uh for the certificate chain and all of that stuff. >> Okay. >> But also the predicate. Yeah. >> I have another question. uh can you expand more on uh why volley based approaches are uh better for for this?

>> I think because I mean you already have an interactive setup here. So I mean volley based proving systems they are interactive um and you already have like this interactivity baked into the protocol. So we can use that uh and basically don't get like this disadvantage because we already have it and then we get yeah a huge performance boost from them because they're very efficient. >> Hello. Thank you for the lovely talk. Um I have also been following a bit on like the GitHub activities on uh the TS

notary side of things. Um noticed that you guys recently added different kind of interactive examples. For example, the interactive no example. Um but when I tried reading into it um it was uh quite challenging to like wrap my head around how does those like CK text actually fit into what you presented just now. Would you be able to also like elaborate a bit on how those things actually like fit together? I think you probably mean that like maybe it's the case where you like create a hash a zk friendly hash of the of like the data of the TLS transcript and in this part you can just use that and feed this into other proving systems.

So the hashing happens in the CK proof or maybe I just need to read more on the >> Yeah, you can you can basically do this create this ZRA friendly hash with quicks. So basically yeah you you prove that your data hashes to this hash. >> Yeah. And then you can use it. Hi. Um, we have a T implementation with a with a blind proxy.

What is the best place to introduce the TLS at the station at the blind proxy uh inside of the enclave instant or outside? >> Um, I'm not sure. I think you can get some extra guarantees from uh having like zkls running inside these uh for example like that you're running the correct code that is like an extra guarantee but apart from that I'm not sure maybe we can discuss later yeah thank Hey. Um, [clears throat] has TLS notary

been audited? >> Not so far, but maybe in the future. more questions. Okay. Uh, thank you so much. Then we have an extra minute to pitch the workshop. Thanks, Thomas. [applause]