The question of whether PBA (Pre-Boot Authentication) is necessary for FDE (Full Disk Encryption), especially for tablets, came up this week. The answer is a definite yes.
First let’s recap the basics. Encryption of any form doesn’t provide confidentially without authentication. For example, a computer with a SED (Self Encrypting Drive) or software FDE that boots right into a user’s account without prompting for a password, 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.
The first choice above is where PBA comes in. According to Wikipedia, PBA provides an “environment external to the operating system as a trusted authentication layer. The PBA prevents anything being read from the hard disk such as 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. I have never heard anyone argue that it is more secure to unlock or decrypt data BEFORE authenticating, but I have heard it proposed that on tablets that maybe PBA is not necessary. The augment 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). On tablets this is not possible because the RAM is soldered in and there are no DMA ports.
I don’t buy the argument that the security of PBA is not needed on tablets for two reasons:
- I suspect that in at least some cases it will be possible to solder in sockets for memory even on a tablet. 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.
- 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. Or, as the Wikipedia article states: “The PBA prevents Windows or any other operating system from loading until the user has confirmed he/she has the correct password to unlock the computer. That trusted layer eliminates the possibility that one of the millions of lines of OS code can compromise the privacy of personal or company data”
The argument against PBA is really based more on usability and high total cost of ownership. 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 SecureDoc has user based self-help password recovery and PBConnex pre-boot networking support. Before the drive is unlocked and the OS is loaded PBConnex can connect to the SecureDoc Encryption Server to authenticate, depending on policy, automatically, with Active Directory credentials or SecureDoc credentials
