5

I'm applying disk encryption to my local machine and I'm storing the key on a usb drive. This means I need the usb drive to be able to boot. This got me wondering, I've heard about different osses providing encryption, Ubuntu, OS X, Windows. From what I understand, people don't need to authenticate pre-boot, they only need to 'log in', everything appears to happen automagically. They don't need to enter an extra passphrase or supply a keyfile.

Doesn't this mean that either: a) the encryption key is stored (unencrypted) on disk, effectively rendering the disk encryption useless or b) the encryption passphrase is the same as the user's password

In the first case, what stops me from pulling the disk, hooking it up to another machine, and using the key to decrypt the disk?

In the second case I don't see how this can be FDE as the os already booted (unless the user's files are on a separate disk). Anyway, what stops me from recovering the user's password (with tools like ophcrack or John)? And will this be enough to decrypt the user's data?

I'm really starting to have some doubts about disk encryption implementations on Ubuntu, OS X, Windows, Android. So, how secure are these actually? And how do these work with such little user interaction?

To be clear; I'm only asking about offline attacks, cold boot attacks or DMA stuff are off the table.

siebz0r
  • 153
  • 4
  • In the case of Bitlocker a passphrase is required and its a pre-boot requirement that has nothing to do with login process "You can use BitLocker to mitigate unauthorized data access on lost or stolen computers by encrypting all user files and system files on the operating system drive, including the swap files and hibernation files, and checking the integrity of early boot components and boot configuration data." https://technet.microsoft.com/en-us/library/hh831507(v=ws.11).aspx – Soufiane Tahiri Nov 20 '17 at 12:51
  • @SoufianeTahiri Thanks for the link, but I wanted to know about implementations that **don't** require additional passphrases etc. Maybe I didn't state that clear enough in the question? – siebz0r Nov 20 '17 at 12:55
  • Ah sorry this misleaded me : " From what I understand, people don't need to authenticate pre-boot" – Soufiane Tahiri Nov 20 '17 at 13:03
  • Shameless self-promotion for my questions: [this question](https://security.stackexchange.com/questions/57153/decrypting-fde-in-disaster-recovery) asks about this process in a different scenario, a work enterprise with FDE enabled on laptops, how could they get the key if an employee left on bad terms? – Canadian Luke Nov 20 '17 at 17:46

2 Answers2

4

The FDE scheme varies between vendors, but the general idea is that there is a security chip on the device itself that combines data with the PIN/password in order to form the final encryption key. This means that even if you know the PIN or password, but you move the storage medium to a new device, it won't work. The data is not only locked to a specific PIN, but also to a specific computing device.

Offline attacks are infeasible, because even if you know the PIN, you're still forced to brute-force a key that's stored in the TPM or security chip. For example, on many Intel/AMD motherboards, the TPM uses a 2048-bit key derived from the user's PIN. You must brute-force this 2048-bit key in order to get the key to decrypt the storage medium. If you're lucky, the volume encryption key will only be AES 128-bit encrypted, which means you might be able to brute force you way through the key in about a century or so; Bit Locker also allows for AES 256 to be used instead.

Android, Apple, Linux, etc use similar protection schemes based on hardware chips, which are nearly impossible to tamper with (but not actually impossible) when available. You'd want to check the manual for specifics. On older devices without security chips, it might be possible to hack through FDE, but almost all devices put out in recent history will have some sort of on-board encryption chip.

These should be considered essentially uncrackable to any average attacker (state actors with nearly unlimited resources might find a way to get at the chip's keys, but it's still risky if the chip is tamper-resistant). If the original device is destroyed or disabled, such that the key can't be recovered, the data on the storage medium would be considered irretrievable.

phyrfox
  • 5,724
  • 20
  • 24
3

Short answer: It depends.

Long answer: It depends mainly on the configuration of the encryption mechanisms and of the chosen encryption mechanism. There are too many options to list them all and compare them. Most common encryption mechanisms (such as Bit Locker, dm-crypt, VeraCrypt) can be configured to ask for a secret on boot, be it on a USB key or in a TPM. Some allow for the secret to be stored on disk, but I do not know a mechanism where this is mandatory. When using a TPM, this will be transparent for the user until the it tries to use the encrypted drive on another computer.

The secret stored in a token is always long enough to make brute-force or dictionary attacks against it impossible, at least for the decades to come.

A. Hersean
  • 10,046
  • 3
  • 28
  • 42
  • Well put. I know that McAFee's Drive Encrytion has a sector that contains the pre-boot file system and you can configure the product to require authenticating before even decrypting the file system. That's moving to using TPM as well. I don't have the resources to prove this, but I suspect that drive encryption mechanisms are moving toward using TPM. – baldPrussian Nov 20 '17 at 13:51
  • The TPM makes sense, but when the secret is stored on disk, (in a token or not) can't I just use that token? I mean, if the application itself can, what prevents me from doing it manually? (Obfuscation is the only thing I can think of, and security by obscurity is bad.) – siebz0r Nov 20 '17 at 14:00
  • @siebz0r Of course, when the secret is available to someone (the user or an attacker), this person can use it to decrypt the disk. That's why schemes where the secret is stored on the disk (for example on a /boot partition) are uncommon and usually come from a misunderstanding of the threat model and the purpose of FDE. – A. Hersean Nov 20 '17 at 15:51