FireStarter: Is Full Disk Encryption without Pre-Boot Secure?

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.

12 Comments

marko Hajeck 2011-05-04

I work at a large financial org. that uses secureDoc with Pre-boot authen, and it works very well. Only laptop users are required to use it, and we use single sign-on also,, to minimize the password pain. I feel much more at ease now, after my laptop was stolen from my car, knowing the laptop has PBE and is now a brick, and cannot ever be used as someone else's laptop.

Chris Blunt (Axenic) 2010-06-23

As I stated above I think organisations would be mistaken in believing that they have achieved compliance if they implement FDE and skip the pre-boot. This would certainly be the case with PCI DSS as it also requires the encryption keys to be protected and organisations to have documented key management process.

Chris Blunt (Axenic) 2010-06-22

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.

Chris Green 2010-06-22

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%.

truenorthern 2010-06-22

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.

rich 2010-06-22

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.

truenorthern 2010-06-21

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.

Rich 2010-06-21

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.

Chris Pepper 2010-06-21

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...

Michael Argast 2010-06-21

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

Brian 2010-06-21

"... 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.

Michael O'Keefe 2010-06-21

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.