6

When setting up whole disk encryption with TrueCrypt, one re-boot is required to test the operation of the TrueCrypt Boot Loader. After this reboot is when actual encryption of the system takes place. The encryption process takes place while the Operating System is running (and, indeed, other applications can be used meanwhile as well) and does not require a reboot to complete.

How is this done? For any other application to do work on system files, it is generally required for the application to have some sort of pre-boot utility (which, by nature, necessitates a reboot) that can perform operations before the Operating System loads and locks the system files. What is TrueCrypt doing differently, that allows it to bypass this requirement without causing system instability?

Iszi
  • 27,127
  • 18
  • 101
  • 163
  • Don't really know for certain, but my guess is that they install some kernel driver during the initial install/reboot that sits between all filesystem access by the OS and any actual writes to the drive. That driver does all the deep magic of letting the OS not know what is going on while it is encrypting things. – Zoredache Jul 19 '12 at 18:56

2 Answers2

5

All applications (even the OS itself) talks through modules (called drivers) to speak to any piece of hardware, In windows this is called the Hardware Abstraction Layer (or HAL). So any request would be

Software making the request -> Hard Drive API in OS -> HAL for Hard Drive type -> Controller board on Hard Drive -> Bits on physical media.

What TrueCrypt does is it adds a new HAL driver so now the request goes

Software making the request ->  Hard Drive API in OS -> TrueCrypt Encryption driver -> HAL for Hard Drive type -> Controller board on Hard Drive -> Bits on physical media.

So to anything making a request to the hard drive nothing has changed, it sees the same API for talking to the drive, but underneath that layer you added your encryption shim.

The bootloader for TrueCrypt loads the driver when windows or linux first boots and then the OS takes over from there passing the information through the encryption driver.

P.S.

For drives that support hardware based encryption, it uses a sightly different model.

Software making the request -> Hard Drive API in OS -> HAL for Hard Drive Type -> Controller board on Hard drive -> Encryption firmware -> Bits on physical media.
Scott Chamberlain
  • 1,320
  • 1
  • 10
  • 16
0

Truecrypt has its own bootloader. It boots up enough to load a disk driver and a decryption service and then chainloads the bootloader for the OS.

See How to chain GRUB2 for Ubuntu 10.04 from Truecrypt & its bootloader (multi boot alongside Windows XP partition)?

Community
  • 1
this.josh
  • 8,823
  • 2
  • 30
  • 51
  • I'm not quite sure this answer (on its own - without following the link) covers the information I'm looking for. I understand there's a boot loader involved, but how does it avoid interfering with system files that are in use? Or, how does it avoid system instability while working on system files that are in use? – Iszi Jul 20 '12 at 12:33
  • @Iszi because the "Files in use" are using the driver to talk to the files. So its not like it is competing for access to the file, it is providing the file. – Scott Chamberlain Jul 20 '12 at 14:59
  • @ScottChamberlain See, that's what I need explained in just a little more detail. Could you post an answer? – Iszi Jul 20 '12 at 15:02