Ethereum Foundation 🛠 Make data portable with TLSNotary

Hello Eat Global. We are Sinu and Henrik from the TLS Notary team, which is part of the Ethereum Foundation's privacy and scalability solutions the Ethereum Foundation's privacy and scalability solutions . First, I'm going to introduce you to TLS not tree, show you why we created it, how it works, and then Senu will demonstrate how you can use it for your projects. First, use it for your projects. First, why did we create TLS node tree?

I assume everyone knows what TLS is, Transport Layer Security. It allows Alice to retrieve data from a web server securely, and TLS ensures that the data originates from the source and has not been tampered with, thus making it authentic. But what TLS doesn't help with is making that data portable so you can share it with someone else, and that's where TLS node comes in. The TLS node tree offers them a way to make their data portable and also to use it with a third party. Well, this is more or less what TS looks like.

The magic recipe is that we introduce multipartite computing. Before we move on, there is no confusion. He is not an intermediary. It's not that the verifier Bob is getting in the way. No, instead it is a multi-party calculation.

Alice and Bob have to work together. Each one has a shared key to communicate with the server. In this way, Bob knows that Alice follows the protocol and cannot cheat on the content of the data, and at the same time Alice knows that Bob only sees encrypted information. In this way, Alice has total control over what she shares with Bob in a later state shares with Bob in a later state . This is also something very important for the TLS notary: privacy.

The TLS notary also allows selective disclosure. This way, Alice can redact parts of the data before sharing the plain text data with Bob. And this can also be further improved with zero-knowledge tools so you do n't have to share information about the redacted parts so that Bob only knows the claims about it instead of seeing the actual text. The concept of verifying TLS communication can also be generalized so that you can have generic notaries verify that the data is authentic, and that way Bob only verifies the content of the data. But in this scenario, of course, Bob has to trust the notary before accepting that the data is reliable.

That was very quick, but now comes the most interesting part: how you can use it for your project. Hello everyone. I'm going to give a relatively short demonstration of how to use our project to query a server for private information and generate a cryptographic proof that can be used to selectively reveal a Discord direct message to another person without revealing the notary's authentication token in doing so. Okay, first let's go to our repository. This example is in our repository and you can follow it if you want.

It's in Chillison Examples, Discord, and we have a Readme here to let you know what's going to happen. Well here to let you know what's going to happen. Well , yes, I'm a tester. I want to prove to someone that I've received a private direct message. I don't want to use OOTH.

I don't want the help of this server. However, I do want to be able to selectively reveal that I have received a direct message from another person. Here is the Discord web application. I've already logged in and received a message for me here. High Youth Global New York.

To obtain the access token, I'm going to refresh, go to the browser, and look for an API request that contains my authentication token that contains my authentication token . And you could definitely hijack this account right now if you wanted to once you see this, but please do n't. So, here's my authorization token. This is what the browser sends along with my request to the Discord server. I'm going to take it.

I'll put it in my example here. So, we only have one environment variables file here. I already have my access token loaded into it. And one more thing I'm going to need here is the channel ID or the relevant conversation for this message. So, I'm trying to test this message here from me.

And the conversation ID is up here in the URL. So, I'm going to generate cryptographic proof that I received this message and show it to someone else. To do this show it to someone else. To do this , we need two different things. So, there will be a fitting room and a notary.

Then the notary will help me do this. Okay, yes, I'm going to start it here. I just started a notary server. It's something generic. It's simply there listening for requests.

And on the left side here, I'm going to...Yes, clean this up. The left side here will be the verifier flow. So, before we run this, I'm going to quickly explain what this actually looks like and how you could modify it to do something more interesting than reveal a direct message. Basically, you can look up anything on the internet and generate cryptographic proof of its authenticity, revealing parts of it to a verifier.

Any web server that supports TLS and any data you can think of . So yes, I'm going to use our approver library here our approver library here . So yes, we're going to connect to Discord and we're going to connect to the local notary I have running on that other panel over there. And we're basically going to use generic Rust tools, the Hyper library to create a request and send it to the Discord server. But what we've done is essentially expose you to a generic TLS connection.

From your perspective, you simply obtain this TLS connection, pass it to the request library, and can interact with the APIs as you normally would with any other connection. But afterwards, we'll finish it and get a test. Okay finish it and get a test. Okay , yes, I'm going to set up a generic configuration for the tester here and it will connect to the notary. They will perform some MPC-related configuration at the beginning.

