Anti-Forensics: Make Secrets Stay Secret

by Frater Ignotius  (unknown@paranoia.no)

There are many reasons to hide something on a computer.

You may want to make sure other users aren't able to read your documents and mail, you may want to hide your pr0n from your boss, or maybe even make sure that if your loving government kicks down your door, your stash of sensitive information is not compromised.

Easy, some say.  Use encryption and you're safe.

Well, O.K.   A partition or file encryption scheme might keep your files safe from your boss or wife or kids or whoever.

But what happens when you've been up hacking all night and finally decide to get some sleep, and just as you're dozing off at 0700, a dozen policemen and/or three-letter-agency operatives bust down your door and have you in handcuffs before you can even turn off your computer?

Or what if your hardcore software firm gets a visit from some "art student" who really only wants to steal your data to pass on to your competitor or someone else?

Even if you closed your encrypted drives or files or maybe even logged out and shut down, you still might be in trouble.  "Why?" you ask.  "I use XYZ encryption and that's unbreakable!"

Sure, the encryption scheme may be unbreakable in a mathematical sense (although I wouldn't count on it just because the README file or web page says so).  But have you considered that the software implementation itself might not be as secure as you would want and that, in any case, your operating system might also give you away?

Consider this: When a piece of encryption software starts, it will need the key and the passphrase for decryption?

Per default many, if not most, simply store the key on your hard drive.  And even if you keep your key in a supersafe place that no one would ever find, it will still need to be loaded into memory in order to decrypt, no?

The same goes for the password.  While it might only exist in your head at the time you boot, the second you type in that password, chances are it's going into RAM.

Now, what often happens to things in RAM?  They get swapped to disk.  Also, do you have any idea what temp files your encryption software makes?  And what they contain?  Are they properly erased or just removed from the allocation table (leaving the actual data still on the drive) the way a regular DEL or rm would?

For all you know, the encrypted file might be written in plaintext to the disk, then after you close the encryption software, the file either stays in place or is just deleted in the regular fashion, meaning that the unencrypted data is still intact and can be retrieved using "undelete" type software.

Someone who wanted to seize a computer for evidence gathering (forensics) or to steal your secrets (espionage) could for instance run a small program that would bluescreen (BSOD) your Windows box or make your Linux kernel dump core.

Then the box would be powered off, opened, and the hard drive would be extracted and hooked up to a gizmo or computer that does a bit-to-bit copy, very much like the dd command on *NIX would.

There are handheld devices made just for this, with IDE (or whatever) connectors and a fast large hard drive.  They can copy a disk perfectly in minutes.

This could leave the intruder with a complete dump of your RAM and an exact copy of the entire file system.  If the key and password are available in any way, shape, or form, assume they will find it.  And that will make your secure encryption scheme nothing more than an amusing puzzle for the spy or forensics expert - even though you memorized a 40 random character password and used a keylength that even the NSA would consider to be overkill.

So what can you do to safeguard against this?

It's not a clear cut thing, and I certainly will not claim to be intimate enough with the internal processes of any OS to propose a solve-all solution.

However, there are some simple steps that I believe will improve the odds.  Concoct a solution that secures your scheme:

1.)  When opening an encrypted file or volume, do the changes you need to do, then close it and reboot.  Make sure you completely flush the RAM and overwrite your disk cache.  Don't leave the software running or the file or volume open when you're not using it.

2.)  Turn off any and all memory/core dumping functions in your OS, unless you're actually using them for something.  Turn off hibernation and whatnot in Windows XP.  Make sure there are no processes dumping your RAM to disk or making "backup" copies of any relevant system files or the files associated with the encryption scheme.  Use a tool to see what files your encryption scheme opens while running, note where they are kept and their names, and see if they are deleted properly or if they can be recovered.

3.)  In Windows XP, take a look in %SystemRoot%\Minidump and observe that there is per default one (albeit small) memory dump from each of the countless BSODs you surely have had since install.  Go turn the damned thing off (found in My Computer -> Properties -> Advanced -> Startup and Recovery Settings).

4.)  Move your temp folders to a proper place if you use Windows.  Regardless of OS, make sure you properly delete your temp files each boot and/or shutdown, using a secure deletion program that actually overwrites the relevant sectors of the disk, as opposed to a regular DEL or rm.

5.)  Investigate, investigate, investigate.  You can play around with this in Windows 2000, Windows Server 2003, and Windows XP Pro.  Turn on complete memory dumping, set HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\i8042prt\Parameters\CrashOnCtrlScroll to 1.  Then hold down the right Ctrl key while pressing the Scroll Lock key two times and Windows will dump the complete memory.  Analyze with a hex editor and see if you can't break your own scheme.  The same thing can be done in Linux by configuring magic SysRq in the kernel.

This may seem paranoid, but if you have something you really want to hide from people with big resources, you have to be paranoid or you'll be at risk.

The safest thing to do may be to have a dedicated box that handles the encryption and to make that box so sensitive to irregular activity that it shuts like a clam if something happens.

For instance, a Linux server with StegFS (stegfs.sourceforge.net) and the aforementioned considerations about memory dumps might take you a lot further towards true security than something like PGPDisk (www.pgpi.org) which would be highly susceptible to dump attacks.

But that is not to say that you can't implement the latter safely.  Even if you manage to force your OS not to dump the memory, the intruders might have their own software or even hardware to do just that, so make sure you find a routine that flushes any sensitive data such as key and passphrase out of RAM and off the hard drive.

In any case, make sure you're not already storing multiple copies of both in your various temp folders already.

There is surely more to be said about this, and now it's up to you to investigate how you can safeguard against this on your OS and with your encryption scheme.

Remember to share your info.