possible to install TrueCrypt (and encrypt partition) before installing Win7?

Discussion in 'privacy technology' started by nmaynan, May 16, 2011.

Thread Status:
Not open for further replies.
  1. nmaynan

    nmaynan Registered Member

    Joined:
    Mar 2, 2008
    Posts:
    98
    Anybody know if its possible to encrypt an NTFS partition with TrueCrypt before installing Win7?

    This can be done with dm-crypt before installing Ubuntu. Wondering if I can do this on Windows using TrueCrypt.
     
  2. jimmy011211

    jimmy011211 Registered Member

    Joined:
    May 16, 2011
    Posts:
    9
    I don't know if you can encrypt a partition before installing Windows 7, but I do know that you can encrypt your system while it's running, which is what I did. It took about an hour to encrypt my 160GB hard drive. The TC website has some really easy to follow instructions on how to do it.
     
  3. chiraldude

    chiraldude Registered Member

    Joined:
    Jul 3, 2010
    Posts:
    157
    Is there some specific security risk associated with encrypting after the OS is installed or are you just trying to be extra Over-The-Top secure?
     
  4. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    Are you referring to the system partition? If so, the answer is no. Installing Windows 7 would overwrite the encryption.
     
  5. cm1971

    cm1971 Registered Member

    Joined:
    Oct 22, 2010
    Posts:
    727
    That would be my answer too. TrueCrypt writes a new MBR and Windows 7 would undo that when it writes its own MBR.
     
  6. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
  7. nmaynan

    nmaynan Registered Member

    Joined:
    Mar 2, 2008
    Posts:
    98
    yes, there is an associated security risk when installing after the OS is installed because I am encrypting an SSD. TrueCrypt warns about the inherent dangers of this. These dangers can be eliminated though if the encryption is done before the OS is installed.
     
  8. nmaynan

    nmaynan Registered Member

    Joined:
    Mar 2, 2008
    Posts:
    98
    Thank you for bringing this to my attention :)

    DiskCryptor looks great except for one thing. My concern with DiskCryptor is over whether I am able to use special characters in my password or not. Can I use !@#$%^&*()-=+,./<>?, etc? The website seems to indicate that I can't--which is ridiculous from a security standpoint. Can anyone confirm this? What exactly is this saying:

    "When encrypting system or boot partitions, you must not use any national symbols in the password. If your keyboard has QWERTZ or AZERTY layout, then you can use symbols only from the following sets: [A–Z][a–z][0–9]."

    http://diskcryptor.net/wiki/Main_Page/en
     
  9. Sadeghi85

    Sadeghi85 Registered Member

    Joined:
    Dec 20, 2009
    Posts:
    747
  10. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    The security risk associated with SSDs is that sensitive data cannot be reliably erased due to the delayed erasure of deleted blocks and the operation of the SSD wear-leveling mechanism. The solution is to encrypt the SSD as soon as you take possession of it and before you write any sensitive data to it in plaintext.

    Thus, it's not a system encryption issue or a TrueCrypt issue. The issue is that you can't reliably sanitize an SSD. If you've already written sensitive data to an SSD as plaintext then it's too late for you to achieve 100% data privacy.

    Is that why you wanted to encrypt the drive before installing the OS? To sanitize it? I thought you wanted the OS to be installed into a pre-encrypted partition because of some weird overkill security considerations, but now I believe that your intention was merely based on a misunderstanding.

    As far as DiskCryptor's warning to users of non-US keyboards, TrueCrypt system encryption has a similar issue, although it is described a bit differently. The shared problem is that the keyboard map seen by the computer during the preboot environment can sometimes be different than the keyboard map that is established after the operating system loads. During the preboot environment, many systems assume that a standard English-US keyboard with a QWERTY layout is attached. Various foreign keyboards use special characters in the place of the EN-US characters. If users select one or more of these changeable characters in their system encryption password, they discover to their shock that they don't have easy access to those characters while they are in the preboot authentication screen, before the relevant OS drivers have had a chance to load.

    The TrueCrypt advice is for users of non-EN-US keyboards to switch to an EN-US keyboard layout when they set up their preboot password, or at least to avoid using any special characters that will have an alternate keymap after the system boots. DiskCryptor's advice seems a bit more restrictive, but perhaps they chose that simpler explanation in order to avoid overly confusing their users.
     
    Last edited: May 24, 2011
  11. nmaynan

    nmaynan Registered Member

    Joined:
    Mar 2, 2008
    Posts:
    98
    Yeah, I know this. The problem is that data are written to drives even when the user doesn't specifically direct it to be done. For example, RAM use alone CAN result in data being written to a drive.

    Yeah, I know this. Where did I say this was a system encryption issue or a TrueCrypt issue? I said it was an SSD issue.

    You are not making clear that you recognize that data can often be written to the hard disk (or SSD) even when it is only being used in RAM. The danger, as explained by the TrueCrypt developers is that when you are creating the FDE your password will be written to the SSD. Most likely this could happen through Hibernation and Swap being active. So it is recommended that these be disabled when setting it up. Although it is probably not going to happen with Hib and Swap deactivated, it is not impossible that writing could still occur. So no guarantees on the safety of it can be made at this time when using SSD technology. However if the system encryption was created pre-OS, it would seem to eliminate the possibility of this happening. Hence, my post. You are the one who is misunderstanding. I already posted that my post was not about "paranoid security." This is an issue that the TrueCrypt personnel brought to my attention on their website. Any system encryption software attempting FDE on SSD with an OS already installed would seem to face this issue.

    Thanks for this explanation. It cleared up the confusion I had about it.
     
  12. dantz

    dantz Registered Member

    Joined:
    Jan 19, 2007
    Posts:
    1,034
    Location:
    Hawaii
    OK, now I understand where you're coming from. I agree that the risk of your password being written to disk as plaintext is quite low, especially if you take the recommended precautions, but I suppose that it's still a conceivable risk. As I see it, the best way to deal with that possibility would be to change your password (and destroy the original rescue disk, which works only with that password) immediately after completing the initial encryption. Since at that point your disk will be encrypted, your new password will be fully protected in the unlikely event that it gets written to disk by the OS.

    Of course, the risks don't stop there. When you change your system password TC writes a new 512-byte header to disk, but the old header won't be overwritten on an SSD, it will merely be flagged as available space. At this point a resourceful attacker could come along and possibly recover your old header, match it with your old password (assuming, of course, that it had previously been written to disk as plaintext and was also recoverable), put them together and gain access to the encrypted system. It's kind of an extreme long shot, but so was the last scenario, so I guess we have to consider it.

    Anyway, if this second scenario were also a concern then perhaps this would be a good time to run the SSD garbage collection function, manually if necessary. It's not a perfect solution, but it might be adequate.

    If not, here are two more untested ideas for your consideration:

    1) Temporarily configure the paging file to use a different (conventional) hard drive, then perform system encryption on your SSD, then then wipe and remove the second hard drive and reconfigure paging back to the SSD. If the password did happen to get dumped to disk by the paging file it would most likely be located on the second disk.

    2) Encrypt your system on a different drive, wipe the freespace (including the paging file, of course), and then clone the encrypted system onto your SSD.

    Just thinking out loud, of course. No guarantees. Wear-leveling and TRIM functions are somewhat undefined, plus they vary from one SSD to the next, so we can't be sure of how they actually work.
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.