Transmissions

by Dragorn

It's probably a safe assumption that everyone reading this magazine is already paranoid, but how paranoid are you and are you paranoid enough (or for that matter, too much, which carries its own risks)?

A proper level of paranoia isn't about thinking that the potted plant is planning to assault your sleep.  It's about making intelligent choices to protect yourself, your privacy, your finances, your job, and, depending on where you live (and what you choose to do), your freedom.

The cost of having your data compromised is ultimately the driving factor behind security decisions.  None of us are particularly excited at the prospect of losing our privacy, bank details, or our jobs because of a security bug.  In a targeted attack, the cost of compromise may be even higher - source code modified to introduce backdoors or security vulnerabilities prior to distribution, records altered, or employer data compromised... and these are just the risks to your workstation.

Security in the real world is the balance between paranoia and practicality.  The most secure system is one turned off, encased in cement, and at the bottom of a quarry.

Despite the seemingly universal acknowledgment of the importance of securing systems, a large amount of incorrect or outdated information still exists.  The guidelines presented here are by no means a canonical answer to the problem of securing yourself, but hopefully thinking about side attacks to conventional wisdom helps in devising proper plans.

Most of the proposed solutions focus on Linux, solely through familiarity, but the ideas will help protect you on whatever system you're running.  Feed your paranoia and keep reading.

"Never run normal applications as root (or administrator)."

Obviously this is a good idea which hopefully most readers adhere to, but the simplest implementation of this guideline is to run all your applications as your normal user, which for protecting your data is just as bad.

A root-level compromise gives an attacker access to all your data.  But how many files on your system are owned by the same user you use to run Firefox, Pidgin, and IRC?  What prevents a compromise in any of those applications from giving access to all your files?

Enforcing per-application security is vital for preventing vulnerabilities in one application from compromising all of them.  The easiest method of locking down applications is by dividing up the users they run as.

On UNIX systems, this is relatively simple and can be done with Sudo and some shell scripts to launch each application as a separate user (and even allow each application limited access to other restricted applications, such as opening a URL) or by changing the ownership of the applications and using the setuid bit.

Segregating all your applications into different users with restricted permissions isn't the only answer, but it's a strong first step.

"Strong passwords are sufficient."

Simply put, no, they're not.  Especially not on a laptop.

With a laptop, you face two unique risks: theft (either random or targeted) and easy physical access.  The risks from both are similar.  No matter how strong your login passwords are, if someone can boot the system with external media or remove the drive and mount it on another system, all your security measures are moot.

Access rights and file protection rely on the operating system to enforce them, and when you no longer control the operating system reading the disk, your data is toast.

Again, fortunately, the solution is fairly simple: strong crypto, either at the filesystem or disk level.

There are a wide range of tools to implement disk crypto on various platforms.  The LUKS system uses changeable keys for full device cryptography and is native to Linux but has Windows tools to operate on it.  Full-disk encryption typically operates at the operating system's device layer, emulating a block device (i.e., a drive).

All I/O to the drive is encrypted at the block level, including the filesystem itself.  Full-device crypto has the advantage of automatically encrypting all data placed on that volume - including cache files, temp files, and others which might not be included in selective encryption.

It also has the advantage that any "ghosts" left on the drive (partially deleted files and incompletely erased data, or a drive which has not been reformatted with alternating patterns designed to wipe out any magnetic remnants of data) are also encrypted.

On modern systems, the impact of performing encryption on every block is minimal, and as the CPU increases in speed the performance hit will continue to drop.

"Strong crypto is sufficient."

But didn't I just say strong crypto was a good solution for laptops?  Well, yes, but that's not the entire story.

Edging further from mainstream risks are the attacks against the hardware itself.  Externally facing buses - IEEE 1384 (FireWire), USB, and CardBus/ExpressCard - allow devices to interact with the system, often below the control of the operating system.  Gaining access to the memory of a running system enables reading of cached files, cached crypto keys, or modifying the system to allow access to an active encrypted filesystem.

These attacks are not so far-fetched - system debugging and imaging hardware to exploit weaknesses like these exists today, and at least one company is advertising the availability of a USB device which extracts all the info from a system.

Unfortunately, when it comes to hardware-level vulnerabilities, there is only one good solution: Go to the hardware store, buy some epoxy, and fill in the external ports.

This probably isn't an acceptable solution for most people - and wouldn't stop someone with the resources and time to open a running system and connect to the internal leads for the bus.  If you're facing attackers with that much determination, chances are you shouldn't be trusting your data to a laptop.

"I only need to encrypt the [messages | files | drives] which are sensitive."

Another piece of conventional wisdom which, while true, may not tell the whole story.

As mentioned above when discussing full-disk encryption versus per-file encryption, there may be files generated for temporary storage, caching, copies left while moving files, etc.

These files can easily be missed when doing per-file encryption.  Encrypting only sensitive communications and files carries the additional risk of making it easier to target "interesting" data: If I know someone only encrypts emails in which they talk about sensitive information, I know that if I have an encrypted email from them it's probably worth trying to decrypt.

Form a habit of encrypting everything, at all times, except when your recipient can't decrypt it for some reason.  GPG integration with email clients is trivial to configure, as are dynamic SSH tunnels (ssh user@host -D 9999) which function as SOCKS proxies.

Off-The-Record (OTH) provides per-message encryption on most IM systems.  Increasing the encryption of your communications increases your privacy and increases the difficulty of spotting important communications among the chaff.

Increasing your security is a holistic choice, modifying both software and human behavior.

An unknown percentage of exposures might be avoided with little more than a careful eye towards security, and an increased level of paranoia.  Like backups, the proper time for making decisions about security is before a compromise.

A balance between security, usability, and paranoia is possible with foresight and planning.