Take the 2-minute tour ×
Information Security Stack Exchange is a question and answer site for Information security professionals. It's 100% free, no registration required.

All serious full disk encryption schemes I have looked into use a static password for authentication. For example, TrueCrypt supports two-factor authentication with keyfiles, but not for system partitions. It's possible to use a Yubikey in static mode as a second factor with TrueCrypt full disk mode. But in both cases the second factor is really just a part of the static password that the user chooses to not memorize.

Clearly full-disk encryption requires authenticating users before the OS boots, so interactive challenge-response protocols involving a remote host won't work. But I don't see any insurmountable obstacles to implementing a secure, pre-boot one-time password mechanism.

Why is support for strong multi-factor authentication not more common in full disk schemes? Are there any viable implementations? Are static passwords considered good enough because an adversary capable of defeating them in a pre-boot context is probably also capable of recovering the encryption key (not authentication key) after any form of authentication, regardless of how many factors?

share|improve this question
You could argue that an encrypted usb drive is two factor. Possessing the drive is what you have and entering the password is the second factor. I got one of these: j.mp/IWWJ8c today and that is actually 3-factor: having the drive, knowing the password, and presenting my fingerprint. –  Mark Burnett Apr 20 '12 at 19:29

2 Answers 2

up vote 7 down vote accepted

The problem is that most multi-factor authentication methods are just that--authentication. They often require some code to verify the validity of the token or information you present.

However, with disk encryption your password is the actual encryption key. There is no gatekeeper involved, either your key unencrypts the data or it doesn't.

I have used the Yubikey's static password feature with lets you create a 32-character password which is nice, but like you said there really is not a true "what you have" going on there, it is still just a static password that could be intercepted and entered without the physical token present.

You could probably find a way to do true two-factor authentication using an HSM that does actual authentication (such as requiring you to enter a PIN) or you could store a keyfile on a device that provides two-factor authentication. But ultimately all you are doing is providing a longer password or static keyfile.

share|improve this answer

I disagree with your premises here: I'd argue that two factor is two factor whether it's static or challenge response, and there's not a fundamental security difference between the two, just practical differences that make one or the other a better choice for a particular implementation.

For example, if you are not authenticating to the local computer itself, but to a remote server via the computer, then challenge response might turn out to be a little more secure because you do less on the local machine (which is less trusted than the server.) But this is a practical implementation issue, not something fundamental.

I expect the reason you mostly see static with FDE products is a business decision. It is a little easier to develop a system that supports multiple types of static token than one that supports multiple types of challenge/response, and since two-factor is typically positioned as an optional extra by FDE vendors, having it support multiple brands of token is good for sales

share|improve this answer
I would say that the difference is whether the additional factor can be reproduced without the token itself. In the case of the yubikey static key, pressing the button just emulates a keyboard to type a 32-char string, something that could easily be faked. If someone intercepted the key, they could enter it without the token present. –  Mark Burnett Apr 20 '12 at 19:27

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.