TrueCrypt
TrueCrypt is a software solution for enrypting data stored on devices like HDD's or USB-sticks. The software is open source and is distributed under the TrueCrypt Collective License. TrueCrypt can encrypt data on-the-fly and was originally designed for MS Windows - the Linux and Mac OS X versions still have limitations. The current version is 5.1a (released March 17, 2008).
TrueCrypt volumes
TrueCrypt uses so called volumes, from which there are two types:
* whole partition or drive * file containers
File containers are normal files, which you can move, rename, delete, etc. Volumes are crossplatform and have to be mounted. Therefor you need a password. Additionally there are hidden volumes, which are mounted by using another password.
Plausible deniability
Hidden volumes are useful if you are forced to reveal your password and can't deny this. In that case the attacker would be able to access all you data. If this data is stored on a hidden volume, you can reveal the password of the outer volume, where some dummy files should be stored on.
TrueCrypt provides two types of plausible deniability:
Hidden volumes - even if the outer volume is mounted, it is not possible to detect if there is a hidden volume or not.
It is impossible to identify a TrueCrypt volume as such - until decrypted a TrueCrypt volume seems to consist of nothing more than random data.
TrueCrypt file containers can have any file extension (.raw, .iso, .img, .dat, .rnd, .tc, .abc, etc.) or even none.
On-the-fly encryption
TrueCrypt decrypts and encrypts data automatically directly before respectively after it is stored to or loaded from disk. The user has not to interfere. For this reason TrueCrypt has to install a device driver on the system. When a TrueCrypt volume is mounted, you can access it like a normal drive. Data can be stored or read likewise a normal partition or USB drive, until it is dismounted.
System encryption
Since Version 5.0 TrueCrypt can encrypt Windows boot partitions. Linux and Mac OS X are not supported, yet. All data, including all temporary files created by Windows and applications, hibernation files, swap files, etc. are encrypted. This feature includes a ao called pre-boot authentication: everyone who wants to access and use the system, has to enter the correct password each time before Windows boots. The pre-boot authentication is managed by the TrueCrypt Boot Loader, that resides on the first cylinder of the bootdrive and on the TrueCrypt Rescue Disc. The Rescue Disc is created during the process of system encryption and is used for repairing purposes.
Available algorithms
TrueCrypt offers the choice between three encryption algorithms:
* AES * Serpent * Twofish
Additionally there are the following cascadings available:
* AES-Twofish * AES-Twofish-Serpent * Serpent-AES * Serpent-Twofish-AES * Twofish-Serpent
Also, there are three hash algorithms:
* RIPEMD-160 * SHA-512 * Whirlpool
Each of the cascade ciphers uses its own independent key.
Modes of operation
Until version 4.0 TrueCrypt used the CBC mode of operation. In version 4.1 (November 25, 2005) it as replaced by the LRW mode. Since TrueCrypt 5.0 (February 5, 2008) the XTS mode is used.
Volume format specification
The format of file-hosted volumes is identical to the format of partition/device-hosted volumes. The "volume header" for a system partition/drive is stored in the first logical drive cylinder. TrueCrypt volumes have no "signature" or ID strings. Until decrypted, they appear to consist of random data. Free space of each TrueCrypt volume is filled with random data when the volume is created (if the options Quick Format and Dynamic are disabled).
The random data is generated as follows:
Right before TrueCrypt volume formatting a temporary encryption key and a temporary secondary key (XTS mode) are generated by the random number generator. The encryption algorithm that the user selected is initialised with the temporary keys. The encryption algorithm is then used to encrypt plaintext blocks generated by the random number generator. The resulting ciphertext blocks are used to fill (overwrite) the free space on the volume. The temporary keys are stored in RAM and are securely erased after formatting finishes.
The maximum possible TrueCrypt volume size is 2^63 bytes (8,589,934,592 GB) but due to security reasons the maximum allowed volume size is 1 PB (1,048,576 GB).
If a TrueCrypt volume hosts a hidden volume (within its free space), the header of the hidden volume is located at the byte #1536 (offset) from the end of the host volume. The header of the host/outer volume is located at the beginning of the volume.
Header key derivation
The header key is used to encrypt and decrypt the encrypted area of the TrueCrypt volume header, which contains the master key and other data. The method that TrueCrypt uses to generate the header key and the secondary header key (XTS mode) is PBKDF2 and a 512-bit salt is used. This significantly decreases vulnerability to 'off-line' dictionary attacks. The salt consists of random values generated by the TrueCrypt random number generator during the volume creation process. The header key derivation function is based on HMAC-SHA-512, HMAC-RIPEMD-160, or HMAC-Whirlpool, depending on the users selection.
The length of the derived key does not depend on the size of the output of the underlying hash function, i.e., a header key for the AES-256 cipher is always 256 bits long even if HMAC-RIPEMD-160 is used (in XTS mode, an additional 256-bit secondary header key is used; two 256-bit keys are used for AES-256 in total). 1000 iterations (or 2000 iterations when HMAC-RIPEMD-160 is used as the underlying hash function) of the key derivation function have to be performed to derive a header key. This increases the time necessary to perform an exhaustive search for passwords (i.e., brute force attack).
Header keys used by ciphers in a cascade are mutually independent, even though they are derived from a single password, i.e., for the AES-Twofish-Serpent cascade, the header key derivation function is instructed to derive a 768-bit encryption key from a given password (and, for XTS mode, in addition, a 768-bit secondary header key from the given password). The generated 768-bit header key is then split into three 256-bit keys (for XTS mode, the secondary header key is split into three 256-bit keys as well, so the cascade actually uses six 256-bit keys in total).
The first key is used by Serpent, the second key is used by Twofish, and the third by AES (in addition, for XTS mode, the first secondary key is used by Serpent, the second secondary key is used by Twofish, and the third secondary key by AES). Even when an adversary has one of the keys, he cannot use it to derive the other keys, as there is no feasible method to determine the password from which the key was derived (except for brute force attack mounted on a weak password).
Encryption scheme
When mounting a TrueCrypt volume or when performing pre-boot authentication, 6 steps are performed
1.) The first 512 bytes of the volume (i.e., the standard volume header) are read into RAM. For system encryption, the last 512 bytes of the first logical drive cylinder are read into RAM (the TrueCrypt Boot Loader is stored in the first cylinder of the system drive and/or on the TrueCrypt Rescue Disk).
2.) The 512 bytes at byte #1536 (offset) from the end of the volume are read into RAM. If there is a hidden volume within this volume, at this point we have read its header (whether or not there is a hidden volume within this volume has to be determined by attempting to decrypt this data). For system encryption, this step and any other steps related to it are omitted.
3.) TrueCrypt attempts to decrypt the standard volume header read in step (1) All data used and generated in the course of the process of decryption are kept in RAM. The following parameters are unknown (to make TrueCrypt volumes unidentifiable) and have to be determined through the process of trial and error (i.e., by testing all possible combinations of the following):
3.a)
The PRF used by the header key derivation function, which can be one of the following:
HMAC-SHA-512, HMAC-RIPEMD-160, HMAC-Whirlpool
The password entered by the user and the salt read in step (1) are passed to the header key derivation function, which produces a sequence of values from which the header encryption key and secondary header key (XTS mode) are formed (these keys are used to decrypt the volume header)
3.b) Encryption algorithm:
AES-256, Serpent, Twofish, AES-Serpent, AES-Twofish-Serpent, etc.
3.c) Mode of operation:
XTS, LRW (deprecated/legacy), CBC (deprecated/legacy)
3.d) Key size(s)
4.) The decryption is considered successful, - if the first 4 bytes of the decrypted data contain the ASCII string “TRUE” - and if the CRC-32 checksum of the last 256 bytes of the decrypted data (volume header) matches the value located at byte #8 of the decrypted data (this value is unknown to an adversary because it is encrypted) If these conditions are not met, the process continues from (3) again, but this time, instead of the data read in (1), the data read in (2) are used (i.e., possible hidden volume header). If the conditions are not met again, mounting is terminated (wrong password, corrupted volume, or not a TrueCrypt volume).
5.) Now we know that we have the correct password, the correct encryption algorithm, mode, key size, and the correct header key derivation algorithm. If we successfully decrypted the data read in (2), we also know that we are mounting a hidden volume and its size is retrieved from data read in (2) decrypted in (3).
6.) The encryption routine is reinitialized with the primary master key and the secondary key (XTS mode), which are retrieved from the decrypted volume header. These keys can be used to decrypt any sector of the volume, except the volume header area (which has been encrypted using the header keys). The volume is mounted.
Random number generator
The random number generator is used to generate the master encryption key, the secondary key (XTS mode), salt, and keyfiles. It creates a pool (640 bytes long) of random values in RAM. This pool is filled with data from the following sources: - Mouse movements - Keystrokes - Mac OS X and Linux: Values generated by the built-in RNG (both /dev/random and /dev/urandom) - MS Windows only: MS Windows CryptoAPI (collected regularly at 500-ms interval) - MS Windows only: Network interface statistics (NETAPI32) - MS Windows only: Various Win32 handles, time variables, and counters (collected regularly at 500-ms interval)
Before a value obtained from any of the mentioned sources is written to the pool, it is divided into individual bytes (e.g., a 32-bit number is divided into four bytes). These bytes are then individually written to the pool with the modulo 2^8 addition operation (not by replacing the old values in the pool) at the position of the pool cursor. After a byte is written, the pool cursor position is advanced by one byte. When the cursor reaches the end of the pool, its position is set to the beginning of the pool. After every 16th byte written to the pool, a pool mixing function is applied to the entire pool to perform diffusion (spreads the influence of individual “raw” input bits over as much of the pool state as possible, which also hides statistical relationships).
Keyfiles
A keyfile is a file whose content is combined with a password. There are no forced restrictions on the contents of a keyfile. The user can generate a keyfile using the built-in keyfile generator, which utilizes the TrueCrypt RNG to generate a file with random content. The maximum size of a keyfile is not limited, but only its first 1,048,576 bytes (1 MB) are processed and all remaining bytes are ignored due to performance issues connected with processing extremely large files. The user can supply one or more keyfiles (number of keyfiles is not limited).
Security precautions/problems
There are several issues that might affect the security of sensitive data stored on TrueCrypt volumes. Some of them are:
paging file
TrueCrypt always attempts to lock the memory areas in which cached passwords, encryption keys, and other sensitive data are stored, in order to prevent such data from being leaked to paging files but Windows may reject or fail to lock memory for various reasons. TrueCrypt cannot prevent the contents of sensitive files that are opened in RAM from being saved unencrypted to a paging file (note that when you open a file stored on a TrueCrypt volume, the content of the file is stored unencrypted in RAM).
hibernation file
When a computer hibernates (or enters a power-saving mode), the content of its system memory is written to hibernation file on the hard drive. By default, before a computer hibernates (or enters a power-saving mode), TrueCrypt automatically dismounts all mounted TrueCrypt volumes, erases their master keys stored in RAM, and cached passwords (stored in RAM) if there are any. TrueCrypt cannot reliably prevent the contents of sensitive files opened in RAM from being saved unencrypted to a hibernation file.
memory dump files
Most operating systems can be configured to write debugging information and contents of the system memory to so-called memory dump files when an error occurs (system crash, "blue screen," bug check). Therefore, memory dump files may contain sensitive data. TrueCrypt cannot prevent cached passwords, encryption keys, and the contents of sensitive files opened in RAM from being saved unencrypted to memory dump files.
multi-user environment
The content of a mounted TrueCrypt volume is visible (accessible) to all logged on users (NTFS file permissions can be configured to prevent this).
unencrypted data in RAM
TrueCrypt is disk encryption software, which encrypts only disks, not RAM. Most programs do not clear the memory area (buffers) in which they store unencrypted (portions of) files they load from a TrueCrypt volume. After you exit such a program, unencrypted data it worked with may remain in memory, so a cold boot attack is possible. Unencrypted master keys have to be stored in RAM, too. When power supply is abruptly interrupted, when the computer is reset, or when the system crashes, TrueCrypt cannot erase any keys or any other sensitive data. Microsoft does not provide any API for handling hibernation, so master keys used for system encryption cannot be reliably erased from RAM when a computer hibernates.
changing passwords an keyfiles
Since the volume header (which is encrypted with a header key derived from a password/keyfile) contains the master key with which the volume is encrypted. If an adversary is allowed to make a copy of your volume before you change the volume password and/or keyfile(s), he may be able to use his copy or fragment (the old header) of the TrueCrypt volume to mount your volume using a compromised password (for example, captured by a keystroke logger) and/or compromised keyfiles that were necessary to mount the volume before you changed the volume password and/or keyfile(s).
windows registry
TrueCrypt provides plausible deniability only if it is impossible to prove that a file or a partition is a TrueCrypt volume and that a hidden TrueCrypt volume exists. Windows stores various data in the registry file, which TrueCrypt cannot securely and reliably erase. After examining the registry file, the attacker may be able to tell that TrueCrypt was run on the system, that a TrueCrypt volume was mounted and which drive letters have been used for TrueCrypt volume(s).
defragmenting
When you defragment the file system in which you store a file-hosted TrueCrypt container, a copy of the TrueCrypt container (or of its fragment) may remain in the free space on the host volume. If you change the volume password/keyfile(s) afterwards, and an adversary finds the old copy or fragment (the old header) of the TrueCrypt volume, he might use it to mount the volume using an old compromised password (and/or using compromised keyfiles that were necessary to mount the volume before the volume header was re-encrypted).
Other issues and limitations
Currently there is a bug where an error occures when encrypting a system partition (or system drive) where Windows XP is installed on a FAT16 or FAT32 partition (as opposed to an NTFS partition). TrueCrypt currently does not support encrypting an entire system drive that contains extended (logical) partitions. Also, TrueCrypt currently does not support encrypting a system drive that has been converted to a dynamic disk. The password of a TrueCrypt volume must consist only of printable ASCII characters. Non-ASCII characters in passwords are not supported and may cause various problems (e.g., inability to mount a volume).