I remember many years ago, as I was thinking about going into technology as a career, I was chatting with a family friend who worked in computer security. I was asking him what he did. He said "If I have physical access to a computer, it's almost certain I will be able to get whatever data is on it. Especially if it's still running and logged in." (or something to that effect).
Stuff like this always reminds me of that guy (haven't seen him in decades, sadly). Oh, you used AES encryption? That's lovely, but your computer knows the key and I can trick it into telling me it.
Truecrypt likely changed the game on some of the claims he made, but that conversations predated it's existence.
Today the angle of attack seems to be around OTP + Password with a timeout on the credentials generated. It narrows the window, but doesn't completely block it.
Truecrypt doesn't change that if the user has the volume open. When computers still had Firewire if they had a warrant for child porn they would use FW and DMA to pull a complete copy of the memory if it was on and get any encryption keys to the Truecrypt volume. They would actually announce that they were coming in on suspicion of child porn because people had a tendency to boot the computer and open Truecrypt to delete all their files.
I suspect similar techniques are still used today, like we see with this tool. If you can get a dump of the computer active memory you can ultimately get the decryption keys on consumer hardware.
>If you can get a dump of the computer active memory you can ultimately get the decryption keys on consumer hardware
What methods are available to get a memory dump if Firewire is disabled? Feds couldn't break my encryption after ~1.5 years but my devices were all off when they showed up. Ironically the one device they did get into was a cell phone powered on but it had little evidentiary value and in one funny way was partly exculpatory.
USB-C+Thunderbolt or eSATA with a vulnerable controller. I know modern OSes have protection against driveby-DMA, but don't know if they protect against memory dump if the "user" - or attacker who gained access to a logged in system - consents.
All these attacks target decryption keys in memory, so they don't work on devices which are turned off.
I'm assuming the computer is "locked" but online, and no users consent to logging in to run anything. Will any of these methods still work if Firewire drivers are disabled?
In that case USB-C/Thunderbolt won't work, in the default config you need to trust the device and cable before anything too interesting can happen. This can be turned off via bios setting though, so there's room for misconfiguration.
E-SATA or PCIe hotplug might still work. However the former is getting less common, and the latter is uncommon in consumer mainboards.
I had a brief moment of technological joy when I worked at a place that had strict rules about leaving your computer unlocked, which I always struggled with.
I had this new Symbian phone with Bluetooth (2?) and there was an app you could get for OS X that would lock your machine when it lost BT signal.
Sub in a larger battery (still one of my favorite mini hacks, removing a little plastic so the 30% bigger Ngage battery would fit) and I was good to go, until the app stopped working.
Big part of why I bought an Apple Watch (and then keep forgetting to set it up)
I worked in a place in 2006 where my username was a badge and my password was my fingerprint.
The badge had to be inserted into a reader for the computer to be unlocked. It was also attached (via a badge holder) to the RFID badge needed to open any locked doors. This meant that to get to and go to the washroom, I had to take my badge out, which locked the computer.
Can someone explain how this works? I thought AES keys were just random bytes, but obviously there must be more to them if this tool is able to detect them.
I took a skim of the source[1] -- I think that it's looking for an expanded set of round keys[2] using their expected layout in memory (accounting for endian flips, forward/reverse ordering, 128/192/256 bit variants, and enc/dec). If a matching region of memory is found, the first round key is the main key.
Yeah, it's a trick that's been around for a while. The thing that makes it a little fiddly is that the various ways to store a key schedule, especially for decryption - it could be in either order, and there's some optimization to do with whether InvMixColumn is pre-applied to the values that I can't remember the details of. I actually had a fork of the classic aeskeyfind that added some of these tricks, though apparently it's broken at higher compiler optimizations now and I probably need to look into that: https://github.com/makomk/aeskeyfind Could just have used this instead if I'd known about it.
Shouldn’t there be a way to relocate the bits so that the L1 and L2 caches are still happy but the data structures aren’t contiguous? Is the main problem that they are all malloced sequentially?
Keys having an expected layout in memory is not a problem, nor is being able to dump encryption keys from process memory if you have access to it. That's the security model these processes operate in.
Processes could conceivably put keys in memory in a non-standard way that is more difficult to write a tool to scan for, but the fact that they don't is not a problem, and even if they did it would not make it impossible to write a tool.
The point is that if we could move the pieces of key schedule around freely it would increase the complexity of the tool significantly since it will have to match each potential block against a number of other potential blocks.
This source file provides a better history for looking for AES keys. It looks like Sam Trenholme developed the technique originally but I know of it because of Jesse Kornblum’s subsequent work. Simson Garfinkel then embedded relevant code inside of bulk_extractor. The technique is over a decade old:
It looks like this particular fork of this code has a few nice features that aren't in older versions, such as support for dumping memory and actually knowing about the other common formats of AES key schedule that are commonly found in the wild. It's really annoying to run a search over a dump that you suspect contains an AES key schedule and coming up with nothing because the encryption library used a slightly different way of storing it than the one expected by the tool.
Stuff like this always reminds me of that guy (haven't seen him in decades, sadly). Oh, you used AES encryption? That's lovely, but your computer knows the key and I can trick it into telling me it.
Truecrypt likely changed the game on some of the claims he made, but that conversations predated it's existence.
Today the angle of attack seems to be around OTP + Password with a timeout on the credentials generated. It narrows the window, but doesn't completely block it.