Daniel Selifonov now delves into the prevalent types of attacks one could pull off to compromise encrypted data on a computer.I break attacks into three fundamental tiers (see right-hand image). First off, non-invasive, which is something that you might be able to execute with just a flash drive; you don’t even need to take the system apart, where you could attach to it some other hardware component, like a PCI card, ExpressCard, or Thunderbolt (the new adapter that gives you basically naked access to the PCI bus). Secondly, we’ll consider attacks where screwdriver might be required, where you might need to remove some system component temporarily to deal with it in your own little environment. And also, soldering iron attacks, which is the most complicated, where you are physically either adding or modifying system components like chips on the system in order to try to break these things. One of the first types of attacks is the compromised bootloader (see left-hand image), or also sometimes known as an ‘evil maid’ attack, where you need to start executing some unencrypted code as part of the system boot process, something which you can bootstrap yourself with and then get access to the rest of the data that’s encrypted on the hard drive. There are a few different ways that you can do this. You could physically alter the bootloader on the storage system. You could compromise the BIOS, you could load a malicious BIOS that hooks the keyboard adapter or hooks the disk reading routines and modify it the way that’s resistant to removing the hard drive. But in any case, you can modify your system so that when the user enters their password it gets written to disk unencrypted or something like that. You can do something similar of the operating system level (see right-hand image). This is especially true if you are not using full disk encryption – if you are using container encryption. There’s the whole operating system that someone can manipulate. This could also happen from attack on the system like an exploit, where someone gets root on your box and now they can read the key out of main memory. That’s kind of a perfectly legitimate attack. And that key can be either stored on the hard drive in plaintext for later acquisition by the attacker or sent over the network to the command and control systems. Another possibility, of course, is capturing the user input via keylogger, be it software, hardware, or something exotic like a pinhole or maybe a microphone that records them typing in sounds and trying to figure out what keys they pressed (see left-hand image). This is kind of a hard attack to stop because it potentially includes components that are outside of the system. I’d also want to talk about data remanence attacks, more colloquially known as ‘cold boot attacks’ (see right-hand image). So, if you had asked five years ago even people who were very security savvy what the security properties of main memory were, they would have told you when the power is down you lose the data very quickly. And then, excellent paper from Princeton, 2008 discovered that actually at room temperature – you’re looking at several seconds of perfectly good, very-very little data degradation in RAM – if you cool it down to cryogenic temperatures by, say, using an inverted can duster, you can get several minutes where you’re getting very little bit degradation in main memory. And so, if your key is in main memory and someone pulls out the modules from your computer, they can attack your key by finding where it is in main memory in the clear. There are some attempts for resolving this in hardware, like “oh, the memory modules need to be scrubbed,” but it’s not going to help you if someone takes the module out and puts it either on another computer or a dedicated piece of hardware for extracting memory module contents. And finally, there’s direct memory access (see left-hand image). Any PCI device on your computer has the ability, in ordinary operation, to read and write the contents of any sector in main memory. They can basically do anything. This was designed back when computers were much slower, where we didn’t want to have the CPU babysitting every transfer from a device it’s doing from main memory. So devices gain this direct memory access capability, and they can be issued a command by the CPU and they can just finish it, and the data would be in memory whenever you needed it.
And this is a problem because PCI devices can be reprogrammed. A lot of these things have writable firmware that you can just reflash to something hostile. And this could compromise the operating system or execute any other form of attack of either modifying the OS or pulling out the key directly. There’s forensic capture hardware that is designed to do this in criminal investigations: they plug something in your computer and pull out the contents of memory. You can do this with FireWire, you can do this with ExpressCard, you can do this over a Thunderbolt now, the new Apple adapter. So, these are basically external ports to your internal system bus, which is very-very powerful.
So, wouldn’t it be nice if we could keep our key somewhere else in RAM? Because we’ve sort of demonstrated that RAM is not terribly trustworthy from the security perspective. Is there any dedicated key storage or cryptographic hardware? There is. You can find things like cryptographic accelerators and use them in web server so you can handle more SSL transactions per second. They are tamper resistant, or certificate authorities have these things that hold their top secret keys, but they are not really designed for high-throughput operations like using disk encryption. So, are there any other options?Can we use the CPU as sort of a pseudo hardware crypto module? Can we compute something like AES in the CPU using only something like CPU registers? Intel and AMD added these rather excellent new CPU instructions which actually take all the hard work of doing AES out of your hands; you can just do the block cipher primitive operations with a single assembly instruction. The question is then: can we store our key in memory and can we actually perform this process without relying on main memory? We have a fairly large register set on x86 processors, and if any of you have actually tried adding up all the bits that you have in registers – it’s something like 4 KB on modern CPUs. So, some of it we can actually dedicate to key storage and scratch base for our encryption operation.
One possibility is using the hardware breakpoint debugging registers. There are four of these in your typical Intel CPU, and in x64 these are each going to hold 64-bit pointer. That’s 256 bits of potential storage space that most people will never actually use. The advantage, of course, to using debug registers is: one – they are privileged registers, so only the operating system can access them; and you get other nice benefits, like when the CPU is powered down either by shutting off the system or putting in sleep mode you actually lose all register contents, so you can’t cold-boot these. A guy in Germany, Tilo Muller, actually implemented this thing as TRESOR for Linux in 2011, and he did performance testing on it and it’s actually not any slower than doing your regular AES computation in software.
How about, instead of storing a single key, we can store 128-bit keys? This gets us into more of the crypto module space. We can store a single master key which never leaves the CPU on boot-up, and then load and unload wrapped versions of keys as we need them for additional task operations.
The problem is, we can have our code or our keys stored outside of main memory, but the CPU is ultimately still going to be executing the contents of memory. So, with DMA transfer or some other manipulation you could still alter the operating system and get it to dump out the registers in main memory, or if they are somewhere more exotic, like debug registers.