Epicenter - Learn about Crypto, Blockchain, Ethereum, Bitcoin and Distributed Technologies - Adam Gibson: A New Kind of Auditing – Cryptographic Proof of Online Accounts

Episode Date: February 22, 2016

A pioneering feature of Bitcoin is verifiability of transactions: It is designed to enable low-power devices and high end computers alike to be able to verify occurrences on the blockchain. This observation led our guest, Adam Gibson, to wonder why webpages aren’t so easily verifiable as a Bitcoin transaction? Can I prove to you that I have certain bank account balance over the internet? Why do we submit photocopies of passports rather than furnishing a cryptographically verifiable proof of citizenship by logging on to a Government site? Born out of this intellectual itch is the TLS Notary protocol. It pioneers a new kind of auditing that enables participants to prove that a certain https page was in their browser. This protocol paves the way to brilliant designs for Proof of Reserves, Smart contract oracles and Decentralised fiat-to-bitcoin exchange. Topics covered in this episode: Why is the current Web structured to be not easily verifiable? What is TLS and how does it work? How TLS differs from SSL The TLS Notary protocol Capabilities and limitations of TLS Notary Applications of TLS Notary including provably honest smart contract oracles Episode links: The TLS Notary website Oraclize, the provably honest oracle service The TLS specification (TLS 1.0 RFC 2246) This episode is hosted by Meher Roy and Sébastien Couture. Show notes and listening options: epicenter.tv/119

This is Epicenter Bitcoin, episode 119 with guest Adam Gibson. This episode of Epicenter Bitcoin is brought you by Ledger, now accepting pre-orders for the all-new Ledger Blue Developer Edition, a Bluetooth and NFC touchscreen hardware signing device. Learn more about the LedgerBlu at LedgerWallet.com and use the discount code Epicenter to get 10% off your first order. And by the GTech Blockchain Contest. If you have an idea for a blockchain-related project,

make sure you apply for your chance to win awards worth 50,000 euro. Go to EpicenterBitcoin.com slash G-Tech, that's G-T-E-C, to learn more about G-Tech and how you can apply. Hi, welcome to Epicenter Bitcoin, the show which talks about the technologies, projects, and people driving decentralization and the global cryptocurrency revolution. My name is Sebastian Kuchu. And I'm Meher Roy. Today we have a very, we have a slightly offbeat topic for our listeners. Most of you must have heard of the problem with oracles, the fundamental problem of how we can, put financial data in trustless blockchains and it turns out there's a very

interesting solution to the problem of oracles but it depends on a technology called TLS notary so we are going to interview Adam Gibson from the TLS notary project about what TLS notary is and what are the kinds of applications with blockchains they are very interesting so this so do to check out the application section but before that let's have an introduction from Adam Adam a bit of all your background please hi yeah so I got interested in Bitcoin probably late 2012 early 2013 and very rapidly after that became interested in the this kind of a mythical beast the decentralized exchange of fiat to Bitcoin which arguably can't exist but

there was endless debates about it back then also perhaps you want to know a little bit about my background but I I'm maths and physics is is my training, but I've been a teacher, software engineer and so on. But anyway, so to come back to this topic of how I got interested in this, so starting around May 2013, myself and another guy online called Dan Smith, and, well, us two originally, started looking for ways in which we could use SSL-slash-TLS as a possible cryptographic solution to that problem of Fiat Bitcoin. exchange. And another guy whose online handle is Oak Pacific kind of joined us a few months later.

And we've been working on it a long time. And at some time around mid-2015, I guess you could say, we kind of finished in a sense that we now have what is now called TLS Notary. And we found that, as you just mentioned, it could be applied in a number of other contexts as well, based around this idea of using a cryptographic proof of a web page, let's say. So could you explain very briefly what the big picture concept behind TLS Nootri is? What allows it to do? Sure. So I thought maybe I could give a simple example, a practical example, where it might apply.

Something that struck me maybe one or two years ago here in Latvia where I live is that I had to go to a government office to provide proof of my income or savings. So I had to provide a financial proof. And as is often the case in this kind of situation, you know, you go to the government office and they've got a very old kind of bureaucracy, and they want some kind of form or piece of paper to prove something. So what I did was I simply printed out, I think it might have been a PDF or an HTML page from my internet banking, printed it on paper, took it into the government office, and the guy

looked at it and sort of nodded his head and say, yeah, this is obviously correct, right? So obviously you have got that money or that income or whatever. And obviously that's ridiculous because anyone can print anything they like on paper with any kind of letterhead. So that's an example where it would be useful to have a digital signature, right? Because that's the main application of a digital signature is that somebody can have a public key out there in the world and it can be used to attest to the fact that they actually made this statement. So that's called a non-reputable statement in the sense that as long as the public key of that organization is known, then if the signature verifies against that public key as cryptographic proof.

Now, there aren't many of, it's surprising in a way. I mean, it might be surprising or might not, that there are many big public institutions, whether they be banks or government offices, that don't actually provide digital signatures for the various statements, that they attest to for their citizens or customers. So in a way, TLS Notary is an idea where we're trying to fill that gap of situations where digital signatures are not being provided, but yet you still want cryptographic proof that a certain authority gave you that statement.

So yeah, I'll stop there. Yeah, and I find that such a telling example. I'll give you a bit of a little story. When I talk about blockchains to really just people that have no idea, I often use this very type of example of taking information coming from one database, which is say your bank or your maybe perhaps your landlord giving you like proof of residency and a government office where there's inputs of data and you're, essentially the transport layer and the trusted party to make sure that all the information coming from one set of data, one output databases essentially and going into the other while you're the trusted third party to verify those and also the transport layer.

So basically you're playing the role of an API between the various outputs of data, like, you know, your bank, you know, your landlord, maybe like the tax office and stuff like that and bringing it over to some lady behind a desk and a glass window who then does risk analysis. Human API, yeah? Yeah, there's risk analysis and then allows you to stay in a country for another year. And since I live in France, I'm confronted with this type of example all the time. So that's a really interesting example. And I guess TLS Notary is a much simpler way of being able to prove outputs of data from one system and being able to bring in it into another. I guess where blockchains might come in handy there is providing the transport layer

