My post 5 rules to Protecting Information on your Laptop finished with a recommendation to encrypt your hard drive.
- 1.6 Ghz Core2 CPU, one CPU core active in the VM
- 256 MB of RAM allocated, fully allocated to RAM (No swap)
- 8 GB of disk drive simulated in a file
- No FDD
- Windows XP Pro SP2 operating system
As you can see, it is a relatively slow machine for today's standard of laptops, but this is on purpose, since the idea is to conclude whether this configuration is useable with an encrypted drive.
The installation of the TrueCrypt is very straightforward, and even the most inexperienced users should have no problems whatsoever. Immediately after the installation, choose System->Encrypt system partition/drive.
Follow the instructions on the windows. Choose a very complex password since it cannot be changed. The software automatically creates a rescue (decrypt) CD Image, which you must burn on a blank CD media. Truecrypt WILL NOT continue with the actual encryption unless you present a burned CD with the decryption data.
The actual encryption is lasts some 20-30 minutes. After it finishes, you have an encrypted system drive.
I have 2 identical clones of the Test Laptop, one with encrypted drive and one without.
PassMark Disk Result for the Non-Encrypted Machine
PassMark Disk Result for the Encrypted Machine
- Booting to Linux and attempting to access the file system - I booted the Helix forensics toolkit (knoppix) and attempted to mount the encrypted drive. The operating system could not identify the file system type. When i forced NTFS file system type, it refused to mount with a message of invalid I/O. The bit-for-bit DD copying still works however the actual copy is just as useless as the original.
- Booting to ERD Commander 2005 and attempting to access the file system - A simpler variant of the Helix attack. The ERD Commander didn't succeed in mounting the drive and complained about overlapping I/O
- Removing the drive and attempting to find strings in it - I tried this with the DD copy of the encrypted virtual drive. There were strings found but nothing useful.
After the initial review of the resulting encrypted drive, i came to the conclusion that the attacker will try to find a way around the encryption and to get the password or the decryption key. Here are the ways an attacker will attempt to obtain the information:
- Social engineering to discover the user password - Unless the user is very careful with the password choice, the hacker can attempt to discover the password by social engineering or phishing methods.
- Obtaining the decryption CD - Theft or social engineering can be used to steal or make a copy of the decryption CD.
- Programmatic collection of decryption key - A Virus/Trojan that can scan memory to find the decryption key can be distributed to the target.
- Cold boot attack - The scenario is that the decryption keys can be read from memory, but is highly unlikely to happen. The scenario functions with the fact that the RAM memory actually keeps the content for several minutes after power-off, and much longer if cooled. For this attack to succeed, the computer must be stolen while in standby mode or while running, and then within a matter of minutes the memory must be taken out and put into liquid nitrogen.
Frankly, i would be much more careful about the first three items
Encrypting the entire hard drive will make it much more difficult for the thief to extract any valuable information, and can prolong the extraction time to a point when the extracted information will be useless.
Encrypting the entire hard drive will cause performance reduction of the disk subsystem, but this is always acceptable when compared to the protection it offers, even for home users.
Always bear in mind that no amount of encryption will protect you if you don't maintain a secure mindset:
- use strong passwords
- be careful about social engineering approaches
- store recovery disks in protected environment
Talk back and comments are most welcome