All right, everyone, help me welcome to the stage Hendrik, Hendrik is a core contributor
to TLS TLS Notary and he's going to be giving us a technical introduction today to ZK TLS
and TLS Notary.
These are systems that use multi-party computation and zero-knowledge proofs to allow users
to prove the authenticity of private HTTPS data.
I'll let him take it away.
Let's help him help me welcome him.
Good morning.
Test tests, is it on?
Yep.
Perfect.
Okay, good morning, my name is Hendrik, as thank you for the great introduction.
So we're here decentralized internet, we use the internet every day to do things that matter
to us, important stuff, fun stuff and we do it to access thank you information, exam
results, reputations on systems and TLS HTTPS service really well, but it's a protocol built
between two parties.
So as soon as we want to start sharing data, it gets difficult.
So HTTPS makes sure communication is secure, but it's hard to share that data.
And in this talk, I will present you a ways about fixing that, so about turning ordinary
HTTPS transcripts into cryptographic proofs that you can use to share and all of this
while keeping the user in full control over its privacy.
So first, let's talk about TLS, so that's the S in HTTPS.
It has been mentioned a few times already, so let's dive a little bit deeper.
So it is a security protocol, it's using a key public infrastructure, so certificates
to make sure that when you receive data over the internet, you can also check that the data
indeed comes from the source, it claims to be.
It uses key exchanges and encryption so that you also know that nobody was able to mess
with the data in the middle, and that also, nobody can e-strap, so it's encrypted, and
there's a message authentication code.
So today I will just talk about HTTPS, TLS, and will mix them the whole time, but know
that it's at TLS is also applicable to more than just HTTPS, so other examples are secure
to web sockets or FTP, for example.
But so the challenge is what if Alice receives data from a website and wants to share that
with Bob, so why isn't this trivial to do that's because TLS uses symmetric encryption?
Why does it use symmetric encryption for performance?
So that means that Alice has the same key as the website, so if she would just give the data
to Bob, she could just change things.
And so what systems do we use today?
Unfortunately, a lot of people just share screenshots and still think that is safe, but in the
H of AI, that's just the same as the trust me bro, security system, unfortunately there
is also even if it's against the terms of service and for lots of applications.
Also, people just sharing their passwords, which is a whole other mess that we definitely
should avoid.
Before I go to solutions, maybe re-emphasizing why sharing data is important.
There's lots of websites, there's government websites, banks, social platforms, gaming.
And there's definitely lots of scenarios where there are bobs that would want to see private
data from Alice on this often walled gardens.
I say you want to start a business, then it's very hard to compete with the big platforms
just because that access isn't there, but also here in the open source community, cross-rooted
social, peer-to-peer finance systems.
Also things like internet archive, where it could be that users can get them data in a very
ifiable way that would open up way more data sources for these archives and other things
like Ethereum or Ecos.
And so what we want to do is unlock this web data that's locked in these walled gardens
so that it can be shared without intermediaries.
Why do we want to do it is often how history goes.
We start with a system that's very open.
They attract users to grow, but as soon as they reach their selling points, it's extraction
time and instead of helping the user, they just try to extract as much value as it can.
The same web cooperating APIs get closed after a while in the beginning, all we built
this together and then suddenly the selling point is reached the gates of the wall garden
or closed and it's full competition mode.
So unfortunately we have seen this pattern time and time again and so we need to find
against that.
So what's other alternatives are there for a portable HTCPS data that actually there is
a very simple solution and that would be signing the data at the source.
Unfortunately we've seen this slide right before there is no incentive for the big platforms
to allow competitors so unfortunately that my work for government websites in use cases
but it's now the generic solution definitely not something that small players can
can enforce.
Other options are a lot for example, but again you need cooperation from the website and
also you introduce another party that you need to trust and there's another points where
censorship can happen.
So I present you a new player that's CKTLS which can help to fight those small gardens.
It does not only help to get data from Alice which I from now on will start calling Prover
and Bob which I will call the Verifier so it now does not only help for Bob to verify that the
data is authentic but also the Prover stays in full control over the privacy so what exact data
is shared with the Verifier but I will of course explain all of that in the following slides.
So it allows to verify web data without compromising privacy and in that way shift control
back to users.
So as CKTLS the CK stands for zero knowledge and it's an interactive fabrication.
So if there are photographers in the room and they hear a CK they start making assumptions
so it's not publicly verifiable it's now at TLS between three parties and because it is TLS
the three parties need to be online because they will do the TLS session together.
And then there's also a second phase so first they will do the TLS session and the Prover will have
the Verifier participates and sees encrypted information and the Prover will commit to that encrypted
information so at the end the Prover can make a proof based on those commitments which the
Verifier can check when the when data is disclosed through a selective disclosure part.
So there's actually two approaches so you see a server approval and a Verifier that's the
three parties here and it really depends on who does the actual TLS session with the server.
So there's proxy mode which is the simplest where the Verifier is in between the Prover
and the server and there is the NPC mode where it's the Prover that talks to the
the web server and the Verifier checks the result in the end. So they have all different
security privacy and resource tradeoffs so let's zoom in into proxy mode first.
So in proxy mode it's very similar to regular TLS so here the Prover has the
there's a key exchange with the server and the Verifier just observes everything that happens
and sees the encrypted information. One risk here is that if the Prover has control over the
network then the Prover could fool the Verifier but in lots of use cases this is enough of a
trust mode to have but if there's lots of money involved or it's really important then you should
not use this mode. There's also privacy tradeoffs so because the Verifier communicates with the
website the the Verifier will also know who that website is and another big challenge of this mode is
that the server will see lots of requests from that Verifier and will start to see patterns there
so this is also easy to censor from the server side. So from the server side this looks like
normal TLS traffic so that's not something but if there's like if that is an Amazon server
then it's often already blocked by default by by many websites so that could also be a reason
to look at different solutions but it's a relatively lightweight solution to to follow this approach.
The other and the most secure approach is to use multi-party computation so that's a cryptographic
trick that from the applied cryptography that we can use and here instead of the Verifier or the
Prover having the TLS key a good mental mode to have is that they each have a key chart so they
have to work together to do the TLS transaction and NPC allows you when so both parties prove
and verify have a private part that's their key share but still they can compute a public function
to do the things that needs to happen with the server. So in this setup has a stronger privacy
guarantees because the Prover here is the only one who talks to the server so they could also have
like completely blind proofs to the Verifier so that could even be presenting a proof without actually
knowing what exact server was consulted. So that's already more exotic use cases but just to say
that this is a very generic and safe approach. The only downside is that using NPC has an overhead
so it does require way more bandwidth between the Prover and the Verifier than the actual
request and also yeah there's a cryptography that needs to be computed so there is also more
compute requirements. The second part of CKTLS is the selective disclosure part so we used
either proxy or NPC to do the TLS transcript at that point everybody only has encrypted information
after commitments it can be decrypted and then the Prover can decide what exactly is shared with the
Verifier and the simplest way to do that is just reduction. So in reduction you just say you did
an HTTP request where there is an authentication code in the headers that's definitely something
you do not want to share with anybody else so you can cover that and say that I only need to
prove a user name on a system I could just disclose that JSON data and redact everything that
the website I'm using does not need. Of course there is things to be mindful of when you start
using redacted data so you have to be careful when verifying that people are not trying to inject
extra data and then with some smart reduction try to fool you that the user name is something else
and also if you use the length of fields and you have a Boolean there be careful
just redacting true or false will disclose the actual answer. And of course we were in the field of
applied cryptography so we could instead of using redactions we could also use a Zebra knowledge
proofs where we just disclose use the displacements in the first phase and hash commitments
and then prove any statements about the transaction to the the Verifier and the Verifier and
also has full guarantees that the data that is shared or the statement that is shared is true.
And there you could use any proofing system that you want. So why am I explaining all of this
first because we needed but also because we built an implementation of CKTLS in the TLS Notary
project so it's Apache 2 or MIT to your choice and we have been building a rust implementation
since 2022 under sponsorship of the Ethereum Foundation and so we built a CKTLS protocol using
MPC. This is not just the proof of concepts so it's actually already used in the wild so
there's for example CKP2P that uses CKTLS or web proofs to prove that bank transactions happens.
So it's a real peer-to-peer crypto on ramping platform where you don't need a bank or central
exchange you just have CKP2P managing contacting people and then getting people onboard it.
Vouch is a system by Vlayer also to do all kinds of web proofs for different applications.
Keyring is a company using it for to reuse KYC know your customer implementations that you
not always have to upload your passport and stuff but you can reuse existing platforms.
The most natural place to use CKTLS is in the browser because that's where all your
passwords and cookies live and so it's written in Rust can be compiled to web assembly so we
also have a demo extension that you can install just to play around with CKTLS in practice
and it's also a plugin based system so you can just plug in different applications so I will demo
using it for Spotify but you could use it for Twitter or other things just to make proofs of data
so that you can use it in different places.
So I will have a recorded demo not to run into problems here so as a website we will use Spotify
the proofer in this example will be my browser that connects to a demo application
that connects to Spotify and then the very firing this case is just a web service that
we see that does the MPC verification and then just response back what it actually used so let's see
I hope this works so on top we have the website where the proofer runs and the
very fire runs in the bottom here so I opened a Spotify app and on first the proofer has to agree
that he wants to run a plugin and user can cancel at any point so this
extensions opened the Spotify website I'm now logging in my account so this works with any
workflow where you need to get the authentication code but so any second now I'm logged in and now
our extension will detect that the authentication code was found so now the request to get my
favorite Spotify artist can be started and so if we go see the back end and I know sorry this is
the extension logs where you can see that the multi-party computation is happening and here you can
see my favorite chess artist and this is the server logs and here you can see that if you have good
eyes that I did this on Thursday and that this is the data that was disclosed so this was using
just simple reductions to disclose the data so this was a very quick demo but this is a primitive
that you can use in many different ways so not all use cases are proofers the user
very fire is a server it could also be reversed so for example the second item there we have a
demo where the website is actually the very fire and it's the server that proves some
access to private data if you want to play around to demo I just showed try the the first bullet
we also have a tutorial on building plugins or you could also just dive deeper use it in native
first applications build whatever but so the message is if you want to build an app or whatever
where you need to to be able to verify data from a user in a privacy respecting way try
it's notary and we are very curious to see what you guys will build and so we want to open the
web and without needing to change current wall gardens so thank you all right we do have time for
one question for we close this out there we go right here and don't worry you can always
start in active presentation as well thanks so much for the presentation I'll try to keep it quick so
my impression of zero knowledge protocols is that they are super computationally expensive
maybe even network expensive so can you perhaps comment on how expensive this is computational
compared to well the current state which is no privacy but just TLS
oh yeah my mic is still on sorry I was waiting for the spatula there's there's definitely
an overhead I don't know the latest numbers but like if you want the Spotify demo that's a few
kilobytes that you get from Spotify that's multiple it's like the 50 megabytes I think that's
now it's changed between proof and verifier and then for speed so this was on a regular laptop
but it also runs on phones the computational overhead is limited it's way bigger than just TLS
but it's not so you decide a couple of seconds you have your proof
all right one more round of applause for Hendrick everyone thank you very much