that would effectively just allow. both entities to share pieces of data and have trust in the data that's provided. So, yeah, just a little aside there. But I really like that example. So let's perhaps talk about TLS because, I mean, for me personally, I, excuse me, but I work in web technologies. And for some reason, I still thought we were using SSL. I don't know why.

I mean, we talk about SSL certificates pretty much all the time. Absolutely. And I was so surprised when I started really digging into what TLS and SSL was, that actually, SEL doesn't exist anymore since it's like the early 2000s. Oh, it does exist, but... Right, but it's not the right way to call it. So let's, could you explain in simple terms what TLS is and what it allows to do essentially, because we use it all the time?

Right, okay. So first let's briefly deal with that SSL. TLS confusion for those who still have a confusion about it. Just think of SSL as the old version of TLS. They're actually the same technology. TLS 1.0 is in a sense SSL 4.0. Now what is TLS? So the basic idea is you want to talk, it's really a way of using public key cryptography to enable encrypted communications between clients and servers. It's very much designed in that client server model. So obviously the web server is what we're talking about here.

And the problem is that you want to provide not just encryption. Well, let's put it this way. You don't just want the data being transferred between the client and the server to be confidential, but you also want it to be authenticated and have integrity. So let's just go through a very high-level picture of what TLS does for those who don't know. So you start with the client generating some secret data.

This is going to be like the key or keys for the session. Then he wraps up that secret data in using public key encryption. So that's something I think most people know what that means. I'll assume you do. So he's encrypted the secret data and he sent it to the server. And the public key he's encrypted it to, let's say in crude terms, is the certificate of the web server. Actually, it's like the public key is signed by a certificate authority, but let's just say, right?

So the client sends the secret data to the web server encrypted, so that only he, the client, and the web server know that secret data. Then, when they both have that secret data, what they do is they kind of munge it up a little bit, and they generate a string of bytes. And they're both doing that same generation on both sides. So they both generate the same bytes. and then they chop those bytes up into sections, and they use each of those sections of bytes as keys for the encryption process that they're going to do, when the client says it's get request

and the web server sends back his HTML page or whatever, they're going to be using some encryption keys. Now, you might ask, well, why didn't they just use the public key encryption at the beginning to send the get request? Well, the main answer is that public key encryption is slower, both in, you know, encrypt and decrypt operations and signing operations and so on.

So you want to use what we call symmetric encryption for the actual data transfer. Symmetric encryption is just where the encryption and the decryption key are the same. So if I can just sort of recap, you're using public-private key encryption to send the initial piece of data that will allow you to generate these symmetric keys

that then we are used for encoding and decoding messages. That's right. And I should probably mention at this point that that bit of data, that secret data you sent at the start is called the pre-master secret, because we're going to refer to that later. The other thing to bear in mind at this stage is that it's not just the encryption decryption keys we need, it's also something called a Mac key, and Mac here means message authentication code.

And the reason we need a message authentication code is to come back to what I said at the beginning. We don't just provide confidentiality. We don't just say, oh, it's enough that the... somebody sniffing the wire can't read the data. We also don't want them to be able to modify it, because if they can modify it, there's a whole set of very clever attacks they can do, which can really screw things up.

So what we do is we append a Mac, which you could think of like a checksum or like a hash, to the end of each block of data that's getting sent between the two parties. And that Mac is actually generated from something called HMAC. So HMAC is a hash function. That's something I think most people listening to this would be familiar with.

HMAC is a hash function but it's keyed. So instead of saying, suppose the data is hello. Instead of sending the hash of hello, we send the hash of 1, 2, 3, 4 hello, where 1, 2, 3, 4 is the secret Mac key. And what that means is that the only person who could generate that HMAC is the person who had that secret 1, 2, 3, 4. It's not enough to know the data, you have to know the secret key too. So because only the server has the HMAC key,

the client knows that when he receives that, knows that when he receives a block of encrypted data with this H-Mac, he knows it came from the server. So just to summarize, what would we say? We said, public key encryption to send the secret across, then symmetric encryption to send data back and forth, and the data is authenticated using H-max at the end of each block, which function like checksums. That's a really great explanation. And the reason you use symmetric encryption to recap is because public key encryption is expensive and you don't want to use it for every piece of communication you send over the wire. That's right. Yeah, exactly. Now, in essence, like, had public key

encryption being used to set each block of data over the internet, then suppose when I connect to my bank, the bank is also sending me the data about my balance and assigning with its private key. and anyone else can verify that this data that the bank sent me. Well, we'll be careful because there's different things here, right? There's public key encryption and public key signing. So, first of all, if we were to do the whole process with public key systems only, we would need a public key from both sides. Now, actually, SSL slash TLS does provide client-side certificates.

So a client can send a certificate to a server if they want to authenticate themselves. But it's interesting that almost nobody uses that system in real life because we want the client to be ultra-lightweight, stateless, the client just comes along, pings, goes away. That's it. Clients are even anonymous in some cases. Of course, not if you have a login, but that's another matter. And also, the other point I wanted to make on that is,

yeah, it could be that the server could be sending signatures with each block of data. And in fact, Sergio Lerner made a similar suggestion to that on the TLS Working Group email list. maybe last year sometime. But, you know, the question is, do people from the server side actually want that? Because it's kind of heavy. Do they want to provide non-reputable?

So to remind you the case of when I'm at the office, I wanted a non-reputable signature that nobody could say afterwards, oh, that wasn't me, right? Do servers actually want to provide non-reputable signatures on every single block of data they send to their clients? I don't know. It's a complicated question. In some cases, they might, in some cases they might not.

Let's take a short break so we can go to Paris. I stopped into La Maiso du Bitcoin, situated in the heart of Paris's startup scene, and I met with Eric Larchavec, Leder CEO, to talk about the Lager Nano. The Lager Nano is a Bitcoin hardware wallet based on a secure element. It is on a USB form factor that you plug directly inside your computer, and it will manage all your private keys. The signature of transactions will be done inside the secure element, thus never revealing the private keys to the host computer.

