Manage encryption on macOS
Glenn Fleishman looks at user-owned encryption
I’m glad to see a positive security trend: more companies have software available for hosted backups and cloud-based storage access that incorporates user-owned encryption. With these products and services, you are the only person or entity that controls the encryption key or passphrase that unlocks the key. The company that makes the software
or runs the service not only never sees it, they have no way to access it.
Apple engages in this only with iCloud Keychain and iMessage. While Apple doesn’t know your Apple ID password, you do have to enter it for the company to transform it into a cryptographically securely formed version that it can compare against what it has stored for you.
But with iCloud Keychain, it doesn’t have enough information to extract information from the middle, because it uses a process that creates encryption keys on the endpoints on your devices. The data sent through Apple’s services is locked away from its eyes. I wrote about how AgileBits and LastPass used a similar approach for their synced services. (Apple’s system could be changed in such a way that it would be able to sniff that data, which is one of the weaknesses of its current model that needs to be and could be changed.)
With other iCloud data, like photos and contacts, and with everything you store on Dropbox, Box, Google Drive, and other cloud storage, the encryption keys are in the hands of the company running the service. Dropbox uses encrypted connections between its apps and its servers, and it stores the data only at rest in encrypted form with keys it possesses. The data has to be decrypted between at-rest storage and transit to and from your devices.
I prefer that people have the option for a one-step remove for everything, not just a few categories, to avoid putting their decrypted data in the hands of third parties. That’s for both security (preventing unwanted people from breaking through protections) and privacy
(preventing unwanted eyes from seeing your stuff ). For instance, Google has emphasized secure transit, pushing https connections widely, and working to help users secure their accounts and keep data away from snoopers. But Google’s business is based on being able to look at your stuff in order to push ads at you based on it, even if they sandbox their approach so they allege they can’t individually identify you. (Which doesn’t explain how they’re going to connect retail credit-card purchases and online ad viewing.)
But you can bypass this kind of creepy-thoughassumed-to-be-legal peering over your shoulder as well as securing yourself against intrusion should a third-party systems be breached.
Own the keys to rooms in the castle
The security world often talks about the ‘keys to the castle’, referring to what secures a system. If those keys get nabbed, the castle is indefensible, and the attackers can ransack it. What I describe here is more like keys to panic rooms in the castle. If invaders storm the fortification successfully, your room remains impenetrable, even if it’s literally cut out of the castle and carted away.
You have five categories in which you can be sure to varying degrees that you’re the only one able to decrypt or manage a connection or remotely stored data.
Messaging. As noted above, iMessage uses an approach that prevents Apple from having access to the keys that encrypt your communications. Signal, an independent company, and WhatsApp, owned by
Facebook and using Signal’s protocol, both take the same tack, but are frankly better implemented and offer a way to validate other parties’ identities.
Password storage. Apple’s iCloud Keychain is done right, and so are 1Password and LastPass. While other options exist, none seem to combine of encryption, security, and app ecosystem as robustly.
Service-hosted backup. I explored at length back in September 2016 the way in which several hosted backup services – like Backblaze and CrashPlan – manage your encryption keys and passphrases. A few meet rigorous tests of never possessing the keys or only possessing them in limited circumstances under your control.
Self-hosted backup. If you want to control where your data goes, Arq is the only solution for Mac that works with multiple cloud providers, SFTP servers, and sync services (such as Dropbox) and allows you to set a local encryption password for archives that
is never transmitted. (ChronoSync works with fewer services, but only supports cloud-side encryption options with Google and Amazon’s storage-unitbased cloud offerings.)
Remote services mounted locally. The latest additional to the arsenal is an update to CloudMounter, which lets you mount SFTP and cloud services as if they’re Finder volumes. Version 2 uses Apple’s built-in encryption libraries in macOS to automatically encrypt and decrypt data at mounted services on the fly. That bridges the last gap for not relying on cloud-side encryption. (Panic’s macOS file-transfer app, Transmit, can mount remote file systems as Finder volumes, and [its sneak-peek screen capture of version 5][*] shows more cloud services included. But version 4, at least, doesn’t overlay encryption as an option.)
Given the extent and kind of intrusions into all sorts of online services, keeping the keys to our castle rooms close seems advisable if you’re in a position where any or all of the above options can work for you. For most people, they should, although it might involve transitioning from one software package or service to another.
With CloudMounter and Arq, you may have the last pieces in place to get the benefits of affordable sync services without having to buy into their security models, too.