This post was written by Ted Pan.
For those of you who were around during the original release of Microsoft’s BitLocker, previously known as Secure Startup, you will remember that it was meant to completely eliminate the necessity for third-party security software. Yes, BitLocker was going to secure our machines against all forms of attack and make sure we never again lost data.
BitLocker is actually pretty good. It is nicely integrated into Windows, it does its job well, and it is really simple to operate. As it was designed to “protect the integrity of the operating system,” most who use it implemented it in TPM mode, which requires no user involvement to boot the machine.
And that’s where problems started.
Hands up: How many people have a TPM chip on their laptop? Everyone, we bet. It’s a ubiquitous piece of hardware nowadays. OK, another show of hands for those who have enabled, and taken ownership of the chip? “Taken ownership?” You remember going through the personalization phase of the chip, enabling it in the BIOS, etc.? Remember, all TPMs are shipped disabled and deactivated.
You didn’t do that before you deployed your laptops? In that case, BitLocker will be a bit of a struggle for you.
Fact 1. To use BitLocker without adding additional authentication, you need an enabled, owned TPM1.2+ hardware chip.
For those of you who did go through this, we congratulate you on your foresight. The only problem is:
Fact 2. BitLocker with TPM-only protection is vulnerable to cold boot, Firewire, and BIOS keyboard buffer attacks.
There are some pretty simple attacks on TPM-only machines. Search for “BitLocker Firewire,” “BitLocker cold boot,” or “BitLocker forensic tool” and you’ll find lots of research, and even a few tools that will unlock your nice “protected” machine and recover the data. There was even a trivial method that allowed an attacker to gain access to a BitLocker protected system as late as November 2015 (8 years after BitLocker’s initial release); this has only recently been patched.
To make a machine secure, and by that we mean give you protection against having to disclose lots of personal information to all your customers if the machine goes missing, you need to use some form of pre-Windows authentication (with or without TPM; it makes no difference). Even Microsoft recommends this mode of operation.
For BitLocker, turning on authentication gives you a couple of choices. You can set a pin for the machine, and, if you want, you can also use a USB storage device (a memory stick, not a smart card) as a token. We wrote “pin”; we certainly did not write “your Windows user ID and password.” In fact, we didn’t mention users at all. BitLocker officially supports one login, so if more than one person uses a machine, you’re going to have to share that with everyone.
Some more facts:
Fact 3. BitLocker is secure only if you use a pin or USB stick for authentication.
Fact 4. There is no link between your Windows credentials and BitLocker credentials.
Fact 5. BitLocker does not support the concept of more than one user.
Even Microsoft’s official advice tells you to use a 6+char pin, plus TPM for authentication—no using it in TPM-only mode.
So now your lucky BitLocker users have PCs protected, maybe with a TPM, but certainly with some form of authentication that is shared between the owner of the machine and with you (as administrator), and probably the system guys. You probably have an Excel spreadsheet with everyone’s pin.
We hope so, because when those users start forgetting their pins, who’s at the end of the phone? The good news is the pin never changes. There’s no forced change or lifetime. That doesn’t fit with your password policy? Did we mention that the PIN can be made only from the function keys, not the normal letter keys, unless you configure a special enhanced PIN mode that does not work on non-USA keyboards? Did we mention there are no complexity or content rules apart from length?
Fact 6. BitLocker PINs are usually Fn-key based. BitLocker does not support non-US keyboards.
For all of you who have implemented public key infrastructure smart cards, bought laptops with fingerprint sensors, or who have tokens such as ActivIdentity, common access cards, personal identity verification, etoken keys, Datakey cards, SafeNet cards, etc. You’d like to be able to use them for authentication to your PCs, wouldn’t you?
Fact 7. BitLocker supports only USB storage devices and PINs—no integration with any other token.
Fact 8. Active Directory and additional servers are required to administrate BitLocker in a corporate environment.
There are Active Directory–based methods. The Group Policy Object settings will let you store the (fixed) recovery key in your AD. I’m not sure how you feel about that data getting propagated to every controller in your forest, but I’m sure you know and trust every AD administrator in your organization who (now) has access to those keys. If someone were to dump those keys and then quit, what would you do? It’s not as if the key ever expires. We guess you could write a program and then run it on every machine to recreate the keys, or write down the recovery key and give it to the user to hold onto.
Let’s review why we are going through this effort. The flippant answer is “because we were told to secure our machines,” but what does that mean? Most likely your company falls under one of the 250+ global laws defining and mandating the protection of people’s personal data, social security numbers, health information, credit card numbers, etc. Regulations such as PCI, HIPAA, HITECH, SOX, etc. You want to use BitLocker to encrypt your machines because when they get lost or stolen, you won’t have to pay fines, or tell everyone you lost their data. You lost the machine, sure, but because the data was encrypted, no one can get access to it.
To use this “get out of jail” card you need to be able to prove a couple of things:
- That the data was indeed protected at the time of loss.
- That the protection method was appropriate given the type of data.
So, applying those tests, a rule appears:
Fact 9. You need extra software to prove BitLocker was enabled and protecting the drive at the time of the theft to claim protection from personally identifiable information laws.
We know how to set GPOs etc. to mandate the use of BitLocker, but we also know how easy it is for a user to turn it off. Setting up an MBAM server with all its associated requirements (such as an additional SQL server) would increase your complexity as well as causing you to write scripts to perform automated deployments. We don’t know of anything in Active Directory that gives me a definitive answer as to the state of protection of a given machine. There’s even a command-line tool that can be run to completely (un)configure it. We need something that reports on the state of protection of a lost machine. Saying “Well, the policy says it should be encrypted” is not enough. Perhaps a reader can help out?
Let’s finally take a look at implementing this solution. You do have a 100% Windows enterprise environment, don’t you? What if you still have some XP, Vista, Business, or Macs? Are you going to leave those machines unprotected, or are you planning to run a mix of third-party software and BitLocker?
Fact 10. BitLocker encryption and administration supports only Windows—with no support for other operating systems, such as Mac or Linux.
You may think that we are not great fans of BitLocker—yet that’s far from the truth. We would use it, and would recommend it to friends. We see it as really good for technical, trustworthy users. But that’s not the market it’s being promoted for. Nothing fills us with dread more than an enterprise product that requires yet another password, requires specific hardware that is not enabled by default, presents a black screen with white text to users (so archaic), does not conform to our recognized password/PIN lifetime policies, does not work on non-USA machines, and does not have audit-friendly output for the main purpose it serves, namely, to tell us whether this stolen machine is a liability.
One of us actually likes it for the following reasons:
- Only one of the three machines he uses has a USA keyboard, so he can use Fn-mode PINs.
- It never forces him to change his PIN.
- He can turn it on and off whenever he likes without corporate IT people knowing.
- He gets to use the TPM chip, even though it took him a whole day to work out how to enable it.
- He can write fancy scripts to turn it on and off. (He’s a closet programmer.)
- He gets a nice DOS-like screen when he turns on his machine, just like 20 years ago.
- BitLocker is mostly controlled through a command-line script (Manage-bde).
- His local IT team can’t come and use his machine, or see what’s stored on it without his knowing.
- He just likes things to be done the hard way.