It is compatible with our own ledger wallet Chrome app, which you can also use for multi-signature with copay or coin kite, and a large range of third-party applications such as mycelium, electron, green bits, green address, and so on. The nano also exists as a cool bracelet wearable, so you can always wear proudly your Bitcoins on your wrist. The Ledger Nano is an easy-to-use hardware storage option, which doesn't compromise on security. If you want to get a secure setup for storing your Bitcoins, go to ledgerwalt.com and use the offer code Epicenter to get 10% off your order. We'd like to thank Ledger for the support of

Epicenter Bitcoin. So in essence, today we are in a state where we are receiving data from various different servers, but once, say, I received data from some server, maybe it's a government server, I can look at the data and I can look at the properties of data, but I can't take that data to you and convince you that this is true. For example, I'll receive something from a government server that I was born in, I don't know, in 1985. So I can be convinced of that data, but if I,

it's not possible for me to go to you and convince you that I was actually born in 85 and that the government told, has certified this because our, government hasn't actually signed that statement using its private key. Exactly. Exactly. What happened was you and the government website were using a kind of repudiable signature. H-MAC is like a signature, but it's repudiable. Because although you know it's real, if you give it to me, I'm going to look at it and say,

right, what were the keys for this session? You give me the encryption keys and the H-Mack keys, right? I can decrypt it. That seems to work. right the HMAX seem to check and then I'll say well hang on how do I know you didn't just create all of this data all the keys

all the web page the whole thing just out of whole cloth and the only way you could answer that is if you could prove to me what the secret keys were that were used in the session but they were encrypted to the government website's private keys so I mean

I don't know maybe there's some weird way you could get the government involved to prove that it was real but then that's kind of begging the question because then you're asking the government anyway. So the data is reputable, yeah. So it's between the two parties, the client server. Everything's absolutely kosher, cryptographically speaking. But as far as anyone else is concerned, it could all just be made up. And so just before we go a bit deeper into TLS notary, specifically, can you talk about some of the vulnerabilities that TLS specifically can fall subject to? Well, wow, that's kind of a huge topic, right? I suppose there are many, but one of the some of the most

common ones that we see line in a lot of the ones that have popped up over the last few years and maybe even going back to sort of 2000 when when TLS1 started are to do that there's a couple of different classes of problems one of them is related to export cipher suites and this is all about the fact that the US government actually wanted it to be weak so there were there were all these kind of legacy systems or legacy let's say elements of the protocol that used slightly weaker encryption standards in them. And there have been attacks based on fallbacks because you have to kind of negotiate

which version you're going to use. So that's one class. Another class is what's sometimes called padding Oracle attacks, which is where you, because of the kind of standardization of the format, if it's possible to kind of ping the server a lot of times, look at the encrypted data, and you can kind of slowly but surely glean individual

bits of information. But those padding Oracle attacks, they got a lot of coverage, but I think in practice, they weren't very realistic, because maybe I shouldn't say that, but it just seems that way to me, because a lot of them involved

actually pinging servers like a million times. I'm trying to think of the other ones. There are a whole, oh yeah, the other whole sort of area of attack, I think, has been based around extensions to the protocol, because being, like any protocol, sort of designed by committee,

it has lots of different bits and pieces that get tacked on. For example, I think the heart bleed of vulnerability that got a lot of play, for a very good reason, because it was a very serious vulnerability, was based on DTS, which was this kind of...

I actually forget now, what was DTS about? But anyway, it was an extension to the protocol. It wasn't the core protocol. But that is a huge topic, and I can't class myself sufficiently expert, to give you a talk about that, I'm afraid. Right, okay. No, but that's interesting.

And I suppose also some higher level problems are related to certificate authorities and... Oh, of course, yeah. You know, that whole... Can you give just sort of a sort of brief explanation of what that problem looks like? Oh, well, the way I see it,

I mean, maybe other people don't agree with me is that certificate authority model is just appalling. I mean, it's a terrible idea, right? Because you have the incredibly centralized entities that are farming out certificates and effectively giving, you know, being in charge of deciding who is actually who on the internet. But it depends what you mean, really.

If you mean what are the kind of cryptographic vulnerabilities in it or what are the kind of systemic vulnerabilities in it? Because, I mean, my experience is on my browser, I go and I look at the list of CAs and I see, you know, 20, not 20, maybe 200 different certificate authorities from all around the world. I have no trust in them whatsoever.

I've actually gone and deleted a lot of them from my browser because I know I don't need them. But any one of them just happening to have some systemic failure within their company or whatever could result in you, thinking you're logging onto your bank when you're logging onto a hacker's website. So at one level you can see, it's pretty – and yet I must say, of course, in reality, that is the system that works. That is the system that brought public key cryptography to the world. It isn't being used outside of that. I mean, nobody's using GPG, you know. So it swings and roundabouts, I guess.

That was a really good introduction to TLS Notary, which is basically a communication protocol on top of the web. TLS, you mean? TLS, not TLS Notary. Now, what TLS Notary is doing is, it's kind of extending TLS in order to make communications verifiable.

So when Meher communicates with Adam, Meher gets the ability with TLS Notary to prove to Sebastian that he did receive something coming from Adam, that he did receive something coming from Adam, right? So just walk us through, like, how TLS Notary is able to achieve this. All right. So earlier we were discussing the scenario where, let's say, you got a web page from your government, and it was all correct, and you gave it to me, and I said, well, hang on. How do I know this is real? You could have made up the web page, right? You could have, but in order to, if you wanted to generate the whole kind of network traffic,

you would have had to generate like network packets, well, TLS records, let's put it at that level. You had to generate a series of TLS records that were encrypted and had HMAX on them, just as I described earlier. And you would have had to give it to me, and I could have looked at it, and I would have said, right, I need the keys, you give me the keys,

and then my problem is, how do I know those keys are really? deal, yeah? So how about this as a proposed alternative in order to achieve what you just said? How about, and what was I thinking? Oh, yeah. So suppose, so in the scenario you described, I think you had Sebastian as the auditor and you as the client and me as the server. Let's just call them auditor, the person who wants to check it, client and server, like normal client server, yeah? Just keep the names clear. All right. So how about this scenario? the auditor generates what I call before the pre-master secret,

