Is it possible that the swap file will contain chunks of data by a file you have accessed, and could this be detected during a forensics analysis?
How could you prevent this situation ?
Is using deep freeze or similar software a valid solution ?
|
Is it possible that the swap file will contain chunks of data by a file you have accessed, and could this be detected during a forensics analysis? How could you prevent this situation ? Is using deep freeze or similar software a valid solution ? |
||||
|
|
|
Yes, swap files can contain sensitive data. On Windows you can configure the page file (swap file) to be cleared at shutdown this way:
I don't know for sure if this is a secure deletion of the swap data, but from the fact that it adds minutes to the shutdown process and from the text on Microsoft page about
I would think the data is securely wiped. On Linux you can manually wipe the swap partition:
Better wiping tools are provided by the Secure-Delete package which comes with the following commands:
Sswap is designed to delete data which may lie still on your swapspace in a secure manner which can not be recovered by thiefs, law enforcement or other threats.The wipe algorithm is based on the paper “Secure Deletion of Data from Magnetic and Solid-State Memory” presented at the 6th Usenix Security Symposium by Peter Gutmann, one of the leading civilian cryptographers. |
|||||||||
|
Yes, it is. Moreover, you may be able to read some passwords, encryption keys and other sensitive/private data.
You can disallow memory swapping for particular virtual address space in a process by using some OS-specific calls:
Other modern operating systems will provide similar functionality. However, data is not generally removed from physical memory (such as RAM) when you shutdown your PC, and it still could be retrieved using a cold-boot attack. |
|||
|
|
|
Using Linux, you could ensure that sensible tools like PGP won't be swapped, by using protected memory. But you have to configure you pre-hibernation script to kill all such sensible tools and umount all crypted filesystems! |
|||
|
|
|
If you're coding, many "unmanaged" languages support (require) the ability to delete dynamically-allocated memory. If you want to be really sure, you can usually also set the value of said memory to all zeroes, or to something not useful to an attacker (random data, "All work and no play...", etc). In managed-memory runtimes such as the JVM or CLR, you do not have this control; the garbage collector checks whether the executing code still has any references to the object, and if not, it schedules it for collection. The marking process, and the resulting memory-freeing and heap-reorganization, happens when the runtime thinks it might be a good time to clean up, not when you know that something should get cleaned up. In these environments, there is usually a structure provided specifically to handle sensitive data. In .NET, the primary type for these things is called SecureString, and it has several advantages over the basic System.String:
In all cases, sensitive data should be kept as plaintext in memory for the least possible time before removal. If it can be kept encrypted most of the time, and only decrypted into plaintext when needed (as SecureString allows for), that's great. |
|||
|
|
|
Almost anything that goes through RAM can end up in the swap space. (The main exception is kernel memory, which cannot be swapped on most operating systems. Some operating systems allow applications to request unswappable memory, but this is in itself a security problem, as an application could then hog the physical memory.) Therefore, if your system manipulates confidential data and there is a risk that an attacker will get access to its storage (e.g. by stealing the computer), you must protect your swap space by encrypting it (and not with a key that's stored on the system, of course). A safe way to encrypt your swap is to use a random key. Some operating systems have an option to automatically set this up at installation time (e.g. Debian). This has the downside that you can't use the swap space to hibernate. If you want both to be able to hibernate and to retain confidentiality against attackers who may steal your storage media, encrypt the swap space with a key derived from a strong password, or with a key stored in an external device (such as a smart card) that you don't leave on the system. You'll need to be physically present to enter the key when the system boots. |
|||
|
|