TC USB VM Security / Speed / Best Practice ???

Discussion in 'privacy technology' started by CaixFang, Mar 24, 2009.

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

    CaixFang Registered Member

    Joined:
    Mar 24, 2009
    Posts:
    72
    Crosspost from TC forum for more exposure:

    I have simple situation. I am creating a portable virtual machine on a 64gb flash drive. I have created 2 partitions on the flash drive, of 30gb each. One will be the VM, one will be apps and data.

    On part1, we'll call it the "system partition" for the sake of this, would it be better to encrypt the entire partition with TC, and then create the VM inside this TC Partition, or would it be better to create a normal readable Windowz partition, create the VM config and HD, load Windowz to the unencrypted partition and then use TC system partition encryption inside the VM?

    Speedwise, I don't see a difference that would matter. Securitywise, the only issue I see with option B, is that you would be able to see there is a VM on that partition, however you would not be able to "browse" it with VM HD offline tools because it would be encrypted inside the VM HD.

    I like option B because all I have to worry about is the TC boot password to handle my encryption needs, i dont need to launch TC, mount the partition, then launch the VM - with option B, I launch the VM, enter the TC boot pwd, and off I go.

    B "looks" more insecure, but in reality I dont see how it would be, it is easier to use, and it looks far less suspicious because it is a plain volume with a VM on it, and unless you launch the VM, you would never know it is encrypted, and using the TC boot screen mods, you wouldnt even need to know its encrypted with a message like "VM configuration corrupted please repair" or similar as the new boot screen.

    Thoughts? Comments?
     
  2. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    you want to have as much protected by full disk encryption as possible, including the system partition / OS. the reason for this is that an attacker cannot compromise an encrypted OS without the keys. otherwise, they could install a trojan or malware that waits until you've mounted the encrypted data partition, and do what it wants.

    this is also why you need a secure bootloader. obviously if you are booting from a read/write USB device the bootloader can be compromised. read-only USB device, ISO images, and even trusted computing (TPM) verification can help here.

    best regards,
     
  3. CaixFang

    CaixFang Registered Member

    Joined:
    Mar 24, 2009
    Posts:
    72

    Well the entire "disk" would be protected, because I would be using WDE from within the VM. The bootloader wouldnt be an issue, because it's going to be running in a VMWare VM, so it will have the VMWare bios, and then laoding the VHDD which will have the TC bootloader.
     
  4. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    you need to secure the bootstrap from the metal upward. if your BIOS, bootloader, or host OS are not encrypted AND bootstrapped securely, everything else is unverifiable (read: pointless).

    remember, an attacker can load whatever bootstrap they want on your flash drive or compromise what is there; it's a read/write memory.
     
  5. CaixFang

    CaixFang Registered Member

    Joined:
    Mar 24, 2009
    Posts:
    72

    Maybe I am just missing something, but I dont see how it would be any more exposed than a normal machine using WDE if I use WDE from within the VM. The VM HDD file, which contains everything from that VM would be encrypted. The only way to compromise that (other than corruption) would be from within the VM while the VM is running, which is a threat no matter how you slice it.

    Im not booting to the USB drive per se, I am running VMWare from the usb drive on partition 2 and loading the VMWare VM located on partition 1 which is encypted using WDE from within the VM.

    But possibly I should not run WDE within the VM and run it on the partitions themselves from the host, just to be extra careful, and for the performance bump.

    Eitherway tho, once those volumes are mounted, they are subject to being attacked from the host, or from inside the VM.

    I guess my thoughts on using WDE inside the VM would be that the host would have NO access to the VM file only the VM would, whereas using a container and unencrypting the container holding the VM would be done on the host and would open that container up to attack from a bad host.

    In practicallity I am not looking at using this VM on untrusted machines at this point, rather I am just trying to get a good windows port to a usb stick and running that VM from my work machine and home machines so that I always have my computer in my pocket.
     
  6. coderman

    coderman Registered Member

    Joined:
    Feb 12, 2009
    Posts:
    39
    sorry, i'm confusing different parts of your question. in this case, you assume the host OS (the WDE setup) is trusted. if that is true, then you're right - there isn't much difference between using WDE directly, and using WDE in a VM on a trusted host.


    ok, i understand what you're getting at now...


    yes, this would be preferable. while using WDE in the VM works too, it is less efficient / more prone to data remanence (page cache, etc).


    the WDE on the partitions directly would be the best for this then, given performance. but you're right that it doesn't matter a whole lot overall regarding the security/privacy afforded the WDE volumes inside the VM or not.

    best regards,
     
  7. CaixFang

    CaixFang Registered Member

    Joined:
    Mar 24, 2009
    Posts:
    72
    Well, one thing...I am NOT, and not planning on using WDE on the host machiens. The hosts will all be unencrypted. The WDE would only be used inside the VM. Essentially just the VM HD file will be encrypted, it would just be encrypted from INSIDE the file using WDE in the VM, versus encrypting the file itself from a host.
     
Loading...
Thread Status:
Not open for further replies.