which means that effectively he's generating all the secret keys. He's generating the secret data. He's giving it to the auditor, gives it to the client. The client then sets up a normal TLS connection with the server, does the business, a page comes back, and then the client gives the page to the auditor. That should work, right? the auditor then gets proof that the data is real, yeah?

Yeah, yeah, the auditor gets the proof because he has generated the secret, and the client used the auditor's generated secret for the communication. But then that also opens up the client to being defrauded by the auditor. Very good, okay. Is that the case? Why? Because the client has to trust the auditor completely in order to generate the secret. Yeah, it's not obvious, but it is true. what you're saying.

I don't know if you've ever heard the phrase man in the middle. Have you heard that phrase? Yes, but let's have an explanation of that. Yeah, it's actually an interesting discussion. We had this discussion early on. I guess it was late 2013, early, 2014. We had this discussion when we were working on it.

Because, yeah, you could do it like that. And for example, you could, well, anyway, let's just explain man in the middle, yeah. So the auditor has all the secrets. So what that means is the auditor can step between the client and the server, and can modify the traffic. He can send, because he knows the secrets, you know what, I should at this stage explain the separation of the secrets.

So I said earlier there's a pre-master secret. It gets split into four or more sub-secrets. There's a complicated process, but let's just say. There's the client encryption key and the client Mac key. I think we've already explained what encryption and Mac keys are. And then there's the server encryption key and the server Mac key. So if the auditor steps in between the client and the server, what he can do is taking the server's response,

suppose the server's response says $100 for Meher, and what he can do is edit it. Because he's got the server Mac key, he can create not only something that's encrypted correctly, but also something that authenticates correctly and give it to the client. So the client no longer has any assurance that what he's receiving from his web server is accurate. And I suppose in that scenario, that scenario is really bad, because also it could go the other way where the auditor could step in,

take the client's request and modify it or read it and so on and so forth. Well, read it's okay because we want him to audit this particular thing. But generally speaking, you don't want man in the middle. you want to have the full scenario where the client is assured that only he and the server are talking to each other. Let's say that. Sorry, I should continue. So we've established A, that it's not good enough to just give someone a page

because they could have made it up. B, it's not really good enough for the auditor to just have all the secrets because he could then step in between and modify the communication. So TLS Notary is trying to avoid both of those problems. So what does it do? Well, the key to it is, there are two key tricks to it. The first one is this. The premaster secret is converted into the four keys that I just mentioned in a complicated process involving something called

a pseudo random function, but it's a special kind of pseudo random function that's designed specifically for TLS. And so part of that complicated process, obviously I won't explain all of it, it'll take too long, but part of that complicated process that transfers the the premaster secret into these what we call expanded keys, client encryption key, client Mac key server, encryption server Mac. Part of that process uses what's called XOR or ZOR. You know XOR?

It's a simple logical operation which takes bits. So you get the exclusive or of two bits. And what the process does is it takes two, within this PRF, it takes two strings of bytes. and it zores them together. I'll give you an example. So suppose I had the string of bytes, A, B, C, D, and you had the string of bytes, EF, G,H, right?

And we know that the output that we want is the Zor of A, B, C, D, with E F, H. So that would mean, literally, that A gets zored with E, B gets zored with F, C gets zored with G, and D gets zored with H. So it operates like bite by byte in this sense. Actually, bit by bit, but it affects the same thing.

So that creates an interesting opportunity, because if you've got the EFGH and I've got the A, B, CD, I can take the A-B and just give you the A-B, and you can take that AB and Zore it with your EF, and you can get the correct output for the first half. You see? Right? Whereas I can withhold the CD. You don't have the CD.

You only have the G-H at the end. So you're not going to get. get the second half of the output. You've only got the first half. So that's what we exploit in TLS Notary. What we do is we say, right, we've got the first half of the premaster secret. Let's say we're the auditor. You've got the second half of the premaster secret. Although there's a lot of other complications in the middle, basically we're going to give you the bits that you need in order to create the client encryption key, the client Mac key, and the server encryption key, but we're going to withhold the bit for the server Mac key.

Maybe we should just stop and think for a moment. What's the significance of that? Why is it particularly useful to just withhold the server Mac key? Because the Mac key, remember, is for authentication. Authentication. So what it means is that because you've got the server encryption key, you can create a page that looks like it's encrypted by the server. But the difference is you can't create a Mac that authenticate that page.

So now at this stage, you as the client have everything you need to do the processing with the server. You've got the client encryption key and the client Mac key. So you create your get request, let's say, you're getting an HTML page. You encrypt it and you append your Mac. You send it to the server. The service is absolutely nothing unusual. But when you get back the server's response, we'll come back to this, but you can decrypt it, but you can't authenticate it.

you also can't authenticate it to me, the auditor. So now we have the next problem, because if you receive a page from the server, which is encrypted, and you can decrypt it correctly, nevertheless, you shouldn't really use that page. Why not? Because it is not authenticated, right? Or rather you haven't authenticated, it is actually authenticated, but you can't authenticate it because you don't have the Mac. Yeah. Yeah?

So you've got this page sitting on your disc or sitting in memory, but you don't. We don't actually know it's from the server because it's not authenticated as being from them. So what we do is we use a commitment. We take that server response and we hash it, just using any hash function like Char-2-56. We send the hash to the auditor. Now as you know, the properties of hash functions, the auditors are just seeing a meaningless hash. He doesn't actually know the data yet.

But by receiving that hash first, when he then sends us back the server Mac key for us to authenticate our server response and verify it's genuine, then we can give in the page and it has to match the hash that we sent earlier. Do you see? Yeah. Sorry, this is a bit complicated, but I'm doing my best to go through it. So do you see the point that we're in this kind of delicate dance where the auditor doesn't want to give the Mac key to the client immediately because then he can fabricate a page? But at the same time, the client needs the Mac key to authenticate the page and no, it's real. Otherwise, it could be like some hacker just sending him a page that's, you know,

