Changed my policy to actual DEVICE encryption

Discussion in 'encryption problems' started by Palancar, Oct 3, 2016.

  1. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    1,592
    I just wanted to pass along my thinking and of course I am open to suggestions. This will be my opinion, and you are free to vary in thinking. Its all good if you do!

    I store large amounts of data off premises, and I want it secure. That means I have always used volume encryption but I have recently decided to completely abandon partition encryption, which is what I was using. VeraCrypt (TC is the same) calls partition encryption device encryption for most users. You will know if you are using partition encryption by looking at the control panel. If you see a partition loaded under the device structure on the panel you are using such a setup. Since the partition is what is actually being encrypted (not the device) there MUST be a valid MBR on the device itself in order to function. I was able to easily extract the MBR from my devices and unfortunately I could view them at will. Now on to the security aspect. It is long known that an adversary can easily use the MBR to do "dirty" things. The first 446 bytes are where foreign loaders can be used to assault your OS. That is the area on an MBR aligned disk that tells the OS how to mount and what to do initially. Remember my data is off premises so control becomes a concern. I have safe places but nothing is like "home" for control.

    For the sake of this post lets assume that all readers know how to fill their disk with noise (wipe it forensically). Since I have written those areas previously I only needed to wipe the header areas and specifically the MBR's off my devices. Then by creating new device encrypted volumes all would be good. I had three areas of device headers to address. MBR - 512 bytes, VC/TC headers ~ 131 K in size, LUKS headers 2,066,432 bytes in size. Using my normal overkill methods I wrote a simple dd command to wipe all three areas enabling me to know that NO header data would remain anywhere on my disk before starting volume creation. Before running dd I used GParted to completely remove all partitions and even the MBR from my externals. 100% unallocated disk. Then dd -- crude but simple and runs in about a second, literally!

    sudo dd if=/dev/zero of=/dev/sdb bs=2066432 count=1 && sudo dd if=/dev/urandom of=/dev/sdb bs=2066432 count=1

    This just writes all zero's over those three areas, and then writes random data over the same area again. Now when I extract the header areas and examine them before starting its all gone and random. Nice.

    Now I created TRUE device encryption and examined the area formerly held by the conventional MBR. This is the result I wanted and examination leaves me feeling better about it.

    Note: having an MBR will NOT allow an adversary to break into your volume IF they don't have access to the device before attacking you. After considering my new approach I feel that absence of any MBR would make it easier to argue that such a device is truly wiped as opposed to encrypted. Either way, I have rock solid decoy volumes on these anyway so I am covered with either argument. The absence of a conventional MBR reduces one small area that a powerful adversary could and has in the past used on the unwary!
     
    Last edited: Oct 3, 2016
  2. mood

    mood Registered Member

    Joined:
    Oct 27, 2012
    Posts:
    867
    And if you want to access the volume?
    So you have to write the information back before you mount it. Then, after you're done with reading/writing data you unmount it, and wipe it again? :cautious:

    The dd-commands are appearing in the history, this can be suspicious. Do you wipe the history?

    And if you can't boot your linux/system, what about accessing your devices?
    You boot a live-distro, grab your headers (you've securely saved somewhere), write them back and access the device?
    Or something like that.
    This means, you encrypted the devices with LUKS and the data from these devices is not accessible within windows, "only" Linux?
     
  3. Palancar

    Palancar Registered Member

    Joined:
    Oct 26, 2011
    Posts:
    1,592
    Looks like I may have confused you. My mention of LUKS was to show that I was wiping space where a LUKS header formerly existed on several external drives. LUKS is a very solid volume encryption tool too. I have completely stopped using LUKS encrypted volumes as an archive tool. I still use LVM on LUKS for my Linux system disks. LUKS is secure but the headers are very revealing as to their "construction". There is NO choice for encryption of a Linux system disk that is better or even equal with LUKS/DmCrypt.

    My aspiration was to gain maximum flexibility, privacy, security, and hidden volumes on ALL archives. This leaves LUKS out as a candidate for my needs. VeraCrypt code and device encryption allows for complete secure access using Windows, or any Linux flavor a user chooses.

    No adversary will ever gain access to the "history" you mentioned from utilizing dd to wipe those header areas. If they ever make into my Linux system disk it would be game over at that point anyway. All of my workspace (internet activity) happens elsewhere within a VM which is snapshot'd clean daily.

    Even if they took the time to get there, man would they be disappointed in how little a "score" they would have!
     
  4. mood

    mood Registered Member

    Joined:
    Oct 27, 2012
    Posts:
    867
    Ok. Thanks for explaining it. Everything is clear now :thumb:
     
Loading...