Lavabit Details Unsealed: Refused To Hand Over Private SSL Key Despite Court Order & Daily Fines

from the as-expected dept

It appears that some of the details that resulted in Lavabit shutting down have been unsealed, and Kevin Poulsen, over at Wired, has the details and it’s pretty much what most people suspected. The feds got a court order, demanding that Lavabit effectively hand over the keys to everyone’s emails. Lavabit’s Ladar Levison refused, and he was then threatened with $5,000/day fines, contempt of court charges and possibly more.

Initially, Lavabit was sent a pen register order letting the government know every time Ed Snowden logged in (Snowden’s name is redacted, but it’s clear that this is about him). Lavabit said that it wouldn’t defeat its own encryption system, and the court quickly ordered Lavabit to comply:

By July 9, Lavabit still hadn’t defeated its security for the government, and prosecutors asked for a summons to be served for Lavabit, and founder Ladar Levison, to be held in contempt “for its disobedience and resistance to these lawful orders.”

A week later, prosecutors obtained the search warrant demanding “all information necessary to decrypt communications sent to or from the Lavabit email account [redacted] including encryption keys and SSL keys.”

Once again, Levison refused to reveal the SSL keys, leading to the $5,000 per day fine imposed by Magistrate Judge Theresa Buchanan. The fines began August 6th. Lavabit shut down on August 8th.

Again, something along those lines was what many people had assumed happened, but now it’s been confirmed. Kudos to Levison for standing his ground on this. I know that people in our comments like to insist that every company should act this way, but it’s not nearly as easy when its your life’s work on the line, and you have the entire US government (including huge monetary fines and the possibility of jail time) coming down on you.

Filed Under: , , , , , , , , ,
Companies: lavabit

Rate this comment as insightful
Rate this comment as funny
You have rated this comment as insightful
You have rated this comment as funny
Flag this comment as abusive/trolling/spam
You have flagged this comment
The first word has already been claimed
The last word has already been claimed
Insightful Lightbulb icon Funny Laughing icon Abusive/trolling/spam Flag icon Insightful badge Lightbulb icon Funny badge Laughing icon Comments icon

Comments on “Lavabit Details Unsealed: Refused To Hand Over Private SSL Key Despite Court Order & Daily Fines”

Subscribe: RSS Leave a comment
51 Comments
out_of_the_blue says:

Re: Insert OOTB incoherent borderline schizophrenic rants

@ Shadow Dragon (profile), Oct 2nd, 2013 @ 3:05pm

Insert OOTB incoherent borderline schizophrenic rants

Come to think of it the only good part of that technology is you can track likes OOTB and have him civilly committed.


There you go, kids. Just takes the right button to be pushed, an enemy to be hated, here over mere web-site comments, and you’ll turn into petty tyrants hoping for the state machinery to be used against them. Your future is grim. Those running the world know how easily manipulated you are.

Scote (profile) says:

Wow...

So, to spy on one guy they wanted the company to give them the encryption key that would allow them to decrypt **all** Lavabit email traffic from the NSA’s internet backbone taps. That means they would have been able to **retroactively** decrypt all of Lavabit’s (including Snowden’s) earlier emails if the NSA stored the Lavabit traffic as part of their huge data dump of encrypted traffic, as well as all future traffic. That is not narrowly tailored, not in the least.

Scote (profile) says:

Can the government legally force a business to commit fraud?

Can the government legally force a business to commit fraud? That is what they were asking Lavabit to do, to fraudulently proclaim to provide security while, in fact, doing the opposite. Would Lavabit get that “Telco Immunity”? Or would he, as a mere email provider be subject to prosecution for lying to the public if he followed the government directive?

beltorak (profile) says:

Re: Re:

I really fail to see how this would stop anything. if you implement forward secrecy and are given the order to provide decryption keys, you will be convicted if you fail to do so. if you say “that’s not how the software is written” they will respond with “so what? it’s open source. modify it and save all ephemeral session keys.”.

Anonymous Coward says:

Re: Re: Re: Re:

And then you’re put in the same torture chamber that Manning is in.

He probably made the best decision for himself: He can’t decrypt his service if his service doesn’t exist. It’s part of the EULA to discontinue it at any time for any reason, so the secret courts will be having a bitch of a time trying to argue that he broke the law by discontinuing it.

Anonymous Coward says:

If the US Gov got ahold of Lavabit’s private SSL key, and Lavabit wasn’t using Perfect Forward Secrecy. Then the US Gov would be able to intercept every single Lavabit user’s email account password.

Simply by passively eaves dropping/intercepting all SSL traffic from internet backbone exchanges. With Lavabit’s private SSL session key, they could then decrypt the packets and view the plain text email password inside each intercepted packet.

Please, don’t get confused and tell me Lavabit’s passwords were hashed before being sent out over the wire. This most likely is not true. At least from what I’ve read about Lavabit’s cryptographic setup, which seemed entirely server-side.

It’s true that Lavabit passwords are stored in hash form on Lavabit’s servers themselves. However, the email passwords were most likely transmitted in the clear over the wire (not counting SSL encryption, which would have been useless if US gov has SSL private session key). Then the servers themselves, performed the hashing operation on the clear text password. Verifying if the server computed hash matches the hash value stored on the server’s hard drive.

So yes, passwords were stored in hash form on the servers, but the servers themselves were doing the hashing AFTER receiving the user’s plain text password over the wire.

The only way a client can send a hashed password over the wire, is through client-side software. Hashing can be done using javascript code running inside a client’s web browser, but from what I read it doesn’t seem like Lavabit was doing this.

