VeraCrypt/TrueCrypt support in GNOME Disks

[segfault]

Hi,

thanks for the quick reply! I re-add the tails-dev mailinglist to Cc.

Kai Lüke:
> Seems I misunderstood while reading, so you already have code.

Correct. Sorry if I didn't make that clear enough. I will still answer
your previous email below. In case you already want to have a look at
the current status (which only supports basic unlocking/locking of
"standard" VeraCrypt/TrueCrypt volumes), the code lies in my forks of
the udisks and gnome-disk-utility repos [1][2] in branch "support-tcrypt".

[1] https://github.com/segfault3/udisks
[2] https://github.com/segfault3/gnome-disk-utility

> If your way of identifying encrypted partitions works good enough (which
> is funny because the partition is not really hidden then) you can ignore
> my sentences on presenting those device contents.

Standard TCRYPT volumes are not supposed to be hidden (in contrast to
the hidden volumes, of which we don't know yet if we want to support
them or not), they are only supposed to be indistinguishable from random
data. We identify TCRYPT candidates by performing a chi-squared test [3]
on each volume, which is a fast test for randomness. We had a discussion
about this here [4].

[3] https://en.wikipedia.org/wiki/Chi-squared_test
[4] https://mailman.boum.org/pipermail/tails-dev/2017-October/011754.html

> From the GNOME Disks point of view it would be good if things work
> mostly the same, e.g. UDisks.Block.CryptoBackingDevice and
> udisks_client_get_cleartext_block.

ACK, I did use the same interfaces that are used for LUKS. As a result,
besides renaming, I only had to modify 3 lines in GNOME Disks to
integrate unlocking and locking support for "standard" VeraCrypt and
TrueCrypt volumes.

> Am 14.11.2017 um 17:36 schrieb 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

Yep, this is what I did.

>> * add the UDisks2.Encrypted interface in UDisks if the block device
>> content could not be identified

Also did that, except that I only add the UDisks2.Encrypted interface if
the device passes the chi-squared test, to have fewer false-positives.

>> * 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")

Exactly, this is the problem of indicating to the user that the volume
*could* be a TCRYPT candidate, which I mentioned in my previous email.
I'm not sure how to best solve this. Currently I set the id_type
long_name to "Possibly Encrypted" and the short_name to "Encrypted?".
But we actually have a UX person in our team who will take a look at the
whole workflow after we evaluated the survey data and decided what
exactly we want to do.

>> * GNOME Disks and GIO/GVFs need to make use of the keyfiles parameter in
>> UDisks (currently lacking for LUKS as well) 

Right. To be sure I didn't miss anything: The only place in GIO/GVFs
which unlocks encrypted volumes is the gvfs-monitor, right?

>> and a way to select a keyfile from GNOME Shell is needed.

Yeah, I think this would be the hard part, because the GNOME Shell
password dialog doesn't allow other windows to be focussed, so I guess
we would have to patch that.

>> One could also decide to explicitly
>> ignore them there and only offer unlocking via GNOME Disks.

This is a decision which will be easier once we evaluted the survey
data, because we asked our users whether they use keyfiles.

>> 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 the survey evaluation shows that we should support file containers
(which I expect), then we will have to find a solution to allow the user
to unlock a container via Nautilus. UX-wise it would be best to
associate all file containers with the unlocking application (e.g.
gnome-disk-image-mounter), but this would require us to detect whether a
file is a TC/VC container. I don't think it would be a good idea to
perform the chi-squared test on every file encountered by Nautilus. An
easy solution would be to rely on the containers having the .tc/.hc
extensions. We will get data on this by the survey, but I'm in favor of
already thinking about alternatives.

I think it would be nice to be able to use gnome-disk-image-mounter in
order to trigger gvfs-udisks2-volume-monitor to unlock the "mounted"
(i.e. loop-device associated) image. But currently
gvfs-udisks2-volume-monitor does not attempt to unlock images which get
associated with loop-devices. Maybe we could change this. Currently,
after opening the file container with gnome-disk-image-mounter, the user
would have to start Disks and unlock the file there, which is not good
UX IMO.

>> 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.

We do not plan to support creating new TC/VC containers, and I didn't
even know that zulucrypt can do this (thanks for the hint!). I find the
idea tempting, maybe I will work on that at some point.

>> 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.

I agree.

>> The best is to open issues for each needed part in every involved
>> project, 

Ok. I will now open one ticket for adding simple TC/VC unlocking support
in Disks. For UDisks such a ticket already exists. I will then add more
tickets for other features once we decided that we want them.

>>I will review the parts for GNOME Disks and also have time to
>> work on something from January/Feburary if needed.

Great!

Cheers!