Why disk encryption is not secure

Post here:

http://www.apple.com/feedback/

From a post on another site, this should address the problem:

pmset -a destroyfvkeyonstandby 1 hibernatemode 25

I cannot confirm the efficacy of the suggestion. More details here:

http://www.frameloss.org/2011/09/18/firewire-attacks-against-mac-os-lion-filevau lt-2-encryption/

Regards.

Enable a firmware password on your Mac and you should be good to go. Apple's firmware password should block DMA access through Firewire and give you security from such attacks. The firmware password on older systems can be reset by changing the hardware configuration; however, doing this will destroy the memory contents anyway so its in effect the same thing. Newer systems have a more secure firmware password.

This is not sometihng that needs to be fixed. Its a part of a technology that gives it a performance boost. There currently are ways to block the potential breach it offers, which Apple includes both in OS X and in its hardware.

sure...ok... 🙂

Its true that virtual memory allows RAM contents to be stored on the hard drive; however, with an encrypted disk this contents of the disk are encrypted. FileVault encrypts everything on the drive, including system files, your files, applications, and temporary files like virtual memory page outs. Therefore, while your concern is reasonable, FileVault has this angle covered and the RAM contents that are written to the hard drive are perfectly safe.

In addition, the virtual memory pageouts themselves are encrypted separately from FileVault, so even they cannot be easily scoured for data if the main hard drive happens to be unlocked for access to them. There are two layers of encryption that protect the issue you seem to be so concerned about.

Yes OS X does encrypt the VM file. OS X used to not do this, but in OS X 10.7 Lion Apple switched to having the VM file encrypted by default. You can disable this in Lion and I believe also in Mountain Lion by running the following Terminal command:

sudo defaults write /Library/Preferences/com.apple.virtualMemory DisableEncryptedSwap -boolean yes

You can also disable the system's dynamic pager by removing or otherwise disabling the following launch daemon in OS X; however, this is not wise to do, but if you are paranoid about the presence of a swapfile then you can do this.

/System/Library/LaunchDaemons/com.apple.dynamic_pager.plist

However, the above steps and concerns are completely unnecessary with a FileVault volume, since the use of CoreStorage's encryption routines has the drive fully encrypted underneath the OS. The encryption keys are present in RAM when the drive is unlocked and you are logged in, but if and when this information is written to the hard drive in a VM file this file will be encrypted just like any other file in the system. This is how the new FileVault works, and why it is such an improvement over the last FileVault.

If you are concerned about FireWire DMA snooping to get around this and recover encryption keys, then you can take several steps. The first is to run the above mentioned "pmset" command to have the system destroy encryption keys in memory when put in hibernate modes, even though this is redundant with FileVault already encrypting any keys that would be written to the hard drive.

Secondly, in more modern Macs the Intel chips used have DMA-blocking components (an I/OMMU) that can be invoked by the OS, so when you have a screen lock or some other software features enabled then FireWire DMA is blocked. Granted this needs proper programming and in the past Apple did make a mistake in early releases of Lion that allowed DMA access despite screen locks, but this has been largely addressed by now.

Lastly, by enabling a firmware password on the system it should disable FireWire DMA in all situations, which should effectively block any DMA access. Even older firmware passwords that could be reset manually are effective here since to reset them you will have to shut down the system and thereby clear any RAM contents.

In essence, while your concern is valid, you are overlooking a number of options that are both automatically invoked or which can be manually set to keep your system secure from the attack scenario you are imagining.

The problem with DMA access through FireWire was addressed with OS X 10.7.2 (see about half-way down the page here, at "CVE-2011-3215": http://support.apple.com/kb/HT5002).

As for the possibilities of breaking an encryption scheme, there may be ways to get around them but this is the case with any security measure, be it FileVault and TrueCrypt or any other encryption, or a password authentication routine; however, the known issues with FileVault that have been discussed have been widely (if not completely) taken care of.

I agree Apple has at times frustratingly denied problems and skirted issues instead of being outright honest about mistakes, but they have to play a Public Relations game. Apple employees likely wont pony up any information either for fear of being fired or whatnot, so its a difficult situation for the end user to get a feel of where and when problems have been taken care of. However, we do have community forums and independent investigations that in part make up for any lack of information from Apple.

Encrypted swap is not going to affect performance much, if at all.

Here is Apple's statement on why it has resorted to always using encrypted swap in OS X 10.7 and higher: http://support.apple.com/kb/HT5002

You mention "companies like you," but I do not work for Apple at all, and have no relation to the company. This is the case with most people on this message board, which is set up by Apple for anyone to join and discuss problems.

gozillagirl, I think you might find a computer forensics course interesting! There are a few ways to avoid storing an encryption key in RAM, and therefore in virtual/paged memory.

A few weeks ago I stumbled upon a research article* about a measure that prevents forensic investigators from retrieving the encryption key from (encrypted) virtual memory in a cold boot attack, which works with all Intel processors made in the last decade. In a nutshell, the authors disabled SSE for all user-level processes and stored the encryption keys in the processor's XMM registers (special high-speed memory cells meant to store operands for multimedia instructions) on the processor, and never in main memory. That way, if you shut down a computer with full-disk encryption, the keys in the CPU registers are lost and a forensic investigator could no longer take out the hard drive and recover the encryption key from virtual memory.

Have a wonderful evening!

* Tilo Müller, Andreas Dewald and Felix C. Freiling, "AESSE: A Cold-boot Resistant Implementation of AES", EUROSEC '10 Proceedings of the Third European Workshop on System Security, p. 42-47, 2010.