Windows – Veracrypt – permanently decrypt a working system drive from another computer and discard the bootloader

Finally figured out a workable solution.

I wiped the 100mb Win7 system partition, & replaced it up with grub4dos. grub4dos does the same job as the Win7 boot menu - but it can be written in a way that doesn't require any user interaction:

#Don't show this menu to the user
timeout 0

#First try to load the encrypted OS.  If that fails...
default 0

#...Fallback on the unencrypted
fallback 1

#Main OS
title 1
root (hd0,1)
chainloader /bootmgr

#Decoy OS
title 2
root (hd0,2)
chainloader /bootmgr

So what happens is, the VeraCrypt bootloader appears. Whether you type your password or press ESC, it will load the grub menu & try to boot the encrypted OS.

*If you typed your password, the encrypted OS will be available and will successfully boot.

*If you pressed ESC, the encrypted OS will fail to boot and grub will fallback on the unencrypted.

So to the user, everything is invisible & automatic, and it essentially behaves the same as the two-disk situation :)

In practice, it's almost as resilient with encryption as without it, as long you backup the master key and metadata properly.

Apart of metadata, the corruption would affect just the block of the corrupted bit, in most cases just 16 bytes of it.

For most of the situations of data corruption, with the key and tools (like your password and Veracrypt/LUKS), you have the same access as a non encrypted disk, just like you do normally with everyday use of a encrypted disk. Encryption would only add a additional step (open a encrypted partition) than ordinary. So in this case, it behaviors just like non encrypted data.

With Veracrypt or Luks, you have to store the master key in the disk, that is encrypted with your password. Damaging this sector(s) would cause permanent data lost. This can be easily solved with master key backup (few kilobytes in size), something easy to do with both software, and it's highly recommended for everyone.

Details about non meta data

Both Veracrypt and Luks uses XTS today. In this mode, it's calculated a key for every block. In a simplification, to encrypt block i you use a key generated with the Master Keys and the block number. So, the encryption of one block in independent of another. If you corrupt some information, it will be restrict to that block.

In XTS, it breaks the block in sub-blocks (of 16 bytes usually) and creates a key, and encrypt that sub-block with it. That means that if we change a bit on it, only this 16 bytes would be affected.

As as test, changing a single bit in a Luks volume, it changes 16 bytes of the original file to gibberish, but the others 496 stills unchanged. In a 7zip file, it uses a stream method, that all bytes are chained, so one byte change would affect all the remaining ones - this is not the case here.

Some consider this a problem, as you can know with precision of 16 bytes when and where you change a plain text, comparing just the encrypted data.

More interesting information about this can be found on these links:

https://crypto.stackexchange.com/questions/6185/what-is-a-tweakable-block-cipher

https://security.stackexchange.com/questions/39306/how-secure-is-ubuntus-default-full-disk-encryption

https://en.wikipedia.org/wiki/Disk_encryption_theory

Details about Master Key

LUKS

LUKS have a few sectors in the beginning of the partition (or disk) with metadata, storing encryption methods, other parameters and 8 key slots. For encrypting and decrypting the disk, it uses a Master Key, a big random number generated when create a LUKS container. To store it, it encrypt the Master Key with your password, through iterating a cryptographic hash function many times over the password and generating a specific key for that slot. You can have 8 different passwords for the same disk, each one encrypting the master key with a different password in a slot. When you change the password, It's as simple as encrypting the Master Key, and not changing all the partition.

So, when this slots and metadata is corrupted, you can't recover the master key that is really used to decrypt, losing all data on disk. This is a easy way to fast destroy all your data. But if you have a backup of the Volume Header, it's pretty easy to recover it.

Below is a copy of LUKS FAQ about backup extracted from https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery

6.2 How do I backup a LUKS header?

While you could just copy the appropriate number of bytes from the start of the LUKS partition, the best way is to use command option "luksHeaderBackup" of cryptsetup. This protects also against errors when non-standard parameters have been used in LUKS partition creation. Example:

cryptsetup luksHeaderBackup --header-backup-file <file> <device>

To restore, use the inverse command, i.e.

cryptsetup luksHeaderRestore --header-backup-file <file> <device>

If you are unsure about a header to be restored, make a backup of the current one first! You can also test the header-file without restoring it by using the --header option for a detached header like this:

cryptsetup --header <file> luksOpen <device> </dev/mapper/ -name>

If that unlocks your keys-lot, you are good. Do not forget to close the device again.

Under some circumstances (damaged header), this fails. Then use the following steps:

First determine the master-key size:

cryptsetup luksDump <device>

gives a line of the form

MK bits:        <bits>

with bits equal to 256 for the old defaults and 512 for the new defaults. 256 bits equals a total header size of 1'052'672 Bytes and 512 bits one of 2MiB. (See also Item 6.12) If luksDump fails, assume 2MiB, but be aware that if you restore that, you may also restore the first 1M or so of the filesystem. Do not change the filesystem if you were unable to determine the header size! With that, restoring a too-large header backup is still safe.

Second, dump the header to file. There are many ways to do it, I prefer the following:

head -c 1052672 <device>  >  header_backup.dmp

or

head -c 2M <device>  >  header_backup.dmp

for a 2MiB header. Verify the size of the dump-file to be sure. To restore such a backup, you can try luksHeaderRestore or do a more basic

cat header_backup.dmp  >  <device>

Veracrypt

Veracrypt is similar to LUKS. I'm not used with it as I was with Truecrypt, but the general idea holds.

Veracrypt just have one key slot, so you can't have more than one password at the same time. But you can have a hidden volume: it's stores the metadata in the end of the partition (or disk or file). The hidden volume has a different Master Key and will use the end of the partition as overlapped space. The idea that you should backup is the same. This can be done with Tools -> Backup Volume Header and Tools -> Restore Volume Header. With system encryption, it used to create a bootable disk with key backup that recovers the Truecrypt loader and keys if any damage happens. It's done before it encrypt anything, and As far as I know Veracrypt continue doing the same way.

For more details see this link https://veracrypt.codeplex.com/wikipage?title=Program%20Menu

Security Considerations About Backup Keys

If you have a leaked password for example, and changes the volume password to a new, strong and secure one, someone with access to the backup would stills being able to decrypt the files with the old password. The backup is basically the Master Key encrypted with the (old) password. So, when changing passwords, it's also needed to make a new backup and destroy the older ones. And destroying data permanently can be very trick.

For every backup you have with that password, is a possible way to decrypt data with that password. This can be used in Veracrypt for instance, using a "Universal Password" (like in a corporation), backing it up and changing for another password. So the IT dept. could recover the access to that volume even if someone lost the password (think as a Master Password, but don't confuse with the Master Key from earlier).

Final Thoughts (TL;DR)

The probability of damaging the specific sector with the master key is less likely than you having a complete disk failure. So if this data is important, you should have a backup of it instead just the volume headers (Master Key).

And corruption of data spread little (16 bytes), resulting acceptable for most uses.

So a bad block in the middle of the partition or disk would affect only that block. And a few bits errors in a sector is restricted to that sector, and won't even affect totally a 512 bytes sector.

Update (23/01/2017): add more information based on the OP comments.