he main thing to watch for is an extra extension jack coming between your keyboard and the back of your computer. However, also be wary of internally installable keyloggers. If your physical environment can't be trusted (note that depending on your situation, this may or may not include your home), buy a new keyboard and seal it with epoxy, or some tamper evident mechanism. Also periodically check the inside of your computer for dangling pieces of electronics coming between your keyboard port and your motherboard. Normally there should only be wires or nothing at all. People have been prosecuted using keylogged data as evidence.

Keyloggers are typically pretty blind. Especially kernel and hardware keyloggers. If you are at a machine you cannot trust and do not feel like making it trustworthy, you do have some options to at least protect your passwords. For example, switching windows mid-password, cutting and pasting characters, and using the mouse to delete sections of text randomly are all effective against hardware and kernel keyloggers, which will only focus on actual keyboard events.

Message-hook and other application-level keyloggers can also be fooled in this way, but they can attempt to do things like sort keystrokes by destination window, target only specific apps, take screenshots, and even attempt to capture cut and paste events. In fact, most commercially available software keyloggers have advanced to the point where they are able to track both cut and paste activity and sort keystrokes according to their destination window. You can still attempt to confuse them by entering keys into other fields in the same window, however.

There are several methods by which an Agent can obtain the legal right to search and seize your digital goods, most of which are conveniently outlined in the US DOJ Search and Seizure Manual (local copy). There are a couple instances where they can get away with searching you WITHOUT A WARRANT that you might not have anticipated:

It should also be noted that anything uncovered while executing a warrant is admissible in court, even if it was not what the agents were looking for.

In addition to the above, you need to be at least peripherally aware of the rules of discovery in civil procedure, especially if it is likely that someone may seek to sue you for damages instead of (or in addition to) pressing charges. In civil procedure, if there is reason to believe that you may have evidence supporting the plaintiffs claim, the process of discovery enables them to demand evidence/records from you. If you destroy this evidence, then not only are you potentially liable for criminal charges, but the plaintiff also is allowed to assume that the destroyed records contained the proof they sought. In the case of civil litigation by large corporations against individual people, the police are sometimes called in to immediately seize relevant materials without warning. Isn't that great?

There are two main cryptographic filesystem solutions for Linux: dm-crypt and TrueCrypt. TrueCrypt setup is covered below, and arguably it has some more appealing features than dm-crypt, but since it is not included in any major distributions, typically you will have to recompile your kernel to support it.

Setting up dm-crypt is relatively easy to do (at least for a simple loop-back filesystem), and their wiki has several good HOWTOs. Unfortunately, setting it up right can be extremely hard and involved. Please read this guide carefully, as there are many subtleties than can catch you off-guard.

To protect against the legal snafus mentioned above, I prefer a bit different approach than that given on the Wiki for actual device creation. I prefer to use GPG to encrypt the filesystem key, and have the passphrase I type into the keyboard be the password to the GPG key. This enables you to change the password without having to rebuild the filesystem. It also enables you to carry the key with you on a USB microdrive to ensure its safety and also to prevent anyone from mounting the fs even if they know the password. In emergency situations, the USB key can be destroyed, and the data can never be recovered. In this way, you can be in full compliance with a court order requiring the password for the filesystem and still not reveal your data. Note that if you destroy a key after a court demands to see it (or simply refuse to give up the password) you can be held in contempt of court and sentenced to jail time (in the US, this is 6 months or less, however). However, if the key/data is a substantial portion of the prosecution's case, and the sentence you are facing is more than 6 months (or if you are a hardcore civil libertarian type), you may want to tell them to fuck off anyway. Probably would get you a good deal of (most likely positive) press attention. Nobody likes to see people imprisoned for refusing to testify against themselves, even if some legal loophole would allow it.

Here are the steps to generate such a key that can be destroyed on a moment's notice:

[root@machine ~/dir]# dd if=/dev/random bs=4k count=1 | gpg -a --cipher-algo AES256 -c - > /mnt/usb/keys/fs.gpg
[root@machine ~/dir]# gpg -q -o - /mnt/usb/keys/fs.gpg | cryptsetup -v -c aes create cryptfs /dev/hdxN
[root@machine ~/dir]# mkfs.ext3 /dev/mapper/cryptfs
[root@machine ~/dir]# mount /dev/mapper/cryptfs /crypto
     
      

So basically what this does is get some random data for the fs key material, and use gpg and AES256 to symmetrically encrypt (-c) it with your passphrase. The next command then decrypts your key file and uses the key material to initialize the dmcrypt driver using /dev/hdxN, where x is one of a-d, and N is the partition number. Note you can also use files instead of partitions, but it is not recommended, especially if that file resides on a journaled filesystem. After that, the /dev/mapper/cryptfs block device will appear, and you can format it for whatever FS you like, and then mount it.

