This project has moved. For the latest updates, please go here.

A few questions about booting Windows in UEFI mode with VeraCrypt . . . . .

Topics: Technical Issues, Users Discussion
Dec 30, 2016 at 12:00 AM
I recently installed VC v1.19, and to my pleasant surprise I noticed that encrypting a GPT system volume works, and moreover, boots just fine! I used the triple-layered AES-TwoFish-Serpent algorithm and still managed to get past VC's loader in about 10 seconds. I have Windows 10 installed on an SSD, so booting is fast regardless. Now I can stop using BestCrypt Volume. I've always wanted to be able to use a UEFI-compatible encryption solution that can boot Windows, but preferably something that is open source and free. I imagine preliminary support for this was added very recently.

However, I did notice the multiboot option was greyed out during encryption, the only option was for a single OS. But I like to boot multiple Linuxes alongside Windows on the same drive. UEFI uses a FAT ESP system partition, and more than OS can share that. It is mostly just a bunch of small files in there that have a *.efi extension, which allows for multiple OS loaders. It's not like legacy MBR booting, in which only one loader can "live" in the MBR (whether or not it can chainload other OSes makes no difference).

It appears that VeraCrypt backs up the current *.EFI loader file(s), and it makes sense that this must belong to Windows since it is the encryption target. But is the Windows EFI loader the only one that is looked for? What about EFI loaders for other OSes? If they are present will it fail to proceed? I would like to chainload VC's loader from UEFI GRUB2 or rEFInd. I know this can be easily done with UEFI. But VC appears to use the generic 'bootx64.efi' as its' EFI loader name, rather than a unique name. When installing various OSes they may drop their own file by the same name in the same location' overwriting VC's file. I was thinking that I could maybe rename the file to whatever.efi, then use some other EFI loader bootx64.efi as my primary, then chainload VC's file from that. Does VC check that the name of its' EFI file hasn't been changed? Or the location within the EFI system partition? What about checksumming itself? Is Secure Boot supported yet?

Thanks again!
Dec 30, 2016 at 7:17 AM
Edited Dec 30, 2016 at 7:21 AM
VeraCrypt loader is EFI\VeraCrypt\DcsBoot.efi

\EFI\Boot\Bootx64.efi is the same DcsBoot.efi. Reason => Some firmware can boot only \EFI\Boot\Bootx64.efi and ignore normal BootOrder EFI from BIOS.

Note: There are several parameters of the loader in EFI\VeraCrypt\DcsProp

Secure boot:
Loader is signed. You can setup VeraCrypt certificate in addition to MS and Linux.

In order to allow VeraCrypt EFI boot loader to run when EFI Secure Boot is enabled, VeraCrypt EFI boot loader files are signed using a custom key whose public part can be loaded into Secure Boot to allow the verification of VeraCrypt EFI files.

to update Secure Boot configuration:
  1. Enter BIOS configuration
  2. Switch Secure boot to setup mode (or custom mode). It deletes PK (platform certificate) and allows to load DCS platform key.
  3. Boot Windows
  4. execute from admin command prompt
    powershell -File sb_set_siglists.ps1
    It sets in PK (platform key) - DCS_platform
    It sets in KEK (key exchange key) - DCS_key_exchange
    It sets in db - DCS_sign MicWinProPCA2011_2011-10-19 MicCorUEFCA2011_2011-06-27
All DCS modules are protected by DCS_sign.
All Windows modules are protected by MicWinProPCA2011_2011-10-19
All SHIM(linux) modules are protected by MicCorUEFCA2011_2011-06-27

By the way - there is preview of TPM 1.2 support.
Dec 31, 2016 at 7:38 AM
Edited Dec 31, 2016 at 8:01 AM
Thanks for the info, although I feel that most of my questions weren't answered with precise explanations. I'll do more testing on my own and post again later.

Being able to dual-boot alongside Linux is my main concern. I have no real use for Secure Boot, but's it's nice to know that VC is now compatible with SB if I were to choose to use it.