Mount VeraCrypt volume with preboot authentication

[tomstolarczuk]

Hello, Is it possible to mount VeraCrypt volumes with preboot authentication?

There's such an option in VeraCrypt suite:

[mhogomchungu]

Did you try it and it failed?

The code should support them[1][2] and the option is set automatically. zuluCrypt tries everything with a result being a painfully slow mounting process when attempting to unlock a VeraCrypt volume with a wrong password.

[1] https://github.com/mhogomchungu/zuluCrypt/blob/3a8bce32d07a72065c10ae4d20a87cc0a819fdfb/zuluCrypt-cli/lib/open_tcrypt.c#L122

[2] https://github.com/mhogomchungu/zuluCrypt/blob/3a8bce32d07a72065c10ae4d20a87cc0a819fdfb/zuluCrypt-cli/lib/open_volume.c#L177

[tomstolarczuk]

I get this error while doing so.

[mhogomchungu]

Did you try to unlock the volume as a VeraCrypt volume?

[tomstolarczuk]

Yes, settings I use:

[tomstolarczuk]

Doing it with zuluCrypt-cli

zuluCrypt-cli -o -d /dev/sdb4 -m sdb4 -t vcrypt -e rw -p XXXXXXXXX

Gives me the same error: ERROR: Volume could not be opened with the presented key

Btw. I forgot to mention - I'm using Arch Linux. Dunno if that has something to do with it.

[mhogomchungu]

I developed this feature a very long time ago with TrueCrypt+Winxp.

Will look into it but it may take a while.

[mhogomchungu]

Trying to solve this one now.

How did you encrypt your veracrypt volume?

I tried to encrypt a windows 10 system with veracrypt and there were two options.

1. Encrypt a partition with windows OS.
2. Encrypt the entire drive including everything.

zuluCrypt worked with a TrueCrypt volume(and should work automatically with a VeraCrypt volume) when the drive was encrypted using the second option and zuluCrypt only automatically mounts the first partition.

[mhogomchungu]

This should be fixed in the git version.

[mhogomchungu]

zuluCrypt GUI now has an ability to select this option as seen in the below image.

Previously, this option was silently auto selected when zuluCrypt failed to unlock a VeraCrypt volume and this caused zuluCrypt to take too long to report a wrong password error.

[ghost]

@mhogomchungu

Sorry for the necro-bump but I'm having the same issue as @tomstolarczuk and I'm out of ideas.

• OS: Arch Linux
• zuluCrypt version: 5.7.0 (installed from AUR)

I'm trying to mount a Windows partition encrypted with VeraCrypt ( /dev/sda4).

$ lsblk

NAME         MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sda            8:0    0 232,9G  0 disk  
├─sda1         8:1    0   499M  0 part  
├─sda2         8:2    0   100M  0 part  
├─sda3         8:3    0    16M  0 part  
└─sda4         8:4    0   209G  0 part

With zuluCrypt-gui:

Open > Volume Hosted In A Hard Drive > /dev/sda4

Always getting this error:

I'm 100% sure the password is correct since it works with VeraCrypt using Mount partition using system encryption (preboot authentication) option:

I also tried to add /dev/sda4 as a system volume but it doesn't make any difference.

Note that I can open regular VeraCrypt encrypted volumes with zuluCrypt just fine, only the Windows one is giving me this error.

Any idea?

Additional questions:

1. I noticed that unlike VeraCrypt, zuluCrypt doesn't ask for my password when trying to open and mount a volume. Would you mind explaining why? I didn't find any relevant info neither in the FAQ nor in zuluCrypt.pdf.

2. VeraCrypt mounts volumes to /mnt/ or /media/ if the directory exists whereas zuluCrypt mounts them to /run/media/private/$USER/. What are the benefits of choosing this mount point?

Thanks in advance!

[mhogomchungu]

zuluCrypt does ask for a password and there is a field where you can enter it, it just doesnt require it allowing unlocking of volumes with an empty password.

The VeraCrypt mount point is public and any other user on the system can get access to it.

zuluCrypt mount points are private and only the user who unlocked a volume can get access to it. If you want other users to gain access to the mount point, then check "share mount point" option and an additional publicly accessible mount point will be created.

[ghost]

The VeraCrypt mount point is public and any other user on the system can get access to it.

zuluCrypt mount points are private and only the user who unlocked a volume can get access to it. If you want other users to gain access to the mount point, then check "share mount point" option and an additional publicly accessible mount point will be created.

I see, makes sense.

zuluCrypt does ask for a password and there is a field where you can enter it, it just doesnt require it allowing unlocking of volumes with an empty password.

I meant my user/root password, not the volume password. VeraCrypt asks for it once and doesn't require it afterwards if I mount other volumes:

As far as I'm concerned, zuluCrypt-gui mounts my VeraCrypt password protected volumes without asking for my user/root password period. Is this the intended behavior?

Any thought regarding the Windows volume issue?

[mhogomchungu]

Root's privileged are required to gain access to the kernel infrastructure that deals with block device encryption and there are a bunch of ways of dealing with this.

zuluCrypt-cli tool in your system is owned by root and has permissions of "4755". These two properties allows it to self elevate and get the credentials necessary to access system resources that only root privileged process is allowed to access.

VeraCrypt application can not do the above and hence it uses sudo tool to elevate it and the password prompt you get is for sudo tool.

Change the permissions zuluCrypt-cli to "0755" to remove the ability to self elevate and then restart zuluCrypt-gui and you will get a polkit password prompt that will ask you for your root's password. In this configuration, zuluCrypt-cli will get the necessary credentials through polkit tool.

Another way of doing this is to break the application into two pieces where one piece is started at boot time and always runs privileged and the other piece is run on demand by the user and the second piece contacts the first piece and ask it to do all the operations that requires root's privileged. Udisks is a good example of a tool that does this.

About the issue.

zuluCrypt uses cryptsetup[1] to create and unlock LUKS1 and LUKS2 volumes. It uses zuluplay[2] to create and unlock TrueCrypt and VeraCrypt volumes.

Cryptsetup can also unlock TrueCrypt and VeraCrypt volumes and can not create them.

The solution i have decided to go with is to switch to cryptsetup when unlocking both TrueCrypt and VeraCrypt volumes. Will look into the problem sometimes in early January.

[1] https://gitlab.com/cryptsetup/cryptsetup [2] https://github.com/mhogomchungu/zuluplay

[ghost]

Thank you for the detailed explanation. I'm so used to get polkit requesting my password for this kind of operations that I didn't think about checking zuluCrypt-cli permissions.

Hopefully you'll find a solution next month as for Windows volumes.

Cheers

[mhogomchungu]

Can you update from git and try again?

The git version now automatically use cryptsetup instead of zuluplay when unlocking TrueCrypt volumes if installed version of cryptsetup is >= 1.6.0(released on 14 Jan,2013)

The git version now automatically use cryptsetup instead of zuluplay when unlocking VeraCrypt volumes if installed version of cryptsetup is >= 1.6.7(released on Mar 23,2015)

I can not test this for myself right now.

[ghost]

Works fine now with git version from AUR, thanks!

[mhogomchungu]

Thanks for the report