Quantcast

A Password Is Not Enough 6: Disk Encryption with the Phalanx Toolset

Description of the Phalanx, a disk encryption tool released by Daniel Selifonov, some security assumptions and general conclusions are what this part is about.

General profile of the Phalanx tool

General profile of the Phalanx tool

And so, the tool I’m releasing – it’s, really, a proof-of-concept experimental code; I call it Phalanx (see right-hand image). It is a patched Xen to do the implementation of the disk encryption stuff that I’ve described. Master key and the first two debug registers, second two debug registers – totally unrestricted. For security reasons, the XMM registers which are used as scratch base are encrypted, as well as the key when you’re doing some VM context switches. And I’ve also done a very simple implementation of crypto using zRAM, because – hey, it’s been mainlined, it does pretty much everything except crypto, so adding encryption on top of it, just a really tiny little bit of code, is great. The most secure code is the code you don’t have to write. The nice thing about zRAM is that it gives you a bunch of the bits that you need to securely implement things like AES Counter-Mode.

System requirements to run Phalanx

System requirements to run Phalanx

Hardware-wise, you do have a few system requirements (see left-hand image). You need a system that supports the AES New Instructions, reasonably common but not every system has it. Chances are, if you have an Intel i5 or i7 – almost all of them support it. But there are some oddballs, so check out Intel ARK to make sure it supports all the features you need. Hardware virtualization extensions – these were very-very common as of around 2006. IOMMU is a little bit more complicated to find if you are looking for a computer. It’s not listed as a sticker specification, you kind of need to dig for it; and there are a lot of people who should know better but don’t – about what the difference is between BTX and BTD and so forth. So, you might need to hunt for a system that supports this stuff. And you want a system, of course, with the TPM because otherwise you can’t implement this measured boot thing at all. Usually, you want to be looking at business-class machines, where you can verify this sort of stuff exists. If you look for Intel TXT, it will have almost everything you need. The Qubes team actually keeps a really great hardware compatibility list on their Wiki, which actually has details for a lot of systems that do this sort of stuff.

Security assumptions for TPM

Security assumptions for TPM

So, security assumptions: in order for the system to be secure, we have a few assumptions about a few of the system components (see right-hand image). The TPM, of course, is a very critical component for assuring the integrity of the boot. You need to make sure that there’s no backdoor capable of dumping NVRAM or manipulating monotonic counters or putting the system into a state where it’s not actually trusted (we just think it is). Based on the remarks by Tarnovsky who has reverse-engineered these chips, I’m sort of setting a bound of roughly 12 hours of exclusive access to the computer that’s required if you want to do a TPM attack on it to pull out secrets.

Assumptions about other system components

Assumptions about other system components

There are a few assumptions about the CPU, memory controller, and IOMMU, mainly that they are not backdoored and they are correctly implemented. Some of these might not necessarily be very strong assumptions, because Intel could easily backdoor some of these things, and we have no way of finding out. And some of the security assumptions about Xen: it’s a piece of software that actually has a very good security record, but nothing is perfect and occasionally there are security vulnerabilities. In the case of Xen, given its privileged position in the system, that’s actually kind of a big deal and you really want to make sure that it’s secure.

Framework for a threat model

Framework for a threat model

And so, under those security assumptions, we have a sort of framework for a threat model (see right-hand image). We want to do a realistic threat assessment where we realize that not every system is unbreakable, especially when there are so many legacy components that were designed without any consideration of security. But at the same time, also, not all theoretical attacks are practical and you can’t lump very simple attacks with difficult, complex hardware attacks. And I think a good analogy is thinking about safe security.

We all know that every safe can eventually be broken; it’s a question of how much time you have to reverse-engineer and break it. But eventually it can be broken. I think we need to think about our systems in the context of having physical security defenses in terms of hours rather than minutes that we have right now. And, as always, if I’ve screwed up, if I’ve made an assumption that you don’t think holds – prove it, verify it, verify mine, make sure I’m right, or wrong.

What you actually get

What you actually get

Expected security – this (see right-hand image) is what you’ll actually get. Cold boot attack is not going to be effective against keys, and stuff that you have in main memory is going to be restricted by whatever you have in clear. Hardware based RAM acquisition is not going to be effective because they are going to be IOMMU sandboxed to nothing, so they are not actually going to get your application state or your system state. And even if you manage to extract the secrets out of the TPM, all it’s going to do is get you back to where we are right now, where, although it’s easily broken, you still go all the way down to zero. And I’m setting an assumption here that if you have a good security habit policy, which is reasonable, say, 12 hours of no contact to the computer, you should be okay. As long as you’re reasonably vigilant and not excessively vigilant, you should be okay.

Key methods for breaking into a system

Key methods for breaking into a system

A couple of attack methods (see left-hand image) which are really the main ones that I would use if I were trying to break into a system. Keyloggers are still going to be very much not defended against. You can do some mitigation of this by using one-time tokens, but it’s still, again, going to be imperfect. TPM attacks, as I mentioned before – either NVRAM extraction or LPC bus intercept/reset hardware. Find some way of tricking the TPM into getting into a configuration that it thinks is trustworthy but is actually not. And RAM manipulation – if you have something which looks like RAM, cracks like RAM, acts like RAM but isn’t actually RAM, it pretends to be RAM for most of the time, but once you manipulate it externally, then there’s really nothing you can do because you’d be able to manipulate the contents of the system, no problem. You could also try things like transient pulse injection, which is how George Hotz broke the hypervisor security on the PS3.

Legal stuff to keep in mind

Legal stuff to keep in mind

Now, real quick about legal notes (see right-hand image); I’m not a lawyer, obviously, not legal advice. As far as I know, if you have self-destruct, it is not illegal yet, but there’s been no legal test case of this; might be interesting to find out, but I’m not sure I’d want to be that test case either. It’s illegal in certain jurisdictions; you can’t use the TPM in, say, China; you can’t use the TPM in Russia. And some countries, like the United Kingdom, have mandatory key disclosure. You will go to prison if you do not hand over your key – the RIPA Act.

A to-do list

A to-do list

Future work and improvements (see left-hand image): production version, stable version – right now it is not stable. If you put your computer to sleep it will eat your data, among a couple of other problems – I’m working on it. And there are some other things that might be fun to do in the future. OpenSSL keys are really important, so if there’s some API that you can do to, basically, let you swap out your contents of memory very-very quickly, your exposure time is very small.

The takeaways

The takeaways

Conclusions: the best security in the world goes unused if it’s unusable (see right-hand image). The model needs to account for realistic use patterns. And it’s not just disk encryption; you really need to think about it holistically from the perspective of the whole system. It’s challenging to do this, but I think it’s possible and we should try. Thank you!
 

Read previous: A Password Is Not Enough 5: Secure Architecture Design

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: