Protection mail at rest

[Steven M. Bellovin]

On Fri, 30 May 2008 15:04:34 -0400 (EDT)
"Leichter, Jerry" <leichter_jerrold at emc.com> wrote:

> At one time, mail delivery was done to the end-user's system, and all
> mail was stored there.  These days, most people find it convenient to
> leave their mail on a IMAP server:  It can be accessed from anywhere,
> it can be on a system kept under controlled conditions (unlike a
> laptop), and so on.  In fact, most people these days - even the
> technically savvy - not only leave their mail on an IMAP server,
> but let some provider deal with the headaches of maintaining that
> server.
> 
> So, most people's mail spends most of its life sitting on a disk
> owned, managed, and controlled by some third party, whose
> responsibilities, not to mention abilities, for keeping that stuff
> secure are unclear to say the least.  On top of that, the legal
> protections for data held by a third party are limited.
> 
> We have mechanisms for providing end-to-end encryption of messages.
> Messages sent using, say, S/MIME are encrypted on the IMAP server
> just as they are out on the net.  But this only helps for mail
> exchanged between correspondents who both choose to use it.
> 
> Suppose I ask for a simpler thing:  That my mail, as stored in my
> IMAP server, spends "most of its life" encrypted, inaccessible even
> to whoever has access to the physical media on which the server
> stores its mail.
> 
> Now, this is a funny goal.  If mail arrives unencrypted, anyone with
> access to the data stream can copy it and do what they like.  It will
> inevitably be buffered, even likely stored on a disk, in the raw,
> unencrypted form.  We explicitly leave dealing with this out of the
> equation - only end-to-end encryption can deal with it.
> 
> Here are two ways of implementation something in this direction:
> 
>  	1.  Client only.  The client, whenever it sees a new message,
>  		(a) downloads it; (b) encrypts it using a secret key;
>  		(c) stores the encrypted version back on the server;
>  		(d) deletes the unencrypted version.  The client can
>  		put the encrypted messages in a different folder, or
>  		it can mark them with a header line.
> 
>  	2.  Server-assisted.  The client gives the server its public
>  		key.  When a message arrives at the server, the
>  		server (a) generates a "session" key; (b) encrypts
>  		the message using the session key; (c) encrypts
>  		the session key with the client's public key;
>  		(d) adds a header containing the encrypted session
>  		key to the encrypted message; (e) stores the
>  		encrypted message.  The necessary work for
>  		the client is obvious.
> 
> In each case, one would probably chose some headers to encrypt
> separately - e.g., the subject - so that one could more easily pull
> them out without decrypting the whole message.
> 
> Obviously, approach 2 greatly decreases the time that messages may
> hang around unencrypted; but approach 1 can be implemented without
> any cooperation from the IMAP provider, which allows it to be rolled
> out even for those who use the large providers without having Google
> and Hotmail and Yahoo! buy into it.
> 
There's an option 2b that might be even more practical: an S/MIME or
PGP/MIME forwarder.  That is, have a trusted party receive your mail,
but rather than forwarding it intact encrypt it and then forward it to
your favorite IMAP provider.



		--Steve Bellovin, http://www.cs.columbia.edu/~smb

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com