As my colleague Garry McCracken ably reported earlier in this blog (Is Microsoft claiming Pre-Boot Authentication for FDE is not necessary?), Microsoft, in its wisdom, has declared that pre-boot authentication (PBA) for full-disk encryption (FDE) is not strictly necessary – except in cases where certain other security measures cannot be implemented.

Really? That would be revolutionary.

On the technology side, it is unusual, to say the least, to declare authentication for an encryption product is not needed. I have never heard anyone argue that it is secure to unlock or decrypt data before authenticating. Encryption in any form doesn’t provide confidentiality without authentication.

On the user side of FDE, enterprises would be delighted if PBA were not needed. As an example, a password reset for FDE is typically cumbersome and time consuming, because pre-boot networking is not available for most FDE products, and thus a network-based Active Directory password reset cannot be used. And, if you are currently using a smartcard or other multi-factor authentication for PBA, dropping PBA without sacrificing security would be wonderful. “No PBA and the associated complex support” would save enterprises tons of time and money.

Some background info regarding FDE and PBA

It’s important for a computer to run securely, and remain secure against all kinds of attacks. Windows, like all operating systems, has a login screen so that only authorized users can access the computer. With millions of lines of code for today’s operating systems, representing a large attack surface, not only Microsoft, but numerous antivirus, antimalware, anti-intrusion, and other hardware and software vendors are hard at work on securing the computer – and make money doing it. (Spoiler alert: They actually are not winning! As you are no doubt aware, hackers have dominated the IT world in recent years.)

But here’s the big gap: The OS and its applications can’t do much when they aren’t running. If an attacker gets physical access to the laptop and can read the data on the disk, the data – the most valuable item of the computer – is compromised, and the OS security can’t do a thing about it. This is where FDE comes in. FDE’s role is to take care of the computer’s security when the OS is not running, when the power is off. The OS (and numerous helpers) take care of security when the OS is running.

As a vendor in computer security and disk encryption, we expend lots of our resources on PBA. While, in Windows, an app can straightforwardly access the screen, keyboard, mouse, smartcard, network, and the various hardware components, the same cannot be said for PBA software. Without a Windows driver, PBA software must work with, for example, an on-screen keyboard and a mouse. To enable stronger authentication, PBA software must deal with various smartcards and readers. And to benefit from versatile and powerful network technologies, PBA software must deal with various Network Interface Card hardware and protocols. Given this level of difficulty in PBA software development, it’s unsurprising that Microsoft BitLocker does not support the on-screen keyboard, smartcards, or pre-boot networking.

It’s important to note, however, that OS security is significantly more complex than FDE. Traditionally, FDE is needed only if the attacker can physically get the computer (disk). FDE’s simplicity makes it much more secure than OS security. An OS can be attacked at any time, through the network, or by someone sitting on the other side of the planet. FDE is needed only if the attacker gets hold of the computer, whether a laptop or a virtual machine in the cloud. It’s possible to make FDE much more secure than OS security because its attack surface is very small compared to that of the OS, which is orders of magnitude larger with all kinds of possible attacks on software and hardware, over the local network, or via the web.

The Advantages of FDE and PBA

“Data-at-rest” encryption can take various forms. Because of its simplicity, FDE has been adopted as the standard form of protection for laptops and computers in general. FDE essentially uses cryptography to protect all the data on disk. “Data on disk” includes the OS, its hardware and software drivers, the applications, the antivirus software, and (of course) the sensitive and non-sensitive data. All of it is protected by a single, strong technology: cryptography.

So, when recommending using PBA only where other mitigations cannot be implemented, Microsoft is implying that:

• memory attacks can be prevented with mitigations
• they are the only possible attacks you would face when you don’t use PBA, and use OS security instead.

For the first point, the attacker may deploy considerable resources to get to the valuable data on the machine, so you cannot rule it out without an analysis of the hardware on a model-by-model basis. For example, Microsoft makes this very point in relation to the recent vulnerability in certain TPM chipsets. Do you know the make, model, and firmware revision of all the TPMs in your enterprise in order to decide if you need PBA or not?

But far more questionable is the second point. Is it correct that by not using PBA you would face only memory attacks? Do you feel lucky? Are you comfortable with taking that risk?

With PBA, the attacker gets the laptop, turns on the computer and sees only the PBA screen. Without the correct password the attacker can do nothing. For all intents and purposes, the laptop is a brick. It and its data are cryptographically protected.

Without PBA, the machine boots to the OS, unencrypting the data on the disk in the background. Even though the Windows login screen is effective protection against attacks via the user interface, many other types of attacks can now be applied to the computer. With physical access to the machine, the attacker can prepare, measure, and attack using the boot process of the computer, applying a logic analyzer to monitor the flow of data between the disk, CPU, and memory during the boot process to capture the disk’s encryption key.

This is only one example. With hackers becoming more sophisticated and resourceful all the time – and they will not advertise how, or even whether, they can attack a given system – will you elect to stay with the no frills but questionable baseline?

Risk management is a balancing act. While ‘no PBA’ could be secure enough for some users, we believe the increase in attack surfaces, and with it vulnerability, is not a good calculated choice for security conscious users. In other words, it would be an unwise choice.

Bottom Line: ‘No PBA’ is not a wise choice for enterprises

Microsoft’s reasoning that you don’t need PBA because the  known  memory attacks are difficult to pull off on most modern hardware is simply wrong because the threat is much more than just those  attacks.  I can imagine Microsoft wishes it were true because they don’t have a full-fledged PBA and hope that  TPM auto boot is good enough.  That would save them spending a lot of work and resources on PBA.  But wishing something is good enough doesn’t make it good enough, not from a security perspective, and not from a compliance perspective.  A more sophisticated approach is needed and Microsoft, as a leader, should communicate that clearly.