This week I had a frustrating incident occur that I’d never wish upon anyone again – my PGP-encrypted laptop hard drive was corrupted! Luckily, I was able to recover the data after hours of research and labor. The whole experience was a painful one and it’s really turned me off from whole-disk encryption as a whole.
The initial problem was caused by one of my least-favorite pieces of software in the world – the Ubuntu graphical installer. I was installing Ubuntu onto an external hard disk while using a Ubuntu LiveCD, and in the process of installing the OS, it overwrote the MBR on my laptop’s hard disk. This seems to be a common pitfall affecting Ubuntu users. Installing GRUB to the first hard disk is apparently the default behavior, according to several posts on the Ubuntu forums. I must have missed the “Advanced” menu option to specify the bootloader location.
Installing GRUB to the MBR wouldn’t be terrible, if not for the fact that PGP Whole Disk Encryption (WDE) also uses a non-standard Windows bootloader – a piece of software called BootGuard that prompts the user for the decryption key to the drive. Because GRUB took over the MBR on my hard drive, BootGuard would no longer execute – and thus the contents of my two partitions were stuck as encrypted with no decryption mechanism on the disk.
Adding further frustration to this issue was the fact that Ubuntu (loaded onto the external HD) wouldn’t even boot up without the laptop’s HD – because the GRUB boot loader was on the internal, encrypted HD, rather than the external HD that held the rest of the operating system.
So, I was stuck with an encrypted Windows installation and a halfway-usable fresh Ubuntu install. What’s a guy to do?
Fortunately, if there’s one thing that our office has, it’s a lot of computers. I was able to use a backup laptop to begin doing some research into recovery options.
PGP has recovery boot disks that can be used to decrypt a drive, so this was the first thing I tried. With my encrypted (and inaccessible) disk in the bay of my laptop, I booted with the PGP recovery CD. Unfortunately, this returned an error – “Internal error accessing disk, 0×80″. A common error, if you do a little googling. Something was wrong in the disk’s partition table or boot record – I would need to try another method.
The first method I found in the PGP Knowledge Base was in Tech Note 807 , which suggests creating a Windows PE recovery disk that supports PGP disk recovery. I followed this path for a while, but had some issues slipstreaming the PGP software into the disk. I gave up eventually after seeing a few other simpler methods suggested.
The simpler recovery method recommended by the members of the PGP forum and the PGP Knowledge Base was to install PGP Desktop on another PC, slave the encrypted drive to that machine, and decrypt the drive using the second PC. I was able to get the PGP Desktop software from our administrator and install it temporarily on a new computer, then cable in my encrypted drive with a IDE to USB adapter. This looked promising at first, with the machine able to recognize the drive and see its (unreadable due to encryption) partitions, but PGP wasn’t able to identify the drive as holding encrypted data on it. After a few tries (and a few hours), I decided to move 0n and try a different vector.
I had seen a post on the support forum suggesting using a Windows disk to rebuild the MBR to a normal Windows state. After doing this, the PGP recovery disc may work, since PGP is prepared to deal with a situation like this (somehow!). By doing this, I realized I would lose the GRUB bootloader info for my Ubuntu installation, so I first pulled that off the drive from within Ubuntu (cat /boot/grub/menu.lst > /home/menu.lst). This would give the UUID of the Linux installation if I ever want to try and get it working and bootable.
After doing that, I decided to just go for it. After installing the encrypted drive into a spare laptop chassis, I put the Windows disc into the CD drive, booted to the recovery console (type R when prompted), and then ran the fixmbr command for the drive. Rebooted, and…. unable to find operating system. This was progress! No more GRUB bootloader!
Finally, I put in the PGP recovery disk again, booted off it, and instead of the error I saw before, it continued on to the recovery console – and it recognized my PGP-encrypted disk!. I typed in my passphrase, and then, very cautiously, chose “D” to decrypt the drive. It very slowly started to decrypt.
The entire decryption process when running from the recovery disk takes quite a long time – on this disk (60GB), it was only about 15% along after 90 minutes. I left the computer plugged in overnight and let it run. When returning to the office this morning – it was done! I put it back into my original laptop chassis (I was using a temporary one while I rebuilt a new installation of Windows on a spare HD in the main chassis), and it booted up as if nothing had ever happened. The whole thing was pretty funny, actually – to see the little guy churning along as if it hadn’t been on the brink of death just 24 hours before.
This entire experience has left a bad taste in my mouth regarding whole disk encryption. It’s very secure, and my experience with PGP prior to this incident had been pretty drama-free, but when it fails, it fails very dramatically. PGP has very sparse documentation about the recovery process, and seems to take the opinion that their software is so reliable that they don’t need to spend much time making recovery a little bit easier. For a user who’s done nothing wrong, they make the barriers to recovery too high – I had the decryption passphrase, and a simple mistake was enough to ruin all my data. I was on the verge of scrapping the drive, suffering an unexpected data loss (which even regular backups can’t protect against perfectly).
I’ll probably avoid PGP WDE in the future, but whole disk encryption as a concept isn’t going away anytime soon. It would be good for developers to keep disaster recovery methods in mind when creating their software!