Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

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.


You can freeze the computer, remove the DIMMs, and then pop them into a different machine to read them: https://electronics.stackexchange.com/questions/32189/freezi...


I thought that wasn't possible since DDR3 or 4?


Smaller capacitors will keep their charge less long, which makes this more difficult, but I understand that there are no fundamental mitigations.


The fundamental mitigation is full memory encryption using a randomly generated key that changes each time the CPU boots. That exists for some CPUs.


Well, that's not part of the ddr3 or ddr4 spec :)


Where do you store the key?


CPU registers - much harder to pull off and reattach elsewhere.


There's (T)SME.


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.


Thunderbolt in some cases: https://thunderspy.io/


There was a neat patch to store the AES key in debug registers and do round key setup for each block. It was even faster than the normal routine. https://www.usenix.org/event/sec11/tech/full_papers/Muller.p...


You can do it via PCIe as well. [1]

1. https://github.com/ufrisk/pcileech


It's a DMA attack, not necessarily a FW attack. DMA is direct memory access, which is how the attacks worked.


It seems unlikely that

(a) FBI understood truecrypt

(b) the target understood truecrypt

(c) the target misunderstood the entire purpose of truecrypt, and they would misuse it to expose themselves

and (d) the FBI expected this and intentionally blew their cover, leaving the target a chance to destroy the drive.


It's likely though that they knew that AES keys are somewhere in the memory.


Why did having FireWire matter?


Because FireWire has direct memory access (DMA).

See https://en.wikipedia.org/wiki/DMA_attack




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: