Private I: Lock your cloud backups away with an encryption key
It’s generally easier to keep safe the files we have under our control, on our internal and external drives, than those that waft far away from us on cloud-storage backup systems. Different backup services handle how they send data for storage and how they encrypt it once it arrives.
A quick overview of how cloud-storage systems work, regardless of the company. Client software running on your Mac finds new files in specified folders or files that have updated modification times since the last scan. Files are analyzed into pieces against which the software calculates a sort of shorthand or signature. This signature is compared against what’s stored in the cloud. If it matches, nothing happens—this is how these services conserve bandwidth.
But if it doesn’t match or there’s no stored record for that chunk, the software opens a connection to transmit the actual data, typically compressed and always in a secure client-to-server session. The data is then stored with redundancy on the service’s drives, sometimes across geographically dispersed data centers.
So far so good. But the issue that we users should be informed about is at which points our data can be viewed by the operators of the services—and, by extension, anyone who might crack the service, or government agencies that could compel the operator to turn over information.
How encryption is implemented for backup services
Encryption can be applied in four places:
On the chunks of data compiled on your computer before they are sent. Before data is ever sent, if encryption is applied, it means that it’s less vulnerable or potentially not practically vulnerable in transit.
To the connection between your computer and the storage service’s servers. Private data in transit should be routinely encrypted in nearly all cases today, and absolutely when files are being backed up or restored.
To the data stored on the backup company’s systems. Obviously, any archival data shouldn’t be stored in a way that a malicious party, gaining access, can simply read or download it. Companies have various policies (and often market them as features) about how they control access to their facilities and encryption keys.
To one or more encryption keys that protect data. All encrypted data requires a key, a run of numbers of sufficient length and randomness fed into an algorithm to transform the original data into something that can’t be recovered without the key. But that key needs to be protected, too, usually by something simpler, like a passphrase or short password, that should be sufficiently resistant to attack as well.
Now, you can recombine those four elements into three potential tiers of protection from strongest to least strong.
Service stores your key. Most commonly, your encryption key is stored in the client software and at the service, secured there by whatever method the company decides upon. All stored data is encrypted with your unique key. Your account password unlocks access at the website. Web access or access via mobile software uses an account password. If forgotten, your password can be reset, and you can regain access to stored data.
You control your key. Some backup services let you generate or will generate for you an encryption key that only you ever see or to which nobody else has access. This key is used on your computer to encrypt data, and those encrypted hunks are stored on the server without the service having any ability to decipher them. An escrow version of the key may be secured with a password and stored at the service, but without your password, that escrow is unrecoverable to the service or outside parties. Lose the password to the key or the raw key, depending on the setup, and your archived data is gone forever.
This level of security provides the greatest resistance from others gaining access to archived data unless you use the service’s website, at which point the key will at least momentarily be stored in memory during decryption operations and thus (however unlikely) be vulnerable to capture.
You don’t own any keys. For Dropbox and other similar sync services, data is only encrypted in transit and in storage, using keys and other encryption material controlled by the service, and which are typically not unique to your data. Your password unlocks access, but your data is decrypted briefly between transmission and storage. If you forget your password, it can be reset, and you don’t lose access to any stored data.
How the backup services handle key storage
I looked at several popular backup services and Dropbox, which offers sync with cloud storage, but often treated as a first-resort or last-resort backup, along these lines. There are dozens of cloud-storage archival services, though, and you can apply the same standards to each.
CrashPlan offers the most flexibility of any backup service. You can opt for a simple password protection, where it’s possible to reset your account password if it’s forgotten and still regain access to your archived data. But two higher-security methods keep the key in your hands. (These methods are available for local and peer-to-peer storage, too, with the purchase of a CrashPlan hosted subscription.)
In one mode, “448-Bit Encryption + Password,” an archive password protects the key the CrashPlan software generates. The key is encrypted with that password and stored only in that form on Code42’s servers. With “448-Bit Encryption With Custom 448-Bit Key,” you generate your own key (a simple matter), and the key is never stored anywhere else. With the “+ Password” mode, only the password is needed to use Web or mobile apps to view or retrieve files.
SpiderOak offers a single model of backup security, in which encryption keys are derived entirely from a password that remains in the hands of a user. It generates many encryption keys from the same source. Encryption keys are only stored in a transformed manner on the servers, and the password is never stored there either. However, lose the password, and there’s no way to recover any archived data, because SpiderOak has no knowledge of your password at all.
Backblaze can store your key (account based) or let you control your key (passphrase based). All accounts have their own encryption keys.
Carbonite provides account-based protection only, and according to its documentation, does not employ individual encryption keys for each user’s data. However, data is encrypted in the client software and stored in encrypted form on Carbonite’s servers.
Dropbox uses account-based protection only to allow sync, storage, and sharing. Files are encrypted only in transit and while in storage, but aren’t encrypted before sending, and are briefly unencrypted between transit and server storage.
It’s a balancing act to store your archives offsite—you want them accessible forever for when (not if) something fails or you delete a file unintentionally. But you’d also rather not fall victim to a hack in which a service’s systems are cracked and your data is carted off and decrypted as a result. You have a lot of shades of choices you can make, but one thing is clear: Ensure you never lose all copies of your backup’s password, even when it’s recoverable through an account reset.