well, let's just say. So we're in that sort of delicate dance there. So the way we deal with that is with a commitment. We send a commitment of the page. We send a hash of the page to the auditor. The auditor doesn't get our page yet, but he gets a hash of it. Then when we send it later, after we do have the server Mac key, then the auditor just checks at the hash matches the page that's been sent.

If it doesn't, then the client is playing around. So that way, both sides get what they want. I don't want to... I've got a couple of questions. I guess more on the technical side and the practical side of it. Right. I think I understood how that works. I will have to listen to it again, though,

to really be sure about understanding everything. It's very complicated. Especially when you're not really familiar with H-Mac and all this kind of stuff. But one thing that perhaps this addresses, this, but if I'm the auditor, the auditor is the person you're giving the information to and who wants to verify that the information does come from a source that has been authenticated and created the data. If I'm the auditor, how do I verify this? Am I, I'm not trusting certificate authorities to say, like, this is the actual website.

Oh, you are, you are. I absolutely are. Because you're trusting the public key. You're in the same trust model as the client was originally, right, where the client goes to mybank.com. His only assertion is that, well, the browse have looked at the CA list and traced the signature down. Okay, so we're using the certificate, we're trusting the certificate authority. So, whatever, if that model's broken, then you're still sort of vulnerable to that. But you're trusting the certificate and having authentication that the exchange of data that happened between those two parties,

well, you can trust that that data has been authenticated. Well, let me go to my next question then. How does a, the auditor, what are the practical ways for the auditor to verify that the exchange of data that happened between the server and the auditee and the client, sorry, rather, is authenticated and correct. And has it been involved for it?

Right, so that's kind of what that's kind of, what that whole process does, but maybe it's not obvious why it does that, but... No, but practically, how does he do it? Like, if you send me a page, a PDF or a document that's given your bank, how do I check it? Yeah, yeah. So, so let's say we're talking about what we might call plain vanilla TLS Notary, which is where we're doing an interactive protocol. What's happening is the two sides, the auditor and the client are both generating the pre-master secret together. They're generating half of each. I'll come onto that in a minute, because it's a very critical technical point, how that works. But they generate it together. So they have to pass

a couple of messages to each other during the handshake, during the TLS handshake. Again, I haven't got time to go through that, but that's, you can imagine there's a handshake. Once that's set up, then the client sends his request, the server response comes back, and this is the critical point. At that point, the client sends a hash of the server response to the auditor. The auditor stores that hash, then the auditor sends the remaining material back to the client. So the client now has the full set of secrets. Then the client is back to a full TLS security model. He verifies that the page is correct.

And then he sends that, let's say, HTML page to the auditor. The auditor then has the HTML page and the hash. When I say HTML page, it's the whole server response and the hash, and he can verify the hash matches. Okay. Because he's, yeah. So, but, so I guess so the, One question I want to ask there is, or perhaps one thing that needs to be made clear, is that this only works with sort of classic vanilla HTTP requests where data is sent.

It wouldn't work with, say, a page that has subsequent requests like Ajax coming back or JSON being processed. Absolutely. Absolutely. I want to, well, I don't want to say absolutely it's impossible, but at the moment that doesn't work. And I want to sort of mention that as one of the list of problems. But there's just one little more kind of section. I have to fill in, otherwise anyone listening to this knows what I'm talking about is going to say that's absolute nonsense. So I have to explain this one more point, which is in order for all of that stuff that I just described to work, you have to have the pre-master secret at the start, right? And here we've got two parties instead of one party. Usually the client generates just using a, you know, dev-view random or whatever on his machine.

He generates some random bytes, actually 46 bytes, and he sends them across to the server and then we're off. But what we need to do here is we need to have the pre-master secret split somehow in order for that exor trick that I mentioned earlier to work. So the way it's done is using RSA key exchange. So I said earlier that we use public key encryption to wrap the secret. Sometimes we use Diffy Hellman. There's more than one way to do it. But if we use RSA key exchange, we can exploit a feature of RSA, which is that it has a homomorphism. Now, that's a fancy word.

What it really means, to keep it simple, is if you take the RSA of one number and the RSA of another number, then their product is equal to the RSA of their product. In other words, if you took RSA of 2 times RSA of 3, then that will be equal to the RSA of 6. Now, doing RSA like that is completely unsafe. So people don't do that. It's called textbook RSA. It's appalling to even think of using that as an encryption technique. But what people usually do is they stick extra random padding bytes into their RSA messages.

in order to prevent this from being a problem. But here we can actually use it as a positive because what we can do is take the two premaster secret halves. The auditor has one half and the client has another half. And with a bit of fancy algebra, we can still get the effect of the fact that them multiplying together gives us the exact format that we want to send across to the server and still have it be safe in that it has random padding.

So I mention all that. I think it's very important. although highly technical is a very important detail because that's the only way this could work. We need to have the two parties, the client and the auditor, have some of the secret data separately so that we can get this final result of at the end of the process, the client can have some of the keys, but not all of them.

And I want to note also that the auditor doesn't have any of the keys, which is a very important technical feature as well. Today's magic word is Auditor A-U-D-I-T-O-R Head over to Let's Stock-Fitcoin.com to sign in, enter the magic word, and claim your part of the listener award. So let me back up and kind of have a top-view summary of this.

So in a normal TLS connection, this is without TLS Notary. There's the client and the server. So, you know, Meher and Adam. Meher is the client, Adam is the server. And then Meher has two secrets. The client has two secrets. The client encryption key and the client Mac key.

The encryption key is used to encrypt. The Mac key is used to create something like a signature, but it's not really a signature. It's just, it's not really a signature, but it's something which allows Meher to create a piece of data and Adam to be sure that that piece of data was actually. created by Meher. It's something like a signature, but not a signature. It's something different. So Meher has these two keys, something to encrypt with and something to create this kind of

rough signature with. And on the other side... You can call it a checksum if you want. Check some. Yeah. Like a checksum, right? Yeah. Or let's use the proper term for it, Mac. Yeah. And then symmetrically on the other side, so the server, Adam, also has these two pairs of secrets, the server encryption key and the server Mac key. By the way, both sides have all four secrets. Oh, both sides, yeah. Both sides, both sides have all four secrets. We could do the whole thing with just one pair of secrets, just an encryption key and a

