Is Microsoft really claiming pre-boot authentication (PBA) for Full Disk Encryption (FDE) is not necessary? One could certainly get that impression from recent articles (HERE and HERE) posted by the organization. The first article on “Types of attacks for volume encryption keys” lists a few known historical attacks that “could be used to compromise a volume encryption key, whether for BitLocker or a non-Microsoft encryption solution”, and the second makes statements like “For many years, Microsoft has recommended using pre-boot authentication to protect against DMA and memory remanence attacks. Today, Microsoft only recommends using pre-boot authentication on PCs where the mitigations described in this document cannot be implemented.”
I will let you read the entire Microsoft articles yourself, if you like, but here is why they have missed the big picture. Encryption of any form doesn’t provide confidentiality without authentication. For example, a computer with a SED (Self Encrypting Drive), or software FDE that boots right into a user’s account without authenticating, leaves the data completely exposed. The need for authentication is obvious, but when should it be done? The two basic choices are:
- Authenticate the user before the drive is unlocked and the OS is booted up.
- Authenticate the user after the drive is unlocked. Unlock the drive automatically, then load the OS or an application and prompt the user to authenticate.
NB: You could also do both if you are a strong believer in defense in depth.
The first choice above is where PBA comes in. PBA provides an environment external to the operating system (OS) as a trusted authentication layer. The PBA prevents any data from being read from the drive, including the operating system, until the user has confirmed he/she has the correct password or other credentials.
The second choice would normally be to have the OS prompt the user for authentication credentials after unlocking. (BTW this isn’t PCI DSS compliant: Read more HERE.) I have never heard anyone argue that it is more secure to unlock or decrypt data BEFORE authenticating, but the article does seem to be saying that if you configure your OS just right and have the correct type of hardware, PBA is not necessary. The argument goes that PBA is only necessary to protect against RAM attacks where the attacker gets direct access to RAM, either physically or through a DMA port, and extracts the data encryption key (DEK). With proper configuration and the right hardware, this is not possible.
The argument that the security of PBA is not needed is incorrect for two reasons:
1) The attacker may deploy considerable resources to get valuable data on the machine, so you cannot rule that out without an analysis of the hardware on a model by model basis. Do you know the make, model, and firmware revision of all the hardware components (including TPM and memory) in your enterprise in order to decide if you need PBA or not on a machine by machine basis? And as even Microsoft states in this older ARTICLE, “TPM-only authentication method offers the lowest level of data protection. This authentication method protects against attacks that modify early boot components, but the level of protection can be affected by potential weaknesses in hardware or in the early boot components.”
2) More importantly, memory attacks are not the only possible attacks. Once booted into Windows and the drive is “unlocked”, full disk encryption is no longer providing any cryptographic protection, which is orders of magnitude stronger than the “programmed” security an OS can provide. If you let your computer boot automatically up to the OS prompt, you are putting all your faith in OS security and that of the machine hardware. You have to trust that even though the DEK is sitting in plain text in memory, and the data is all readable, that the OS login screen is going to keep attackers out, and that OS is not going to let data leak out of the device via LAN, WAN, or other ports or connections. Modern operating systems consist of millions of lines of code and are very complex. The computer hardware also evolves rapidly. Together, they constitute an enormous attack surface with countless potential unknown vulnerabilities. It is very difficult, if not impossible, to get a reasonable degree of assurance that authentication before decryption is not required.
On the other hand PBA’s main reason for existing is to cryptographically protect the drive keys. With PBA the attack surface is much smaller and manageable. For example, the PBA application can be submitted to a Common Criteria lab for certification against the collaborative Protection Profile (cPP) for FDE Authorization Acquisition (cPP AA). Read more HERE.
The argument against PBA is really based more on usability and high total cost of ownership (TCO). For example, in the Microsoft article on “Configuring BitLocker for Tablets” they write, “deploying pre-boot authentication within their organizations which results in a diminished user experience and increases support costs (for example, a forgotten PIN).” The answer to this is NOT to lower security and compliance standards to avoid the high TCO of PBA, but rather deploy products which have full-fledged PBA that addresses these issues. For example, WinMagic’s SecureDoc offers user-based authentication, self-recovery and network connectivity at pre-boot, providing a level of usability to match security requirements.
—
To summarize, Microsoft has got this one wrong. The fault in their logic is thinking that PBA is limited to protection against memory attacks AFTER automatically unlocking the drive. They missed the whole point of PBA, which is to prevent anything being read from the drive, such as the operating system BEFORE the user has confirmed they have the correct password or other credentials. PBA is a necessary component of a FDE solution in order to fully achieve the confidentiality (and compliance) that full disk encryption is capable of providing.