So in order to prevent every single customer’s password from being sniffed off the internet backbone. Lavabit would have needed to use SSL with Perfect Forward Secrecy or would need clients to hash their plain text email passwords client-side, before sending them over the wire to the server.

Even then, all it would take is a National Security Letter and gag order, signed by the Secret Rubber-Stamp Court. To insert a backdoor into the client-side software, and compromise all customers, or select customers, passwords.

This is why I no longer do business with American IT companies. You never know what the Secret Rubber-Stamp Court is going to do next, and what kind of gag orders they’ll deploy to shut everyone up. Or throw them in prison.

I just wanted to explain how the US Gov could intercept all the passwords, for all of Lavabit’s customers, if the US Gov had possession of Lavabit’s private SSL key.

Unless Lavabit was using Perfect Forward Secrecy. In that case, being in possession of the private SSL key would do the US Gov no good. Every single client connecting to Lavabit, would have a uniquely generated private session key. With no way to decrypt all those encrypted sessions. Even if the US Gov did have Lavabit’s private SSL key.

Anonymous Coward says:

Re: Passwords and encryption

  1. Client-side password hashing is no different than making the hash itself the password and transmitting that password over the wire in plain text. Just copy the hash and you’re in.
  2. You don’t ever want to send encryption passwords or their hashes over the Internet. The proper way is to encrypt locally and send encrypted messages only. Besides, if you’re doing encrypted email you’re probably using PKI, which doesn’t require any passwords be used or transmitted.
  3. As you’ve pointed out, client-side software is vulnerable to being replaced with compromised versions. This is why your email provider should never be the same legal entity as the one which distributes the client-side software. This is why encrypted Webmail will never work.
Anonymous Coward says:

Re: Re: Passwords and encryption

You’re right. Using a hash for a password would defeat the purpose. Unless symmetric key wrapping is used.

1. User creates a new account and chooses a password. That password is used to wrap (encrypt) a symmetric key inside an outer AES encrypted ‘shell’.

The user needs to know the correct plain text password to unlock the outer AES ‘shell’, in order to gain access to the symmetric key wrapped inside the outer AES shell.

User also generates a hash of their plain text password. User then sends this hash value, plus the wrapped symmetric key, to the server for storage. This is all done with client-side software during account signup.

2. In order to log into the server, the user creates a hash value of their plain text password, and sends this hash value to the server.

2. Server compares the received hash value to the one it has on file for that user’s account. If the hash value matches, server sends the user back their wrapped symmetric key.

3. User unlocks the wrapped symmetric key using their plain text password. User can then encrypt and decrypt all email messages using that unlocked symmetric key.

The only thing the hash does, is verify the user knows the correct plain text password, at which point the server will send the user their wrapped symmetric key.

The hash cannot unlock the outer AES encrypted shell, wrapped around the symmetric key. Only the user’s plain text password can unlock the outer wrapping (shell). The plain text password never gets sent to the server over the wire. The plain text password never leaves the user’s computer.

Of course all the encryption would have to be done client-side. Which is probably why Lavabit never attempted it, because doing encryption client-side is much harder than doing it server-side.

On a bright note though, the user never has to worry about loosing their private encryption key, because it’s stored (encrypted) on the server. Which avoids all the PKI key distribution headaches.

I realize I wasn’t clear about all this in my first post, but I was trying to keep things simple and not long winded. I just find cryptography an interesting subject, but I’m far from a cryptography specialist.

Anonymous Coward says:

So to sum up, it’s non-targetted, it would intercept *all* Lavabit users. ‘Probable cause’ doesn’t have any meaning in that instance.

They also wanted to do it in a way that would let them not just read emails but also write fake emails. i.e. write fake untraceable evidence, since emails can and are used as evidence.

“accomplish the installation and use of the pen/trap device”

They’ve also substituted a ‘device’ for the request for data. So instead of the data being handed over in a way that a court can verify (and Lavabit can verify in its role as guardian of the data), a black box is added with an unverifiable promise that it only does legal stuff and grabs nothing else. The leaks show these devices go far beyond their legal remit.

The judge, a non-techie, trusts the badge, without understanding the issue.

“?He?s had every opportunity to propose solutions to come up with ways to address his concerns and he simply hasn?t.?”

*He* should address HIS concerns? What some sort of self arguing?

“?It filters everything, and at the back end of the filter, we get what we?re required to get under the order….No one looks at that, no one stores it, no one has access to it.”

Liar. It splits the data into filtered and unfiltered. The filter is made available to the FBI agent, the unfiltered+filtered is stored in the NSA giant database aka ‘lockbox’. General ‘collect it all’ collects it all. We got that from the leaks.

But the key to me is, IT LETS THEM FAKE COMMUNICATIONS. He would be handing over a key that would let the NSA make fake & send emails, impersonating any Lavabit user with an audit trail that would pass forensic investigation. I assume that was the intention when they didn’t just want Lavabit’s email, they wanted the ability to put a device in with Lavabits own SSL keys.

Add Your Comment

Your email address will not be published. Required fields are marked *

Have a Techdirt Account? Sign in now. Want one? Register here

Comment Options:

Make this the or (get credits or sign in to see balance) what's this?

What's this?

Techdirt community members with Techdirt Credits can spotlight a comment as either the "First Word" or "Last Word" on a particular comment thread. Credits can be purchased at the Techdirt Insider Shop »

Follow Techdirt

Techdirt Daily Newsletter

Techdirt Deals
Techdirt Insider Discord
The latest chatter on the Techdirt Insider Discord channel...
Loading...