Improving (i)Cloud security.

Most of the popular cloud systems are insecure. The recent hack of celebrity accounts, and the subsequent release of nude pictures clearly demonstrate this once again. The problem is that most cloud systems rely on passwords to restrict access to an account. The reason is usability: it allows the account to be accessed from any device. To make this really usable, an easy to remember password needs to be selected. Unfortunately, such passwords can be guessed by brute forced. Of course this can be prevented, for example by restricting the number of times one is allowed to enter a wrong password. But then account recovery strategies, that allow legitimate users to regain access to their account if they forget their password, provide a second avenue of attack.

In other words: user-friendliness kills security. Can this be fixed somehow?

I recently came across an interesting idea on Twitter. (I am pretty sure that it was Matt Green suggesting it, but the closest I could find was this, which is an entirely different idea.) In the case of iCloud, which is typically accessed from a single iPhone or iPad, one could use strong cryptography to bind the iCloud account to a specific device. In fact, an approach similar to iMessage appears to be appropriate.

Whenever a user decides to activate iCloud for his iPhone, the phone generates a private key and associated public key, and sends the public key to iCloud. This public key is stored in the account information associated with the account. To access the account, you need the corresponding private key. This key is securely stored in the phone, and whenever the phone needs access it transparently authenticates to iCloud using this key. As the key never leaves the phone, an attacker can only access the account if he has physical access to the phone, or if he targets the specific phone with malware to maliciously obtain the key. Access thus requires a targeted attack, which makes it much more secure.

Some people share their phone with other people. The phone may contain games for the kids to play. Or a colleague forgot his phone and urgently needs to make a call. In such circumstances, it makes sense to lock the key with a short, easy to remember and easy to type access code. Typically a 4 digit PIN will do. Of course only a limited number of failed attempts to enter the code are allowed.

For additional security, an additional pair of keys can be used to encrypt the data before sending and storing it in the cloud. In this case you would typically use a hybrid approach where the data is first encrypted using a symmetric key (because this is faster), after which the symmetric key is encrypted against the public key encryption key. This encrypted key is stored with the data in the cloud. Again, the corresponding private key is needed to recover the symmetric encryption key to decrypt the data.

If a user decides he wants to access his iCloud account from another device, say an iPad, he first has to pair the iPad with the account as follows. Generate a key pair on the iPad, and request access to the iCloud account. iCloud contacts the iPhone currently associated with the account, asking whether it is OK to allow the iPad access. It should display some meaningful information on the display of both devices to allow the user to verify that the correct device is being paired to his account. If the user agrees, the new public key is added to the account information as an additional key that has access.

Finally, for web based access, one could revert back to password based authentication, with a similar pairing procedure as sketched above. It is important to note that this step is optional: by default, if you only access your cloud from a mobile device, authentication

Note that a similar scheme could also be used to drastically improve the security of the iTunes and app store accounts. And of course it applies to other cloud systems similar to iCloud as well.