New Ethereum talks, every Monday. The week's conference uploads by event, in your inbox.

Loading player…

TLSNotary Workshop | Hendrik Eeckhaut | Own your data with TLSNotary | ETHDam 2024

CryptoCanalMon, Oct 7, 2024, 12:00 AM

Workshop with Hendrik Eeckhaut - “Own your data with TLSNotary” at ETHDam 2024. Hendrik supports the TLSNotary team at Ethereum Foundation's Privacy and Scaling Explorations lab, working on privacy-preserving data provenance software. https://twitter.com/heeckhau https://twitter.com/PrivacyScaling https://pse.dev/en https://tlsnotary.org/ James Campbell - MC of ETHDam, Hackathon Organiser, and Web3 Developer. ETHDam - a conference and hackathon held in the heart of Amsterdam, Netherlands from April 12th to 14th, 2024, celebrated its second edition, gathering more than 600 participants. In the dynamic space of ETHDam, privacy and security took center stage, featuring groundbreaking discussions on hacks, recovery, and the revolutionary work of figures like Pertsev. Privacy is dead in crypto, people that know, know. People who don’t know, should know. ETHDam is powered by CryptoCanal, an education and events platform growing in Amsterdam, spreading its roots to Rotterdam and Zürich. Keep up with us to see updates on future events: https://www.cryptocanal.org/ Follow CryptoCanal on X: https://twitter.com/CryptoCanal Join CryptoCanal TG Community: https://t.me/CryptoCanalCommunity Join CryptoCanal Discord: https://discord.com/invite/XJVjpCqQBz We would like to thank our partners that made this event possible. 🌷 Battleship Partner 🛳Oasis Network https://oasisprotocol.org/ Jet Ski Partner 🛩⛷ NEAR https://near.org/ Canoe Partners 🛶WAKU https://waku.org/ 🛶Trail of Bits https://www.trailofbits.com/ 🛶Avalanche https://www.avax.network/ 🛶Privacy + Scaling Explorations https://pse.dev/en 🛶Threshold https://threshold.network/ Our Canoe Partner & Official Node Provider 🛶dRPC https://drpc.org/ Sponsor 🤝EF Ecosystem Support Program https://esp.ethereum.foundation/ Paddle Partners 🚣ChainSecurity https://chainsecurity.com/ 🚣Lido https://lido.fi/ 🚣Cyber Capital https://www.cyber.capital/ 🚣Diva https://www.divastaking.net/ 🚣Firn Protocol https://firn.cash/ 🚣Beefy https://beefy.com/ 🚣0xbow https://www.0xbow.io/ 🚣Obscura https://obscura.build/ 🚣Panther https://www.pantherprotocol.io/ 🚣Maven 11 https://www.maven11.com/ 🚣Zama https://www.zama.ai/ 🚣zkSync https://zksync.io/ 🚣Secret Network https://scrt.network/ ETHDam AfterParty Fren 🥳Bitvavo https://bitvavo.com/en Chapters: 00:00:00 - Introduction 00:01:23 - What is TLSNotary? 00:04:10 - Enabling Privacy through TLS Connection 00:05:30 - How TLS works and its components 00:06:45 - Cooperative Communication for TLs Server 00:08:00 - Practical Demonstration of TLSNotary 00:09:21 - Verifying a Multi-Party Computation 00:10:47 - Use cases for TLSNotary 00:12:09 - Reusable Proofs and Data Verification 00:13:27 - Proving Twitter Account Ownership 00:14:42 - Monitoring and capturing requests and usernames in a debug view 00:15:58 - The potential uses of TLSNotary 00:18:41 - Websites on IPFS without DNS 00:19:56 - The importance of data server responsibility 00:21:09 - Working on Browser Support for a Feature

Transcript

