This FireStarter is more of a real conversation starter than a definitive statement designed to rile everyone up.
Over the past couple months I’ve talked with a few organizations – some of them quite large – deploying full disk encryption for laptops but skipping the pre-boot environment.
For those of you who don’t know, nearly every full drive encryption product works by first booting up a mini-operating system. The user logs into this mini-OS, which then decrypts and loads the main operating system. This ensures that nothing is decrypted without the user’s credentials.
It can be a bit of a problem for installing software updates, because if the user isn’t logged in you can’t get to the operating system, and if you kick off a reboot after installing a patch it will stall at pre-boot. But every major product has ways to manage this. Typically they allow you to set a “log in once” flag to the pre-boot environment for software updates, but there are a couple others ways to deal with it. I consider this problem essentially solved, based on the user discussions I’ve had.
Another downside is that users need to log into pre-boot before the operating system. Some organizations deploy their FDE to require two logins, but many more synchronize the user’s Windows credentials to the pre-boot, then automatically log into Windows (or whatever OS is being protected). Both seem fine to me, and one of the differentiators between various encryption products is how well they handle user support, password changes, and other authentication issues in pre-boot.
But I’m now hearing of people deploying a FDE product without using pre-boot. Essentially (I think) they reverse the process I just described and automatically log into the pre-boot environment, then have the user log into Windows. I’m not talking about the tricky stuff a near-full-disk-encryption product like Credent uses, but skipping pre-boot altogether.
This seems fracking insane to me. You somewhat reduce the risk of a forensic evaluation of the drive, but lose most of the benefits of FDE.
In every case, the reason given is, “We don’t want to confuse our users.”
Am I missing something here? In my analysis this obviates most of the benefits of FDE, making it a big waste of cash.
Then again, let’s think about compliance. Most regulations say, “Thou shalt encrypt laptop drives.” Thus, this seems to tick the compliance checkbox, even if it’s a bad idea from a security perspective.
Also, realistically, the vast majority of lost drives don’t result in the compromise of data. I’m unaware of any non-targeted breach where a lost drive resulted in losses beyond the cost of dealing with breach reporting. I’m sure there have been some, but none that crossed my desk.
Reader interactions
12 Replies to “FireStarter: Is Full Disk Encryption without Pre-Boot Secure?”
Everything takes time, costs money, and affects business. That’s true of non-security tools as well as security.
So the consensus seems to be the investment in FDE if you skip pre-boot is only to make compliance go away, and isn’t to improve security.
I suppose I understand that decision, but that doesn’t mean I agree with it.
Hi Rich,
With preboot, the disk is encrypted until the preboot authentication is successful, without preboot authentication, windows boots and the disk is decrypted. Then the only protection is windows authentication and all regular windows vulns are available.
If one uses preboot, you have to give the users an extra password, ideally one for each user/for each device, a big headache.
If you use pass-thru authentication for preboot, then you have issues around synchronizing the windows password and the preboot password.
A related issue is the local credentials on the mobile device expiring. Remote users that may not connect to the network directly for many months at a time. User may change their windows password via their regular workstation and then later try their encrypted mobile device and will not be able to use their new password,…
When remotely managing devices with preboot authentication, you are out of luck after a reboot, until the local user logs in.
All of this issues take extra IT time and user time which costs money and effects business.
This sounds like useless encryption. Somewhere, at boot, the encryption keys are available. Most likely, there is a slim preboot environment that automatically logs in. There’s the keys and the demise of your control.
I think WDE is most impacting to orgs that have little control over their desktop rollouts. It gets very hard to support with a myriad of competing recovery environments / “look what i bought at best buy” deployments. Most of the WDE tools support “don’t passphrase me at next boot” option that could be used for the people rolling out patches. However, it might take a patch with a .05% error rate and move it up to 5%.
A poorly implemented control is sometimes worse than no control at all in my opinion as it could lead to a false sense of security.
In my opinion, an organisation implementing FDE to assist it to achieve its regulatory or contractual compliance that doesn’t implement the pre-boot environment is not meeting its compliance obligations.
It’s interesting to think of the impact these blanket orders have. There are individuals with access to sensitive data, and I’ll bet some of those have it downloaded to their laptop like the employee in the link below, but for many of us, the corporate laptop is used to access e-mail and surf the corporate web, and to run various work-related software.
Lost Deloitte laptop with details on 100,000 pensions. As indicated by others on this post, there are bigger security issues at work here if employees are allowed to download such a large amount of confidential data to their personal systems:
http://www.accountancyage.com/accountancyage/news/2228066/100-pensioners-details-deloitte
With BitLocker, depending on the configuration, you can even turn off the encryption. I found this out when trying to install Ubuntu on a corporate laptop, that had recently been upgraded to Vista. Vista was indeed dog-slow, so as everyone must ask – what in the world is it doing as the disk churns away? Ah, the disk is encrypted, that might make a difference.
http://windows.microsoft.com/en-us/windows-vista/What-is-the-difference-between-disabling-BitLocker-Drive-Encryption-and-decrypting-the-volume
Perhaps what is lacking with the encryption rollouts is a little more transparency. I’m perfectly fine with my laptop running markedly slower, with increased problems with upgrades and installs, as it did with Vista, if this is for the greater purpose of improved security.
“… automatically log into the pre-boot environment, then have the user log into Windows.”
Compliant vs. Secure? 🙂 Their way may be compliant (“yes, we have FDE deployed”), but certainly does not improve security of the setup.
I agree with you – it does not makes much sense.
No.
Full stop. Not using a proper POA/Pre-Boot Authentication results in a significant vulnerability which is relatively easy to exploit. The keys end up in memory during the boot sequence, meaning they are accessible to a number of hacking tools, etc.
We actually included this in an internal training seminar at Sophos recently for our Sales Engineers to reinforce the importance of PBA/POA (the complexity it poses to users is a common customer refrain, especially for products like BitLocker/etc which don’t have a nice GUI for their PBA environment).
That being said, as has been commented above, a lot of people are doing this for compliance and not security (hopefully the compliance guys catch on to this trick – after all, what was the point of requiring FDE over file based encryption if you’re not going to enforce a PBA/POA?).
Argh.
Michael
Rich,
You’re glossing over a critical point. What is the encryption key used to encrypt the drive, and how is it supplied? Is this really FDE, or is it most-of-disk E, with Windows itself unencrypted so it can come up to a login prompt without user intervention?
If it’s proper FDE, it seems like there needs to be a decryption prompt before the CPU can read & boot from the (encrypted) disk. And thus some way the user supplies that, whether by password, USB token, iris/face scan, or whatever…
I do understand the pushback, although I’ve talked with plenty of large orgs who have it deployed and working fine.
I’m trying to figure out 2 main things:
1. Are most of the pushback fears unjustified? (I think they are).
2. When deployed this way, is it then merely a checkbox that doesn’t improve security?
My gut tells me *not* deploying pre-boot means you shouldn’t even bother deploying the encryption, but I posted this to get more feedback.
I have personally experienced this situation in a large organization. Implementing in this way allows the organization to meet regulatory standards. They have disk encryption and can check that box in the audit. As with all controls, whether is actually is effective is a different issue.
And, when it comes time to implement pre-boot authentication, the push back is tremendous. From business, service desk, patching teams, software provisioning, remote users,… and on and on. Pre-Boot authentication creates some major issues and of course major costs.