Last Sunday a dead hard drive reminded me that the TODO to upgrade and automate my cloud backups needed to be moved from “do when I have time” list — which for me is hard to distinguish from the “never” list — to the “do now” list. I planned to user SpiderOak as my provider: I like their “zero knowledge” approach where, without the password that only I have, nobody can decrypt my data. A bit more shopping found Bitcasa, which offers the same zero knowledge storage, plus unlimited capacity for a fixed price. Sounds like a great deal. However, Bitcasa doesn’t give quite as much information about how they secure my data, so I decided to look a bit and see if I could confirm that my data would be as secure as it is with SpiderOak. For those who don’t want to read the whole post, the answer I found is for Bitcasa is “No, your private data could leak a bit.”
Some months ago, I wrote about using PGP and S/MIME to keep e-mail private. As much as I love the idea of keeping my e-mail private, I rarely use PGP or S/MIME. This is because the people with whom I communicate don’t use PGP or S/MIME. To improve this situation, I’ve been looking at ways I can help my friends and family try securing their e-mail.
I can’t think of anyone who would argue that keeping e‐mail private is of little import or an easy task. I use e‐mail as storage for personal information, for authentication, and for communicating when I want the communications to be private. Such private information should be well‐protected. Unfortunately, this is rarely the case.
My current e‐mail service provider uses machine learning techniques to read my messages and display frighteningly‐relevant advertisements to me. (This is part of the bargain of free e‐mail service.) It also does a good job providing reasonable security against most parties who would like to read my e‐mail.
So, how would I go about keeping my messages private to those whose names are on the To and From lines of the message? There are some solutions to this challenge. Two common solutions are PGP and S/MIME. Each of these solutions uses public-key encryption.
Public‐key encryption is a type of encryption that requires separate, related keys for encryption and decryption. I control a keypair—a public key and a private key. My friend John also controls a keypair. When I send John a message, I use his public key (which is publically-available) to encrypt the message. He can then use his private key to decrypt and read the message. When he sends me a response, he uses my public key to encrypt the message and I use my private key to decrypt the message.
PGP (Pretty Good Privacy) provides a means of encrypting messages and files (but not the recipients or the Subject of a message.) It is easy to use as encryption goes and relatively secure when used properly. Identities in PGP are built on the notion of a web of trust. The web of trust is a very important part of PGP. What good is encryption if you don’t encrypt the message for only the correct recipient?
The web of trust system works on the idea that you are willing to trust your friends. If you and I meet and exchange keys, you know that when you encrypt a message with my public key, I am the one who can receive that message. If I introduce you to my friend Alan, you might be willing to accept that a public key he provides you is in his control. However, with PGP, I can send you a file that proves to you that I believe that a certain public key is controlled by Alan. You can then trust that Alan is in control of that public key because you trust that I have verified Alan’s public key.
S/MIME (Secure/Multipurpose Internet Mail Extensions) also provides a means of means of securing the body of a message. It is built on the notion that central authorities should verify your identity. This makes it popular in larger companies that need to secure e‐mail. (It can also be used as the basis for single sign‐on implementations.)
The public key infrastructure system uses central authorities like companies or governments to verify identities. You (or, more accurately, your software) may trust one of these authorities to verify that Troy at Art & Logic is really Troy at Art & Logic. This is useful for companies that want their employees to communicate privately. Each company can verify the identities of the employees to the other company. This works less well when you want to communicate privately with your friends from college.
There are some drawbacks to encrypting your e‐mail.
If you want your messages to be scanned for malware, you must do that after decrypting the message. Alternatively, you or your IT team may keep a copy of your private key and use that to decrypt the message and scan it for malware. This makes your messages less private, but may save you some pain. Alternately, you may decide that you don’t need to worry about it if you trust the sender and PGP and S/MIME allow you to verify the identity of the sender.
Searching encrypted messages is not easily done if your software is not built for it. You can search Subjects, but the Subject of each message is not encrypted, so you need to find the balance of what you are willing to leave unencrypted.
In all, e‐mail encryption provides usable privacy for your messages. It does not secure the Subject line or the sender or recipients of a message. It provides some challenges for defending against malware and searching your messages in the future. If you must have privacy for your communications, I suggest you evaluate one of these options.
In order to store private data in an iOS Core Data database, there are several methods available for encryption, including:
- iOS-level data protection based on the device passcode
- open source projects like SQLCipher for iOS that encrypt the database file