VeraCrypt/TrueCrypt support in GNOME Disks

[Kai Lüke]

Hello,

of course there is more than one way to do it, but this is how I quickly
thought about this:

* use the cryptsetup support for locking/unlocking in libblockdev and
make it work from the UDisks2.Encrypted interface
* add the UDisks2.Encrypted interface in UDisks if the block device
content could not be identified
* GNOME Disks needs some changes in terms of how to present such a
device in a different way from normal LUKS devices since for most people
the block device is indeed empty and it would be confusing to confront
everybody with failing decryption actions (maybe call the action
"attempt to unlock hidden volume")
* GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
UDisks (currently lacking for LUKS as well) and a way to select a
keyfile from GNOME Shell is needed. One could also decide to explicitly
ignore them there and only offer unlocking via GNOME Disks.

This should give support for existing containers/partitions. I would
treat containers as normal filesystem images. When opened from nautilus
they are mounted read-only by default with gnome-disk-image-mounter →
need to expose writeable mount there.

If desired at some point: Formatting a partition/block device with
veracrypt needs to be added to libblockdev (maybe cryptsetup can't do it
but 3rd party binaries like zulucrypt-cli). This has to be made
available from UDisks2.Block.Format()
Then, to create a new container, one would open GNOME Disks, create an
empty disk image and format it.
Currently the format dialog offers no encryption option for NTFS/FAT →
add veracrypt here. The dialog page with other filesystems  could also
expose veracrypt if that is really needed.

Please give some feedback if this rough plan fits the needs. Not all can
be planned in advance but discussing things now raises the chances to
consider some corner cases before code lands.
The best is to open issues for each needed part in every involved
project, I will review the parts for GNOME Disks and also have time to
work on something from January/Feburary if needed.

Regards,
Kai

Am 14.11.2017 um 02:55 schrieb segfault:
> Hey,
>
> thanks for the quick response!
>
> Bastien Nocera:
>> [...]
>> What UI differences would be needed to handle those different types of
>> encryption? I'm guessing none for handling encrypted disks, because the
>> UI should be pretty much the same as for the existing LVM based
>> encryption support.
> Do you mean the LUKS encryption? In that case you would be correct, the
> UI *should* be pretty much the same. But with VeraCrypt/TrueCrypt
> encrypted volumes we have the difficulty that the volumes can not be
> detected as such with absolute certainty, because, by design, they just
> look like random data, and, in contrast to LUKS, have no cleartext
> header. So we need to figure out a good way to indicate to our users
> that a volume *could* be a VeraCrypt/TrueCrypt volume (because it looks
> like random data).
> There is also a possibility of confusion with dm-crypt plain and LoopAES
> volumes, because those also look like random data. So we thought about
> adding a dialog which lets the user specify the encryption type when
> they want to unlock a (possibly) encrypted volume. We started discussing
> implications of this on [1], and are currently leaning towards ignoring
> dm-crypt plain and LoopAES and omitting an additional dialog.
>
> [1] https://labs.riseup.net/code/issues/6337
>
>> How to deal with creating encrypted volumes, and even more so when
>> talking about other types of encryption would need to be designed after
>> you've figured out whether it makes any difference to the user, and how
>> it would get integrated in UDisks.
> We do not intend to add support for *creating* encrypted volumes, but
> only unlocking/locking.
>
>> I'd start with adding a transparent way to mount encrypted disks and
>> volumes in UDisks, and see whether anything else is needed on top of
>> that for your users, including explaining why particular types of
>> encryption are better than others and under which circumstances.
> I agree that we should start with adding the support to UDisks (which I
> already started doing).
>
>> I'm also not sure what "file containers" and "keyfiles" are, but it
>> sounds like filesystem level encryption which would likely live in GIO
>> and UIs on top of it, not in Disks or UDisks.
> File containers are not filesystem level encryption, but encrypted
> volumes which are stored in a file on the filesystem instead of a block
> device. They could be handled by UDisks/Disks by first mapping a loop
> device to the file container (for example using udisksctl loop-setup,
> gnome-disk-image-mounter or the "Attach Disk Image..." option in Disks).
>
> If a VeraCrypt/TrueCrypt volume is configured to use keyfiles, all
> configured keyfiles need to be added in addition to the password (if
> any) in order to unlock the volume (similar to LUKS keyfiles, which are
> supported by UDisks/Disks, except that those replace the passphrase).
> This also has nothing to do with filesystem level encryption.
>
> Cheers!
> _______________________________________________
> devkit-devel mailing list
> devkit-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/devkit-devel