I ran across this info today, and thought that I'd post it...it seems quite important, in that it pertains to the use of physical memory (RAM) to deal with whole disk encryption (WDE), referred to as "cold boot attacks on disk encryption".
This looks like very cool stuff. Give it a read, and let me know what you think.
Don't forget that TechPathways provides a tool called ZeroView, which can reportedly be used to detect WDE.
If I may simply copy my post to another forum, there was quite an interesting discussion on capturing or acquiring residual data from memory chips after shutdown on Craig Wilson's Digital Detective Forum. http://www.digital-detective.co.uk/cgi-bin/digitalboard/YaBB.pl?num=1184139817/0 At first, it seemed that the evidence recovery defied accepted logic. However, as the rather capable practitioners tested the findings mentioned in the thread, it seemed that this theory was more urban legend than something that can be relied upon in standard practice. I recall that much of the data that appeared to be from "left over RAM," was actually data placed in RAM during the boot-to-Windows process. Far be it from me to critique anything that comes from the halls of Princeton, but I'm skeptical. I don't think the practice has advanced to the point where I'll be examining memory sticks from the machine seized last month.
ReplyDeleteX-Ways Capture also can detect BitLocker and some othe WDE schemes. TrueCrypt's latest seems interesting, and there's also free CompuSec.
Harlan,
ReplyDeleteI also read this paper when I spotted it over at another location.
Much of the algorithm stuff went WAY over my head. However I thought the researchers did an excellent job making most of it quite readable. Certainly opened my eyes to the deeper issues of drive encryption and security.
I had posted a summary of the findings on another blog site and one commenter suggested that a lot of stuff here would rely on first having physical access to the machine. It kinda missed my "bigger" point...
I responded that I agreed that the constraints would likely make breaching most encrypted laptops in such a situation a bit of a "Mission Impossible" acquisition method and not a likely attack vector in daily practice. But it does point out it could happen, and maybe more easily than one would think. Thinking about in in terms of forensics...if during a seizure event it is known (or even suspected) that a target system might be using drive/volume encryption, is in an otherwise "locked" state, this certainly does provide additional avenues for the investigator to consider on recovery and access to the system. (Hey patrolman, got a spare can of dust-be-gone or liquid nitrogen in the back of your patrol car trunk?)
I'm sure in most circumstances, the "defendant" would be compelled by the courts to surrender the encryption password, but in the event that they would not (or could not), it would be wise to consider in advance. However this might ring quite true in a private/corporate forensics investigation where the company may not want to turn to the "courts" but the employee has information on a company system that needs to be examined, but might be more inclined to refuse to surrender the password.
For more practical purposes (corporate espionage or secure data hacking), if an end user say, places their encrypted laptop in a "sleep/hibernation" state (say hanging out at the airport getting ready to go through screening or in a conference setting during a break) and let their guard down thinking "it's encrypted, what's the worry?" the attacker could seize the laptop while still "hot" (although locked) and use these methods to latter attack it at their convenience.
I do agree that in most cases drive encryption is still (currently) the best method to keep critical data secure, particularly on a portable device. However the paper does show that it is no final panacea.
The paper does provide some suggested solutions, and it might be even more secure to do a "layered" encryption process on portable drives; encrypt the entire volume/drive--then once "live" further encrypt the most sensitive files/folders using the OS's encryption or a 3rd-party solution like TrueCrypt or others and only decrypt them while you are present and using them. Don't leave encrypted drive systems unattended or in a "sleep/hibernation" state, and finally, when you shut down the system, be sure you remain with it long enough to ensure the DRAM finally "degrades" long-enough (a few minutes?) to feel secure knowing it can't be re-read if stolen/acquired.
Any thoughts and perspectives on how this paper's information might apply forensically from your personal/professional experience, at least in terms from a corporate or criminal forensic examination angle?
Claus,
ReplyDeleteThanks for the comment...
...Hey patrolman...
From what I've learned from LE, I wouldn't think that that is a likely scenario. It's a little too slipshod and not nearly structured enough.
...it would be wise to consider in advance.
Agreed. This is something I've been looking at for what I do...how do we go about determining WDE on a system when we roll up on it, and if we do discover it, what do we do? For me, the answers to both questions are pretty trivial, and accompanied by documentation, but what I would do very often flies counter to and in the face of the "purist" and more "traditional" CF practices.
Any thoughts and perspectives...
Sure...
As with many things of this nature, it's not something that will necessarily find it's way into everyday practice all that soon. Taking a bit of a tangent, I've been so surprised and shocked that the magazines and journals that are available today for the CF field are largely academic and theoretical in nature, and that I have to go grab the latest edition of Linux Admin or SysAdmin to do any regular reading of forensic-y stuff.
But I digress. Andreas Schuster showed a while ago that the DFRWS 2005 Memory Challenge RAM dumps included what appeared to be EPROCESS blocks left over from a previous boot. I have mentioned this, as well, in my use and demos of lsproc.
However, my big caveat to all this is that we shouldn't keep pushing forward in this field at all...we should not stop trying to push the boundaries that we've set for ourselves when it comes to acquisition and analysis of data.
Claus,
ReplyDeleteI'm sure in most circumstances, the "defendant" would be compelled by the courts to surrender the encryption password, but in the event that they would not (or could not), it would be wise to consider in advance. However this might ring quite true in a private/corporate forensics investigation where the company may not want to turn to the "courts" but the employee has information on a company system that needs to be examined, but might be more inclined to refuse to surrender the password.
There has been some recent Criminal Court Cases where the Court has protected the Defendant from being compelled to provide their password. Based on their 5th amendment protections. See this link.
http://www.volokh.com/files/Boucher.pdf
"it is better that the guilty go free than an innocent person goes to prison"
In my jurisdiction, the training we provide for our officers would prevent them from utilyzing the freeze method to image and recover the password from memory. By the time our lab guys would have an opportunity to examine the computer it would probably be unrealistic that this method would work.
Don L. Lewis
I need to adjust my previous comment.
ReplyDeleteThere has been some recent Criminal Court Cases where the Court has protected the Defendant from being compelled to provide their password. Based on their 5th amendment protections. See this link.
http://www.volokh.com/files/Boucher.pdf
The court considered protecting the Defendant. It is only a matter of time befor these types of arguments are sucessful.
Don L. Lewis