|As illustrated in this blog post, encryption can result in irrecoverable loss of data. It is strongly recommended that you take a backup before using BitLocker to encrypt existing data. The approach outlined here worked for me but you may not be as lucky. Use at your own risk!|
Rather than spend lots of time researching the technology, I uncharacteristically jumped head first into the world of Bitlocker and clicked “Turn BitLocker on” for the drive mentioned below:
As you will read shortly, this didn’t go too well but before we get into the problem/solution, I’d like to describe the context first. I would suggest you read this even if you are already in a bad situation and are looking for a quick solution (e.g. your data is partially encrypted with BitLocker and you can’t access it), as there are some useful articles mentioned here that might help you understand the issue.
The example hard drive (victim) used in this blog is…
- A Buffalo Ministation 1TB USB 2.0 Slimline Portable External“. Note that this is a USB 2.0 drive and is notan SSD which might explain the slow encryption/decryption times.
- A removable data drive, meaning that it does not contain any OS or system data. This is relevant in that encrypting an OS drives requires usage of a TPM and/or startup key stored on a USB flash drive
- Secured using the Password unlock method – I would consider a more secure option if the data were more sensitive (see below).
The drive has a single volume stored as an NTFS file system:
Scope of this blog
It’s important to note the narrow scope of this post – we are only discussing usage of Bitlocker to encrypt aremovable drive using a password with Windows 8 Pro. This is perhaps one of the “simplest” options and probably one of the most likely that consumers will choose as specialist hardware isn’t required and everyone understands and uses passwords (despite the growing fear that passwords should die). There are anumerous other deployment scenarios that would need to be considered if rolling out to an Enterprise that might have specialist hardware available and more stringent security requirements, but the options I have selected are probably “good enough” for the data contained on my personal external USB drive:
- 128-bit AES with Diffuser algorithm (default option in Windows 8 Pro, which is what I’ve stuck with for no reason other than simplicity)
- 128-bit AES without Diffuser algorithm
- 256-bit AES with or without Diffuser algorithm
- Operating system/system
- Removable data drives – the subject of this blog
- Fixed data drives
- Unlock method – options differ drastically if encrypting an OS volume:
- TPM only
- TPM + PIN
- TPM + startup key
- TPM + PIN + startup key
- Startup key only
- Removable or fixed data drives:
- Password – this is the method I’ve used for this blog. I don’t have/need a Smart card infrastructure.
- Smart card
- Automatic unlocking
There are also a bunch of other more granular options that could be implemented depending on what level of security is required. For example, it is possible to deny write access to removable drives that are not encrypted with Bitlocker.
- I attempted to encrypt the drive using the Password unlock method from the Windows 8 Pro UI.
- After around 8 hours, the encryption process appeared to be stuck at 94%. The physical drive was also producing a slightly alarming clicking sounds that I have not got to the bottom of yet (presumably indicating a hardware fault).
- I clicked “Pause”. The encryption dialogue locked up and after an hour or so I attempted a reboot.
- Subsequent attempts to access the drive failed- upon entering the (correct) Bitlocker password the UI would freeze. In short, the drive and data were no longer accessible.
It’s probably worth re-stating the obvious here: if you don’t have either the password, recovery password, or recovery key, no solution will restore access to your data. It’s nearly currently impossible to access BitLocker-encrypted data after removing all BitLocker keys because this would require cracking 128-bit or 256-bit AES encryption.
Even if you do have one of the aforementioned recovery items, we are still in a pretty bad situation. Encryption is only partial and we can’t interact with the drive via the UI. There is no guarantee that the BitLocker Repair Tool will get your data back in the same way it did for me.
Caveats out of the way, let’s move on…
- The password, recovery password or the recovery key for the encrypted volume. Note that various article and forum posts suggest that the password alone is not sufficient (stating that some combination of the recovery password or key are required in order to repair a Bitlocker volume) – thepassword alone was sufficient to repair my drive in this case (I assume this changes if using another drive type and/or unlock method)
- A volume with at least as much space free as the partially encrypted volume. This can be a partition on an external or internal drive, although be prepared to remove any existing data before following this process (if the decryption process is successful, data on this volume is removed). Contrary to what various knowledgebase articles indicate, a secondary USB drive is NOT required for the scenario described here. As far as I can tell you just need a spare, empty partition that is at least as large as the Bitlocker encrypted drive.
The steps described below involve usage of the BitLocker Repair Tool to decrypt data held within the inaccessible volume. This is included with Windows 8 Pro but may need to be downloaded if using an earlier OS. Note that the process is simplified because a.) I chose the password unlock method and b.) we are repairing a non-OS volume (negating the need to copy the repair tools to a location that is accessbile during start up).
- Create a 1TB partition dedicated to storing decrypted information during repair (I.e. the drive should be formatted before following the process below)
- Use the BitLocker Repair Tool, targeting the spare, empty partition. I ran “repair-bde encrypteddriveletter: emptydriveletter: -password” (you will be prompted to enter the password used to lock/unlock the volume)
- Decryption will probably get stuck at the same point as encryption (in my case 94%), at which point hit cntrl+c at the command prompt to interrupt the decryption process
In my case, my decryption log file looked like this:
|LOG INFO: 0x0000002aValid metadata at offset 8832512000 found at scan level 1.LOG INFO: 0x0000002b
Successfully created repair context.
LOG ERROR: 0xc0000037
Failed to read sector at offset 9211592704. (0x00000017)
LOG ERROR: 0xc0000037
Failed to read sector at offset 9211593216. (0x00000017)
…followed by around 20 similar entries that differed only by the offset value
Your data should now be decrypted on the original problematic volume, and the new drive will contain the partially decrypted files (unless the process completes to 100%, in which case these files will be removed).With any luck, you should now be able to view your unencrypted/insecure files on the problematic drive. Hoorah! J
What went wrong?
I can’t be 100% sure but my best guess is that my external USB drive is suffering from a hardware fault, meaning that sectors located somewhere near the end of my drive are inaccessible. This is based on the decryption log (showing failure to read sectors at a late offset) and the scary clicking sound that I mentioned earlier.
- The most important lesson of all here is to back up the data that you wish to encrypt before starting the encryption process. As shown here, if something goes wrong it might be difficult or impossible to recover your data (I was lucky).
- You do not always need a recovery password or package to decrypt/repair a drive – just the original encryption password worked in my case (this depends on the unlock method chosen in the first place). As an aside, note that you can backup your recovery key to a Microsoft account (i.e. store it in the “cloud”)
- Encryption can takes ages! This drive took around 8 hours.
- The decryption process doesn’t necessarily need to hit 100% in order to get data back, especially if encryption didn’t finish in the first place (Bitlocker encrypts/decrypts on a per file basis as opposed to encrypting or decrypting an entire drive in one operation). Note that if decrypting to an image file (using “pathimagefile.img” as the OutputVolumeOrImage parameter), “partial” decryption may not succeed (I originally tried this option without success – I hit 94%, stopped decryption using cntrl+c and the image file appeared to be unusable/corrupt).
- Multiple partitions are not required if encrypting a removal data drive. I would guess this is also the case for an internal data drive but haven’t tested this.
- It’s much quicker to “encrypt” used space only as opposed to encrypting a full drive, especially if said drive already contains data. See the screenshot and notes below.
My revised (more precautious) approach to implementing BitLocker on new removable drives
For what it’s worth, the approach I’ve selected for my personal data (which isn’t particularly sensitive) is:
- Backup (copy) data somewhere else and test the backup works (i.e. Try to open some files)
- Format drive that will be encrypted using BitLocker
- Run chkdsk to ensure there are no bad sectors
- Turn on BitLocker on formatted drive, opting to encrypt “used disk space only” (see screenshot below, this is only really appropriate if encrypting a new drive)
- Copy files back to the BitLocker-enabled drive
- (optional) optimise drive using your favourite disk tool, e.g. PerfectDisk
- Reboot machine and ensure you can still access files
- Lock/unlock drive and ensure you can still access files
- When happy remove backup files
This approach has worked well for me for the last week or so with no issues thus far. Having said that, I’m new to the BitLocker world so would welcome any further thoughts in the comments.
Suggested further reading