Blog: BitLocker

For some versions of the TPM chip found in the Lenovo ThinkPad T420, you will receive an Access Denied error message when attempting to encrypt the hard disk if you have a group policy enabled that restricts CD/DVD access.  Apparently, some models of TPM chip are seen by the system as a CD/DVD device, and will not function correctly if it has been disabled via Group Policy. 

The fix is to just disable the group policy until after the disk has been encrypted and the PIN has been setup.  Once it has been encrypted you can reapply the Group Policy and it will continue to function normally.

There has been a lot of discussion about whether a BitLocker pre-boot PIN increases security or not. The primary argument we have had is related to the PIN providing a layer of security between an attacker with physical access and the Windows credentials.

If a user is running Windows 8 or later and has encrypted the OS volume, there is a GPO designed to protect against Windows password guessing. If Windows credentials are cached, which is common for laptops, it is possible to bypass account lockout settings if the system doesn't have access to a domain controller. However, this GPO will help protect a system even if it can't reach a domain controller.

Administrators can set the “Interactive logon: Machine account lockout threshold” Group Policy under \Computer Configuration\Windows Settings\Security Settings\Local Policies\Security Options.

When applied, this setting will cause the following message to be displayed shortly before the machine account threshold is reached. After the threshold is exceeded, the system will reboot and require a BitLocker recovery key in order to boot.

When I was upgrading to Windows 10, I decided to install from the Current Branch for Business ISO rather than an in-place upgrade since it'd been more than three years since I'd performed a clean install. Immediately after the Windows 10 install and activation, I decided to enable BitLocker since it seemed like a good idea to do this as early in the process as possible.

After enabling BitLocker and setting a PIN I rebooted and was presented with the BitLocker passcode screen. I entered the code and pressed Enter and the system stayed on the BitLocker screen. After several minutes, I forced power off and then powered the laptop on. The BitLocker screen appeared again with the same results after entering the code. After repeating this cycle several times, I pressed the escape key in order to enter the recovery key. Rather than prompting for a recovery key, the system booted directly into Windows and, after logging in, displayed an error message about C: not being encrypted because the key could not be obtained from the TPM chip.

I tried several things related to UEFI-only boot and UEFI/legacy boot in the laptop startup screens without any success. Every time we changed any boot options on the laptop and then saved and restarted, the system could not find the boot drive until we forced power off. Then, the boot drive could be found.

Finally, I installed Windows patches before trying to enable BitLocker and it worked perfectly.

A system was running GUID partition tables (GPT) in place of MBR and UEFI instead of BIOS. After a restor from backup, when trying to enable BitLocker, I got an error saying, “Element not found”. This vague error message did not provide any helpful results on Google, so I tried running BitLocker from the command line. Running the command “manage-bde –on C: -tpmandpin” gave me an error code (0x80070490) to go with the vague message. A Google search for the error code yielded this link to TechNet that says this is a known issue when moving hard drives between systems using the UEFI boot firmware and that running “bcdboot %systemdrive%\Windows” command will fix it. The command did not fix the problem, but it pointed me in the right direction. Some more searching led me to this link that talks about how to manually delete the “bootmgfw.efi” file in the UEFI boot partition. After deleting the file and then running the “bcdboot” command from the TechNet article, BitLocker encrypted the drive.

Crucial M500 SSDs support self-encrypting drive (SED) technology which allows BitLocker for Windows 8 to simply be used for encryption key management rather than software-based encryption.  Out of the box, the drive encrypts all written data and decrypts all read data - and functions like a non-SED drive until key management software like Windows 8 (and Server 2012) BitLocker is used. [more]

When you turn BitLocker on using Windows 8 and a compliant SSD like the M500, you don't have to wait for the whole disk to be rewritten and it's encrypted.  Thus, you can encrypt the whole drive in a couple of minutes or less.  As far as BitLocker and Windows is concerned, it functions just like traditional non-SED drives do regarding pre-boot passwords, recovery keys, etc. 

An interesting spec is Crucial states their SSDs are designed to support 72TB total bytes written (TBW) - which is equal to 40GB per day for 5 years.  It stands to reason that if you don't have to rewrite every byte of an SSD when you use BitLocker to encrypt or decrypt the whole drive, it should help the life expectancy of the drive. 

So, since the drive I/O specs include the hardware encryption overhead, you lose no performance whatsoever when you implement whole disk encryption using BitLocker for Windows 8 on these drives. 

A very basic description of Crucial M500 encryption can be found at

http://forum.crucial.com/t5/Solid-State-Drives-SSD-Knowledge/An-introduction-to-the-encryption-features-of-the-M500/ta-p/128272 

More specs are available (since this is a Micron drive) from:

http://www.micron.com/~/media/Documents/Products/Data%20Sheet/SSD/m500_2_5_ssd.pdf

I was working in the Command Processor to fix a BitLocker problem. I needed to enter a couple of commands which were posted in the CoNetrix blog. To be sure I didn’t make any typing mistakes, I copied the first command into Notepad where I verified the input and then copied and pasted into the Command Processor. Doing that I got an error, the command wouldn’t work. I retried several times, none were successful. Eventually I resorted to typing the command directly into the Command Processor and, surprise, surprise, it worked.

For the second command I committed the same error (not always a fast learner). I got errors when pasting the command and success when I typed the command directly. [more]

Since this happened to me twice I began to research the problem with pasting info into the Command Processor and discovered it was a problem with two different characters entered for the dash (-) character. While one character was entered by pasting, a different character was entered when manually typing. In testing I discovered this is true both in Notepad and the Command Processor. (If I retyped the dash in Notepad before copying and pasting into the Command Processor, the command worked.) The problem comes because there is no visible difference in the characters, both look the same in Notepad and Windows processor, but behind the scenes, in the code for the characters, there is a difference. While I haven’t researched this beyond the dash characters, I would imagine there could also be problems with other special characters as well.

The gotcha is not to assume characters are the same just because they appear the same.

Bit Locker encryption on my new laptop asked for a recovery key every time I booted the system. Nothing had been changed within the system to cause this behavior. In an attempt to stop this from happening I un-encrypted and re-encrypted the drive. When the re-encryption was complete I rebooted and it asked for the recovery key. I went into the Bit Locker settings and suspended the encryption and reboot without an issue. I then re-enabled the encryption, reboot and it did not ask for the recovery key again. So if your system begins prompting for the recovery key. Disable and then re-enable Bit Locker and it resolves the problem.

One of our information security auditors recently had the motherboard on his laptop replaced to fix the "shutdown on its own" issue he'd been having for a while.  When he got the laptop back, his BIOS level fingerprint logins (to unlock the hard drive and BitLocker key) were no longer working.  Also, the x64 VMware machine he uses for audits would no longer boot.  The VM issue was pretty clear.  The CPU virtualization setting in the BIOS was disabled and needed to be turned back on.  The fingerprint issues, however, took a little more digging to figure out.  Eventually we realized the TPM on the new motherboard was not activated.  Once we activated and initialized the TPM, then turned BitLocker off and back on (without decryption), all the pre-boot login information unlocked by the fingerprint started working again.

UEFI problems:  I have found that Bitlocker will not be able to use the enhanced PIN as specified in our GPO on the Thinkpad T420 when using UEFI.  The problem lies in the BIOS (yes, it is still called the BIOS, even though it is UFEI) and it requires an updated version so that the keyboard keys are represented properly (alpha characters) during the boot phase of the startup. My T420 had version 1.24 of the BIOS, and version 1.25 seems to fix this issue. Here is a snippet of the Release Notes for 1.25: [more]