Defending from common thieves
Rather than wiping Windows 7, I've left it as a honeypot operating
system. If a thief steals the laptop, when they turn it on, it will
automatically boot up into Windows, without so much as even being
prompted for a password. I installed a free application called Prey
which will allow me to grab loads of information from the laptop, such
as its location, and pictures from the built in webcam.
Unlikely. Most laptop thieves have been in prison at one point in their lives, so they've learnt a thing or two from their fellow inmates. They are wise to this trick. When they steal electrical items that can communicate, they take batteries out (and SIM cards if applicable). Most mobile phone thieves carry opening tools for iPhones, so they can quickly remove the SIM. They'll then sell the laptop onto a fence (someone who sells on stolen goods) who will take out the drive and wipe it, and install a new OS on it. Usually a pirated copy of Windows.
Defending from experts
I consider full disk encryption to be essential if you want to secure your laptop. However, there are several attacks against machines that use full disk encryption; I decided to address as many of them as possible.
Agreed that full-disk crypto is good! Let's move on...
Evil maid attacks
Even if you have a machine which uses full disk encryption, the boot partition and boot loader need to be stored somewhere unencrypted. Typically, people store it on the hard drive along with the encrypted partitions. The problem with doing this is, whenever you go to your machine, you don't know if somebody has tampered with the unencrypted data to install a software keylogger to capture your password. To get around this, I installed my boot partition and boot loader on a Corsair Survivor USB stick. I wanted a USB stick which would never leave my side.
This is a real threat, albeit rather unlikely. However, the USB stick booter does not protect you. It makes the bad guy's job more difficult, but if they're going to the trouble of tampering with hardware, they could just as easily install a hardware keylogger under your keyboard. Lock the laptop in a case when it's out of your sight. I always do this in hotels, because it helps prevent theft too. I also suggest investing in a decent Kensington lock, which can be attached around pipes and various other strong fixtures.
On a typical system with disk encryption, the encryption key is stored in RAM. This would be fine, if it weren't for the fact that there are several ways for an attacker with physical access, to read the contents of the RAM on a machine which is running, or which has been running recently. You might think that your machine's RAM is wiped as soon as it loses power, but that is not the case. It can take several minutes for the RAM to completely clear after losing power. Cooling the RAM with spray from an aircan, can extend that time period.
This is misleading. At room temperature, modern DDR3 loses integrity below the 50% confidence mark at around 3-15 seconds after power-down. DDR2 tends to do so at around 20-30 seconds. This makes a cold-boot attack on DRAM modules very unlikely, even if you almost immediately leave the room and someone jumps in and drops your laptop into a convenient vat of liquid nitrogen. It's just not going to happen. However, you should avoid sleep mode, which puts the system in a low-power state and continues to refresh the RAM. In such a case, an attacker could freeze the DRAM modules on-site and take them to a lab for analysis. Hibernate isn't a problem if you're using full-disk encryption - the machine state is stored on disk and the system is completely shut down.
You could password protect the BIOS and disable booting from anything other than the hard drive, but that still doesn't protect you.
It won't protect against coldboot attacks, but it protects against a lot of other stuff. You'll also find that a lot of BIOS implementations offer a boot password too, which will make things more difficult for an attacker or thief, since the machine won't even POST without the password.
The second defence I used is far more interesting. I use something called TRESOR. TRESOR is an implementation of AES as a cipher kernel module which stores the keys in the CPU debug registers, and which handles all of the crypto operations directly on the CPU, in a way which prevents the key from ever entering RAM.
This only prevents your crypto keys from being stolen. The RAM will still contain all sorts of other important data, such as file system cache. It'll also contain your LSA keys, LSA vault and in-memory SAM (or the equivalent structures in Linux) which can be used to recover account password hashes. If these are cracked, it might give an attacker an idea of what your disk encryption password is. As such, I highly recommend using a unique password for your disk encryption.
Attacks via firewire
If a machine has a firewire port, or a card slot which would allow an attacker to insert a firewire card, then there's something else you need to address. It is possible to read the contents of RAM via a firewire port.
Yep, and the same is possible via cardbus. If you're paranoid, you'll need to physically disable these interfaces.
So instead, I built firewire as a set of kernel modules, and prevent the modules from loading under normal circumstances using
Won't work. The OS can't interact with the device if you disable support or remove drivers, but a firewire device or cardbus module can still function in any way it likes at the hardware level - it just can't interact directly with your OS software. DMA requests and interrupts can still be sent by the device, allowing it to read memory. This allows the attacker to collect it later, or have it transmitted over RF.
Preparing for disk encryption
you should completely wipe a new hard drive with random data before setting up disk encryption. This is to make it impossible for somebody to be able to detect which parts of the drive have had encrypted data written to them. Doing this, is as simple as creating a partition on the space you want to fill with random data, and then using the "dd" command to copy data directly to that partition device in
/dev/urandom. This took a few hours to run on my system.
This is a silly way to do it. TrueCrypt automatically wipes the entire disk with random data as part of the volume creation wizard. It's also faster than direct reads from
/dev/urandom, because TC does its own strong AES-based random data generation on top of what the system provides. Don't bother doing it manually with
dd - you might get it wrong.
I complicated this procedure slightly by using something I purchased called an EntropyKey. The EntropyKey provides a much larger source of "real" random data, as opposed to the much more limited "pseudo" random data that is generated by the operating system.
This is maybe a good idea. I don't see any real technical analysis of this device, so I can't really say whether it's good or not. Passing various statistical checks doesn't really mean a whole lot. It uses avalanche noise from the P-N junction of a transistor, which is a known good source of random noise, since it is created by the probabilistic effect of quantum tunnelling. However, the noise isn't without bias. Due to various electrical properties of a circuit, such as inductance and capacitance, you'll see small biases towards particular waveforms that "resonate" with various power planes and loops within the board's copper pathways. This bias can be reduced with a software filter called von Neumann whitening, which involves translating bit pairs from 01 to 0, 10 to 1, and discarding 11 and 00 bit pairs. This reduces the output speed of the generator by a factor of at least 1/4 (for an idea random source), but removes bias. I can't tell if this is being done within the EntropyKey.
More on disk encryption
When I initially did the installation, I chose to protect the full disk encryption key with a passphrase. It is also possible to protect it with a keyfile. The advantage of using a keyfile is that you can store it on an external device. An attacker can't just observe you entering the password, they also need to get hold of the keyfile. It's also much more difficult to brute force.
This is fine as long as you have both the keyfile and a password. It essentially provides two-factor authentication.
If you need to use swap. Make sure it is encrypted too. The easiest way to make sure everything is encrypted is to create an encrypted device, and then use LVM on top of that so that all of your partitions and swap end up on top of the same encrypted device.
Wise words. On Windows you should configure your virtual memory (swap) to be placed only on disks that are part of your full-disk encryption regime.
The laptop I purchased has something called a Trusted Platform Module. This TPM can handle a number of crypto operations it's self. It also provides a random number generator similar to the EntropyKey. Apparently a lot of modern laptops contain one of these.
I'd avoid this, due to past problems with TPMs and government backdoors. Whilst I can't cite any concrete evidence, it makes me nervous enough to avoid it.
I use Firefox as my web browser. Surfing the web scares me; the browser strikes me as the most likely way in for a remote attacker. And yet, most people run the browser under the same user id as the rest of their programs. So if the browser is compromised, all of the files that your user can access are also instantly compromised. To try and minimise any damage if this happens, I decided to run Firefox in its own account.
Again, smart. It'd be even smarter to sandbox it entirely, as well as run it under its own user. This is more difficult for Windows, so I'd say your best bet is to have your user account set as a limited user for most tasks (with UAC switched on!) and only switch to an admin account when you actually need to. Something like Sandboxie can also help.
All of my incoming email is encrypted using my public GPG key. I detailed how I do this here. This means that I need to store my private GPG keys on my laptop. They're protected by a passphrase, but is this enough? If my account was compromised, an attacker could key log my passphrase and then steal my keys. Luckily, when I purchased my laptop, I ticked the "Smartcard Reader" option. I then purchased an OpenPGP Smartcard. My encryption and signing subkeys have been transferred to the smartcard, and the master key has been removed from my laptop.
Useful, but this fails to take into account the "evil maid" attack mentioned earlier. It's possible to sniff the card's communications, or tamper with it so that it stores the keys for later retrieval.
I use the following Firefox addons to minimise the chance of MITM attacks against my browsing, and to prevent most XSS/CSRF attacks: Certificate Patrol, Cipherfox, DNSSEC Validator, HTTPS Everywhere, HTTPS Finder, NoScript, Perspectives and Request Policy.
I installed an application called blueproximity. It detects when my phone is in range, via bluetooth. If my phone moves out of range, the screen automatically locks. I've no doubt that this can be prevented via spoofing my phone, but it adds another layer of security.
A cool gimmick, but easily spoofed. Bluetooth security is crap.
All in all, a pretty neat article. It has its flaws, but it also has a lot of sound advice. If you follow even half of it you should be secure against all but the most determined attackers. At the end of the day, it's a balancing act between the risks you care about and the time/money you want to put into it.