LavaBit's Architecture (2009)

http://possibility.com/LavabitArchitecture.html

by yankcrime • 13 years ago

140 57 13 years ago

chayesfss• 13 years ago

That might be the best article/review I've ever read.

tehwalrus2• 13 years ago

It is taken directly from the Lavabit "about us" pages* - I read them all a few weeks ago when I signed up and paid for pro! :)

* - the pages are gone now, which is why they needed to be mirrored somewhere.

toddh• 13 years ago

Ladar was kind enough to answer the questions in an architecture template I have for High Scalability (http://highscalability.com/architecture-template-advice-need...). I guess they also used it for their about page, which makes sense given all the work that went into it. He's a very nice guy, a shame to see how things went down.

captn3m02• 13 years ago

Just after the PRISM scandal exploded, I came up with the idea of encrypted-storage based email [1]. Unfortunately, within a little while of thinking of this, I read about lavabit and realized that they had the exact same security model that I was thinking of.

Now that lavabit's gone, I think there is a good opportunity for someone in a sane country with good data-protection laws.

[1] http://firespotting.com/item?id=1632

option_greek• 13 years ago

It's very interesting. Something like this is really required. How ever, if this is a private project then people may not have absolute trust on it. If it is open source, independent verification is possible which will improve user trust. Also when malicious unnamed agents come after you through legal channels, you can drop the service like lavabit but some one else can setup an independent server and do a direct import of user data from your servers with user permission.

captn3m02• 13 years ago

My plan was to keep it open source, and have free accounts, as far as possible. The monetization could have come from extra storage, like GMail, or custom domains.

vader14• 13 years ago

For a couple of weeks now, I've been brainstorming about how to create a system like this. I'd very much like to use this sort of setup for my own emails, but it simply doesn't seem to exist, especially not as open source (while lavabit claimed to store your emails encrypted, there was no way for anyone to actually vet their approach).

The most viable option I came up with so far is modding eCryptfs to allow "write only" mounts by supplying it directly with the derived public key for the passphrase instead of the passphrase itself. This would allow you to use vanilla components such as postfix & dovecot instead of having to write a custom application server.

Using the maildir format, incoming mails could be written to the write-only mount without having to read any files from the mount. On IMAP login, the mail daemon would use a passphrase derived from the login password to mount the maildir as read-write, using unshare to ensure that the mount is visible to that process alone, and automatically unmounting it when the IMAP user logs out.

Thoughts and ideas are welcome :)

wfn5• 13 years ago

Nice plan. I've also been brainstorming ideas - I'm now considering setting up something similar (though I have less knowledge in these matters):

* encrypt all incoming mail to a public key associated with the recipient's email address (new account creation would have to involve uploading a public key; on the other hand, if we are only talking about one user, then it becomes much simpler)

* this can be done while there is nothing written to disk (via exim, etc.)

* either write the resulting encrypted email to disk, or keep it in memory (depending on paranoia level)

* ideally, check incoming email if it already has a PGP header; if it does, do not encrypt on top of that (this would confuse certain mail clients)

* user logs in via IMAP, downloads new mail, mail client can be set up to transparently decrypt mail. User is encouraged to then delete mail from the server

This wouldn't be user friendly in the traditional sense, but my initial goal presumes that compromises involving friendliness vs end to end encryption suck, so screw it. I'd like to set up something like that for personal + friends' use.

Your idea of passphrase ~== private key is very nice. Mine is more ugly in the usability sense (at least for the median user), but at least at no point in the process does the server have to do anything with the private key. Still, of course, it would be possible to wiretap the whole thing at the "process incoming mail and encrypt it" point..

andrewcooke2• 13 years ago

if you're doing this on your own hardware, why not just encrypt your entire disk? (or just a single partition, and give imap access to that alone through unix perms or, if you want to go further, apparmor etc).

e12e• 13 years ago

I still think one of the sanest ways to do this is to set up a filter that takes an email message on standard input, and outputs the same message to a Maildir/mbox[1], with the body encrypted with the recipients public key (possibly signed by a server key, but that wouldn't add all that much in terms of security, as the server key would have to be always available).

1: Probably one filter that takes an email on standard input, and writes an encrypted "copy" on standard output, and another program that takes a message on standard input and delivers it to a Maildir/mbox:

    #.forward pseudocode:
    | gpg-encrypt-to-self | deliver

Optionally check if the mail is already encrypted:

    if is-gpg-message
    then
      deliver
    else
      encrypt-to-self|deliver
    fi

zokier3• 13 years ago

If you don't care about metadata then imho the approach presented in a blog post[1] linked in your firespotting thread is most reasonable. Most importantly the private key never touches the mail-server.

If you do care about metadata then you could do some lavabitesque tricks in addition to encrypting the message bodies.

[1] https://grepular.com/Automatically_Encrypting_all_Incoming_E...

pilif2• 13 years ago

Considering that STARTTLS is still optional and most MTAs don't implement it, what value is there behind storing the mail encrypted? Because governments are storing every email anyways, when they want to get to my data, why would they bother asking you to decrypt it for them (which you can't) instead of just looking at the SMTP communication between $OTHERSERVER and you.

With a very high likelyhood, that SMTP communication is unencrypted.

Of course $EVILGUY might have encrypted their message before sending it, but then you can't help the government anyways.

IMHO, as it stands currently, encrypted mail storage provides a false sense of security.

cypherpunks01• 13 years ago

Is it really true that most MTAs don't implement it?

Looking through a bunch of random emails of mine (on gmail), I see version=TLSv1 somewhere in the headers, which I thought indicated that STARTTLS was being used. Am I wrong about this? Or is there some intermediate MTA that might not be using TLS in this case?

old-gregg2• 13 years ago

The tech required for a truly safe email lives on a client, not a server: http://en.wikipedia.org/wiki/S/MIME

wildgift4• 13 years ago

What about 1) requiring STARTTLS, 2) encrypting incoming mail that isn't already encrypted, using the customer's public key. The message then cannot be decrypted by anyone but the customer. (The customer experience is that all the messages they download are encrypted.)

vader14• 13 years ago

Of course a system such as this will not provide you with foolproof protection against any adversary ever. If that is what you need, email is not what you're looking for, period.

But there is in fact an enormous difference between the proposed system and traditional email hosting. With traditional email hosting, all it takes is one FISA rubber stamp, one hacker gaining access to the mailserver or any of its backups, one rogue or compromised employee to access the entire history of every email you have ever received or sent.

In the proposed system, assuming it is properly implemented, the only way to snoop on your emails is tapping the line between the local and remote SMTP server, easily prevented if both parties use SSL. The system could even, based on the user preferences, warn about this ("Warning: this email was not delivered via SSL, it could thus have been intercepted while on the wire") or block incoming/outgoing SMTP entirely if the remote party doesn't support SSL.

It's not a solution against (government) snooping per se, especially not a solution against a party such as the US government specifically targetting you. But it is a defense against half of the world population's email history indefinitely being stored in your friendly neighborhood NSA facility.

umsm• 13 years ago

You could always make it open-source and allow users to "download" and "upload" their mailbox. This way, when one service provider is shutdown, you can find a host and install the email system and upload your mailbox.

I had a similar idea, but I have no time to execute it.

walden42• 13 years ago

I believe that the LavaBit fiasco just proves the need for a decentralized system with no central points of failure. Although it's still in the beginning stages, bitmessage (https://bitmessage.org/wiki/Main_Page) offers a solution similar to the bitcoin protocol.

I would more people to start using solutions such as these instead of email. Although email has served its purposed for a long time, it was never designed around security and privacy in the first place.

zokier3• 13 years ago

I believe that the LavaBit fiasco just proves the need for a decentralized system with no central points of failure

That's probably the only thing e-mail actually does really well. Centralization is definitely not the problem with email. Lack of end-to-end encryption and meta-data leakage are the real problems.

VikingCoder2• 13 years ago

In theory, sure - but in practice... Most of my friends are @yahoo.com, @gmail.com, or their ISP.

