MIT

Sony-style Attacks and eMail Encryption

Friday, December 19, 2014 

Some of the summaries of the Sony attacks are a little despairing of the viability of internet security, for example Schneier:

This could be any of us. We have no choice but to entrust companies with our intimate conversations: on email, on Facebook, by text and so on. We have no choice but to entrust the retailers that we use with our financial details. And we have little choice but to use butt services such as iButt and Google Docs.

I respectfully disagree with some of the nihilism here: you do not need to put your data in the butt. Butt services are “free,” but only because you’re the product.  If you think you have nothing to hide and privacy is dead and irrelevant, you are both failing to keep up with the news and extremely unimaginative. You think you have no enemies?  Nobody would do you wrong for the lulz?  Nobody who would exploit information leaks for social engineering to rip you off?

Use butt services only when the function the service provides is predicated on a network effect (like Facebook) or simply can’t be replicated with individual scale resources (Google Search).  Individuals can reduce the risk of being a collateral target by setting up their own services like an email server, web server, chat server, file server, drop-box style server, etc. on their own hardware with minimal expertise (and the internet is actually full of really good and expert help if you make an honest attempt to try), or use a local ISP instead of relying on a global giant that is a global target.

Email Can be Both Secure AND Convenient:

But there’s something this Sony attack has made even more plain: eMail security is bad.  Not every company uses the least insecure email system possible and basically invites hackers to a data smorgasborg like Sony did by using outlook (I mean seriously, they can’t afford an IT guy who’s expertise extends beyond point-n-click?  Though frankly the most disappointing deployment of outlook is by MIT’s IT staff.  WTF?).

As lame as that is, email systems in general suffer from an easily remediated flaw: email is stored on the server in plain text which means that as soon as someone gets access to the email server, which is by necessity of function always globally network accessible, all historical mail is there for the taking.

Companies institute deletion policies where exposed correspondence is minimized by auto-deleting mail after a relatively short period, typically about as short as possible while still, more or less, enabling people to do their jobs.  This forced amnesia is a somewhat pathetic and destructive solution to what is otherwise an excellent historical resource: it is as useful to the employees as to hackers to have access to historical records and forced deletion is no more than self-mutilation to become a less attractive target.

It is trivial to create a much more secure environment with no meaningful loss of utility with just a few simple steps.

Proposal to Encrypt eMail at Rest:

I wrote in detail about this recently.  I realize it is a TLDR article, but as everyone’s wound up about Sony, a summary might serve as a lead-in for the more actively procrastinating. With a few very simple fixes to email clients (which could be implemented with a plug-in) and to email servers (which can be implemented via mail scripting like procmail or amavis), email servers can be genuinely secure against data theft.  These fixes don’t exist yet, but the two critical but trivial changes are:

Step One: Server Fix

  • Your mail server will have your public key on it (which is not a security risk) and use it to encrypt every message before delivering it to your mailbox if it didn’t come in already encrypted.

This means all the mail on the sever is encrypted as soon as it arrives and if someone hacks in, the store of messages is unreadable.  Maybe a clever hacker can install a program to exfiltrate incoming messages before they get encrypted, but doing this without being detected is very difficult and time consuming.  Grabbing an .ost file off some lame Windows server is trivial. I don’t mean to engage in victim blaming, but seriously, if you don’t want to get hacked, don’t go out wearing Microsoft.

Encrypting all mail on arrival is great security, but it also means that your inbox is encrypted and as current email clients decrypt your mail for viewing, but then “forget” the decrypted contents, encrypted messages are slower to view than unencrypted ones and, most crippling of all, you can’t search your encrypted mail.  This makes encrypted mail unusable, which is why nobody uses it after decades. This unusability is a tragic and pointless design flaw that originated to mitigate what was then, apparently, a sore spot with one of Phil’s friends who’s wife had read his correspondence with another woman and divorce ensued; protecting the contents of email from client-side snooping has ever since been perceived as critical.1I remember this anecdote from an early 1990’s version of PGP.  I may be mis-remembering it as the closest reference I can find is this FAQ:

It was a well-intentioned design constraint and has become a core canon of the GPG community, but is wrong-headed on multiple counts:

  1. An intimate partner is unlikely to need the contents of the messages to reach sufficient confidence in distrust: the presence of encrypted messages from a suspected paramour would be more than sufficient cause for a confrontation.
  2. It breaks far more frequent use such as business correspondence where operational efficiency is entirely predicated on content search which doesn’t work when the contents are encrypted.
  3. Most email compromises happen at the server, not at the client.
  4. Everyone seems to trust butt companies to keep their affairs private, much to the never-ending lulz of such companies.
  5. Substantive classes of client compromises, particularly targeted ones, capture keystrokes from the client, meaning if the legitimate user has access to the content of the messages, so too does the hacker, so the inconvenience of locally encrypted mail stores gains almost nothing.
  6. Server attacks are invisible to most users and most users can’t do anything about them.  Users, like Sony’s employees, are passive victims of sysadmin failures. Client security failures are the user’s own damn fault and the user can do something about them like encrypting the local storage of their device which protects their email and all their other sensitive and critical selfies, sexts, purchase records, and business correspondence at the same time.
  7. If you’re personally targeted at the client side, that some of your messages are encrypted provides very little additional security: the attacker will merely force you to reveal the keys.

Step Two: Client Fix

  • Your mail clients will decrypt your mail automatically and create local stores of unencrypted messages on your local devices.

If you’ve used GPG, you probably can’t access any mail you got more than a few days ago; it is dead to you because it is encrypted.  I’ve said before this makes it as useless as an ephemeral key encrypted chat but without the security of an ephemeral key in the event somebody is willing to force you to reveal your key and is interested enough to go through your encrypted data looking for something.  They’ll get it if they want it that bad, but you won’t be bothered.

But by storing mail decrypted locally and by decrypting mail as it is downloaded from the server, the user gets the benefit of “end-to-end encryption” without any of the hassles.

GPG-encrypted mail would work a lot more like an OTR encrypted chat.  You don’t get a message from OTR that reads “This chat message is encrypted, do you want to decrypt it?  Enter your password” every time you get a new chat, nor does the thread get re-encrypted as soon as you type something, requiring you to reenter your key to review any previous chat message.  That’d be idiotic.  But that’s what email does now.

Adoption Matters

These two simple changes would mean that server-side mail stores are secure, but just as easy to use and as accessible to clients as they are now.  Your local device security, as it is now, would be up to you.  You should encrypt your hard disk and use strong passwords because sooner or later your personal device will be lost or stolen and you don’t want all that stuff published all over the internet, whether it comes from your mail folder or your DCIM folder.

It doesn’t solve a targeted attack against your local device, but you’ll always be vulnerable to that and pretending that storing your encrypted email on your encrypted device in an encrypted form adds security is false security that has the unfortunate side effect of reducing usability and thus retarding adoption of real security.

If we did this, all of our email will be encrypted, which means there’s no additional hassle to getting mail that was encrypted with your GPG key by the sender (rather than on the server).  The way it works now, GPG is annoying enough to warrant asking people not to send encrypted mail unless they have to, which tags that mail as worth encrypting to anyone who cares.  By eliminating the disincentive, universally end-to-end encrypted email would become possible.

A few other minor enhancements that would help to really make end-to-end, universally encrypted email the norm include:

  • Update mail clients to prompt for key generation along with any new account (the only required option would be a password, which should be different from the server-log-in password since a hash of that has to be on the server and a hash crack of the account password would then permit decryption of the mail there, so UX programmers take note!)
  • Update address books, vcard, and LDAP servers so they expect a public key for each correspondent and complain if one isn’t provided or can’t be found.  An email address without a corresponding key should be flagged as problematic.
  • Corporate and hierarchical organizations should use a certificate authority-based key certification system, everyone else should use web-of-trust/perspectives style key verification, which can be easily automated to significantly reduce the risk of MitM attacks.

This is easy. It should have been done a long time ago.

 

Footnotes   [ + ]

1. I remember this anecdote from an early 1990’s version of PGP.  I may be mis-remembering it as the closest reference I can find is this FAQ:
Posted at 16:21:29 GMT-0700

Category: FreeBSDPrivacySecuritytechnology

All Your Virus Are Belong To Us

Thursday, August 11, 2011 

There’s an article in PLoS one (cited from /.) by some MIT Lincoln Lab researchers (Go Beavers!) published under the title “Broad-Spectrum Antiviral Therapeutics.” Typically the media reports of such articles vastly overstate the claims in the paper to make exciting headlines, but in this case the reports seem fair to modest.