Mac key, but there's a technical reason I won't go into why it's better to have two pairs. Okay. So both sides have all pairs, and that's how we are communicating. Yeah. The problem is, like, once we have a communication like this, it is impossible for me to prove to Sebastian that. Adam sent something to me because Sebastian will ask the question, how do I know that these four secrets are actually the correct ones?

So in this case, what TLS Notary is doing is it is somehow restricting the power of the client. So when the client is actually communicating, you give him not all the four secrets, but just three of them. and one of them is the client does not have one of the secrets and only the combination of auditor and client so Meher and Sebastian has the in combination the fourth secret Yeah, let's say it's I think the best way to understand it

because it is confusing is that the auditor is withholding the data necessary for that fourth secret that the auditor is not withholding that secret He doesn't have it because if he did that would be a security problem He's withholding the data necessary to create that secret And because the auditor is withholding this data, so there's a point in the communication where auditor is withholding this data. So then the client, which is Meher, receives the communication.

And first of all, he creates a hash of the communication, like the whole communication. Send it to the auditor. So the Meher doesn't have the fourth secret at this point. When he sends the hash, the auditor sends some data that allows Meera to calculate the fourth secret. You've got it. you've got it. Right. And now once I have all the four secrets, I can send the auditor the data.

Well, the first thing is once you have all four secrets, you're back to vanilla TLS. Because you've got your full security model, let's say. And so then you can read the web page, right? Because that's actually the next thing that happens is that the client, suppose you're using our browser add-on. You would just like look at the web page at that point. You'd say, okay, that's all right, yeah. Yeah. And then the auditor, so from Mayer's perspective, now this is like a normal TLS connection.

But from the auditor's perspective, what has happened is the auditor knows that during some part of the communication, Meher did not have all of the secrets, yet he sent me a hash of the communication. So in some ways, Meher, I have proof that since Meher did not have all. of the secrets, yet he sent me a correct hash that this must be the data pattern he received from the server. The effect of sending the hash is to fix the server response, isn't it? You can't change it after that. And so it's fixed before you have the data that you would need if you were going to forge

it. So you can't forge it without being exposed as a liar. Because if you try to forge it, you need to have the server Mac to make a valid. forgery, right? So it's fixing it in advance. It's called a commitment is the kind of general idea of how to do these things. Okay. Sebastian, any questions on this? So I want to come back to really just the practical side. How do we verify this? Is there a tool? Is there, and how do we create these notaries? Can we talk about the browser plugin that you've developed? Yeah, absolutely. But I think it might be better, if you don't mind, if I just list, it doesn't need to take long,

but there's three or four very important limitations to this. And then it'll make more sense in context how we use it. So the first limitation is that it only applies to TLS 1.0 and 1.1. And that is quite a serious, maybe the most serious limitation, because at some point they will no longer be supported. We might be able to create a new version. I don't know. That's a huge topic.

So that's one very important limitation. The other limitation is the fact that you were mentioning, Sebastian, which is that the, if you have like, let's say, a dynamic page, you've got a lot of different server, client requests and server responses all kind of mingled up there, and we can't really get this commitment feature that we were talking about in that context. Now, although that's a very serious restriction, and it means that this system only works for certain kinds of webpages, On the other hand, that is a restriction that might conceivably, there might be a way to get around it. It might be possible at some point with some extra engineering to get around that. But that's an open question.

Other restrictions, it's restricted to RSA key exchange. And again, this is an example where we're working with something which is kind of the old version of TLS. It's still out there in the wild. It's still supported by most servers. But at some point in the future, it won't be. So again, you know, it might require some new technique to solve that. Those were, I think, the three main, or the fourth main restriction is kind of, maybe we've mentioned it, but it's just one server response. Now that's fine if you're just pinging an API and you're just getting one API response.

But if somebody wanted to audit a whole stream of web pages, that would be a problem. Right? So, well, I mean, I say it would be a problem. It's probably the least significant of those four limitations. because, you know, obviously you could just go back and do it again. Those are limitations. So I wanted to really emphasize those limitations because I don't want people to think this is some magic fairy dust, right? Because I've seen people saying things like, oh, wow, Deel's everything.

It really doesn't, okay? It's very restricted, but, you know, still practically could be useful in certain contexts. So, yeah, let's get on to practical applications, I agree. So do you want me to give an example of how it might be used in practice? Yeah, how would it be used? Because there's a browser plugin, which the name escapes me. Can you explain how that works? Page signer.

Sure. Right. Page signer. So we set this up, I guess, around the end of 2014, because we were thinking, well, you know, people want to actually use this. How do we make it easy to use? And the idea is, well, let me not talk about the theoretical idea. You want the practicals. So the practicals is you can, there's a plug in, I think, for Firefox and Chrome.

Yeah, not, I think. definitely for Firefox and Chrome. And it's basically set up so that you can just literally click. You go to a webpage. Let's say you go to some private message page or some, yeah, just some official web page. One amusing one is I verified my teacher's certificate. Because actually the UK government has a kind of a website for that. So I went and I clicked a button on the toolbar.

And what it does is it then reloaded. the page, under the hood, it sets up a whole new TLS session for that page, reloads it, and it gets represented to you. Now, when the page is represented to you, you'll see it's, you'll often see there's some, like, weird formatting loss, because all it's doing is just dumping the first server response. So if it's like get slash index.html, it's just literally giving you that. So, and we want people to understand that. So we have a button, and you can click and you'll see, oh, here's the actual raw server response.

response. And so at that point it will create a file called a .PGSG file, which is just a binary dump of all the relevant data, including a signature. And what's going on behind the hood there is in order to make it simple, I had the idea maybe we should have something like a blind notary server. In other words, okay, you can do an audit with an auditor, but you'll have to do that in real time. And we have developed that and you can do that. But that's That's kind of inconvenient for most people, right? Interactive protocol with an auditor. So what we do is, we say, right, there's a blind notary server out there.

It doesn't know anything. It doesn't know the secrets. It doesn't know, you know, there's no login or password or money involved or credentials or anything. All it does is it just generates half a premaster secret, pings it over to you, waits for a hash, and when it gets a hash, it signs your response. So then anyone can see that that blind notary server, has signed using this TLS Notary Protocol that web page.

