What are the considerations when migrating from Bitlocker to Veracrypt?

Question

We are currently evaluating migrating from BitLocker to VeraCrypt. Based on the most recent update to VeraCrypt, there appears to be support for UEFI/GPT. Additionally, it seems that decryption isn't required when updating Windows 10.

The reasons for migrating from BitLocker to VeraCrypt include:

• Not all devices support TPM
• Limited supported for BitLocker as a number of devices are deployed with Windows 10 Home

Assuming that there is the ability to adopt VeraCrypt, I imagine the natural progression would be to decrypt the devices currently using BitLocker first. If yes, what risks does this present to the data on the disks?

For example, will the be exposed such as if there are attempts to perform data recovery after the drives have been encrypted with VeraCrypt, these could be discovered?

Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?

As the devices that currently use BitLocker store sensitive information such as personally identifiable data, financial statements, etc, I would like to limit the risk of data leakage.

Answer 1

To begin with, VeraCrypt is open source. So, you can ensure the code does not contain backdoors. While BitLocker is closed source and hence not open to inspection. For this reason posts like, Can the NSA Break Microsoft's BitLocker have come about. While Microsoft Opens Windows Source Code to EU Governments is good news, it still allows me to make the statement BitLocker is as trustworthy as Apple's FileVault, because the source code is not public, until that date, this statement remains true.

To my understanding, VeraCrypt's hidden partitions work similar to the discontinued TrueCrypt. The hidden partitions work very nicely,

It may happen that you are forced by somebody to reveal the password to an encrypted volume. There are many situations where you cannot refuse to reveal the password (for example, due to extortion). Using a so-called hidden volume allows you to solve such situations without revealing the password to your volume.

The principle is that a VeraCrypt volume is created within another VeraCrypt volume (within the free space on the volume). Even when the outer volume is mounted, it should be impossible to prove whether there is a hidden volume within it or not*, because free space on any VeraCrypt volume is always filled with random data when the volume is created** and no part of the (dismounted) hidden volume can be distinguished from random data. Note that VeraCrypt does not modify the file system (information about free space, etc.) within the outer volume in any way.

The password for the hidden volume must be substantially different from the password for the outer volume. To the outer volume, (before creating the hidden volume within it) you should copy some sensitive-looking files that you actually do NOT want to hide. These files will be there for anyone who would force you to hand over the password. You will reveal only the password for the outer volume, not for the hidden one. Files that really are sensitive will be stored on the hidden volume. - Source

VeraCrypt has cross-platform support. Such that you can access VeraCrypt volumes on FreeBSD, Linux, Mac OS X and Windows. However, BitLocker volumes can only officially be supported, as of writing, on Microsoft Windows. Furthermore, Cryptsetup can decrypt and open VeraCrypt volumes cryptsetup --tcrypt-hidden open --type tcrypt [volume] [name].

If looking for aspects of BitLocker which are less secure, it should be noted that TPM does not aid security when compared with using a removable USB key, as this can be taken with you more easily, while the TPM cannot. Furthermore, BitLocker does support password decryption, similar to that of LUKS. So, BitLocker provides three options for where to store the decryption key: TPM, USB key or password (which you remember).

Assuming that there is the ability to adopt Veracrypt, I imagine the natural progression would be to decrypt the devices currently using Bitlocker first. If yes, what risks does this present to the data on the disks?

Storing any sensitive data on a decrypted drive presents a considerable risk. As once done, you have to properly overwrite the data after, which on SSDs can become considerably more tedious.

Should the data first be migrated across to another alternative destination that is already encrypted prior to decryption and encryption again?

As the devices that currently use Bitlocker store sensitive information such as personally identifiable data, financial statements, etc, i would like to limit the risk of data leakage.

Copy the sensitive data directly from the BitLocker encrypted directly onto the VeraCrypt encrypted partition, this mitigates data leakage. Alternatively, if this is not viable archive the data into a 7z archive and encrypt that using AES256 with a strong random password. Then extract that archive onto the VeraCrypt partition. Then discard the password and overwrite the 7z archive, the overwrite part is optional.

Answer 2

From some experience I have with Veracrypt, there are a few considerations I have. I agree with all the advantages of Veracrypt over Bitlocker set out by safesploit . But Veracrypt can give some difficulties at the time of introduction. The encryption / decryption process - the purpose of it all, seems robust and reliable. But the main thing you want with full-disk encryption is that when you reboot the computer for a Veracrypt-encrypted internal hard drive, it boots normally, asks for the password, and you are ready. In the past few years there have been quite a few users who had problems with the booting process - as opposed to with decryption.

My recommendations:

• Follow the documented procedures very thoroughly. In particular, do not skip any aspect of the pre-testing, and the creation of a Rescue Disk. In the beginning you may well need this to recover.

• Problems with (re-)booting seem to be quite dependent on the make of the computer. Especially Acer has given problems; but I've also seen them reported about HP and Toshiba. Depending on the number of computers you look after, and the variation in the manufacturers, I would ideally run a trial run with one computer of every individual make in the devices you are responsible for.

• When it works properly, the current Veracrypt versions can fully cope with UEFI and GPT. According to some of the forum comments, the rebooting problems originate in the UEFI standards not having been that stable, and some manufacturers not adhering to the standards in every detail. Sometimes the boot order is maintained after a warm reboot, but not after a cold boot. So the problem is certainly not fully of Veracrypt's making.

• The people looking after problems, and who mainly reply on the main Veracrypt-dedicated forum, Mounir Idrassi and Alex, are very competent, well-intentioned, but perhaps somewhat overloaded. Apart from carefully following the documentation, it pays to read ahead on the forum pages. The main technical answers are in the series on https://sourceforge.net/p/veracrypt/discussion/technical/ .

• I fully agree with safesploit's advice to avoid moving any data to a disk that does not have full-disk encryption. Move data only from an opened / decrypted / mounted Bitlocker volume to a new Veracrypt-encrypted volume. That is the only safe process; and it means you have no risks with data recovery.

• If you are aware of the above issues, I think you can rely on Veracrypt. I have not heard of any real data loss occurring, other than as a result of user mistakes, such as loss of passphrase. But it is good to prepare yourself for a certain learning curve, and set aside time to make sure that every single type of machine you have will, for the internal hard drive, not give any problems with hot or cold booting. For external drives this is of course not an issue...

I hope this assists, and addresses your questions about considerations to evaluate, and risks.