Discussion:
VeraCrypt/TrueCrypt support in GNOME Disks
(too old to reply)
segfault
2017-11-13 16:36:19 UTC
Permalink
Raw Message
Hi,
we at Tails (tails.boum.org) currently work on integrating support for
unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
monitor). We internally track the status of this work in [1] and [2].
Currently we are gathering data on the requirements of our users via a
survey [3], in order to make decisions about which features we want to
implement (support for legacy TrueCrypt volumes, file containers, hidden
volumes, keyfiles).
We would like to know whether you want to have VeraCrypt/TrueCrypt
support in upstream too. I assume that this is wanted in udisks2,
because there is already an open ticket for this [4]. What about GNOME
Disks?
[1] https://labs.riseup.net/code/issues/6337
[2] https://labs.riseup.net/code/issues/11684
[3] https://mailman.boum.org/pipermail/tails-ux/2017-October/003505.html
[4] https://github.com/storaged-project/udisks/issues/282
I forgot to add: Assuming that you would like to have this in upstream,
some heads up for when it would be ideal for us if an upstream
maintainer was available for reviewing:
- We will evaluate the results of the survey and make design decisions
in December
- Patches will probably be ready in January

Cheers!
segfault
2017-11-13 17:55:08 UTC
Permalink
Raw Message
Hey,

thanks for the quick response!
[...]
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!
segfault
2017-11-14 19:02:13 UTC
Permalink
Raw Message
Hi,

thanks for the quick reply! I re-add the tails-dev mailinglist to Cc.
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.
Hello,
of course there is more than one way to do it, but this is how I quickly
* 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!
.. ink ..
2017-11-15 07:25:20 UTC
Permalink
Raw Message
Post by segfault
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.
zuluCrypt[0] uses zuluplay[1] to create and unlock TC/VC volumes and
if you are to add support for creating
TC/VC volumes then i think zuluplay will be a better dependency to have.

While here,i think it is a bad idea to try to figure out if a volume
is a TC/VC volume because there will be no point
in using these over LUKS if a volume can reliably be guessed to be
TC/VC. Best thing to do is to call blkid on the
volume and assume it is encrypted if blkid fail to find a file system
on it and the volume is not a swap partition.

Doing guess work here will just result in inconsistent behavior and a
support nightmare.


[0] https://mhogomchungu.github.io/zuluCrypt/
[1] https://github.com/mhogomchungu/zuluplay
segfault
2017-11-15 13:05:28 UTC
Permalink
Raw Message
Post by .. ink ..
Post by segfault
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.
zuluCrypt[0] uses zuluplay[1] to create and unlock TC/VC volumes and
if you are to add support for creating
TC/VC volumes then i think zuluplay will be a better dependency to have.
Thanks, I will look into this when/if I start working on support for
creating TC/VC volumes.
Post by .. ink ..
While here,i think it is a bad idea to try to figure out if a volume
is a TC/VC volume because there will be no point
in using these over LUKS if a volume can reliably be guessed to be
TC/VC. Best thing to do is to call blkid on the
volume and assume it is encrypted if blkid fail to find a file system
on it and the volume is not a swap partition.
I think there is no way to identify a swap partition as such (unless it
is currently enabled for swapping).
Post by .. ink ..
Doing guess work here will just result in inconsistent behavior and a
support nightmare.
I think the opposite is true. If we would use standard ways to identify
the filesystem type, we would have inconsistent behavior, because this
means checking for (small) magic numbers, often only two bytes. I
verified that modifying only two bytes in a TC volume made it appear as
a FAT volume in UDisks / GNOME Disks. So there is a non-negligible
chance that a TC/VC volume would be wrongly detected as
filesystem-formatted (i.e. greater than 1/2^16). In contrast, the
chi-squared test never identifies a filesystem header as random (I
forgot to note in my previous email that we calculate chi square only
over the first 512 bytes of the volume). There are still false
positives, but none that the blkid method wouldn't also have (i.e.
devices overwritten with random data, dmcrypt-plain volumes or loopAES
volumes).