And after that, we'll connect to the application server, send the request, and then get the response. Okay, let's review it a bit. I'm just building the application here. This is just the API endpoint for the Discord API. I'm going to look into this specific conversation.

I'm going to pass the user agent and the token that I just extracted from the browser. Once you do that , you will get the answer and print it. From there, I assume we'll finalize the process with the notary, and from there, we'll basically do a lot of MPC finalizations in the background for you. What you get is this kind of concise proof of the transcript of all communications with the server, and once we get that proof, we can selectively reveal parts of it to a verifier. So I'll run it here.

You won't really see anything interesting, but hopefully it works. This is a live demo, so I'm checking the Discord API right now. And that's it. Well, yes, I just connected to a notary. You see a mistake there.

Let's sweep it under the rug for a second. In fact, it was completed successfully. Okay, yes, I've now saved this JSON file here. Basically, this is just the notarized session. It contains all the private data from the session, as well as a notary's signature, and with all this data you can build evidence from it.

I'll go to the real-world testing section of this code. You can see that, basically, where is it here? We are identifying all the ranges in the TLS transcript that actually contained public data and private data. We need to differentiate between that and when it is actually confirmed. Basically, what I did was implement a simple helper function here, but it just looks for the deactivation token in the TLS transcript, identifies the ranges in the transcript there, and then we confirm the surrounding data as well as the deactivation token itself .

And we get a bunch of different confirmation identifiers from this. And then, later on , when we generate our proof down here, we simply say proof down here, we simply say : "Okay, we want to reveal the data that corresponds only to the public ranges and we're going to specifically redact only the proof token." So yes, it creates the test and it's also saved to a JSON file here. Once again, it's just a small JSON file that essentially contains only the test itself. And then we have another example here: then we have another example here: what is the verification process for a test like this?

This is just a simple checker. It simply deserializes the test from the JSON file and verifies it for you. So it's quite simple. Basically, you just need to provide the notary's public key. So in this situation, we use a notary, so the verifier really needs to trust the notary that the data is authentic.

Then we pass your public key and it essentially verifies the server certificate and then it will also print the redacted TLS transcript. We'll run the verifier and that's it. I'll show you the result here so you have a general idea of ​​what just happened. This is the full TLS transcript of what happened with the Discord server of what happened with the Discord server . The verifier revealed essentially everything, except here, you can see that the authorization header in the request that would allow you to hijack their session if they had this, was redacted and replaced with X.

The verifier did a few things here. First, he verified the server's identity . He verified the server's TLS certificates to confirm that this really came from the Discord server. He verified the notary's public key and, in this case, he trusts the notary to know that the data is authentic. And now you can analyze this data and, I guess your application could be like a DM checker, and it would analyze the content of the server's response and say, "Oh, look, this message was sent to this account at this time and this is its content."

Again, you can think of replacing this DM flow with any information from the internet, and yes, that's basically the demo. I'm glad it mostly worked. Yes, you can go to our GitHub repository. We have a couple more examples GitHub repository. We have a couple more examples .

We have a sample Twitter DM and sample code on how to set up a notary and things like that. And yes, that's all. Yes, we are also in our repository; you can find our documents and things like that there. And where is the list? Here we go.

Yes. So, you can find us at tlstory.org and you can also find our documents there. Brilliant. Thank you.

Do you have any questions? Yes. Do they separate the data for plum and wet products? Well, first they have to commit to them. So, before the notary gives them the signatory's signature, they basically say that these are the ranges I'm going to commit to ranges I'm going to commit to .

The notary does not see any of the private data, but they still have to identify where it is and then commit to it. Then, the notary will sign their commitments and then they can take those commitments to a verifier and open specific commitments for the verifier. Yes. Any other questions? I think I only have about five minutes.

Well have about five minutes. Well , we have a prize here. A hackathon , we have a prize here. A hackathon . We have 5K.

Our project is in a very early stage, so it's going to be quite bold and ambitious if they're going to try to use our libraries, but we thought we'd come here and see if anyone has any interesting ideas. You can modify it and see what you can do. And yes, any type of application will be very interesting, but also any type of tool. If you want to create something that complements or integrates with the overall protocol, that would also be extremely useful. And well, I think I can end here.