Data security is important. More so today than possibly any time in the past. Especially on portable devices that can be lost or stolen, but even on desktop PCs as well. I once sold some old hardware on Kijiji, one individual was extremely interested until I’d mentioned that I’d wiped the harddrives. Suddenly he had no interest in anything I had. He didn’t want the hardware, he wanted what data might be left on it.
This wasn’t a new concept but it really drove home just how important it is for everyone to encrypt their data. Not everyone is going to spend the time to wipe their devices properly before getting rid of them. And not every hard drive needs to be destroyed when you dispose of an old machine. I don’t like destroying things that work perfectly, nor do I need the 100% assurance that the data is no longer recoverable. The 99.99% assurance encryption offers is good enough, assuming you use a good passphrase of course.
- The Beginning
- The Problem
- The Solution
- Going For Broke
- Encrypting my HP Envy 13
- Additional Configuration Suggestions
- A Year With BitLocker and eDrive
- Going Forward
The first thing I bought myself in 2012 was my very first SSD. It was a 128 GB Crucial M4 and it felt (and was!) lightning fast compared to the spinning rust I’d now relegated to storage only from here on out. Like many people back in 2012 the goto software for encryption was TrueCrypt, and I’d been using this for USB sticks and files for quite some time. But I wanted to try out full-disk encryption (FDE) on the boot drive, and now seemed as good a time as any. In fact, it was probably the best time.
In the past when considering FDE you had to consider the overhead cost of encrypting and decrypting data on the fly, but by this time the AES-NI instruction set was supported on many Intel and AMD processors. This meant that the encryption process was accelerated and the overhead cost was reduced, at least when using AES.
If you’re really concerned about your data you should always encrypt right from the very beginning. This is especialy true of SSDs due to the nature of their wear levelling, unencrypted data can remain on the drive for quite some time, even if it’s been encrypted elsewhere.
So with that in mind, I used TrueCrypt to encrypt my operating system drive, as well as all my storage drives.
The drive ran flawlessly, there was never any issue with loss of data or anything. I knew that you would only get so many writes per cell, and so when the drive life indicator dropped, I thought it was a normal process, and it is. But I don’t believe the speed at which it eventually started happening was normal.
My poor M4’s life had been shortened dramtically over just a single year’s time. Dropping from 65% health left to just 18% over a 9 month span, averaging one percent every 5.7 days. What on earth was going on?!
Unfortunately there were a couple of things I didn’t know or didn’t consider that would have helped mitigate the issues FDE would cause.
- Garbage collection. Using the TRIM command an operating system can indicate to the SSD which blocks of data are no longer required, allowing the device to perform garbage collection in the background to ensure optimal performance. However TrueCrypt might not have been correctly passing this on to the drive, which made garbage collection a much less efficient process. The device would have to perform garbage collection each time a write was issued, causing the drive to read and write considerably more data for every write issued, reducing performance and wearing the drive out much more rapidly.
- Overprovisioned and unprovisioned space. Some SSDs come with some amount of overprovisioned space that has been set aside. Originally I’d thought that all drives came with it, but I’ve since learned that this might not always the case. None the less, I believe that my M4 had 7% overprovisioning, leaving me ~120 GB accessible, of the 128. The drive uses this overprovisioned space to wear level and to replace retired NAND flash cells that are no longer reliable. By using FDE the device believed it was full, limiting wear leveling to this overprovisioned space. One possible solution is to partition the drive smaller, in effect adding to the overprovisioned space the drive has available to it, increasing the drives longevity.
I speculate that for the drives lifetime it was slowly moving that 8 GB chunk around in an attempt to as best as it could wear level the drive. Inefficiently performing garbage collection, and rapidly wearing out the NAND cells in doing so. However as these things are basically black boxes, only Crucial could really say.
With this unexpected turn of events I now needed to replace the drive before it failed completely, and find a solution so the new drive wouldn’t suffer the same fate.
As luck would have it, I no longer had just one problem to solve, I had two. TrueCrypt had been discontinued by it’s authors just two months prior to the final dive on the chart above. Speculation was rampant about why the authors threw in the towel, especially given their support of Microsoft’s BitLocker and claims that TrueCrypt had unfixed security issues.
I was very weary of the TrueCrypt clones sprining up in the wake of it’s departure. Could the new authors be trusted? Would they write the code as well as TrueCrypt had appeared to be written? Which of the bunch would last and provide long term support? Things I admittedly took for granted with TrueCrypt, but couldn’t any longer. Because of this uncertainty I decided to seriously consider BitLocker, as it was highly unlikely Microsoft would drop support for it.
By this point in time self-encrypting drives were becoming quite popular and were readily available everywhere. However documentation for them was not. How were they going to work? Would I still suffer from the issues I had with the previous SSD? How would they interact with BitLocker? Then I came across two SSDs that listed Microsoft eDrive support under encryption. What was that? Surely that would work with BitLocker!
Once again documentation was scarce. Microsoft’s own documentation doesn’t even mention the name “eDrive” in the document, instead calling it “Encrypted Hard Drive”. The document also doesn’t list support for Windows 7, it might have been supported, but since the Windows 10 update was free I decided to take them up on their offer to ensure continued support. With the assumption that because Windows 8 supported it, Windows 10 would as well. This was a pretty safe bet, but not 100%.
As few drives actually listed eDrive in their specifications this limited me to just the two I’d found originally. As I was unsure if other drives hardware could be leveraged correctly, or if I’d be forced to use software based encryption with them instead. This meant it was either a Samsung EVO Pro or a Crucial MX200. In hindsight I think Samsung was the better choice, but I went with the MX200. No complaints mind you, I’ve been happy with it, but research since says the Samsung would have been the better buy.
The idea here was that since the drive was doing the encryption itself, not only would it offload the entirety of the process and be aware of what blocks were empty, TRIM commands would be properly executed as well. Resulting in a healthier, faster, and longer lived device. I have however since learned that Microsoft’s BitLocker issues TRIM commands correctly and so the original concerns were unfounded. None the less, offloading the encryption to the device itself should result in higher performance, and you wont be duplicating encryption.
Microsoft’s document above lists most of the requirements, but I found them difficult to grok initially.
For encrypted hard drives used as data drives:
- The drive must be in an uninitialized state.
- The drive must be in a security inactive state.
What I found this to mean in my experience was even a brand new from the factory drive didn’t meet these requirements. The drive needed to be completely reset using Diskpart’s clean command. This will of course wipe all the contents of the drive.
For encrypted hard drives used as startup drives:
- The previous two items.
- The computer must be UEFI 2.3.1 based and have the EFI_STORAGE_SECURITY_COMMAND_PROTOCOL defined. (This protocol is used to allow programs running in the EFI boot services environment to send security protocol commands to the drive).
- The computer must have the Compatibility Support Module (CSM) disabled in UEFI.
- The computer must always boot natively from UEFI.
In practice some of these requirements are difficult to find. At the time I was doing this there was absolutely no information on what motherboards would support the security command listed above. Few even mentioned what UEFI version they were based on. I suspect this hasn’t changed much since. What this meant was I just had to try it out and see. The last two requirements seemed easy, and should be easy, but I’ll explain why they weren’t in my case a bit later.
Not listed in the requirements, but perhaps implied through some of them, Secure Boot must also be enabled. Additionally a Trusted Platform Module (TPM) version 1.2 is ‘required’ for BitLocker. This can however be disabled via Group Policy.
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\Operating System Drives\Require additional authentication at startup Choose Enabled Check "Allow BitLocker without a compatible TPM"
Oh yeah, and all of that (except the GPO) must be set perfectly from the very beginning, or you’re going to have a bad time. If you have as many unknowns as I did going in, you’re going to start over a lot. Luckily there are some indicators along the way you can use to check your progress before you get in too deep.
Going For Broke
Before starting anything, as I was still on Windows 7 I allowed the Windows 10 update to be applied prior to moving forward. This would then allow me to do a fresh Windows installation, which is a requirement for this whole process to work.
Following the list of requirements, I booted my computer into it’s UEFI BIOS and made sure that CSM was disabled, and that Secure Boot was enabled. Next I threw in my Windows 10 installation media, which must be a UEFI enabled media like a FAT32 USB stick, otherwise UEFI boot wont work and the whole process will fail. Windows quickly installed, the whole process had felt so easy, too easy. I’d done all this before of course, but I expected to encounter some issues, extra options, something. Once booted into Windows, I started up BitLocker. First issue.
As previously explained, BitLocker requires a TPM. That wasn’t listed on Microsoft’s documentation for eDrive, but is of course listed as a requirement for BitLocker itself. I’d apparently neglected to read that documentation. Thankfully after some quick Googling I found the solution above. Back in business!
BitLocker now allowed me to encrypt the drive and finished successfully. Great success! What an easy process, all those requirements, I guess my system met them with ease…. Wait, but how can I check? Is there a way to see if you’re actually using hardware encryption? The wizard never presented me with any extra options. Did it really work?
Back to Google. After some searches I found you can check the status of BitLocker via a command line utility. Using an administrative command prompt I typed the following, which produced the subsequent output:
> manage-bde -status BitLocker Drive Encryption: Configuration Tool version 10.0.14393 Copyright (C) 2013 Microsoft Corporation. All rights reserved. Disk volumes that can be protected with BitLocker Drive Encryption: Volume C: [System] [OS Volume] Size: 465.21 GB BitLocker Version: 2.0 Conversion Status: Fully Encrypted Percentage Encrypted: 100.0% Encryption Method: AES 128 Protection Status: Protection On Lock Status: Unlocked Identification Field: Unknown Key Protectors: Password External Key Numerical Password
I learned that if the Encryption Method field read “Hardware Encryption - 2.16.822.214.171.124.4.1.42” you were good to go. So of course mine read “AES-128”. Which is the default cypher Windows 10 uses. No wonder it had been so easy, it didn’t work. But why didn’t it work?
This is when I learned what uninitialized and security inactive meant. I’d thought that as the drive was brand new and untouched it met those requirements. Nope! So I threw my old M4 back into the machine and booted off it (in hindsight, this working without turning off UEFI boot was probably another indicator of more issues I’d yet to discover). I then opened an administrative command prompt and performed the following commands:
> diskpart Microsoft DiskPart version 6.1.7601 Copyright (C) 1999-2008 Microsoft Corporation On computer: <name> DISKPART> list disk Disk ### Status Size Free Dyn Gpt -------- ---------- ------- ------- --- --- Disk 0 Online 119 GB 0 B Disk 1 Online 465 GB 0 B DISKPART> select disk 1 Disk 1 is now the selected disk. DISKPART> clean DiskPart succeeded in cleaning the disk. DISKPART> exit Leaving DiskPart...
In the above, the 465 GB disk was the new drive and the one I wanted to clean. If you were doing this on your machine the listed disks would surely differ. Also important to note here, there’s another indicator for why things weren’t working, though I’d missed it when I did this initially, not realizing why it’d be an indicator. Under the Gpt column there should be an asterisk to indicate the drive has been formatted GPT instead of MBR. This is a requirement for a native UEFI boot. As you can see there was no asterisk. My system was not booting UEFI despite being set to do so, but I wouldn’t realize this yet.
Once the drive was ‘cleaned’ I started from the beginning and tried the whole process again. This part of the process was infuriating, I don’t know how many times I installed Windows and fiddling with settings. I opened msinfo32.exe and it had “Legacy” listed next to “BIOS mode”. What?! How could this be, I’ve set all the settings, why on earth was UEFI not working?
Through all this trial and error I found another useful indicator, similar to the one above. First, when you’re installing Windows with this in mind, you must click custom during the install. I do this out of habit so I didn’t realize this was a requirement, but it would seem that it is. Then create a partition that uses up the entirety of the drive in question. Setup will then prompty you that it must make some additional partitions and you must allow it to do so. Here’s where the indicator is. If the setup created four partitions, it’s created a GPT drive and UEFI is working. If it created just three partitions, it’s not and you’ve got to go back and figure out why.
After hours of frustration and Google searches I was about to give up. I couldn’t even get far enough to get UEFI working to start troublingshooting the potential next issue, would it support that command protocol that was required, and how would I figure out if it did. Just as all hope was lost I stumbled upon the issue. It was my old ATi Radeon HD4870, it was preventing UEFI from working and forcing legacy mode.
I removed the card and switched over to the onboard video and sure enough, UEFI mode worked. I got my four partitions during the setup. I’d at least made it that far, I might as well push on. With Windows 10 installed, TPM requirement disabled via GPO, I opened BitLocker one last time… And encrypted my drive.
> manage-bde -status BitLocker Drive Encryption: Configuration Tool version 10.0.14393 Copyright (C) 2013 Microsoft Corporation. All rights reserved. Disk volumes that can be protected with BitLocker Drive Encryption: Volume C: [System] [OS Volume] Size: 465.21 GB BitLocker Version: 2.0 Conversion Status: Fully Encrypted Percentage Encrypted: 100.0% Encryption Method: Hardware Encryption - 2.16.8126.96.36.199.4.1.42 Protection Status: Protection On Lock Status: Unlocked Identification Field: Unknown Key Protectors: Password External Key Numerical Password
Finally. Finally it read Hardware Encryption. But now I had a new problem. Onboard video sucks! Actually I had two problems again, my power supply couldn’t support the newer GPUs. So I replaced both of those. The whole project of encrypting my system drive cost me considerable effort and money, but it was worth it. Everything I learned, the sense of accomplishment at the end, the new GPU I now had an excuse to buy. Definitely worth it.
Encrypting my HP Envy 13
Fast forward to January 2016 when I purchased a 13” HP Envy, the first device I’ve owned with a TPM. The unfounded assumption was that because this device had a TPM, the rest of the requirements would also be included. However I’ve been unable to confirm that with HP, nor have I managed to get hardware encryption to work.
The early indicators mentioned previously showed that the whole system was in fact booting UEFI from the start. The disk was formatted GPT, Secure Boot was enabled, the TPM was turned on and BitLocker was happy with it. But still no hardware encryption.
I contacted HP about this, but all that they could tell me was that I didn’t have a TPM, because no consumer laptops come with TPMs. Despite my insistence that I did in fact have one, as it was listed in the UEFI BIOS, Device Manager under “Security devices”, and that the TPM’s status was “ready for use” as listed by tpm.msc. HP’s consumer support was very helpful… So I didn’t get to ask further about hardware encryption support.
So I went to Google. Again. I looked up the drive that’s in the Envy and it was a Lite-On L8H-256V2G-HP. The -HP model was not listed on Lite-On’s website, but the specifications for the non-HP model listed data encryption, supporting AES-256. However it didn’t list any of the specifcations for this support, eDrive, TCG OPAL, or IEEE 1667, etc… So possibly the issue lies here, the drive might not be supported. I tried to contact Lite-On for further information but received no response.
Another possibility is the installation of Windows. The laptop shipped with Windows 10 Home installed, which I upgraded through the Microsoft Store to Windows 10 Pro. I think this was a mistake, because the Pro license is attached to the store account, which I have to activate after the installation is finished. Which means Windows installs as Windows 10 Home from the beginning, and then gets upgraded after the installation is all said and done. This might affect how the whole process works.
Fortunately it’s not a big deal anymore, as I’ve learned that TRIM commands are sent correctly with BitLocker. However the drive doesn’t provide much info in the S.M.A.R.T. output, and CrystalDiskInfo doesn’t seem to have much support for Lite-On SSDs as it seems unable to decypher many of the fields. I might consider upgrading the SSD in the future to something that should be supported, but for now it’s sufficient the way it is.
Additional Configuration Suggestions
One more thing to consider when you’re looking at BitLocker GPOs, you can change the default cypher to be used on system drives and data drives with the following GPOs. Each offers a different selection of cyphers but choose the one that suits your needs.
Computer Configuration\Administrative Templates\Windows Components\BitLocker Drive Encryption\ - Choose drive encryption method and cipher strength (Windows 10 [Version 1511] and later) - AES-CBC-128-bit [default for removable drives] - AES-CBC-256-bit - XTS-AES-128-bit [default for OS and fixed] - XTS-AES-256-bit - Choose drive encryption method and cipher strength (Windows 8, Windows Server 2012, Windows 8.1, Windows Server 2012 R2, Windows 10 [Version 1507]) - AES 128-bit [default] - AES 256-bit - Choose drive encryption method and cipher strength (Windows Vista, Windows Server 2008, Windows 7, Windows Server 2008 R2) - AES 128-bit (with Diffuser) - AES 256-bit (with Diffuser) - AES 128-bit [default] - AES 256-bit
A Year With BitLocker and eDrive
Since it was installed a year and 3 months ago the MX200 has written on average over 56 GB per day. Totalling 25,825 GB with a power on time of 8,3611 hours. Despite that rather high number of writes per day2 the drives health status has only fallen by 6% to 94% remaining.
Unfortunately I don’t have the first 20% of the M4’s life to compare to, nor does the M4 log the number of writes. And really the comparison would be unfair anyway, as the drives different vastly in capacity. The MX200 has considerably more spare to wear level.
The M4 isn’t dead yet though. It sat unused for 7 months, but I decided to put it back to use as a scratch drive. When the drive was removed it was at 17% health remaining, and there it’s remained for the past three months. It seems considerably more happy now in this configuration, used mainly for Photoshop, Lightroom thumbnails, and short lived virtual machines. What will be interesting to find out is what happens with the M4 drive when it hits 0%, but at it’s current rate it looks like it’ll have a pretty decently long life after all.
Since switching to Windows 10 and BitLocker over a year ago, Microsoft has changed the minimum hardware requirements for future devices running Windows 10 Mobile and Desktop operating systems. They’ve made TPMs a standard requirement for all Windows 10 Mobile devices as well as desktops and laptops (but not servers or IoT devices).
I hope that this will mean greater out of the box support for self-encrypting drives and encryption by default on Windows machines in the future. Apple has been encrypting by default since Yosemite, and many popular Linux distributions have offered home folder and drive encryption as an option during the installation process. Microsoft should definitely be offering this as an option during the installation and/or first use of a device, if not by default. They need to catch up.
Personally, I’m more than happy to continue using BitLocker. Once all my ducks were in a row BitLocker’s been flawless so far as I can tell. It’s stayed out of my way, it’s been reliable, and I’ve noticed no issues with SSD wear so far. And of course, I keep regular (encrypted) offsite backups, as everyone should! In case something does happen, I wont lose my important data.