For added safety, I prefer to move /var, /tmp, and /home to /crypto and create symlinks back to /, so that .bash_history and system logs aren't available to someone who might want to prove you have certain files or access times. You should run telinit 1 before doing this, to ensure that no daemons are running and actively using those directories when you move them.

        [root@machine ~/dir]# telinit 1 [or reboot into single user mode]
        [root@machine ~/dir]# [killall rpc.idmapd]
        [root@machine ~/dir]# [umount /var/lib/nfs/rpc_pipefs]
        [root@machine ~/dir]# mv /var /tmp /home /crypto
        [root@machine ~/dir]# ln -s /crypto/* /
        [root@machine ~/dir]# [vim /etc/selinux/config]
        [root@machine ~/dir]# telinit 3 [or reboot]
      

On Fedora Core 4 systems, you'll need to killall rpc.idmapd and possibly umount /var/lib/nfs/rpc_pipefs before the mv, or just reboot into single user mode. In addition, this whole setup is likely to cause SELinux conflicts, so you should probably set SELINUX=permissive or SELINUX=disabled in /etc/selinux/config (or add selinux=0 to the kernel boot parameters in /etc/grub.conf).

Once this is complete, you'll want to make sure that your crypto fs is mounted before anything tries to use /var. The way I prefer is to create a script interface to gpg that has the right options to enable it to work from /etc/rc.d/rc.sysinit. For Fedora Core users, you can typically just call that script right after the rest of the local filesystems are mounted. Search the rc.sysinit file for "mount -a -t" or "Mounting local filesystems". You should end up somewhere near a bunch of mount -f lines and an SELINUX relabeling call. Stick a call to /path/to/mount-crypto right before the SELINUX stuff. If you prefer to run your system in runlevel 5 (with graphical login), you will need to edit /etc/grub.conf and remove the rhgb option from the kernel config line in order to be able to enter your FS password. Note that you will probably want to have a boot disk handy or be ready to do linux init=/bin/bash from the boot command line in case something goes wrong.

Alternatively, if you don't wish to be prompted for a password at bootup because the machine is a remote server, you can use chkconfig or edit /etc/rc.d/rcN.d (where N is your runlevel -- type runlvl as root if unsure) to remove syslog, sendmail, crond, atd, and any other daemon that shows up in an lsof -n | grep var and lsof -n | grep tmp. In summary:

        [root@machine ~/dir]# runlvl
        [root@machine ~/dir]# lsof -n | grep var
        [root@machine ~/dir]# chkconfig --level 3 syslog off
        [root@machine ~/dir]# chkconfig --level 3 sendmail off
        [root@machine ~/dir]# chkconfig --level 3 crond off
        [root@machine ~/dir]# ...
      

Unfortunately, there are likely to be a crapload of daemons you're going to have to do this for, especially if you run Fedora Core 4. Once you finish this, you'll want to make a script that mounts and then starts all the needed daemons. As a starting point, you can have a look at my crypt-start and crypt-stop.

Note that if your system is running remotely, it may not be too happy about brining sshd up for you after the unmount or upon bootup, unless you mkdir -p /crypto/var/empty/sshd/, and mkdir -p /crypto/var/lock/subsys in the unmounted dm-crypt directory.

It should go without saying, but if you go through all this trouble to encrypt your harddisk, you shouldn't leave backups lying around on unencrypted media. If you have to transfer a backup to unencrypted media, tar it up, and then use gpg --cipher-algo AES256 -c to encrypt it. GPG does compression before encryption.

Last, but not least, you should also consider encrypting your swap so that pieces of programs you run aren't recoverable after shutdown. I prefer to use the lazy route and just make a swapfile on the encrypted filesystem.

In MacOS you have two options. If you trust Apple (and your sysadmin, where applicable), and really believe there is no master password set, you can use the built-in FileVault feature to encrypt your entire home directory with 128 bit AES, or you can attempt to do it yourself. Given the amount of work involved in doing it yourself, I would suggest trusting Apple and going the FileVault route.

In Windows, everything is easy. Unfortunately, everything also sucks. For some reason, Windows implements encryption at the filesystem layer, and you can enable it by right clicking on a file/folder and going to Properties->Advanced. Unfortunately, all of the file names in an encrypted directory are still viewable without the key. Worse still, the Administrator account has access to all these files through a special recovery key, and there seems to be no option to disable this.

If you do choose to run Windows on your desktop, an alternative you might consider is building a Linux fileserver that houses all your sensitive documents on an encrypted Samba share, but be aware that Samba does not encrypt traffic. You can set up an OpenVPN tunnel between your Linux and Windows machine, however, if there is danger of someone monitoring your network.

