Tuesday, December 31, 2013

Lavabit - There's a sucker born every minute

P.T. Barnum was a master showman. His name has fallen from public use, but his methods haven't.  You may be familiar with his name as part of the Ringling Bros. and Barnum & Bailey Circus.  He's notably remembered for promoting many hoaxes, and associated with the phrase "There's a sucker born every minute".  It likely wasn't his phrase, but when I see a monkey head sewn to a fish, that's the man I think of.

That's also the phrase that comes to mind when I hear about Lavabit. The company was founded specifically as an answer to Gmail's business model of using your email content to deliver ads.  The idea was to encrypt incoming email so it wasn't viewable. They released a whitepaper touting their encryption, but what it came down to was doing a lot of busy work to locally encrypt and decrypt your email. Everything sent over the wire was plain text - albeit via an encrypted tunnel. The service was billed as "so secure that even our administrators can’t read your e-mail". Unfortunately their users aren't InfoSec experts, and didn't understand this statement to be completely false.

What most users don't understand, and I've run into this when speaking with Lavabit supporters, is that there are basically two types of encryption.  There is encryption at rest, and encryption in transit.  SSL provides encryption in transit, the data sent between two nodes is not viewable by a third party. Lavabit provided encryption at rest.  If you weren't using it, it was encrypted. When you sent or received email, it was decrypted (if read from disk) and sent via SSL.  SSL is essentially a 'tunnel' - anyone on either end can see what's going in and out, when the data is in plain text.  A solution to that problem is PGP - encrypt your data before it's sent, and it will be encrypted at rest and in transit (whether it's via SSL or not).

What's curious is this apparently 'successful service' actually stopped accepting new users in May, 2013. That's very odd. Someone may think that's related to the FBI Probe, but that didn't start until June 10th. Now, I run own and operate VFEmail.net - the subpoena on pages 2 and 3 is nothing out of the ordinary. They always have a 'gag order' attached. The FBI is just as paranoid about the target finding out about the order, as many users are paranoid about the NSA reading their email.

On June 28th, Lavabit received a wiretap order.  This is the 'pen/trap' device. Having received this sort of order in the past, using a 3rd party device IS NOT REQUIRED.  In fact, Page 7 states use of a trap and trace device or process ("pen/trap device")   The ('pen/trap device') is a legal notation to say that from here on, this entire sentence will be referred to as 'pen/trap device' - not that a physical device absolutely will be installed.

At that time, Lavabit could have implemented it's own data duplication system.  An email archive feature, and grepping of the log files is all that's needed to comply.