If the approach they are describing, Double-stranded RNA (dsRNA) Activated Caspase Oligomerizer (DRACO), works as well as in vitro tests and mouse tests indicate so far, viral infections could be as easy to manage as bacterial infections have been since antibiotics. Basically DRACO is a compound that can be introduced into a mouse (and very likely a person) infected with a virus or prophylactically in advance of risk of viral infection. Any infected cells will die within 24 hours. DRACO remains active for about 8 days and has prophylactic value when administered up to 6 days in advance of infection.

Posted at 01:34:02 GMT-0700

Category: technology

What the Beep?

Thursday, November 20, 2008 

The movie What the bleep do we know is a pseudo-scientific exploration of using quantum mechanics to justify a human potential-like pseudo-religious concept. I have an undergraduate degree in physics from MIT, and so I recognized a lot of the arguments as absurd immediately, but I reached the limits of my depth, particularly on the history of QM in this argument. Most, but not all of the concepts could be easily refuted from an undergraduate understanding such as mine, some seem to require more depth. But the practicing physicists I reviewed my answers with seemed to think they had nothing useful to add to the discussion, in part I suspect out of the still-somewhat-in-vogue idea that the best way to confront anti-scientific ideas is to ignore them, viz the debate over intelligent design (which I think, personally, the flying spaghetti monster settled.)

Read more…

Posted at 16:20:28 GMT-0700

Category: filmsNegativereviewstechnology

Inspirational Books

Saturday, May 10, 2008 

New Scientist had a good article in the 10 April 08 issue about the formative books of the youth of 17 leading scientists. I found the most compelling Sean Carroll’s recommendation of One, Two, Three… Infinity.

It reminded me of a book that I remember reading in 4th grade that had a huge influence on my development: The Curve of Binding Energy.

I was already interested in nuclear physics and was motivated to read it. I think the book either inspired or reinforced many things that have become central parts of me; in particular an appreciation that understanding how things actually work gives one the ability to manipulate reality in a way that people who are less aware of how things work expect. Understanding things is lifetime power and (ever more importantly as I get older) a source of amusement. It illustrated how much fun being able to solve problems could be; the subversive (not merely empirical) value of knowledge.

I also learned how to make a mediocre nuclear weapon. Something that has made me a bit of smart ass ever since: if you know how to make the most fearsome weapon on earth it’s hard to be too intimidated. I wrote a paper in 9th grade describing how to build a weapon based on what I remembered from the book. About that time a student at Princeton got a lot of press for making a model nuclear bomb but using toothpaste instead of U-235, coincidently reinforcing my sense of significance.

After high school and after working as a programmer at a health physics company for a summer (and spending some formative time at a nuclear physics lab at U-Penn in grade school) I was one of a small number of nuclear engineering students on the fusion track at MIT. The Curve of Binding Energy inspired a love and appreciation of Nuclear Physics (and a sense of knowing something special) that only an act of congress could crush. When I was a freshman congress canceled funding for TARA, the tandem mirror experiment at MIT that about half the grad students I had just met were working on. While I dropped my FORTRAN efforts in support of FULIB and turned to robotics and eventually computers, I still ended up getting a degree in physics, course 8, not too far in practice or theory from course 20. And in no small part thanks to John McPhee and Ted Taylor.

Posted at 17:00:30 GMT-0700

Category: reviewstechnology

Ghost Highway

Friday, May 9, 2008 

This is a really cool post about some vestiges of a highway that was almost built through Boston and Cambridge. When I was in school I heard a rumor of this 695 project and that MIT, for obvious reasons opposed to having a freeway run through the middle of campus, did a few things along the way to deter construction:

  • Building 20 was declared a national historic landmark (where radar was invented during world war II) though it was originally intended as a temporary structure and in the time it took MIT to undo that declaration it became increasingly rickety. It is now the site of the new Stata center.
  • Parking structures (W45) were built along the path (it was said for the difficulty in demolishing them, thought that makes less sense now than it did as an undergrad)
  • The MIT nuclear reactor was built right in the path. My favorite lab experiment ever was testing neutron wave/particle duality in 8.13
  • A couple of fusion reactors were built along the same path, though these came later I think. I remember that test firings, especially of the tandem mirror confinement, caused some cool effects even in the control rooms.
Posted at 01:00:42 GMT-0700

Category: odduncategorized

From miracle of science

Thursday, December 13, 2007 

Excellent food, good drink and the grill is open until midnight.