Cheers!
intrigeri
2017-11-17 16:22:37 UTC
Permalink
Raw Message
Hi,
Post by .. ink ..
While here,i think it is a bad idea to try to figure out if a volume
is a TC/VC volume because there will be no point
in using these over LUKS if a volume can reliably be guessed to be
TC/VC.
The main reason why we at Tails need TC/VC unlocking support in GNOME
is inter-operability with other operating systems, rather than the
(optional and disputable) hidden property of TC/VC volumes: we need to
allow users to transfer files between Windows/macOS and Linux,
offline, in an encrypted manner, and without having to use the command
line. For the record this comes from actual user needs we've
identified. Sadly, LUKS does not address this need currently, hence
this project :)

In passing, with this use case in mind, said TC/VC volume can be
created on Windows/macOS, which is why our current primary goal is
limited to unlocking such devices on GNOME. Supporting the creation of
such devices in GNOME makes it harder to design the UI because we
would need to help users choose between LUKS and TC/VC depending on
their situation. It's certainly doable technically, but the
cost/benefit in terms of UX seems highly disputable to me. Anyhow, our
UX people are better qualified than me to make this call.

Cheers,
--
intrigeri
segfault
2017-11-14 19:08:37 UTC
Permalink
Raw Message
[...]
* 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.
Correct me if I'm wrong, but key files in TC/VC are a little bit different
concept than key files in LUKS where they are simply files containing the
passphrase (binary) data.
This is correct, but it is also true that both LUKS and TC/VC keyfiles
are currently not supported by GNOME Disks and GVFs, which could be
fixed via the same UI patches.
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.
Sounds great to me otherwise. Thanks for working and willing to work on
this, everybody!
Same!
Vratislav Podzimek
2017-11-14 15:18:44 UTC
Permalink
Raw Message
Post by segfault
Hi,
we at Tails (tails.boum.org) currently work on integrating support for
unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
monitor). We internally track the status of this work in [1] and [2].
Currently we are gathering data on the requirements of our users via a
survey [3], in order to make decisions about which features we want to
implement (support for legacy TrueCrypt volumes, file containers, hidden
volumes, keyfiles).
We would like to know whether you want to have VeraCrypt/TrueCrypt
support in upstream too. I assume that this is wanted in udisks2,
because there is already an open ticket for this [4]. What about GNOME
Disks?
[1] https://labs.riseup.net/code/issues/6337
[2] https://labs.riseup.net/code/issues/11684
[3] https://mailman.boum.org/pipermail/tails-ux/2017-October/003505.html
[4] https://github.com/storaged-project/udisks/issues/282
I forgot to add: Assuming that you would like to have this in upstream,
some heads up for when it would be ideal for us if an upstream
- We will evaluate the results of the survey and make design decisions
in December
- Patches will probably be ready in January
Hi,
as far as this is concerned I would say it doesn't really matter. The only
thing related to this is that fact that the libblockdev patches need to
land first so it would be nice if they came first.

Thanks!
--
Vratislav Podzimek
Senior Software Engineer
Kernel Storage
Red Hat Czech, Brno
segfault
2017-11-14 19:05:06 UTC
Permalink
Raw Message
Post by Vratislav Podzimek
[...]
Post by segfault
I forgot to add: Assuming that you would like to have this in upstream,
some heads up for when it would be ideal for us if an upstream
- We will evaluate the results of the survey and make design decisions
in December
- Patches will probably be ready in January
Hi,
as far as this is concerned I would say it doesn't really matter. The only
thing related to this is that fact that the libblockdev patches need to
land first so it would be nice if they came first.
Ok. I'm not sure if libblockdev patches are required at all, but if it
turns out they are, I will try to prepare them first.

Cheers!
Vratislav Podzimek
2017-11-15 07:41:15 UTC
Permalink
Raw Message
Post by segfault
Post by Vratislav Podzimek
[...]
Post by segfault
I forgot to add: Assuming that you would like to have this in upstream,
some heads up for when it would be ideal for us if an upstream
- We will evaluate the results of the survey and make design decisions
in December
- Patches will probably be ready in January
Hi,
as far as this is concerned I would say it doesn't really matter. The only
thing related to this is that fact that the libblockdev patches need to
land first so it would be nice if they came first.
Ok. I'm not sure if libblockdev patches are required at all, but if it
turns out they are, I will try to prepare them first.
TC/VC key files are not supported by libblockdev now. But I believe
everything else should be covered.

