TrueCrypt Boot Loader

Hi. Just been looking at the new version of TrueCrypt. In order to use WDE, the first cylinder of the boot drive contains the TrueCrypt Boot Loader - which obviously will impact upon plausible deniability, since it will be obvious that the drive is encrypted.

However, the Rescue Disk also contains the Boot Loader, in case the original becomes corrupt. Any reason why the boot drive also has to have the Boot Loader? i.e. could the system partition just be encrypted as a typical volume, then the Boot Loader run from the rescue disk? That way the plausible deniability (impossible to prove that the drive is encrypted) would be preserved?

Sorry if the answer to this is obvious...and thanks for any replies.

 

Hello,

From the TrueCrypt User Guide, page 34 :

(emphasis is mine).

I suppose it answers your question
It may be possible to restore the MBR, to remove the TC boot loader, then boot from the CD.
However it has to be tested to be sure.

Regards,
gkweb.

 

Hi

I'm running XP SP2 with my primary disc partitioned into C and D drives. I have installed Truecrypt 5, prepared my rescue disc and encrypted my C drive. However when I boot from my C drive the only dialog that I get is 'TrueCrypt Boot Loader'. I do not get any of the options.

I have restored the boot loader but it doesn't change things. I then restored the data key but this had no effect. However I can boot directly from the rescue disc without problems.

Has anyone got any suggestions as to how I can sort this out?

Thanks

Mike

 

What i want to know is, if you can use the emergancy boot cd to decrypt the hard drive perminantly, why dont they make it so you can boot from cd and encrypt your hard drive? Kind of like a truecrypt GUI for a boot loader for system partition encryption management?

 

I think that when you deal with entire disk encryption, plausible deniability doesn't apply. Especially in situations such as laptops with only one hard drive, or even one drive period. It will be assumed that there is data on the drive, and if its not readily recognizable, it will be presumed encrypted.

With a hidden volume in a container file, you can deny that anything exists, as long as you have "false sensitive information" in the outer volume of the container. Since you can't have a hidden container within a whole disk encryption as part of the disk encryption itself, it doesn't apply. However, you can still have plausible deniability if you add an encrypted container inside the encrypted disk as either a standard or a hidden volume.

Let me try and illustrate

|--Encrypted Disk-----------------------------------------|
|-----------------------|---Container File----------|------|
|-----------------------|-------------|-Hidden Vol-|------|

You will still have deniability of both the Container (limited, provided its well hidden in the drive structure) and Hidden Volumes (original plausible deniability).

 

Depending on where it is, you might be able to write over the TC bootloader, but you wouldn't be able to write random data over the MBR because it contains the partition table, hence there will always be cleartext on the device. You could however plausibly claim to have wiped the partition itself regardless of what bootloader is present.

I'm more interested in booting such a laptop or other system from a USB key, since they are much smaller and more versatile.

 

The program makes a distinction between encrypting the system partition, and the whole drive, it states that all partitions can be encrypted, with only the first cylinder remaining cleartext.

Since they said cylinder (and not sector) I'm assuming this is a fair bit more space than the 512bytes the MBR resides in (plus the 446byte executable section of the MBR is too small for this sort of thing). I've also noticed that at least Vista tends to offset the first partition by 1,024k, so perhaps truecrypt is keeping its bootloader here?

 

When mounting a TrueCrypt volume (assume there are no cached passwords/keyfiles) or when performing pre-boot authentication, the following steps are performed:

The first 512 bytes of the volume (i.e., the standard volume header) are read into RAM, out of which the first 64 bytes are the salt (see TrueCrypt Volume Format Specification). For system encryption (see the chapter System Encryption), the last 512 bytes of the first logical drive cylinder are read into RAM.


The 512 bytes at byte #1536 (offset) from the end of the volume are read into RAM (see the section TrueCrypt Volume Format Specification). 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 more information see the section Hidden Volume). Note: For system encryption, this step and any other steps related to it are omitted.


Now TrueCrypt attempts to decrypt the standard volume header read in (1). All data used and generated in the course of the process of decryption are kept in RAM (TrueCrypt never saves them to disk). The following parameters are unknown* and have to be determined through the process of trial and error (i.e., by testing all possible combinations of the following):


PRF used by the header key derivation function (as specified in PKCS #5 v2.0; see the section Header Key Derivation, Salt, and Iteration Count), which can be one of the following:

HMAC-SHA-512, HMAC-RIPEMD-160, HMAC-Whirlpool.

A password entered by the user (to which one or more keyfiles may have been applied – see the section Keyfiles) and the salt read in (1) are passed to the header key derivation function, which produces a sequence of values (see the section Header Key Derivation, Salt, and Iteration Count) from which the header encryption key and secondary header key (XTS mode) are formed. (These keys are used to decrypt the volume header.)


Encryption algorithm: AES-256, Serpent, Twofish, AES-Serpent, AES-Twofish-Serpent, etc.


Mode of operation: XTS, LRW (deprecated/legacy), CBC (deprecated/legacy)


Key size(s)


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 – see the section Header Key Derivation, Salt, and Iteration Count). 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).


Now we know (or assume with very high probability) 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).


The encryption routine is reinitialized with the primary master key** and the secondary key (XTS mode), which are retrieved from the decrypted volume header (see the section TrueCrypt Volume Format Specification). 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.

Much of this, and many other questions, can be found in the new and updated TrueCrypt Documentation:
http://www.truecrypt.org/docs/