Guide to Who Holds The Decryption Keys for 16 Cloud and Backup Services

As many people are now learning, simply knowing that something is encrypted is not enough. Encryption, like security, exists on a continuum that runs between safety and convenience, and it's important to know where on that continuum your data – and cloud providers – lie. The largest factor in determining the relative security of your encrypted data is knowing who has access to the decryption keys (i.e. who is able to decrypt it... and when?)

Below are some services commonly-used by Apple users along with who holds those keys:

Apple Services

iCloud Backups - Stored on Apple's servers, encrypted with Apple's keys.iTunes Backups - Stored on your computer, encrypted with your keys if you choose to do so (but you then might also store those keys in your system keychain).iMessage - Encrypted with your keys while sending (but backups inherit the key access of the backup method).iCloud Mail - Stored on Apple's servers, encrypted on Apple's servers with Apple's keys. End-to-end encrypted only if you use optional S/MIME or PGP.Contacts & Calendars (synced to iCloud) - Stored on Apple's servers, encrypted with Apple's keys.

Third-Party Services

Gmail - Stored on Google's servers, encrypted with Google's keys.Google Calendar, Contacts, Drive, Docs, Sheets & Slides - Stored on Google's servers, encrypted with Google's keysDropbox - Stored on Dropbox's servers, encrypted with Dropbox's keys.CrashPlan - Three options if storing on Crashplan's servers: CrashPlan's keys, a key of your own that CrashPlan generates, or a key of your own that you generate.Backblaze - Two options: Backblaze's key or one of your own that you generate. All data stored on BackBlaze's servers.

I've always maintained that data encrypted with providers' keys is "secure until a subpoena." That is, if your cloud provider has the keys they are able to divulge your data if (legally) compelled to do so. On the surface it seems like no one would ever want this, but think about how much convience you enjoy when you allow your providers to hold the decryption keys.

Ever access your iCloud calendar on the web? How about when you restore your iPhone from an iCloud backup? All you do is authenticate with your Apple ID and, magically, your data is decrypted and made available to you. Or how about when you login to Dropbox from a new device and are able to see all your data? Apple and Dropbox encrypt all that data on their servers, but because they have the decryption keys all you have to do is login to your account and you're granted access.

Some services, like CrashPlan or Backblaze, give you a choice as to whose encryption keys you use. If you choose to use the providers' keys in those cases, accessing your data is just like we described above. But if you provide your own key then there's an extra step: after you login to your account you have to provide a long, likely-complex key to access your data. And you have to decide both where you want to store that key and if you even want to provide it over the web to your backup service.

Again, it comes back to where you want to exist on this continuum. If you don't want anyone to have access to your data, don't store it anywhere. But that also means YOU won't have access to your data. If you want access but want to ensure that other people likely will not, then you have to encrypt your data with a key that no one else has and store it in a place you trust, making it difficult — and inconvenient – for others to access your data. But what's inconvenient for them is equally inconvenient for you.

So, as I see it, my choice b/w convenience & security in using iCloud services probably comes down to this:

- as long as the DOJ/FBI don’t have any court orders demanding my info from Apple, the only parties who realistically will have access to all my data there are the NSA/CIA via clandestine hacks or NSA letters, because their databases are probably ≈unhackable, so I could comfortably use, iCloud Backups, iTunes Backups, iMessage, Mail, Contacts & Calendars.

- But, if i think the DOJ/FBI might have any interest in me, since whatever secret info the DOJ/FBI may keep anywhere will likely always hackable by Chinese, Russian, Azerbijani, Nigerian, Macaoian, all the world’s various crime syndicates & anyone dreaming of geek glory or marketable secrets at DEF CON, then I’d need to avoid using not iCloud Backups, Contacts & Calendars, & only use iMessage, iTunes backups stored on my computer & encrypted only with my keys, & Mail with S/MIME or PGP only.

Alternatives in file storage (e.g., iCloud and Dropbox) is to create an encrypted sparse bundle and mount that as necessary. For tools like Dropbox it defeats the sharing aspects, but if you’re using it for a quick-and-dirty backup of some critical files, it works fine.

PDFs can be encrypted and password protected (Note: Password protecting is not enough since it really does not encrypt the document).

Finally, one popular service you left is Evernote. There’s a lot to consider with Evernote, but the data is not encrypted. You can encrypt data individually (or store an encrypted PDF), If you encrypt the data, it uses symmetrical encryption (I think AES 256) and uses your passcode. You have to enter your passcode. Evernote does not store it. That means if you lose your passcode, you’re going to lose the encrypted data.

I’ve been trying to devise a security scheme that encrypts all data client-side but then encrypts the key with the password and sends that to the server too so it is easy to connect new devices. The client has to also provide metadata to the server in unencrypted form to support various services (like give me all the recently-modified items). While my system isn’t completely secure yet (a common first rule of making a new security scheme is “don’t”), I think companies could put more effort into technology so that not even the service provider can read your data (without hacking your password).

I don’t think there is enough motivation for this, because it takes a lot of effort and makes it harder to add features to the product. So upper management would probably either nix it or put it perpetually on the sideline.