Ladar Levison - The Future of Email Privacy

Right now I'd like to introduce LIDAR Levinson. LIDAR has earned the admiration in Silicon valley of many technologists for the stand that he took around responses to demands for access to information. Sure. That's his story, and I'm not gonna tell it for him if he has it in mind, but please help me welcome mingled out today. Thank you. I'm I'm not gonna tell my story again.

I, I think I've told it enough times, at least for my own good. I'm actually here to talk about the future. It's good to be back in Germany. The one thing I love about this country is that we can drive as fast as we want. We have safe limits, not speed limits. I got a reminder of that on the way here, the taxi cab driver was going about a buck 60 in a zone that was marked a hundred. And I thought about pointing out to him that I had just flown 16 hours and a couple more minutes wouldn't make much of a difference.

But by the time I had that thought, he was already up over 200 and I didn't want to distract him, but it just goes to remind me of another freedom that I've already lost back home. And that's the right to privacy. So I thought I would start my discussion about email privacy with a description or definition of the word. Privacy.

To me, privacy is about control of your information. Being able to decide who knows my social security number, my birthday, my middle name, The fact that I like chocolate or my password. So when you relate that to email, we're talking about the ability to control who sees your messages. And that really only has one answer end to end encryption. You decide who has control over your email by giving them the key to access the message. And I think that is the future.

So Martin stole big portions of my speech or at least the theme of it, but he did bring up something very important that I wanted to talk about. He said that the future will be information centric, security. I disagree with the first word. I don't think it's going to be information. I think it's going to be customer centric security. There's an important distinction there. Do you care about securing your information at an organizational level or an individual level because both could be your customer. Now the problem is designing new standards for protecting information that takes into account.

All these new variables is incredibly difficult. Trust me, I've been trying, I've been working on a little project to do exactly that. To make email security, end-to-end encryption for email automatic. And what I've found is that we've solved the problem of encrypting a real-time conversation. We agree on a key that we're going to use that one time for that conversation, but when the two parties have never even met, let alone exist online at the same time, Securing that conversation becomes a lot more difficult.

You have to go out and discover the other person's key, which brings me to an inviolable rule. The more automatic you make security, the easier it is to fool and in a world where we have to worry about attackers with unlimited resources, sophisticated technology, the world's largest pool of cryptographers, building a system that can't be tricked, or at least easily tricked is an incredibly difficult technological problem to solve. I think I've got some ideas on how to do it. Hopefully I'll be finding out in the next couple of weeks, if they'll actually work.

When I show them to other people, some of you may know I've been working on a little project. We've nicknamed dark mail for its goal of turning all of the world's email dark, but really what the goal of that project is, is about giving users back control over how much they want to trust their service provider. The cloud doesn't go away. The cloud remains a commodity. It provides a service, but now you have control over how much access or how much you need to trust them, not to peak inside your inbox. So let me talk about some of the problems that we've been trying to attack. Keep in mind.

The goal of dark mail is to make all of these happen automatically from the perspective of the user, because unless we can accomplish that, we will never see ubiquitous email end-to-end encryption. And that's really our goal. We want to be able to talk to the person that we've never talked to before, who has no concept of security, say a journalist and know that we can communicate with them securely without them having to go back to college and learn how to use the tools. Some of the problems that users seem to have issues with are key generation and management.

When you get outside the technological community, you start using words like public keys certificates, X 5 0 9, and you get glass eyed folks saying, yeah, that's good. That's great. What the heck did you just say, how do I use it? How does it apply to me? Needs to happen under the covers key discovery? How do I know that this key, that I'm encrypting this message to actually belongs to you again, Martin brought this up. How do we know? How can we authenticate the identity of the other party that lives out all the way across the internet?

It's a problem we've solved inside an organization through central management, a central authority federated, if you ask Microsoft, but having a centralized server that everybody authenticates to. But when we go out into the wild west, that is the internet. How do I know that the person I can't see is actually the person? I think it is Perfect Forward security. Somebody happens to intercept that message. How do I know they're not gonna hold onto it, break into my apartment late at night or my office late at night, get the key and decrypted later. And then of course made a data.

And unless we can figure out a way to protect the Maita data, it's just a matter of time before we lose our, another one of our valued freedoms, which is the freedom to associate. I mean, you've already seen this happening today. I'm in Germany. There's another former American civil misfit. Who's made Germany, his home, Jacob Applebaum. And I wanted to email him to tell him I'd be here. But I was afraid if I emailed him, I'd show up on one of those magic lists that would put me under an even bigger microscope, unless we can protect the metadata as well.

We're not going to solve the problem now, for those of you who know how SMTP works and how email works today, you know, that figuring out a way to protect the metadata, using those leg and fitting them into those legacy standards is going to be incredibly difficult. But I think it's something that we have to do.

And again, I've been working on it, Hopefully by the end of this summer, you'll actually be able to read what it is that I've been working on. I think I have the architecture down. I've been working on the protocol details. All that's really left is to show it to somebody else so that they can poke all those big holes in them, depending on how many holes they find determines how long it's gonna take me to actually get it to the rest of the world. But that's just the exchange of messages. There's a second half of the problem that dark mail is also trying to solve.

And that's how do we access our messages securely end to end security? The key is on your device.