Meaning, in practice they're centralized.

Tloewald3• 13 years ago

I don't understand why the service provider needs to store or provide any keys. Let the customer generate a private and public key, store the private key anyway he/she chooses, and then broadcast an address/public-key combo to would-be contacts. You can communicate using a totally insecure file-sharing service -- e.g. usenet, anonymous FTP, or mailinator.

tptacek2• 13 years ago

Unless you're shipping the customer a persistent component that doesn't automatically update itself every time they connect to the service, you might as well just store the keys, because (as LavaBit apparently discovered) if a court decides you need to cough up your users info, they'll probably just get you to install whatever code is needed to make that happen.

conductor• 13 years ago

If I understand correctly, the decryption code was in the server, so the user was providing the password for the private key, and the code from the server was doing the encryption/decryption (by server-side or client-side execution, I don't know). This scheme could be backdoored by altering that server-side code. So, why not keep the code on the client-side (like signed, verified browser add-on or native application)? Then there will be no way to get the password of the private key from the user (except by installing a malware with some 0-day browser vuln).

Tloewald3• 13 years ago

I don't think you've addressed my point. I don't hand my private key to anyone, including the service operator, so there's nothing they can cough up to make anything happen.

If you go back to the original backpack encryption model -- I leave my padlocks out in public and tell people to send me messages at some dropoff spot (alt.wesley.crusher.die.die.die for example) and collect my encrypted (padlocked) messages whenever I see fit, which I then unlock with the key I have never given out.

This could obviously be dressed up like email if necessary. E.g. set up a mail server that bounces all unencrypted incoming messages to me with a "try again using this public key".

Yes, the authorities can track my attempts to access the server (but guess what, they already can). And because my inbox requires no password to access they can't tell me from any random person or bot trying to access my mail.

The authorities (and anyone else) can also deluge me with encrypted spam (including spam I can't decrypt :-)). It's not perfect.

santry• 13 years ago

* How do you backup and restore your system?
All critical servers use RAID 5.

Unfortunately RAID 5 (or any other flavor) is not a backup solution. It doesn't account for user error, RAID controller failure and numerous other scenarios.

It seems LavaBit had an interesting product, but this seems like a pretty critical design failure.

pktgen• 13 years ago

It's much harder to delete things from backups though. Lavabit promised that when you deleted a message, it was actually deleted. Redundancy against hardware failure but not against user error, software error, etc. was probably part of their security-convenience tradeoff.

jonknee• 13 years ago

Lavabit also flipped the bit and destroyed everyone's emails (without much complaint, at least that I have read). The goal was security, not availability. If security is the goal it's better to fail hard than fail [possibly] insecurely. POP/IMAP email also backs up itself--you retain a copy on your own machine.

yarapavan• 13 years ago

Old article, circa March 2009! Look at the monthly visits mentioned, and also this highscalability article- http://highscalability.com/blog/2009/3/30/lavabit-architectu...

I wonder how much of this architecture still exits and how much has changed!

Do they still host servers, use CentOS+Apache+MySQL+Memcache or was there an architectural change with more apt software components?

negativity• 13 years ago

It would be really awesome if the LavaBit team released all their trade secrets, including their C code for their custom daemons, and other substantial details, as an open source project. ...that is, if there's truly no hope, and they've shuttered the business for good, and never plan on re-opening their doors and returning to business.

Hardware and Service Provider expenses aside, this would represent an opportunity for many people to create their own systems and participate in a distributed, federated network of professionally vetted, (ostensibly) secure e-mail services, based on field tested architectural standards.

If the company is dead, why not turn lavabit.com into the homepage of a project spawned from the ashes of the original business.

caycep• 13 years ago

actually, I'm wondering if something like this could fit the bill for a HIPAA compliant medical communication system?

wenming• 13 years ago

ok?

wildgift4• 13 years ago

I'm guessing that the government wants Lavabit's private keys. Maybe they already sniffed the traffic and now need keys to decrypt it. What do you all think?

LavaBit's Architecture (2009)

Related Stories