Sasha Romijn

But where is the decryption key?

Encrypting sensitive data is usually a good practice. You’ll see many organisations, like Dropbox, advertise this as part of their offering:

Or Apple iCloud:

This means that your data is protected from unauthorized access … when it is stored in the cloud. iCloud uses a minimum of 128-bit AES encryption …

Using strong AES for this situation is a good choice. There are some other technical details to be considered, like the block cipher mode. However, a more fundamental question is missing. The technology used, be it AES or DES, is only half the story when we wonder about the security of data. The other important question is: where is the decryption key?

The nature of encryption of data means there is always someone or something holding the decryption key. If nobody has the key, nobody can decrypt it. And to someone with the decryption key, the encryption method is largely irrelevant, as with the key, the data can be effortlessly decrypted.

Where are the iCloud and Dropbox decryption keys?

Given that Dropbox and iCloud use encryption for their data, who has the decryption key? This is not an easy question to answer with certainty, but I am sure about one thing: it’s not me, or at least not only me.

How can I be so sure that I’m not the (only) holder of the key? Because decryption keys have a particular property: they can never be reset or recovered. If the key is lost, the data is lost. There is no way around this.

Both Dropbox and iCloud support password resets. Therefore, my password is not the decryption key (and neither is the key derived from my password), because then it could not be reset. In other words, because I can forget all my Dropbox and iCloud secrets and reset all of them, none of these secrets form part of the decryption key. My password is just a record in some database.

My best guess is that Apple and Dropbox hold the keys, and are probably the only one with the key. This means that, even though it might be stored with well configured AES encryption, they can access my data at any time, and do anything they choose, without my active involvement being required.

Note that this logic is only certain in one direction: because all secrets I have can be reset, I know for sure I do not have the key. However, if Apple or Dropbox would not allow me to reset them, that would not guarantee they form part of the key.

Why we don’t always give keys to the users

It’s easy to complain about Apple and Dropbox advertising encryption, while they are coincidentally also the one holding the key. We could argue that they should be using the user’s password as the key, or at least part of the key. That’s a secret the user needs to remember anyways.

However, there is a reason both have a password reset mechanism in the first place: it’s because users forget passwords. As soon as the password becomes part of the key, there is no such thing as password reset anymore, because you can not reset decryption keys. If the user loses their password, they lose all their data. And as much as we can argue that it helps their data stay secure, it might upset them a little.

For Apple’s FileVault, the full-disk encryption feature of Mac OS X, the user’s password is part of the key. However, this is an explicitly enabled feature by the user, and they are also given a recovery key, which can also be used to decrypt the actual disk encryption key.

Between convenience and security

And so it comes down to the usual balance between convenience and security. In the case of Dropbox or iCloud, we expect that their systems are designed so the encrypted data is not available to unauthorised parties. However, there’s a much larger chance that my laptop is stolen at some point, with the encrypted copy of my data. So it definitely makes sense to be much stricter with key management in FileVault than with Dropbox.

For one client, at their request, I store the database on their server in an encrypted volume. So what do we do with the key? Storing it on the server makes the encrypted volume rather pointless, but not storing it on the server means that after a reboot, the key must be manually entered. In the meantime, the website is unavailable. In this case, the client preferred the safer option, but this is rare. Also, while the database is being used, there’s another copy of the encryption key in memory. So this does not add any protection when the server is compromised while it is running, because at that moment the server remembered it’s own decryption key. FileVault has the same limitation.

iCloud Keychain

Given that iCloud supports a password reset, my Keynote files are most certainly not encrypted with a key I am managing.

However, iCloud Keychain seems to be a little different. You can only authorise a new device for your shared Keychain in two methods:

  • Provide a security code and pass validation through mobile phone.
  • Authorise the new device from an existing device.

Apple also stresses that if you lose the security code, there is no recovery. All this suggests that the iCloud Keychain is encrypted with keys that are only available on existing authorised devices, or can be derived with the security code. That matches Apple’s claim that loss of both results in full loss of the Keychain. Of course, my previous disclaimer applies: there is no way for me to prove that this is the case, or that Apple does not secretly keep another copy of the key themselves.

What we can learn

If you are the user of a system that claims to use encryption, and you can reset all your credentials without losing access to the data, remember that you are not holding the decryption key. Although the data may be stored in encrypted form, the same organisation typically also has the decryption key in this scenario, meaning they have full access to the data without your involvement. How much security the encryption adds depends on the exact setup and the attack scenarios. I really wish companies with document their key management process more often, so that I can make better informed decisions about my data.

If you are designing a system that involves encrypted data storage, don’t just think about the proper technology, but also at how you will manage the key. For someone with access to the key, encryption is no longer a barrier. Storing the decryption key right next to the encrypted copy of the data adds very little security. On the other hand, remember that decryption keys can not be recovered or reset: loss of the key results in the permanent loss of all the data.

Further reading

From this blog, you may also like An appeal for security for the ordinary developer and A basic guide to when and how to deploy HTTPS

Applied Crypto Hardening is a very practical and readable document on how to configure cryptography-related settings, like ciphers. It’s still in draft, but very promising. I particularly like how it offers both directly usable config snippets, but also extensive explanation of rationale behind the choices.