In the literature I've been pouring over as of late, I have discovered a trending issue, the use of full disk encryption. This all started with a mandate that all UT Arlington issued laptops be subjected to full disk encryption. Reading more I learned that they were using WinMagic to complete this UT mandate. I have never used WinMagic, but it is cross platform and seems to be well received in the security community.
This lead me (of course) to search for open source options, and to check up on the progress of TrueCrypt. The last time I looked at TrueCrypt there were some issues in using the restore functionality but these have been resolved. The community is strong and support is well maintained for an open source project. Cross platform has always been a standard for this group and it's good to see that has been maintained as well. TrueCrypt does exactly what it states, full disk encryption (although it does do more than these basic functions).
This leads me to the issue at hand. How are investigators to know when full disk encryption is being utilized in a search and seizure? The current best practices for most electronic seizure states to turn off the power and transport. When you disable power to a machine running FDE, you reset the encryption state, and unless you can get the key through forensic means or by compelling (legally compelling) the owner, what you have is a fully encrypted disk. This is not weak encryption I might add. TrueCrypt uses what the industry considers adequate and strong encryption (link takes you to the encryption supported). Unless an investigator notes the use of FDE, then the investigation to files and logs may very well end badly at the seizure scene.
This is the same argument that Casey and Stellatos make in the paper "The impact of full disk encryption on digital forensics" (Casey & Stellatos, 2008). They argue quite well that the use of full disk encryption could effectively hamper an investigation quickly. This issue leaves only a few possibilities.
- React and treat all electronic devices as though FDE were enabled and running
- Modify the best practices to incorporate FDE analysis
- Compel FDE makers to supply a back door
- Compel users to release the key
There are of course issues with 3 & 4, mainly that back doors to algorithms are generally bad and would compromise the integrity of the software and its legitimate use. Compelling users to release a key when software can create fake volumes or separate information when supplied a second key are becoming more available (See Grover 2004). One would have to prove in court that the defendant was not cooperating, which would be difficult to show in that case.
Obviously 1 & 2 are the easiest to enable and utilize, but getting the necessary training and use to practitioners is already an issue, which is only being compounded by increases in security. It leaves a lot open for discussion. I'm interested in studying this further from a process, technical, and legal standpoint.
Bibliography:
Casey, E., & Stellatos, G. J. (2008). The impact of full disk encryption on digital forensics. SIGOPS Oper. Syst. Rev., 42(3), 93-98. doi: 10.1145/1368506.1368519
Casey, E., Fellows, G., Geiger, M., & Stellatos, G. (2011). The growing impact of full disk encryption on digital forensics. Digital Investigation, 8(2), 129-134. doi: 10.1016/j.diin.2011.09.005
Grover, D. (2004). Dual encryption and plausible deniability. Computer Law & Security Review, 20(1), 37-40. doi: 10.1016/s0267-3649(04)00007-x
TrueCrypt Icon by Flashhack @ deviantart
http://flakshack.deviantart.com/art/TrueCrypt-Flurry-Icon-274705836
1 comment:
My company also requires full disk encryption on all portable devices [laptops, phones, tablets etc].
They are have standardized on using Bitlocker, since they can manage keys via AD, and for the most part only support Windows. There is one group which uses Macbooks, but I have no idea what they use.
I am, I believe, the only person using Linux on my laptop. Obviously that means I can't use Bitlocker. After having a good experience in the past using Truecrypt on a Windows machine, I went to look into using it for this system. Unfortunately when I looked into it, Truecrypt didn't seem to support FDE [or pre-boot authentication more specifically] for Linux systems. I ended up using Debian's built-in partition encryption [LUKS I believe], which allows me to have both the main OS and swap encrypted. Unfortunately it requires an unencrypted boot loader and /boot partition.
I'm guessing that, assuming all else is in good shape, this wouldn't be an issue. But I can see a potential issue if somehow a trojan boot loader is installed [perhaps by compromised packages at Debian?] which could then silently capture my key the next time I boot, or something along those lines.
I'm guessing a similar issue is possible with Truecrypt, as it still needs some form of unencrypted MBR to do the pre-boot authentication.
Is this a reasonable concern?
Aside from finding a system that performs the encryption/decryption from the hardware itself [or BIOS?] is there any decent solution out there?
Post a Comment