A very interesting post from Ben Adida introduced here by Mitchell Baker (Chairperson of the Mozilla Foundation) explains some points about cryptography and its useability to protect our private data.
Sure, cryptography is not magic and the Key Management is a real problem when thinking about cryptography in a widely used system.
But only if you consider services the way they are designed today.
Ben Adiba takes some examples, lets review them.
– Sony needs to be able to charge your credit card, which requires your billing address. They probably need to do that whether or not you’re online, since you’re not likely to appreciate being involved in your monthly renewal, each and every month.
Do you remember the time when to charge someone for a service you had to send him a bill ? This had two purpose : let her accept the service and request for the payment. It was a well understood and accepted process. Now, because we have computers, we accept the automated charging and the difficult opt-out process. It’s not a faith with computers. We are able to design computerized processes that do not eliminate the need for the service provider to request acceptance. And in the new design, guess what? Sony does not need to store your billing information in their datacenters. Information needed would be provided by the user software in a transactional encrypted packet built with data stored in the user environment (maybe a memory thumb or her phone…). And yes, I’d accept to be involved in my monthly renewal. At least, I would be pleased to have the choice.
– Meanwhile, Dropbox wants to give you access to your files everywhere. Maybe they could keep your files encrypted on their servers, with encryption keys stored only on your desktop machine? Yes… until you want to access your files over the Web using a friend’s computer.
Why the key should have to be stored somewhere else than on my, let’s say, phone? Nowadays I carry it always with me and it can store a lot of keys, protected, if I’m cautious. Useable with any computer I need. Provided that the client part of the service is designed well enough to avoid storing a copy of things into the computer disk.
– And what if you want to share a file with a friend while they’re not online? Somehow you have to send them the decryption key.
Well, I just have to be able to request the service to built a version of my file encrypted with the public key of my friend. This has another benefit: I am now able to revoke permissions or grant them for a limited amount of time without changing my personnal encryption key. Of course, to be able to design a good user experience, we need to automate a lot of things like knowing precisely what information is needed by the service and so, we need standards. Technical standards are not enough, we need semantic models of the dialog between user, client software and service software.
Ben has something (not complete) about that:
– Maybe you’re thinking you can use public-key encryption, where each user has a keypair, publishes the public encryption key, and keeps secret the private decryption key? Now we’re back to “you can’t get your data back” if the user loses their private key.
It’s true only if I consider that my data reference is the service provider storage or if I avoid any backups. Even without encryption what garantee have I that my data won’t be lost by the service provider ? Leaking data is not the only problem with the cloud. I still need backups.
– The more useful the product, the closer the decryption key has to be to the encrypted data.
There are solutions to this kind of problems. We have technologies. And we have to use them right.
Technology is not a solution. Using technology is.