[Music] so welcome I'm indeed hendrik with um the TLs notary team which is a research project inside psse so the privacy and scaling Explorations lab from the ethereum foundation so um I'm glad happy to say share with you that almost the entire TS notary team is here so if you have questions uh come find us today you can find us at the boot but our team will also be hacking in the utter track so if we're not at the boot uh go find us somewhere where we're hacking and then uh just discuss your questions or IDs with us we're uh very happy to uh to discuss them so first uh why are we putting so much effort into developing TLS notary well our motivation is that we want to liberate your um private data so today lots of our data is stored on servers of centralized companies and so TS notary found a way to unlock that data so you can make it portable and reuse it uh somewhere else um but so let's dive into do it uh what TLS notary actually is so um I assume most of you know what TLS is so it's uh the S is in HTTPS so the transport layer security um TLS is a great way to guarantee that when Alis gets data from a server that the data she gets actually comes from the server and that also nobody on the network uh tempered with that data and so there it serves its purpose very well but where TLS doesn't help is when Alice wants to share that data with Bob because TLS uses uh symmetric encryption Bob has no guarantees that Alice didn't tamper with the data and so one example here could be you have a bank website Alis wants to um needs information from that bank to negotiate a deal with a mortgage lender Bob and so Alice can log into the website of the bank and get a view on her account so she has actually $100,000 there but then how does Bob know so today lots of people just take a screenshot uh but so there's lots of problems there so Alis could doctor that screenshot and there's often more information on that screenshot that needs to be shared so the goto uh status quo solution there is to use oout but there's also issues there so there's another trusted party the bank server needs to cooperate and give that third party access and then there's also only very uh course levels of uh configuration for for your privacy and so that's where TLS notary steps in so with TLS notary you do the TLs connection with multiple parties and so it has the same guarantees as steals itself so you also get proof that the data is authentic but it also allows you to take that to to for Bob to have uh guarantees about the authenticity and so in a nutshell that makes the data that was on the server portable and at the same time um TS notary also does not depend on cooperation of the server so at the server side nothing needs to to to change and also no extra parties are involved and as I will explain next it also helps you or gives full control to Alis uh for her privacy because at uh once the TLs connection is um set up and Ellis wants to share data with Bob she um has the option to redact data so to leave out data while Bob still has cryptographic guarantees that the data is uh authentic and that can be further augmented with zero knowledge proofs so instead of sharing the actual address you could add a proof that you're not in the US for example or instead of sharing the actual birth date you add a proof that you're over 18 so how does it actually work so before we go to TS notary let's have a look at the standard TLS first so from a high level perspective if you have very detailed questions or the real experts are uh uh at the venue or also in the audience here um but so just to give you a rough idea how it works so first Alice and the server exchange your public keys they um negotiate on session keys with with cryptography and then once they each have the the same key so it's a symmetric key they then can share or send encrypted messages over the network with some kind of checksum so that you also know that nothing changed and so that way they can um very effect actively uh communicate in a in a safe way so with TLS notary the the left part the server is almost the same and by the way I will from now on I will use prover instead of Alice uh because she has access to the data that she wants to share with Bob and Bob will verify that data so for uh this presentation I will now use approver and verifier for those roles um but so I was say the server uh so from the server's perspective nothing changes so it's still regular TLS protocol um uh but the pro the the client side of TLS is split in two roles so you have aover and a verifier that needs to cooperate to communicate with the with the TLs server so instead of having just alysis public key it's now a combination of the keys of the approver and the verifier and then instead of Al is doing all the communication she needs to cooperate with secure multi party computation with the verifier and so that gives cryptographic guarantees that Lis uh the prover cannot cheat and uh cannot send messages without the corporation of the verifier and also that Alice or approver cannot change the data afterwards so they really have to jointly compute the the keys and then also something important that I didn't mention so they've both approv and verifier have private inputs and so the verifier only sees uh encrypted data so never the plane test text uh until the very end of the the process and also the prover cannot Forge the response because it first commits to the encrypted data uh before it can decrypt it uh and so that whole uh system is sound and uh guarantees that uh nobody is cheating or nobody is tampering uh with the data um to make that a bit more practical and to show that TLS notary actually works in practice I've uh created a small uh setup where there's different roles so the prover in this case um has uh uh access to private data on the Star Wars API website and so what the prover wants to prove to the verifier is that he has private information on Luke Skywalker and so he will share that with the verifier but he will redact the the home world and then the verifier will um so cooperate in the multi-party uh TLS SE session and then afterwards uh check that the data uh is authentic and uh correct so I didn't want to tempt the demo God so I recorded the the video so not so on the left side you have the approver and on the right side you have the verifier so now I'm starting a verifier server so which is listening and so the prover runs in in a browser and so now the the proof and the verifier are change exchanging data for to set up the circuits for the multi-party computation and so yeah that takes some um communication so now they have set up the the TLs Keys there's uh encryption and decryption going on and we're already now in the finalization phase and uh big success so we have exchange data and um so let me uh zoom in on the the final oh on the final result so this is what the uh verifier gets in the end so we got a response from the the the swappy server we have a secret HTML header here that's redacted and also also as you can see here in the Json data the home world is redacted but everything else the verifier has cryptographic guarantees that nobody is uh cheating in this uh in this setup um so this was actually a very artificial example so the data on the swappy server wasn't even really private but you can imagine for real use cases uh what is private information that matters it's identity information reputation on websites like Airbnb if you want to reuse that somewhere else uh held information is important one where everybody agrees that privacy is really important you could also like um prove that you own certain accounts um also like real words assets if you have a test Tesla car that also comes with a Tesla account so you could prove stuff there that you actually own stuff and so this unlocks a lot of use cases that were not possible before um so we're also very curious ourselves to see uh what you uh all will uh find for for new use cases uh for TLS notary so uh for most you use cases the setup I've shown before with just a server prover verifier uh should be enough but for S use cases you want the proofs to be reusable and so for that scenario it's also possible to split the MPC TLS verification from the actual data verification and so that's what you see here in this diagram so the the not we introduced the notary here who only does the we CDLs verification and then the data itself is um checked by somebody else of course in this setup it's important that the notary is trustworthy because if the prover were to run his own notary then we're back to square one where you do use regular TLS and then you could just fabricate uh any data that suits you but so in this scenario you can then reuse the proof you have or design data with a second verifier and so for some use cases that's um preferable and so this uh this way you really get portable data that you can take anywhere with the only side note that the one verifying the data has to trust that the notary is um that did not collude with the approver and is truly neutral so that's the extra um trust that's required and so for onchain uh applications you're more uh towards this uh this setting so also for the notary server um I've prepared prepared a small demo so in this use case the prover uh wants to prove to a verifier I have a Twitter account so in this case I'm the prover and I will prove that I have a Twitter account uh or an X account nowadays and then as the verifier I will use a very simple online tool that we built that just visualizes the proof and does the the checks um this is actually an example that we have on our quick start guide so if you want to start exploring or or playing around with TLS notary you can just uh follow that link or go to our docs first and then you can run this example very easily yourself so again I have recorded it so um so we are using a TLS notary extension here and what I'm doing is I open uh a debug view so that you can follow along with the um the noes so what the extension does it monitors all requests and so there's one specific request that we can use to um to get your username and so in the extension I'm clicking the notorized button so it's now doing the all MPC dance I took a a quick redution here to not leak any of my session uh Keys uh but so um in the end you get um a proof which is a Json file uh with some redacted data but I will uh download it now uh to my computer I still yeah it's still in development so I'm adding the Json extension here and then when I have the the the Jason extension I can go to this uh visualizer website we have we're working on a better version also and then you can see it's not valid because I'm using the wrong public key but when I use the correct public key you see that the verifier can now see that when uh the proof was made the headers are redacted that um and that the received data um has uh my Twitter username there um so uh now I could also use this proof for um different verifiers so say that you need some kind of guarantee that I'm a real person maybe you want to combine a few different sources uh to just prove um you're human or whatever some kind of kyc this uh could be used yeah and then um TLS notary is open source it's a public good um it's uh available under MIT or ap2 your choice it's written in rusts um but it can be compiled to web assembly so it can easily be used in typescript to uh so that's why I had the the demo in two sides in a browser and uh in a in a terminal um so yeah um go to our website for documentation as an extra incentive for you guys to choose DLS notary to build on we have a $2,000 Bounty um if you use this QR code you also get to a special page on our notion website with uh extra links to to get you started it as uh as quickly as possible so yeah in a nutshell this was DS notary we also have a boot but if you have questions now [Applause] shoot thank you very much does anybody have any questions yes hi uh thanks for the presentation um does this require any changes from how CA operate uh the types of certificates used today uh no so that all stays the same but as a verifier you have the option on how you get the certificates so um so that it's also lots of building blocks so you choose how how you combine them but so that's all uh in your uh your control so it's basically backwards compatible with how browsers work today how C work today yeah yeah okay yeah a bit of a followup question given that dependence or I guess like how it's built on the existing CA system today uh how does this work with something like um websites that are ens or like don't actually use the regular DNS system so say I wanted to publish my website with a pure ipfs front end that doesn't use that DNS existing like intersection of SSL DNS HTP today well so if you know what you're doing and you know where to get it you you can get it uh where we know it is so it's it's flexible so I yeah I guess I wouldn't so I could just use the building blocks and generate my own CTS and use that um well it's the verifier that has to trust the certificates yeah so if you generate them yourself and then there's no trusts yeah uh I don't want to steal anybody else has more questions um so are you working on any standards tracks for this are you working in the ITF or w3c um no so uh this is what what we actually want what our end game is that everybody would simply sign their data so if our the data would be assigned it to Source then this whole dance wouldn't be necessary um but so lots of data servers don't have the incentive to sign it because yeah that it would just be taking more responsibility so this is also some kind of activism tool to educate the world and to help people demand sign data so in the perfect world TLS notary would not be necessary right I guess like a final question have you thought about what Native browser integration of something like this would look like because it does seem to need to escape the I guess like origin isolation and things like that you need to make a I guess a CH request out to the notary for example and it seems to chain a few different types of HTTP request response yeah um yeah yeah it's it's steps so we we're now building in what's possible today so in the browser you need a websocket because you cannot set up the TCP connection in the browser so there's some hoops we have to jump through um but yeah and it would be nice if if if browsers would would support this so it's working progress there thank you very much that's all we've got time for if anyone has any more questions PSC have a booth downstairs please go and speak to them interact with our partners as much as possible [Applause] [Music]

Automatic transcript — names and jargon may be misspelled.