Must we submit to Big Brother?
The revelations about the National Security Agency's Prism program have had many people thinking about George Orwell's dystopian novel, 1984. A lot of pixels and ink have been devoted to questions about the rightness or wrongness of Edward Snowden's decision to unmask the program and the relative importance of privacy vs. security. I'll leave those questions to others and instead focus on what we all can do to better protect our online activities from prying eyes.
The first thing that probably comes to mind when thinking about privacy in communications is encryption. That means either private-key (symmetric) or public-key (asymmetric) encryption algorithms and tools. In both cases, the important thing is key management: Who generates the keys? How are keys exchanged? Who controls the keys? In other words, what is our basis of trust?
As a general rule, I favor the approach that gives the end user the greatest control feasible and dislike systems in which the keys are generated and/or managed by other entities. These are the ones that are least likely to be subverted by folks who wish to intercept our private communications -- although I should stress there are no guarantees.
There are other issues to be concerned with, of course. Cost is one. Scalability is another. If you need only communicate within a small community of users, your options are quite different than if you need to communicate within a large community.
Case in point: AES (a symmetric algorithm) is believed, within the crypto community, to be very strong. For a very small community of people that needs to securely communicate, AES-256 with a preshared encryption key is quite strong, as long as the key itself is strong and is never communicated in plain text. (I'm very much simplifying a complicated set of problems, but bear with me.)
But that preshared-key approach is unwieldy for a large community. That's where public-key systems are useful.
With those basics in mind, let's consider what's available. For starters, you should only connect to a network other than your own using strong VPN (virtual private network) tools. There are many free or very inexpensive options available for this, but you want one that uses robust mutual authentication: preshared keys for small groups, certificates for larger groups. Those connections should be to specific IP numbers so that DNS-based attacks can't fool your systems. And the certificates must be rigorously validated (e.g., with certificate pinning, or with the public certificates statically installed on client and server endpoints).
Once you're securely connected, you should use strong encryption for application-level communications. My focus here is email, but Web and mobile application communications should also be considered -- and note that mere SSL may well not be adequate without certificate pinning (which is feasible in many cases).
For encrypting email, you have several options. The Internet-standard S/MIME is the one that is most broadly available across various email platforms. But it's also perhaps the least used or understood. To use S/MIME, you need a client-side email certificate, which can be obtained from any of several commercial services. Enterprises with their own certificate authorities can manage their keys internally, but that option is generally beyond what most consumers are able to do.
As a result, although S/MIME is a strong option, it also usually requires relinquishing key management control to an external organization, which pretty much puts us back at square one with regard to possible eavesdropping on private communications. As a result, I like using S/MIME for digitally signing emails I'm sending, because it's quite easy for my recipients to verify with pretty good confidence that the messages are from me and haven't been tampered with. But when it comes to encrypting mails, I'm less inclined to use S/MIME.
For small to medium-size communities, I generally use PGP, or Pretty Good Privacy, tools. These are available for free as well as in commercial encryption products. I mostly use the GNU Privacy Guard (GPG) tools, which include plug-ins for my email clients. I combine that with a stand-alone PGP app on my mobile devices so that I can view and encrypt data on my mobiles.
The key thing -- no pun intended -- about PGP is that key generation and management are entirely in the hands of the end user. Although PGP requires a modicum of tech savvy to learn and use, it enables communication with a high degree of confidence, and it puts key management in your own hands. But again, by generating and managing our own keys, I have a lot more confidence that they haven't fallen into others' hands.
Depending on how extreme your privacy needs are, you can adjust how you implement encryption. For example, on most modern computers, putting a stand-alone or virtual machine image onto a USB stick is quite feasible. If you encrypt that USB stick using full disk encryption, you're adding an additional layer of protection to your secure communication system. Next, if you do your encrypting and decrypting only while the secure communication system is not connected to any network, you'll prevent your encryption keys and certificates from straying from your system without your consent.
Several commercial options are also available to encrypt email, voice communications, instant messages, etc. Again, my principal advice with those is to seek systems where the encryption keys are not generated or communicated off your own computer or without your consent.
Yeah, I know: What I've outlined are some pretty extreme measures. Many people will find much of what I've described to be unnecessarily burdensome. Finding the degree of detail that is right for you will require careful consideration of the value of the information you need to keep private and the risks inherent in the environment where you're communicating. We all must come to our own decision, but we shouldn't do so without the careful consideration these matters deserve.
With more than 20 years in the information security field, Kenneth van Wyk has worked at Carnegie Mellon University's CERT/CC, the U.S. Deptartment of Defense, Para-Protect and others. He has published two books on information security and is working on a third. He is the president and principal consultant at KRvW Associates LLC in Alexandria, Va.
Read more about encryption in Computerworld's Encryption Topic Center.
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.