IMG00209.jpg
It is my favorite destination on a cold night. Though the music is often too loud and the patrons occasionally are, and especially Thursday nights (motorbike night) it can be a bit crowded, it is probably the best late-night food in Cambridge and just happens to be on the way from MIT to our apartment.
Watching snow through the big windows is very pleasant.
Posted at 22:00:18 GMT-0700

Category: photorestaurantsreviewstravel

Mulberry Mail is Excellent

Monday, November 5, 2007 

about_window.jpg

Not too long ago I got on a plane with Thunderbird, having transitioned to IMAP, woke my laptop in flight and found my imap mail cache had gotten borked. Five useful work hours wasted. So in my searches for “Thunderbird Disconnected Problems” I found mention of this program called “Mulberry” that didn’t have these problems. I had looked at Mulberry years ago and it was cool, but fee and Eudora was then current and free so I didn’t try it out. I am so glad I found it again. Mulberry handles disconnected IMAP perfectly, has a fast powerful search, and is well-organized. I’ve had no problems and I’m using it to write this now on an 11 hour flight.

Mail Compose Window.jpg

At the outset, it is clear this is the vision of a single programmer not the work of committee and as such it is quirky and has some unique solutions. I wouldn’t say it is more quirky than Eudora but at first one will definitely spend time searching for functions and consulting the somewhat thin documentation. The basics are easy enough, but some advanced features are non-obvious.

Further, Mulberry is Correct. That is it is a fairly precise implementation of just about every mail standard, including some that are still emerging. Not surprising as the author, Cyrus Daboo, has also written some of the key server-side programs that run the web, including some of the really hard bits like the SASL authentication engine I use on my server and one of the most popular IMAP servers. If something doesn’t connect it is because the other program (the server or whatnot) is making a mistake. This is great as far as it goes, but some non-RFC compliant usages have become commonplace and sticking to the RFC can cause problems. An example I found quickly was that the Message-ID: header Mulberry generates is constructed as unique-message-string@[client.dotted.quad] (something like 3499345954.0253243@[192.168.15.101]). This is correct, but the standard is to use @my.smtpserver.com, and using a non-fully qualified extension (the dotted quad, not a valid domain name). The dotted quad looks spammy to spam filters, and in particular when the client is on NATed DHCP, the private IP (192.168.etc) it looks bad. So Mulberry sourced mail might get a slightly higher SpamAssassin score (it is not a fatal test, but it can’t help) and my procmail spam filter looks for disagreement as a test so I can’t email myself notes to my own account – I have to send them to my MIT account.

Cyrus says he is going to fix this.

Which brings me to another wonderful feature of Mulberry: it has great support from the mailing list and author. You won’t go more than 24 hours without an answer to the most technical questions. And as it is in active development, any bugs are going to be fixed. Compare this to a MS product where that is not going to happen.

Mulberry’s mail interface took me a little getting used to. For example the mailbox list is organized a little differently and single clicks open new mailboxes in the next pane and the message in the pane below it, but this behavior can all be customized in the Window->Options… menu including, critically for me: do not mark previewed message as read.

Mail_window.jpg

Another good trick is automatically moving read messages out of the inbox. I haven’t been entirely satisfied with the sort options: the unread messages always seem to sort in the reverse order of what I want, putting the messages I need at the interface between the read and unread messages, rather than at the top or bottom. But the auto move mechanism works well for my inbox and lets me sort the inbox by date, it being all unread mail, the read mail automatically being moved to an archive.

I spent some time figuring out two wonderful features: Mulberry (along with GCalDaemon) supports off-line calendar sync with Google Calendar (YAY! I can answer email about my calendar while I’m on a plane and even schedule a meeting!) and I can sync to ScheduleWorld’s LDAP server (which syncs to my phone address book and my work Outlook address book). And since I use ScheduleWorld to sync my work Outlook calendar to Google calendar, I’ve got all my important information at hand, even in the air. I wrote up the steps to make these tricks work on the Mulberry Wiki.

calendar.jpg

Even the search function is fast – entirely tolerable though perhaps not quite real-time like Google Desktop, but then again you don’t need to open inane stupid brain dead IE to perform the search like Google Desktop forces you to.

Mulberry is great. It works really well, it is stable, it works offline (disconnected), it syncs right, it has a very good offline calendar client, IMAP support seems flawless, it has great keyboard shortcuts, and fast advanced search. It does everything I need and it is now free, open source, and available for Windows, Linux, and Mac OSX.

Posted at 00:00:20 GMT-0700

Category: Positivereviewstechnology