Another alternative is to use TrueCrypt, which actually provides the benefits of both crypto and steganography in that it has an emergency password that you can use if ordered to reveal your filesystem password under threat of force. TrueCrypt is a very nice piece of software, and more than makes up for the pile of suck that is NTFS encryption, and now also has a Linux version. Creation of hidden volumes is pretty straight forward. There is online documentation, but really you only need to be aware of a couple of things. First, it is best to create the hidden and the outer volumes at the same time, using the "hidden volume" radio button. The outer volume is created first, and is populated (by you) with non-sensitive files and encrypted with the emergency password. Note that if you place more data on the outer volume later, you must remember to specify your hidden volume password as well, so TrueCrypt is able to find areas unused by the hidden volume to store the new data. Once the volumes are created, you can mount the same volume file/partition with either password to test it out.

Additionally, TrueCrypt has recently added support for keyfiles. The support for this feature is particularly excellent. You can combine an arbitrary number of keyfiles along with a password to yield the actual key to the filesystem. This allows you to create a collection of both fake and real keyfiles such that your adversary has to know which subset are actually required (assuming they can even find any of them), in addition to knowing your password. It can be seen from this formula (or by visualizing keyfile "fake/real" as a binary string), that for N keyfiles, the total number of combinations of keyfiles is 2^N. Thus you can easily provide for a large number of possible combinations of both keyboard and mouse input (which is particularly comforting if keyloggers are a possibility). Couple this with hidden volume support and clever concealment of encrypted volume files amongst other large and unintelligible program data files, and you have yourself a pretty secure and undetectable encrypted setup. Just remember to frequently mentally rehearse all of your passwords (instead of writing them down), as mentioned above. Filesystem passwords are used much less often than login passwords. It is easy to forget them.

The only real drawback is that TrueCrypt cannot encrypt the Windows Swap file. This means that it is possible for programs to write pieces of their memory to disk unencrypted. This obviously can leak sensitive information. However, the swap file can be disabled in Windows XP by navigating through Start->Properties->Advanced tab->Performance section->Settings->Advanced tab->Virtual Memory section->Change->No Paging File->Set->OK.

On Linux, however, a TrueCrypt volume can of course contain a swapfile as discussed above.

For the extra paranoid, you can write a quick perl script to monitor network connectivity, and immediately unmount and remove the crypto device as soon as pings fail (or execute any other arbitrary command). I've done this already for you. My first cut was a simple script that pinged a series of hosts and executed your crypt-stop script from above. This script gave The Man one second to move your machine to a network that would also respond to all those pings while he transported it.

This is problematic in that The Man could simply throw in a hub with a bunch of machines that would also respond to those IPs and turn it on as soon as they disconnected your box from the network (assuming they figured out what to do about power). So after thinking about it for a bit, I decided I didn't even want to make it that easy for that bastard. So I wrote a pair of scripts you can run on various machines on your LAN (or across the Internet) to ensure network connectivity.

The way this works is there is a client script and a server script. The client script is the one you run on your secure machine, and the server script you run on any host on the Internet. The scripts are written in standard perl, and depends upon the Unix utility md5sum, which is available on Linux, Mac OS, and cygwin. You should be able to replace md5sum with any command line hashing program, such as FSUM if you do not want to install all of cygwin.

When you start the pair (start the server first), they ask you for a password to be used for that session. The client script then periodically (every 0.25 seconds by default) sends the MD5 (or SHA1) hash of a random number (from /dev/urandom) to the server script, and the server script appends this random number to your password. It then hashes this combined value, and sends the result back to the client. The client compares this value to one it generates locally via the same manner. If they match, the process is repeated with a new random hash, if they do not match, a script you specify (such as crypt-stop to unmount your drives) is run. The script is also run after a timeout period (1 second) or if the TCP connection otherwise dies.

This is a common cryptographically secure authentication technique that is used to prove two people know a password without revealing it to a third party (The Man).

Note that there is nothing stopping you from running multiple copies of this program on a given machine to connect to multiple servers with different passwords, in case there is concern a password could be recovered by attacking a particular server. It won't hurt your volume to attempt to unmount it twice.

On Linux, the relevant utility is called wipe. There are two versions of this utility. The more popular one is hosted at sourceforge, and the other is available here.

For most uses, I would just accept the defaults. To wipe a file, wipe filename should be fine. wipe -r directory will get an entire directory recursively. To wipe all free space on a drive, wipe -a some_file should do the trick.

On Mac OS, secure file deletion is built right in to the trash bin. You need to ensure that you do not interrupt this process, however, or you may loose access to any FileVault volumes you may have. Keep the power plugged in.

It is also possible to erase free space on your Mac if you emptied the trash bin without using the secure file deletion option. For instructions on how to do this, go to Applications/Utilities and select Disk Utility and search the help for information on erasing free space. FIXME: Better description. Can it do free space?

On Windows, far and away the best option is Eraser, since it adds right-click context menus to wipe a file or directory, and allows you to schedule tasks to wipe all free space as well. Very nice piece of software.