The collision of cloud and cryptography

We have an impending collision: cryptography and cloud computing.

The big problem with most cryptographic systems is the "key problem". Most systems use a "symmetric key", in which the same key is used to encode and decode the message. This presents a problem: for me to send you an encoded message, I must first send you the key. But anyone who has the key can decode the message, so how to send you -- confidentially -- the key? I cannot send it as a message, because either it is encrypted or it is not. If I send the key encrypted, then you cannot decrypt it, because you need the key! If I send it unencrypted, then anyone who sees the message (including intermediate e-mail servers) have access to the key and can decrypt any successive, encrypted message.

This problem was solved (or so we thought) by asymmetric keys. With asymmetric keys, two keys are used: one to encrypt and a different one to decrypt. Technically, one key is the "private key" and the second is the "public key". The two work together, and while either can be used to encrypt (with the other used to decrypt), the two are a matched set. Only the other key in the pair can decrypt a message encrypted with the other. The private key is kept private and the public key is published to the world.

The asymmetric key approach allows for flexibility. If we both have a pair of keys, I can use your public key (which is readily available, since it is public) and only you can decrypt the message. Thus, I know only you can read the message. You can send me a confidential message by using my public key; only I can decrypt the message.

Tangentially, I can encrypt the message with my private key, and when you decrypt it with my public key, you know that the message is from me. No one else can encrypt a message that is decryptable with my public key, because they do not have the private key.

The nature of the private key is the problem with cloud computing. The cryptography system relies on a private key, a number that you keep, well, private. It remains in your domain and you must not reveal it to anyone. But cloud computing pulls computing away from a person and into "the cloud", into a system of provisioned servers that are outside of my domain.

Let's look at a simpler case: e-mail. The same concepts apply to cloud systems.

If I want to encrypt my e-mail messages, the process is fairly easy. I can program my private key into my e-mail client, and the e-mail client will use that key to encrypt all outbound messages. (Sophisticated e-mail clients allow me to enable and disable encryption on each message I send.) This all works, as long as the e-mail client is on my equipment -- remember, one cannot give the private key to anyone else.

To use encryption with a web-based e-mail system, I would have to give the e-mail system my private key. (I have to use the private key for encryption, since the public key -- the other key -- must be used for decryption. My recipients cannot have my private key, since it must remain private.) But if I give my private key to the e-mail system (whether it be GMail, Hotmail, or Yahoo! mail) then someone other than me has my private key! This is unacceptable to the encryption strategy.

For web-based e-mail, the best I can do is 1) compose the e-mail, 2) copy it to my local system, 3) encrypt the message on my local system, and 4) paste the encrypted message into the e-mail client. This allows my to keep my private key in my local domain and send encrypted messages.

You can see that this solution is a kludge, and while it works for e-mail it fails miserably for cloud applications. (Cloud apps do not always allow for the cutting and pasting of data at the appropriate points in processing.)

With the current technology of cryptography, there is no way around this dilemma. I must keep my private keys private, and use them on my equipment. (That is, equipment that is completely under my control.) To use encryption with cloud applications, I need a a local processor, a mechanism to ship data to my local processor, the ability to encrypt the data, and a means to send the encrypted data back to the cloud application.

I don't see anyone working on any of these mechanisms. Sadly, the cloud was designed with no thought for personal encryption. (Cloud apps can encrypt data between themselves, but that the is application encrypting the data with whatever means -- if any -- and only good for other cloud applications. It does not handle encryption at the user level.)

Encryption (or more specifically, the "public key infrastructure" or PKI) is useful for sending confidential messages (messages that only the recipient can read) and signed messages (messages that anyone can read but are guaranteed to be from me). We need these abilities, especially for commerce. Yet cloud computing works against these goals. Cloud computing, with its "move everything to someone else's servers" is at odds with the "private key on my processor" requirement of PKI.

And that is the conflict between cloud computing and encryption.