Well, what if you have two devices again? I think the cloud is here to stay because there's no other way to solve that problem. Okay. So we figured out how to do encryption on the terminal on the client. But what about all those people who like webmail? Can we really trust the JavaScript? That's been loaded off the server? If the server can be so easily compromised, easy being a warrant or other means if you don't happen to live in the us, I guess, right?

Mobile devices, when the message is a giant encrypted blob, how does a cell phone with limited network bandwidth and processing power access the text of the message without also downloading the 28 megabyte file of their best friend, playing with their kitty cat and time. There are people who like to go on African Safari's stay disconnected off the grid for six months. At a time they come back, they check their mail.

How are they going to find the key, the public keys for the people that sent them messages six months ago so that they can validate those messages when that person could no longer be using that account, that service provider could be offline. These are all technological problems that keep me up at night. I think in the short term, we've already seen a huge uptick in the adoption of TLS.

For years, we've seen it between the server and the client. Now we're seeing it between servers. We can't trust the backbone the way we used to. We've seen an even bigger uptick or an even bigger effort towards integrating at least support for open PGP, into many of the mail systems and packages that we use today. But I'll leave you with this thought. If we stop there, we haven't gone far enough. If all we get out of the Snowden, disclosures is an incremental increase in security. Then we've lost because what we've learned is that the systems and tools that we use today can all be defeated.

It's just a matter of how much effort it takes. And I'm not talking the math because the math is sound. The problem is us. The humans. Can we protect the keys on our systems? The private keys to our servers. I asked this question a year ago in front of an audience about this size. And I'll ask it again by a show of hands. How many people protect their SSL, private keys on their web server so that they have to enter in a password when it starts up one, one, I have a sticker for you last year. It was zero.

If we don't encrypt the private key on the server, then it comes down to how hard is it to break into the server to get the key? Because once they have the key, they can listen to the conversation and we're fooling us ourselves. If we think they're not doing that, The problem is we don't know when a key has been compromised. Another issue we're trying to fix with dark mail. How do we detect that? One thing I still struggle with is hardware. How do we solve the problem of trusting hardware? Because I think that's where we're going.

We've seen how easy it is to break into web servers, defeat operating systems. We're seeing a bigger move towards virtualization just to separate the physical hardware from the operating system to make it a little bit easier. But I think ultimately we're going to see more systems designed to separate out the cryptographic functions from the user level functions. Even if they happen to compromise my machines, they still can't get access to my machine, to my private keys. There Are systems and tools to do that today.

I think one of the vendors here is SafeNet they make H hardware security model modules that do exactly that. But the question is, how can you trust them? Unless you have an electron microscope in your garage and a degree in electrical engineering, you can't exactly pull away for apart and make sure it's doing exactly what it says it does. I don't have a solution to that problem yet, but when we start talking 10 to 20 years out, when we start moving towards a world where everything is encrypted end to end, that will be our next challenge is protecting those keys.

In terms of my timeline, when I get back to Texas, I'll actually be capping off the release of magma classic, which is the source code that was powering love a bit when I shut it down, sort of a white boxed version of it, trying to get that out to the world, which does server side encryption. It protects data at rest, coupled with PGP. It's a pretty good solution, but it's not the solution because as I found out the hard way, if you can't protect the SSL key server side encryption, doesn't really matter that much.

We'll just get it after you decrypted on the server and send it down the wire, or they'll get the password. If they have the password, then they can get access to the key. So how do you build a system where the password never goes to never traverses the wire? At that point, you're talking about changing the protocol. I'm still hoping fingers crossed to release some documentation on the dark mail protocol in July, and as soon as possible afterwards, release a working implementation of it.

I say that because I'm hoping not to end up with the duke Newcomb problem of becoming so paranoid that I never release, but that's the future. And my hope is that after hearing me here today, when I do release those things, you'll go to your organizations and you'll talk to them about upgrading their systems or including support for dark mail in your products and services, particularly your email servers, but it just doesn't have to stop there.

The scheme that we're using is really about authenticating identity and being able to exchange messages, not just email messages, but data in general, between two parties in an authenticated, encrypted and secure way. Think I've run out of time.

Usually I, I ask for questions, but I don't think we're quite set up for that. Thank you. Did you have a Question? I do. I do have just one actually, cuz you know, even in a context of X 5 0 9, 1 of our biggest exposures has been the DNS system and DNS X been around now for nearly 20 years. Adoption's always an interesting challenge as we try to put in place much more secure mechanisms. Have you given any thought to yeah. Adoption?

Well, PG P's been around for 20 years and look how long it's taken for that to take hold I P V six. I can release it. I can build it, but I can't make you use it. And that was what I closed with. Cause I can give you the ability to protect yourself, but if you don't meet me halfway and actually adopt the standards that have been developed to do exactly that, what are you gonna do? All right. Thank you. So we appreciate Your time.

So, well I, I guess what I'd say is that the one nice thing that has come out of the snow and disclosures is that it's really lit a fire under everyone's butt. You know, I tend to have been out at the, the pinnacle of the forefront, you know, for the last 10 years I thought server side encryption was enough. Now I'm trying to push that envelope by pushing it out to the user. My hope is that we won't see server based encryption for the next 10 years while everybody catches up. Cause the, the one, the one issue there is you should all watch your initialization vectors. Hmm.