And the immediate response people have when they hear that suggestion is, well, then what about the trust in the blind notary server? You've got another point of trust in the environment there. And that's absolutely true. But we did obviate that or alleviate that problem very significantly by using what's called an AWS Oracle. Now, I suspect it's going to be a bit too much to go into the details of that technology now. So this is basically what you're saying is auditing as a service.

Yeah, that's TLS Notary as a service. Yeah. So what you have set up is kind of auditing as a service where I, so if I'm the service provider, I can set up an auditor as a service business and I become the service provider. What that allows you to do is let's say you are the user, I don't know, Alice, and you are going to a certain web page and you want to prove to the world that you got certain data from that web page.

Then you can contact me, take my services and then have some kind of digital proof that you did get some data from. And that's a business model many business people across the world can set up auditing as a service. And maybe Alice, she doesn't trust just one auditor and she can do this

like many different or anything as a service companies and then have like very concrete proof of having received something from a web page. Yeah, it's an interesting point. I mean, it's a business only in as much as there's any trust involved in it. If you try and set up the machine as an Oracle, let me give you like the five second version of the AWS Oracle idea. It's just a machine which is untamperable even by its owner. Okay. It does still require that you try to that Amazon's AWS service works as intended. So it's a trust point with Amazon. But basically we set up the machine so that it can't be tampered.

It can only be shut down. That's all you can do. So in that sense, it wouldn't really be a business model. I mean, I know, as you say, there are indeed already business models like that. I know of a few companies that are sort of based around like notarization, especially for identity, I think. But the way we set up was more as an Oracle so that it wouldn't really be possible. You wouldn't really have to trust it.

That's the idea. I mean, you can argue whether it's true or not. So I think Sebastian's question was, what's the user experience like? Right, right. So, like, you have this video on your website. Our listeners can check it out. It's a video about paid signer, and it's like it shows a set of steps people can do in order to generate a certificate of having received a certain page.

Yeah. So just explain to us what the user experience is like. Okay, yeah, so if your plan is to get, let's say, an objective proof that you would deliver a certain web page at a certain time, let's say, for example, you're a trader on, I don't know, BitFinex or something, right, and you want to prove that you had a thousand Bitcoin's in your account, and you can't get BitFinex to actually, you know, well, they shouldn't really. It's considered private, right? So what you could do is you could load up your account page,

and you could just, once you've installed page sign, you could just click the button on the toolbar, and as I said before, it will load briefly. It takes just, I don't know, one to five seconds. It doesn't take long, maybe 10 seconds. It reloads, and usually you'll see it reload without formatting, I think I already said. And so at that point, what you have is a file, and if you want, obviously, this is something

you have to very carefully consider yourself as an individual, you can share that file with a third party. And what that file is effectively is proof, as long as you believe that the AWS Oracle is set up correctly, is proof that that page was in fact delivered by BitFINX, up to you actually trusting BitFINX is public key. And, you know, if you're sufficiently technical,

you can check the public key in the file corresponds to the one that your browser reports for BitFinex. That's actually something you can, and I've done that. Yeah. So does that give an idea of how PageSigner, at least, might be used in practice? Yeah, so I've actually tried PageSiner, and it was super easy to install. I mean, the whole TLS Notary concept seems complicated, but like page signer was like just a breeze to install. And I ended up generating proofs of having visited many websites.

Oh, very good, yeah. And I have these proofs, and I can, you know, I was thinking of putting one of them on Twitter, you know. Hey, look, hey look, I do own five bit coin, you know. Right, right, exactly. You could brag, couldn't you? Yeah, I was like, yeah. I mean, yeah. I mean, if you've tried it, then you've probably seen that, you know, occasionally,

I mean, it always comes up looking a bit weird, the page, right? And sometimes it just doesn't work at all. I mean, if the page is very, very dynamic, you might not be able to get certain data. So that's one thing I should caution people. It's not, it's not, it's, what the important point there is, if you're ever going to use it, please make sure it works before you use it. And the other thing you have to be really careful about, if you're dealing with sensitive data is that there could be cookies involved because this is an entire server

response and in some cases server deliver cookies with the page. So you should look at the kind of response you're getting. I mean it depends if it's not likely to be an issue, that's fine. We do very strongly advise people, log out, right? If you're going to get a proof of a certain page, that's fine, but then afterwards immediately log out so that that session cookie is no longer valid. It just depends on the application, but be careful. It's not. It's not a certain page. It's just like everything's easy, right? Let's take a short break to talk about the G-Tech blockchain contest. G-Tek, the German Tech Entrepreneurship Center, is a new center in Berlin for entrepreneurship,

and they want to support exciting projects happening in this space. So that's why they're running a blockchain contest together with RWE, which is one of the largest energy companies in Europe and Globumbus and Foundation supporting entrepreneurship. You can participate by submitting your idea for your project, win up to $50,000 in free grant money. That's equity for you. Just take the money and do what you want with it. Anybody can apply whether you're an early stage startup and perhaps you just have an idea, a blossoming idea, or you can apply if you've already raised funding and are well on your way to becoming the next multi-billion dollar company. And anybody can apply whether you're in

Berlin and Siberia, in Shanghai or in San Francisco. There's no geographical restrictions. and anybody who applies can win up to 12 months of free office space in Berlin, free mentoring, legal support, et cetera. Of course, that's totally optional. If you want to stay in Siberia and work on your blockchain startup, you can also do that. The application deadline is March 31st, so make sure you submit your idea as soon as possible. You can learn more about the contest and apply by going to EpicenterBitcom slash G-TEC. That's G-TEC.

And we hope you'll win. We hope you'll make it to Berlin to collect your money and that will get it. to hang out in person. Now we would like to thank G-TEC, RWE, and Globombus for their support of Epicenter Bitcoin. So let's get into how you can build oracles using it. And specifically for our listeners, there's this very interesting startup called Oracleis, which is based out of London, by an Italian guy called Thomas Bertani. And what he has done is he has used TLS Notary in order to make a provably online.

