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: doj, ed snowden, email, encryption, fbi, ladar levison, pen register, privacy, ssl, wiretap
Companies: lavabit


Reader Comments

Subscribe: RSS

View by: Time | Thread


  1. identicon
    Anonymous Coward, 2 Oct 2013 @ 11:07pm

    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.

Add Your Comment

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



Subscribe to the Techdirt Daily newsletter




Comment Options:

  • Use markdown. Use plain text.
  • Remember name/email/url (set a cookie)

Follow Techdirt
Insider Shop - Show Your Support!

Advertisement
Report this ad  |  Hide Techdirt ads
Essential Reading
Techdirt Deals
Report this ad  |  Hide Techdirt ads
Techdirt Insider Chat
Advertisement
Report this ad  |  Hide Techdirt ads
Recent Stories
Advertisement
Report this ad  |  Hide Techdirt ads

Close

Email This

This feature is only available to registered users. Register or sign in to use it.