On June 28th (Page 12), we see The representative of Lavabit indicated that Lavabit had [he technical capability to decrypt the information but that Lavabit did not want to 'defeat [its] system.' . Here Levison admits to being able to decrypt data, but is hiding behind Company Policy to state "We just don't do that".  I dare you to find anyone in InfoSec who thinks Company Policy is a valid security method.

On July 9th, (Page 20) we see that Levison is compelled to appear before the court to explain why he simply can't decrypt email for a single account - or for those of us who know how email works - why mail received via SMTP for/by the target account simply wasn't archived prior to encryption.

On Page 31 we see the actual summons, Levison is to appear in the Virginia court on July 16th - this summons includes the request for the SSL key.  This is because Levison is defying a lawful order to simply archive SMTP communication - which is in clear text on his system.

On July 16th, (Page 34), we see all the dirty details of what the FBI needs to do to accomplish a simple thing that Levison could have done. 

We also see on Page 46 - Levison had caved to this simple request, but demands $2000 to provide the information requested, and then another $1500 after 60 days. We also see that the government has paid for his expenses to travel to VA.
(edit:) Why didn't the FBI pay $3500 for that, and instead opt for the SSL key?  Here's an example of how to use Capsa Professional to save emails. Once that content is saved, it's trivial to grep each text file for the target's address. I'm sure the FBI has software that includes the filtering. This isn't magic or hocus pocus, it's simple network sniffing that anyone with a basic background in InfoSec can do. There's no reason, other than complete lack of familiarity about how it's done, that Levison couldn't provide the requested information at a reasonable reimbursement rate.


Beyond that it's all about the SSL key.  The entire episode was CAUSED by Levison's failure, and flat-out incompetence, to implement a simple SMTP archive feature and then his attempted fleecing of the American taxpayer by charging $2000 to provide that information.

(Edit) Some people have said the 'archive' is very complex to implement or the email would have been encrypted.  Actually, neither are true. First, Levison was already 'up to date' by manually decrypting the mailbox, just new mail needed to be sent in an automated fashion. Second, SMTP is very simple - it's basically 4 commands.  You connect, say HELO, MAIL FROM, RCPT TO, DATA.  What you see in an email all follows DATA. MAIL FROM is only for return mail, and RCPT TO is the destination. A simple archive feature would merely read the RCPT TO, do a text match, and programatically add 'fbi' as another RCPT TO.  For outgoing mail, you just do the match on the AUTH (or MAIL FROM) line instead. Levison claims to have written the entire Lavabit code, so adding this option should have been a trivial exercise.(/Edit)

But it's not over.  He's taken his half of the story, the "NSA is attacking the constitution" to the public. I'm no fan of the NSA, but other than the probable target being Ed Snowden, the NSA violations are in no way related to this case.  Surprisingly, even after admitting to the NYT that the entire issue was caused because he couldn't provide real time archiving, people STILL think he's full of integrity.  Quoting the article - He would log the target’s communications, unscramble them with the encryption keys and upload them to a government server once a day. The F.B.I. told him that was not enough. It needed his target’s communications “in real time,” he said.
If you think that's bad - remember Levison's original version of 'security': "We just don't do that".  Apparently that's a good enough answer for him, but when the FBI requested his SSLKeys, all of a sudden 'we apply filters per policy' is no longer an acceptable answer.  So now, supposedly, everyone's data is at risk.

Levison wasn't able to make $3500 off the FBI, but the gullibility of the public has earned him over $200,000 on Kickstarter, and $100,000 on Rally.  Who knows how much he's taken in on Bitcoin, Paypal or other direct methods.  He may not be much of a tech, but he's good at marketing.

VFEmail has no interest in supporting this person or DarkMail - another marketing ploy to target the non-technical public. If someone does come out with an untainted open source, encrypted, SMTP replacement that still allows AV Scanning, Spam Scanning, and User Filtering on the server - we'd love to hear about it.

Who knows why the media won't cover this angle of the story.  I understand USA Today or NYT not having proper staff to understand tech issues at this level, but Ars?  It's a sad state of affairs.  Frankly, I've thought about shutting down VFEmail because of Lavabit. Not because of 'NSA hacking', or 'Subpoenas for SSLKeys' but because Levison and Silent Circle are trying to manipulate the public into using a solution that won't ever be able to meet their demands. 
 
(Edit 2/24/14) I was subscribed to the Dark Mail Alliance email list - JUST IN CASE they were to release something of substance. Apparently it's nothing more than a marketing list for Silent Circle's products.(/Edit)

If you would like to support me or VFEmail, you may donate to paypal@vfemail.net or via Bitcoin to:


1MgWNPqZqwqhUR38cx2UVJQsDSckpDxYAt 

3 comments:

JMP said...

Cool, Waukesha! I won a bike race there in 2002 - nice little Wisconsin town...

So what is the process, in detail, for implementing functionally secure encrypted email for the individual?

Havokmon said...

The best solution right now is to use some form of PGP on your local client. That will allow you to use public/private keys (one encrypts, the other decrypts) to secure your email within the current email infrastructure. That is, if you have Hotmail or VFEmail, your encrypted mail will "ride on top".

Public keys can be shared manually, or uploaded to a public keychain (like http://pgp.mit.edu/ ) When your public key is easily found, it's easy to send you encrypted email.

To 'mange' your email and keys, I would suggest starting with the Enigmail site (www.enigmail.net). It will help you integrate PGP with the Thunderbird email client so you can send and receive encrypted mail.

There is no 'It just works' interface for PGP at this time, it takes a little effort on behalf of the user - but the benefit is that you likely won't receive encrypted Spam either. Although Horde5 has a nice interface, it does run on a server that could intercept your email - though if you're unfamiliar with PGP, it's a good way to get your feet wet.

Using PGP, by default, does encrypt the content but not the Subject/To/From headers (which could be done manually) or your Metadata in server log files. VFEmail's Metadata Mitigator rewrites the logfile 'Mail From' (not the same as From) to hide your identity in logs to help with this, but without a complete rewrite of the email system (and unless everyone is online 24/7, there has to be some sort of queuing system) that sort of log data will always exist.

You can PGP encrypt strings as opposed to 'an entire email', so IMHO the next 'baby' step is further integration of PGP into email clients so the Subject/To/From headers can be encrypted too.

We need to be careful though, full encryption by everyone invites abuse. It needs to be done in a way that's easy enough for an most end-users to use, but isn't on by default so it doesn't attract Spammers.

Blogger said...

If you're looking for the #1 Bitcoin exchange service, then you should know CoinMama.