Generally, we expect to find encryption keys forWhole-disk ofVirtual Disk cryptosystems while the disks are mounted. Implementation-specific quirks or key obfuscation techniques could thwart our search attempts, and no reverse engineering is performed if a key that are expected to be in memory is not found.
While in operation, cryptosystems are required to keep the key in some form in memory, and thus may be vulnerable to a coldboot attack. However, good cryptographic practice recommends wiping of keys when they are not in use [38].
We do therefore not expect to find keys when the cryptosystem is terminated, containers dismounted, or in any other state where there are no need for the keys to be resident in memory. We have summarized the expected results for each cryptographic software class (see Section 6.5) in Table 6.3. See explanation of this type of table in Chapter 7.
We also suspect that not all cryptographic applications pre-compute the key schedules, thereby decreasing the timeframe the full key schedule is stored in RAM. This may especially be true for theSession-basedclass of applications, and may drastically reduce the window of opportunity when the key is in mem-ory.
State / Software Class Whole-disk Virtual Disk Session-based
Live Yes Yes Yes
Screensaver Yes Yes No
Dismounted N/A No N/A
Hibernation N/A Yes No
Terminated N/A No No
Logged out Yes No No
Reboot No No N/A
Boot No No N/A
Table 6.3: Software classes and their expected results.
Results
This chapter contains the results of the research performed during the writing of this thesis. The findings were derived using the methodology described in the preceding chapters together with the theoretical background in Chapters 2, 4, 3 and 5.
The structure of the rest of this chapter is as follows: Each application is introduced together with its findings, and a brief discussion of the results and specific search methods used. For the sake of clarity, the application specific results are discussed here rather than in Chapter 8. A simplified representation of the findings can be found in a table similar in format to the table below.
State / Cipher Cipher Name
Live Key found?
Screensaver Key found?
Dismounted Key found?
Hibernation Key found?
Terminated Key found?
Logged out Key found?
Reboot Key found?
Boot Key found?
Here, each row in the table is simply answered by a ”Yes”/”No” value, indicating if keys were found in that state, using the particular software with the cipher in that column. If the state was not tested or is unavailable for the cipher (for example, it is hardly recommendable to dismount a system disk used in whole-disk encryption), a value of ”N/A” is inserted. All applications were tested using their default settings unless otherwise noted, on a Windows XP build2600.xpsp sp2 gdr.070227-2254.
101
7.1 Truecrypt Results
We tested version 5.1a of Truecrypt, using both the independent system disk and virtual disk encryption and all its available ciphers. The full results can be found in Table 7.1.
Whole-disk Virtual Disk State / Cipher AES Serpent Twofish AES Serpent Twofish
Live Yes Yes Yes Yes Yes Yes
Screensaver Yes Yes Yes Yes Yes Yes
Dismounted N/A N/A N/A No No No
Hibernation N/A N/A N/A No No No
Terminated N/A N/A N/A No No No
Logged out Yes Yes Yes No No No
Reboot No No No No No No
Boot No No No No No No
Table 7.1: Truecrypt disk encryption key search results.
To safely extract Twofish keys, we cannot rely upon sequential pages in dumped memory, as explained earlier. Instead, we used the reconstruct method in Interrogate to rebuild the virtual memory of theSystem.exe process, which runs the Truecrypt device driver thread. The mounting of a virtual disk drive creates four new Truecrypt threads in System.exe, who are responsible for on-the-fly encryption/decryption during the time the drive is mounted (See Figure 7.1). These threads allocate memory using the previously discussed method ExAllocatePoolWithTag [Fou08b].
Figure 7.1: The Truecrypt driver (truecrypt.sys) running in theSystem.exe process. Screenshot from Sysinternals Process Explorer.
To reconstruct this part of memory, we first used PTFinder (any tool able to find the value of the PDB of a process would suffice, see Section 5.2) to find the CR3/PDB value of the System.exe process, and used this as part of the input to Interrogate (output from PTFinder truncated):
$ ./ptfinder_xpsp2 --nothreads Truecrypt-Image.vmem No. Type PID TID [...] Offset PDB Remarks
---- ---- --- --- [...] --- --- ---1 Proc 0 [...] 0x00559080 0x00039000 Idle
[...]
33 Proc 4 [...] 0x01bcc830 0x00039000 System
$ ./interrogate -r 00039000 -a twofish Truecrypt-Image.vmem
In general, we had no trouble finding keys when Truecrypt was running and disks mounted. Truecrypt uses a header key to encrypt the master key in the header section of the virtual or physical drives [Fou08a], and both this and the master key were found during normal operation. We were also able to verify these keys by modifying the Truecrypt source, compiling it as a command-line tool and mounting the disks using this tool.
Truecrypt seem to be purging keys as soon as they are not needed (e.g., at the the point of dismounting of the disk), as good cryptographic practice suggest. We found no traces of the keys in the hibernation file, and in the case of the system partition encryption, this file would also be encrypted making such a search impossible.
We did however on some of the tests encounter a third Twofish key in ad-dition to the master and the header key, also after dismounting the encrypted drive. We are however unsure of the origin of this key, and no further research were conducted on the matter. For completeness, the key’s sub-, whitening-and S-box keys are presented here in the format of the Truecrypt Twofish data structure (see Listing 6.1):
a354793d 6e1a33f0 6ab01a83 7df52a97 12fbc877 d427152a cf9eb934 69f6e699 3ce0b947 7c5ab06d 66d41ad8 4e9f86dd d25f6999 a3a35380 5c7cc0e2 27517ce9 9c43a538 b58d216a 49136074 4053fa28 8dd37cac 2d732874 725e993f 3f874a31 c06b1d66 b3045d42 69a78bf1 318e9035 795d6178 7692a11c cf239ae9 bafeb974 8926908b fffc400d 16a21cf1 ec65cfb2 22ad4541 01a0f21f 08fe84ab ef282332