Thanks!
--
Vratislav Podzimek
Senior Software Engineer
Kernel Storage
Red Hat Czech, Brno
segfault
2018-02-11 13:16:53 UTC
Permalink
Raw Message
Hi,
Hi,
we at Tails (tails.boum.org) currently work on integrating support for
unlocking VeraCrypt (and probably also TrueCrypt) volumes in Tails via
udisks2 and GNOME Disks (and maybe also GNOME Files and the GVfs
monitor). We internally track the status of this work in [1] and [2].
Currently we are gathering data on the requirements of our users via a
survey [3], in order to make decisions about which features we want to
implement (support for legacy TrueCrypt volumes, file containers, hidden
volumes, keyfiles).
We would like to know whether you want to have VeraCrypt/TrueCrypt
support in upstream too. I assume that this is wanted in udisks2,
because there is already an open ticket for this [4]. What about GNOME
Disks?
[1] https://labs.riseup.net/code/issues/6337
[2] https://labs.riseup.net/code/issues/11684
[3] https://mailman.boum.org/pipermail/tails-ux/2017-October/003505.html
[4] https://github.com/storaged-project/udisks/issues/282
Yesterday I opened pull requests for this in libblockdev [1] and udisks [2].

I mentioned previously that we were gathering data on the requirements
of our users. The results are available on our website [3]. We found
that all of the various VeraCrypt/TrueCrypt specific features, like
hidden volumes, system volumes, keyfiles, are used by a high ratio of
users, so we implemented all of them.

We are currently working on the patches for the unlock dialog in Disks.
This will probably be finished soon. The resulting UI is much more
complex than in the LUKS case, but this simply reflects the more complex
needs of VeraCrypt users.

We already designed the UI changes for creating VeraCrypt/TrueCrypt
volumes in Disks [4], but this will not be implemented before at least a
few weeks, because we chose to prioritize other work higher (backporting
the patches to the versions shipped in Tails / Debian Stretch, patching
the unlock dialog opened by the GVfs udisks2 volume monitor).

Cheers!

[1] https://github.com/storaged-project/libblockdev/pull/320
[2] https://github.com/storaged-project/udisks/pull/495
[3] https://tails.boum.org/blueprint/veracrypt/#survey
[4] https://tails.boum.org/blueprint/veracrypt/#ui
segfault
2018-02-20 11:52:53 UTC
Permalink
Raw Message
Hi,
Post by segfault
We are currently working on the patches for the unlock dialog in Disks.
This will probably be finished soon. The resulting UI is much more
complex than in the LUKS case, but this simply reflects the more complex
needs of VeraCrypt users.
the Disks patches are ready now, they can be found in the support-tcrypt
branch at https://github.com/segfault3/gnome-disk-utility.

This branch requires udisks and libblockdev with TCRYPT support, which
can be found in the support-tcrypt and add_veracrypt branches at:
https://github.com/segfault3/udisks
https://github.com/segfault3/libblockdev

This extends the unlock dialog by widgets which allow specifying the
parameters supported by TrueCrypt and VeraCrypt volumes. This includes:

- Whether the volume to be unlocked is hidden.
- Whether the volume to be unlocked is a system partition.
Note: TrueCrypt and VeraCrypt only support encrypting Windows system
partitions [1], so the label for this option is "Windows system".
- Whether to use a PIM [2].
- Whether to use one or multiple keyfiles. In the beginning there is
only one button to choose a single keyfile. When a keyfile is chosen,
another button appears below to allow selecting another keyfile, and
so on.

To reduce the number of options displayed by default, the additional
options are hidden below an expander labeled "More options".

Since TCRYPT volumes cannot be reliably detected as such, a label is
displayed at the top of the unlock dialog to indicate to the user that
this volume might not actually be encrypted.

[1] https://www.veracrypt.fr/en/System%20Encryption.html
[2] https://www.veracrypt.fr/en/Header%20Key%20Derivation.html

Cheers!

Loading...