Thursday, August 11, 2011

Keeping Private Data out of Governments' Hands

Whenever a company says "we value your privacy" or "we will never pass your details onto third parties", there is always the implied, and sometimes expressly stated exception for "government and regulatory authorities as required by law" as has been revealed recently with regard to cloud service providers.

When companies or government agencies ask personal questions, if they really want truthful responses, there should be some line in the sand that sets a non-negotiable barrier against compulsion by the state to reveal the personal information.

I'm on this train of thought due to the recent census in Australia. Quite a lot of sensitive questions are on there, from inquiries about salary and housework to religion and race. The last question is about the ABS being able to keep the data in a format that links my answers to the person so that, after 99 years, they can release it, well after its sensitivity should have ceased. I allowed them to, because I really like that kind of historical data being available, however despite any claims about them keeping the link between me and the answers secret, if the police come in with a warrant, and most likely even if they just request the data from a police email address, the data will be turned over. So what is the motivation for the general public to either answer honestly, or allow the linkage between person and answers to be kept?

Well, I'm not going to solve this problem, especially in Australia where there is no constitutional right to privacy, meaning the government can always pass a law to get access to any of our data.

Instead, I'd like to sidestep the problem, at least for some system types. The idea is to allow organisations to give up our data, because it makes no sense to anybody else.

Let's look at webmail.

Any decent webmail system encrypts data between the client (like Hotmail or Gmail in the browser), and the server (like the Hotmail and Gmail servers at Microsoft or Google). So nobody listening to all the data flying past over the wire between the client and the server is able to eavesdrop. That's great, but that's only part of the problem.

The main issue is that the data is stored in plain text on the email servers. To solve this, the data that is stored on the email servers themselves needs to be encrypted so that even the webmail providers cannot read it. This can be done by using good old public key cryptography. Anyone familiar with encryption is probably now saying that the emails have to be unencrypted at some point on the server, though that's not strictly true. The encryption and decryption of emails could all happen on the client. Similar things have been done in the past with programs like PGP, but they have never been transparently easy for users to use.

What I propose is that major webmail providers build this right into the sites. Each email address would be issued a private key (that is used for decrypting emails sent to the user), which would be stored on the server but first encrypted with a symmetric algorithm. The user, on logging in, would download their private key and decrypt it locally by entering another password, which is never submitted back to the server. The user's public key (that is used by others to encrypt emails to be sent to the user) would be stored on some trusted server, such as the webmail server itself, or some other kind of centralised or decentralised key system.

Whenever an email is received from another user, the private key is used to decrypt it on the client so the user can read it. If the webmail providers still want to target advertising based on content, there could be some client-side logic for choosing advertising categories.

Whenever the user wants to send an email, the client would fetch the public key of each recipient, which would then be used to encrypt a copy of the email just for them.

The main drawback of this system would be danger of losing a password. If that is lost, then the private key is lost, which would mean that any received emails would be effectively lost. There are probably several mitigations against this, but the main one that comes to mind is keeping the password with a lawyer, possibly in a will, which should be safe from government authorities. I'm pretty sure that lawyers can't be compelled to rat out their clients under any circumstances. I hope I'm not wrong there.

If a private key were compromised, due to a compromised password, a new set of public/private keys could be chosen, and the old private key could be used to decrypt all the existing emails, using the new public key to re-encrypt them for storage on the server.

So in summary, we just can't trust that anything we do will be beyond the prying of various governments. To keep them out of our stuff, and to make it easier on the service providers, we can ensure that our data is useless to anyone but ourselves. With webmail, this seems to be feasible by making use of some industry standard encryption techniques, but applying them on the client instead of on the server so that data is secure all the way from client to client.

Like any kind of back-of-the-envelope software spec, this idea is probably flawed in several ways, so let me know what you think about it, or how it could be improved. If there is any merit in it, I'd love to see it implemented by enough large email providers that it could become a standard. Also like any back-of-the-envelope idea like this, it's probably already been done before, so if you've seen this idea, let me know where.

No comments:

Post a Comment