FileVault 2 Easily Decrypted • Hacker News Board

Re: FileVault 2 Easily Decrypted

#31

Post by ryannielsen » Fri, Feb 03, 2012, 10:00 AM UTC

droithomme wrote: post #28

cyann wrote: post #23

This is what I set on my MBP (equipped with SSD): sudo pmset -a hibernatemode 25 destroyfvkeyonstandby 1 sms 0

Thanks, that is very useful, I was wondering why it didn't scrub it from memory when it sleeps. Article discussing this setting and providing links to a free and open forensic library so people can actually test the FW memory search method themselves, yanking passwords straight off of their friends laptops as a fun party trick or what not: http://www.frameloss.org/2011/09/18/firewire-attacks-against...

It's not scrubbed from memory on short term sleep so the OS can provide a more user friendly experience – rather than dropping you at the EFI login window when you wake from sleep, you'll be presented with the more capable and better looking OS sleep unlock window.

If the machine is asleep for "a while" then it will write out a sleep image file and power off RAM (and other hardware) to go into a deep sleep. Since the sleep image file is written to the FDE volume, you must first unlock the volume at EFI's login window to gain access to the sleep image and resume from sleep. That process takes far longer than waking from a warm OS, so it's not done by default. You can change sleep settings using pmset on the command line and force it to always destroy the FV keys on sleep, if security is more important that a quick wake from sleep.

Re: FileVault 2 Easily Decrypted

#32

Post by mike-cardwell » Fri, Feb 03, 2012, 10:18 AM UTC

JoshTriplett wrote: post #24

Current Linux disables the device-initiated DMA mechanism for firewire and other "untrusted" busses, though it should probably consider more types of busses "untrusted" than it does. This requires the host driver to initiate DMA, which it'll only do for devices it knows how to talk to safely. Turning this protection off (and thus making the system insecure) requires both compiling a kernel with the debugging-only opt…

This is a great article about this subject:

http://www.hermann-uwe.de/blog/physical-memory-attacks-via-f...

It contains mitigation information for OSX, Linux, Windows and various flavours of Unix.

Re: FileVault 2 Easily Decrypted

#33

Post by droithomme » Fri, Feb 03, 2012, 10:21 AM UTC

ryannielsen wrote: post #31

droithomme wrote: post #28

Earlier quoted context omitted.

Thanks, that is very useful, I was wondering why it didn't scrub it from memory when it sleeps. Article discussing this setting and providing links to a free and open forensic library so people can actually test the FW memory search method themselves, yanking passwords straight off of their friends laptops as a fun party trick or what not: http://www.frameloss.org/2011/09/18/firewire-attacks-against...

It's not scrubbed from memory on short term sleep so the OS can provide a more user friendly experience – rather than dropping you at the EFI login window when you wake from sleep, you'll be presented with the more capable and better looking OS sleep unlock window. If the machine is asleep for "a while" then it will write out a sleep image file and power off RAM (and other hardware) to go into a deep sleep. Since the…

Yes, I switched the pmset settings after reading the article I linked to that discussed his settings and making the comment.

Benchmarking it shows that with all programs quit and hibernatemode at 25, it takes around 2 seconds to enter RAM-off-sleep and 8 seconds to awaken from it, rather than both happening instantly with RAM-on-sleep. It's not really all that slow, I wouldn't say it's all that noticeably longer. It's kind of an impressively fast memory dump and restore.

Re: FileVault 2 Easily Decrypted

#34

Post by caller9 » Fri, Feb 03, 2012, 1:27 PM UTC

droithomme wrote: post #22

Canada wrote: post #21

Earlier quoted context omitted.

So, you kinda made the part up about personally breaking then?

No I didn't make it up, I have recovered passwords on encrypted volumes just as I said, and just as you can. It's been a few months since I last had to do this. After posting I realized I was unsure if the hashing algorithm was really MD5, went and looked at the actual hash after posting to make sure that I had it right, saw that it's SHA-1 not MD5, and appended the post with a prominently noted edit so it would be c…

Or they could salt the password hash with the username. Rainbow tables would need to be based on the salt and therefore unlikely to exist.