Your data is your data. What belongs to you should stay with you, until you choose to give it away. Your personal data shouldn’t be subject to theft. It’s for this reason that banks use SSL on their websites; to protect your data in transit. Obviously, banking online without using SSL to protect your bank account information, balance information, and passwords to access your account, should not be an option for anyone. Only a foolish person would attempt it.
While banking information is extremely important, so is the information on your own system. Whether corporate or a home user, data integrity is vital. Most people know to make backups, to retain their data in the event of a crash. So what do you do when your laptop is stolen or someone breaks into your system? You have a backup, right?
What about the stuff that requires more than a simple backup? Think GPG or PGP private keys. Think SSH private keys. Think accounting information with the same data contained at the bank that you so meticulously ensure you only connect via HTTPS to obtain. Is a backup of this data enough?
Of course not. If someone obtains your GPG private key, they can, in essence, take over an online persona. They can send messages as you, using your key. If someone obtains your SSH private key, any accounts you connect to using the key, likely passwordless, are open for them to login to. Granted, both GPG and SSH keys should use a passphrase… how good was your passphrase again? They may not be able to access that data immediately, if you use a good passphrase. Another reason for a good one.
Local Privacy and Encryption
Take the good passphrase one step further. Use an encrypted loopback filesystem to store your GPG and SSH data. This offers you a few advantages. It’s another layer of protection between a thief and your personal data. It prevents people from looking at some of the data that can be useful immediately. For instance, while you may have your SSH private key adequately protected via a passphrase, the data stored in the known_hosts file is stored in the clear; this gives a thief an excellent overview of what remote systems you connect to, and may give them one known username on those remote systems. If you maintain a ~/.ssh/config file, there is data there that no one other than yourself should have access to either. In short, protecting the entire ~/.ssh and/or ~/.gnupg directories is vital, especially on something like a laptop.
Of course, using an encrypted filesystem is useful for more than just private keys for SSH and GPG/PGP. They are useful for holding data files for banking or accounting software, documents that may be sensitive or personal such as resumes, and more. One day, all filesystems should offer encryption as a choice, preventing using loopback filesystems as “containers”, or similar software solutions (such as PGP Disk).
On a side note, using small keychain USB memory sticks that can be mounted as filesystems is an option as well, although encrypting the data on the removable device should be mandatory (which is easier to lose? keys or a laptop?). Storing these encrypted filesystems on such a device adds yet another layer of protection.
There are a few different ways you can accomplish this. We’ll look at a few of them here.
- Encrypted DMG Files in OS X
- Using CFS
- Encrypted loopback filesystems
Secure Communications Over Insecure Networks
Another important aspect to personal privacy is secure communications. This means being able to communicate with others securely; sending encrypted emails or files that others cannot read, but only the intended recipient. There are a few different ways to handle this sort of private communication; two very big ones are PGP and GnuPG, both of which require the use of private and public keys. There are other means of securing personal communications, which we will also look at.
Both PGP and GPG perform the same basic function; the primary difference is that PGP is a commercial product and GPG (GnuPG) is an open source product. But they can both interact with each other and use the same standard. PGP has clients for most operating systems, and so does GPG. To use PGP, one must pay for it… with GPG, there is no cost attachment. We will look specifically at GPG, however a lot of the terminology and theory used is interchangeable with PGP. They do not have the same interface (PGP is primarily GUI-driven), and the commandline operations differ.
Privacy and Encryption for Network Services
Another means of communication that I have found invaluable is IRC, however it is inherently insecure for two reasons. The first is that more often than not, it is done in the clear; there is no encryption to secure the communication on channels. The other is a lack of authentication. Some bots offer this functionality but most will ask for authentication once you have connected, not before. There are two ways that an IRC server can be secured, for use as an internal communications tool in a company, for example. The first is to use SSL to encrypt data. You can then use a bot of some sort for authentication once the user is connected to the server. The second is to use SSH, which provides both authentication before connection, and encryption.
When discussion security over web services, more often than not SSL (Secure Socket Layers) is the defacto standard of protecting data in-transit from client to server. This isn’t always the case; we’ve seen how to encrypt IRC data using SSH. The drawback here, however, is that some relationship must exist between client and server before the transaction, and this isn’t always feasible. For instance, to purchase something online, you don’t send your SSH public key to the admin, he doesn’t install it on the server, and you don’t create a SSH tunnel from your system to the server, and then connect to the localhost at the other end of the tunnel. With so many people involved in e-commerce these days, something like this simply isn’t feasible.
What is more common is using SSL to protect websites and other services. This is a transparent encryption layer that protects data from your client to the server without you having to do anything more than making sure it exists. When you connect to a website using HTTPS (or the secure HTTP protocol), your data is protected with SSL. Due to big Certification Authorities who verify and sign server certificates, chances are you’ve never had a request to verify a SSL certificate. This is because these Certification Authorities have done the verification for you; they have verified that the individual or company requesting the certificate are in fact who they claim to be. There have been notable exceptions to the rule in the past, but these are few and far between. Of course, just because your data is protected by SSL, and just because Verisign or Thawte have verified the other end is who they claim to be, doesn’t mean you should trust them. All it means is that they are who they claim to be; there is no history checking or character validation… so don’t assume that because you are doing something over HTTPS that the other end is trustworthy… that is something you need to determine for yourself.
Having said that, SSL is used to protect a variety of services, not only web traffic. It can be used to protect IRC traffic, POP3, IMAP, and much more (even services not specifically designed for SSL support can be made to use it via tools like stunnel).
Getting a Certification Authority to sign your server certificate is a good thing. This allows people to connect to your site or service without any warnings or interruptions. It makes it a seamless experience. The downside is that having a registered Certification Authority sign your server certificate can be expensive, so depending upon your needs, you may opt to self-sign certificates or generate your own personal Certification Authority. To put the numbers in perspective, Verisign currently charges $349USD for a single year single site certificate, whereas Thawte currently charges $199USD for a similar package. See the Resources for a list of other Certification Authorities so you can shop around if you really do require a proper CA to sign your certificate (recommended in the case of e-commerce sites, etc.).
Another topic of interest is using SSL with various services, including HTTP, FTP, IRC, etc. We will look at securing various network services using SSL.