[Cryptography] "Hey! You! Get off of the cloud!"

Perry E. Metzger perry at piermont.com
Sun Aug 25 17:41:30 EDT 2013


[Second in a series of several posts about what is needed to make all
Internet messaging go encrypted. Again, if the contents of this post
sound unoriginal, that's because it isn't original thinking. It does
strike me as part of a larger puzzle, however, and some people may not
be familiar with all the arguments.]

I have a lot of friends who work in offices where the sysadmins are,
somewhat reasonably, hostile to the idea of their users installing or
configuring applications on their company machines.

Users in such offices have gotten quite used to using their browsers
to access web mail and chat systems -- de facto GMail and GTalk -- as
well as things like facebook messaging etc. This, and one's smart
phone, is many people's interface to the world outside work. Companies
still let you do https: to Google even if they won't let you install a
chat client locally, so that's what everyone does. (Well, lots of
people do http: but never mind that).

In any new world where everyone's messages are end to end secure and
probably transiting mix networks to prevent traffic analysis, such
users are going to have to be accommodated.

That means that their end-to-end encryption endpoint is going to have
to be on the web server they're talking to. Keys are going to have to
be on that machine, because you're not going to be able to install
software to use them on your work machine, and even if you could do
everything in javascript, you probably have relatively limited trust
for the local box and certainly not enough to leave long lived high
entropy keys on it.

Now, it is relatively easy for such a user to check that the cert for
their web mail provider doesn't come from a Bluecoat box -- no one
does, but it is kind of feasible. It is relatively difficult for
someone to bug your local machine -- hardly impossible, but not
something that is supposed to happen without the local system
administrator doing something to your machine or a remote bad guy
using malware.

On the other hand, a company that's hosting your email and chats
almost certainly will hand over encryption keys you store with them if
the government forces them to, and it is absolutely impossible to know
if this has happened. You just have to assume it has in your threat
model.

It strikes me that the only real solution to handle this for people to
replace their "router" (really NAT) boxes on their cable modems with
tiny cheap servers that host their email and chats and such. Luckily,
the cost of such things has gotten very low -- a Raspberry Pi class
machine with a USB thumb drive larger than a GMail quota costs less
than a carton of cigarettes or the cheapest monthly Cable TV bill, and
such devices will only get cheaper and cheaper in the near term. It is
also feasible to make such machines insanely reliable, especially if
there's no mechanical disk involved.

(I'm of course not the first person by far to make this observation --
the FreedomBox people, among others, have been saying it for several
years. The idea is far from original.)

Sure, a bad guy can of course break into your apartment, but that's a
lot more expensive than simply getting Google or Facebook to hand over
all your communications, and hard to do on a "vacuum it all" basis.

With appropriate software and a friendly UI, one's Email, IM, remote
file storage and similar needs could be easily managed on such a
device with no greater difficulty than one faces in using GMail,
GTalk, Dropbox etc. That's "just" a question of keeping the user
interface easy.

Note that, however, this is not merely a requirement and stumbling
block -- it is also an opportunity. If everyone has such a box at
home, they've got a server, and the kinds of protocols they can
participate in to enhance their own security can be a lot more
sophisticated.

Some additional notes:

a) Certainly, the security of a home server device is no greater than
that of the underlying software -- mass surveillance through malware
is possible. However, I presume that even there, doing so _en masse_
is dangerous to an attacker, since it leaves lots of traces. Also,
just as attackers have been improving their game, there are methods
that defenders can employ to improve security on such devices with
time -- malware is not a foregone conclusion forever, and is in some
sense a higher quality problem.

b) I'm aware that many ISPs prohibit the use of "servers" on their
home customer's networks, but loads of people ignore this. They also
used to prohibit (de facto) sharing connections with lots of machines,
and the arrival of commercial NAT boxes named "routers" made that
policy fade away as though by magic. I think they mostly don't want to
have to re-engineer their networks overnight, but in practice I doubt
a device hosting your email and some baby pictures is going to alter
traffic patterns enough to cause that anyway.

c) Even if people are happy using their smart phone to read their home
mail instead of their desktop at work, and could be persuaded to run
special software on their phone to do so, it would be of benefit for
them to have their own server, on their own physical premises,
requiring an actual physical entry into their premises to interfere
with their security.

d) It is certainly the work of a large and sophisticated staff to keep
a service like Dropbox or GTalk up and running, but for the most part,
there's not much need for maintenance when there's only a single user
or a handful, and what is needed can be automated. Encrypted backups
are easily traded with friends given the right UI -- it could be as
simple as entering in the friend's email address and then later
clicking a box in the web interface for "accept", especially if easy
key management is around. (I'm aware that the spam problem now
requires a huge staff to deal with, but there are potential solutions
there as well -- for example, one could just not do SMTP based email
at home. More on that in another message at some point.)

-- 
Perry E. Metzger		perry at piermont.com


More information about the cryptography mailing list