Quantcast

A Password Is Not Enough: Why Disk Encryption Is Broken and How We Might Fix It

Software engineer Daniel Selifonov taking the floor at Defcon 21 to touch upon aspects of full disk encryption, including the motivations, methods, and hurdles.

Daniel Selifonov Hi! We’re here to talk about full disk encryption; why you’re not really as secure as you might think you are. How many of you encrypt the hard drives on your computer? Yeah, welcome to Defcon! So, I guess it’s, like, 90% of you at least. How many of you use open source full disk encryption software, something that you could potentially audit? Okay, not as many of you. How many of you always fully shut down your computer whenever you’re leaving it unattended? Okay, I’d say about 20%. How many of you have ever left your computer unattended for more than a few hours? A lot of hands should be up. And, obviously, another question of course is how many of you leave your computer unattended for more than a few minutes? Also pretty much everyone.

Motivations for encryption

Motivations for encryption

So, why do we encrypt our computers? It’s surprisingly hard to find anyone actually taking about this, which is really weird. And I think it’s really important to articulate our motivations: why we are doing something, a particular security practice (see left-hand image). And if we don’t do that we don’t have a sensible goalpost to see how we’re doing. There’re plenty of details in the documentation of full disk encryption software of what they do, what algorithms they use, and so forth. But almost nobody is talking about why. And I argue that we encrypt our computers because we want some control of our data, some assurances about confidentiality and integrity of our data, that nobody is stealing our data or modifying our data without us knowing about it. Basically, we want determination over our data; we want to be able to control what happens to it.

You can’t build a secure network without the foundations of secure endpoints.

There are also situations where you have liabilities for not maintaining the secrecy of your data. Lawyers have to have attorney-client privilege; doctors have patient confidentiality; people who are in finance and accounting have all sorts of regulatory rules they need to comply with. And so, if you’re leaking data – you know, there are companies which have to notify their customers that “Oh, someone left a laptop unencrypted in a van and it got broken into and stolen, so your data might be out there on the Internet.” It’s really all about physical access to our computers and we want to protect them because, really, full disk encryption doesn’t do anything if someone just owns your machine. But it also gets to a greater point of, if we want to build secure networks, if we want to have secure intranets – we can’t do that unless we have endpoints that are secure. You can’t build a secure network without the foundations of secure endpoints.

A lot more to do

A lot more to do

But by and large, we figured out that disk encryption had theory aspects of the stuff. We know how to generate random numbers reasonably securely on a computer; we know all the block cipher modes of operation that we should use for full disk encryption to get these sorts of nice security properties; we know how to derive keys from passwords securely. So, mission accomplished, right? We can all stand on an aircraft carrier (see left-hand image) and, you know… The answer is No, it’s not the whole story; there’s still a whole lot of cleanup that you need to do.

Even if you have absolutely perfect cryptography, even if you know it can’t be broken in any way, you still have to implement it on a real computer, where you don’t have these nice black box academic properties of your system. And so, you don’t attack the crypto when you’re trying to break someone’s full disk encryption. You either attack the computer and trick the user somehow or you attack the user and convince them to either give you the password or get it from them in some other means by a keylogger or whatever.

Limited liability of encryption software

Limited liability of encryption software

De facto use doesn’t really match up with the security models of the full disk encryption software. If you’re looking at full disk encryption software, they’re very much focused on the theoretic aspects of full disk encryption. Here’s a quote from the TrueCrypt web page, their actual documentation, that they do not secure data on your computer if someone has ever manipulated it or is manipulating it while it’s running. I wish I was making this up. Basically, their entire security model is like: “Oh, if it encrypts the disk correctly, if it decrypts the disk correctly – we’ve done our job.” (see image above)

Surprising answers to sensible questions

Surprising answers to sensible questions

This (see left-hand image) is an exchange between the TrueCrypt developers and another security researcher by the name Joanna Rutkowska, where she brought up this attack and tried to talk to them and see what their reaction was of feasibility. And so, this is what they said: “We never consider the feasibility of hardware attacks; we simply have to assume the worst.” And she asks: “Do you carry your laptop with you all the time?” They say: “…how the user ensures physical security is not our problem.” And she asks very correctly: “Why in the world should I need encryption then?”

So, ignoring feasibility of an attack – you can’t do that! We live in the real world where we have these systems that we have to deal with; we have to implement them; we have to use them. And there’s no way that you can compare a 10-minute attack that you conduct with just software, like a flash drive, to something where you need to pull apart the hardware and manipulate the system that way. And regardless of what they say, physical security and resistance to physical attack is in the scope of full disk encryption. It doesn’t matter what you disclaim in your security model. At the very least, if they don’t want to claim responsibility of that, they need to be very clear and unequivocal about how easily the stuff can be broken.

Full disk encryption boot process

Full disk encryption boot process

This is sort of an abstract system diagram of what is mostly in a modern CPU (see right-hand image). So, as we know, the bootloader gets loaded from the secondary storage on the computer by the BIOS and it gets copied into main memory through data transfer. The bootloader then asks the user for some sort of authentication credential like a password or a key smartcard or something like that. The password is then transformed by some process into a key which is then stored in memory for the duration of the computer being active. And the bootloader, of course, transfers control over to the operating system, and then both the operating system and the key remain in memory for the transparent encryption and decryption of the computer. This is a very idealized view. This assumes that nobody is trying to screw with this process in any way. I guess we can all think of a few different ways where this can be broken. So, let’s enumerate a few things that might go wrong if someone is trying to attack you.
 

Read next: A Password Is Not Enough 2: Crypto Attack Vectors

Like This Article? Let Others Know!
Related Articles:

Leave a comment:

Your email address will not be published. Required fields are marked *

Comment via Facebook: