Considering Full Disk Encryption (FDE)

Microsoft’s implementation of Full Disk Encryption is called BitLocker. BitLocker is capable of being configured (by GPO or through InTune) to require TPM protection, pin-based protection, or both. BitLocker also supports a novel unlock mechanism, termed “network unlock”. When network unlock is enabled, a server-based service runs on the network in order to provide the information needed to allow the machine to boot. This is useful in preventing data exfiltration attempts. While using Bitlocker without a PIN is more convenient for the end user, it is also more vulnerable to hardware-based attacks.

Linux Unified Key Setup (LUKS) is a popular software package used by various Linux distros and is capable of volume-based encryption (encrypting only a particular disk partition) or FDE. LUKS works by generating “master keys” in “slots” at the start of the block device. Since each possible “slot” corresponds to a decryption key capable of accessing the volume, it allows for auditability. A user password unlocks each master key and is required in order to access the volume. A limitation of any password-based system, LUKS included is that it is only as secure as the weakest password which can unlock the volume! Brute-forced attacks whereby an attacker tries every possible combination is very much possible with LUKS. LUKS by itself does NOT rely on or require a TPM.

Earlier versions of android had support for full-disk encryption, but it was not a widely adopted or defaulted feature. It required a user to enter a PIN (which was used to unlock access to a master key) at boot before booting to the lock screen. Newer versions of Android use what Google terms “file-based” encryption which is a new spin on FDE. Android’s File-based encryption allows the phone to boot to the lock screen in a limited capacity. Calls are possible, notifications come through if users configure lock screen notifications, but access to data is not possible until the first unlock. (This is why Android requires you to provide your PIN on reboot, even if you’re in a trusted location! It needs this information to unlock the master decryption key.) Notably, FDE in Android as of recent versions is enabled by default, no user interaction required.

iOS relies on cryptographic secrets stored in a hardware chip, similar to a TPM termed a “secure enclave”. This secure enclave is responsible for processing cryptographic operations on behalf of the operating system, somewhat similar to intel’s AES-NI instruction set extension which provides support in hardware for cryptographic operations. iOS uses a unique per-file key which is stored in the metadata of each file on the phone’s file system, making attacking cryptographic keys an extremely cumbersome process for an attacker.

The biggest downside of FDE is that while it prevents an attacker from accessing data without going through the Operating System, it also prevents the user or a legitimate IT Professional from being able to recover data if a machine were to fail. While some FDE schemes such as Bitlocker generate a “Recovery Key” which if known can allow a live system to mount the data volume, it is still extremely important for all users to have backups of data they cannot afford to lose. Notably, on a failed drive, forensic analysis through a company such as Drive Savers is less likely to be effective, as the data recovery through clean room techniques would be the encrypted data!

FDE is a powerful and important technology, and the industry-wide push to enable this feature by default is a wise one. However, users must be educated regarding their responsibilities to backup data which is important to them. Additionally, users must understand that FDE is only as secure as the PIN or Passcode they choose to protect their data, and it is often unwise to sacrifice security for convenience.