an oracle and on an oracle that has proof that let's say uh let's say there's a smart contract that needs the ether to us dollar exchange rate every every every hour then uh that smart contract can get the ether to ether to us the exchange rate and also a proof that the oracle is not lying about that exchange rate could you explain how thomas built it what's the what's the design behind this well the simple answer to that is no I can't explain how Tom has built it. I don't have a huge amount of knowledge about it. Obviously, I chat with him from time to time on various venues,

but I think it's really interesting what he's doing. All I do know is he's using a combination of Ethereum with, obviously, for the contracts, with IPFS for the storage. And TLS Notary is one way he's using to provide the kind of Oracle effect, the proof effect, the objective proof. effect. For example, I know when he started out, he was using as a test case, Wolfram Alpha, which is kind of an interesting example, because Wolf from Alpha, you know, you can get various kinds of knowledge out of it, so he could just ping their API, TLS notarize the API

response. And so, you know, you can imagine toy examples like weather and so on, currency. But I know in recent months he's been really kind of moving forward with it. I've seen some examples on his website. Very impressive. Things like YouTube and I don't actually know how it works with the YouTube thing. But anyway, I only know in general terms, right? The general idea is that he's using a page signer style notary server. I think he might have moved from our original page signer server, which was up for like

nine to ten months without going down, which we're quite happy about. He's moved from that. I think he's built his own one, but it's the same basic design. I mean, all of our stuff is open source. I think he's built his own AWS server using the same model. Whether it's his or ours, it doesn't matter. The basic idea is when you use that, you're going to generate a proof, like a PGSG, we call it, proof, which can then be distributed. It can be put on IPFS or whatever.

Sorry, I can't really give you many details about Oracle. So basically, like, it's Oracleis. is a service that gets, that can fetch information from like Google's, Google's API, old from Alpha's API or in the future maybe Bloomberg's API. Yeah. And then it can give this information to the smart contract. But using TLS Notary, it can also certify that it actually did fetch this data from Google and that it is not lying when it says this comes from Google.

And then the smart contract can basically take this data from, different services and maybe average that data out and have a really good trustworthy source of data. It's not decentralized, but it's high throughput and it's it is trustless to a certain degree. I'm glad you mentioned that because maybe I don't know how much longer we've got, but that's one thing I really forgot to mention. I think is really interesting is when I wrote a blog post about this, I wrote you can think of TLS Notary either as a stopgap or as a disintermediation. And the stopgap part is obvious. Like, if you don't have digital signature, there's TLS Notary. But the disintermediation part is something that's really fascinated me for a long time. Like, if you use,

let's say, Bloomberg, like you mentioned, if you use Bloomberg to get your financial data, the trust relationship is really interesting. Because if you're just pinging their API, and they don't even know who you are, and they're this huge multi-billion dollar company, and you're just like nobody, yes, not decentralized. It's using their trust point, but it's using it in a way that they're not interested in it at all. And similarly with this Amazon AWS Oracle idea, we set up this silly little server. It's just, it's tiny, right, on Amazon AWS. It doesn't hold any money. It's not important to anybody. Amazon doesn't care about it, but you can use it. As long as you're reasonably small, you can use it without them caring, and yet you're kind

of leveraging the trust in Amazon without their permission or involvement. There's a lot of ideas like that I think are very interesting. Yeah, so. Yeah, so what you're saying is, it's like OryKlaz is a tiny company, but it can, it can, it can leverage the trust network of Bloomberg saying, hey, we're getting that this, this data from this company that's been in 20 years in the business and you can trust them for good data. But like, we can provide as a small company the same quality of data as them by using TLS notary.

And that allows. Yeah, I mean, I would look like, imagine, you. wanted to use TLS Notary to validate a $50 million contract, well, you wouldn't really want to do that because, I don't really mean TLSRFRI. I mean page-sided. You can do TLS Notary like from person to person as an interactive protocol without any trust in any other parties apart from the public key of the server, right? But if you use this kind of lightweight service model, then you can kind of leverage trust in Amazon as long as the, let's say the value of what you're doing is relatively low. And also, they don't really know about it either.

They don't know that you're using it like that. So this is the kind of trust models we're playing with, I think. So before you wrap up here, this has been a really fascinating discussion. Can you tell us where people can learn more about TLS Notary, perhaps install the PageSigner extension or contribute to the project? Sure, absolutely. So TLSNotary.org is the website. There's a link there to PageSigner.

you can just install it pretty easily. In terms of contributions, we tend to hang out a lot on IRC at the TLS Notary dash chat channel on FreeNode. There's obviously the GitHub repository, which is GitHub.com slash TLS Notary. There are several sub-repositories. Please do read the white paper and give any comments if you have on the actual sort of underlying technological ideas.

But that's it, really, yeah. Cool. Anywhere else you want to send people? No, that's fine. If you want to contact any of us, you can see our contact details on the contacts page on the website. So just go to the website. It's all there, really. Okay, great.

Well, thanks, Adam, for coming on and being guests on our show. It was fascinating discussion. I mean, personally, it is a little bit over my head, technically speaking. I'm going to have to listen to that again and really, to really get the grasp of how TLS works. Because it is an important protocol that we use every day. be amazed. I would be amazed if you found that easy to understand. It took me years. So, you know, all right. Well, thanks again for coming on. And to our listeners, thank you for tuning in to Epicenter Bitcoin once again. We release episodes of Epistocetcoin every Monday. Of course, we're part of the

Let's Stock Bitcoin network. You can go to less stock Bitcoin.com to find a whole bunch of shows about Bitcoin, blockchains, cryptoccurrencies, all kinds of interesting stuff. You can get Epicenter Bitcoin on YouTube at YouTube.com slash Epicenter BTC if you're interested. and watching the videos. Otherwise, if you want the audio version, you can get that on iTunes, SoundCloud, or anywhere where you get your podcasts. Of course, if you want to leave us a tip, you can do that by tipping the tip address in the show description. And if you're interested in getting one of these t-shirts, you could always leave us an iTunes review and send us an email at show at a personorbiturban.com and we'll send one out to you. So thanks so much,

and we look forward to me back next week. I'm going to be I'm going to