Project

General

Profile

Feature #6337

Feature #14468: Add VeraCrypt support to Tails

Add support for VeraCrypt volumes in udisks

Added by intrigeri about 4 years ago. Updated 11 days ago.

Status:
In Progress
Priority:
Normal
Assignee:
Category:
-
Target version:
Start date:
03/01/2017
Due date:
% Done:

25%

QA Check:
Info Needed
Feature Branch:
Type of work:
Code
Blueprint:
Easy:
No
Affected tool:

Description

This is "A.4 Add VeraCrypt support to udisks".

Upstream ticket: https://github.com/storaged-project/udisks/issues/282

Upstream feature request (unanswered since 2013): https://bugs.freedesktop.org/show_bug.cgi?id=70164

After TC volumes are supported in udisks, support can be added in GNOME Disks, Nautilus, whatever.

Screenshot GNOME Disks.jpg View (14.3 KB) segfault, 10/23/2017 09:51 AM


Subtasks

Feature #12276: Let udisks upstream know we intend to add VeraCrypt supportResolvedsegfault

Feature #14461: Review VeraCrypt support in udisksConfirmedanonym

Feature #14462: Upstream VeraCrypt support in udisksConfirmedsegfault

Feature #14470: Write tests for VeraCrypt support in udisksConfirmedanonym


Related issues

Duplicated by Tails - Bug #11069: GUI for CRYPTSETUP. Duplicate 02/07/2016
Blocks Tails - Feature #11684: Add support for VeraCrypt volumes in GNOME Disks Confirmed 03/01/2017
Blocks Tails - Feature #14464: Add VeraCrypt support to GNOME Files Confirmed 08/28/2017

History

#1 Updated by intrigeri over 3 years ago

  • Parent task deleted (#5703)

#2 Updated by intrigeri about 3 years ago

  • Type of work changed from Upstream to Wait

#3 Updated by intrigeri almost 2 years ago

  • Duplicated by Bug #11069: GUI for CRYPTSETUP. added

#4 Updated by Dr_Whax over 1 year ago

  • Blocks Feature #11684: Add support for VeraCrypt volumes in GNOME Disks added

#5 Updated by intrigeri over 1 year ago

  • Assignee set to segfault
  • Target version set to 2017
  • Type of work changed from Wait to Code

#7 Updated by segfault 3 months ago

  • Subject changed from Add support for TrueCrypt volumes in udisks to Add support for TrueCrypt/VeraCrypt volumes in udisks
  • Description updated (diff)
  • Target version changed from 2017 to SponsorW_2017

udisks now uses libblockdev as a backend, and libblockdev already supports opening truecrypt/veracrypt volumes. So we only have to make udisks use the libblockdev functions for handling truecrypt/veracrypt volumes.

#8 Updated by segfault 3 months ago

  • Subject changed from Add support for TrueCrypt/VeraCrypt volumes in udisks to Add support for VeraCrypt volumes in udisks

#9 Updated by segfault 3 months ago

#10 Updated by segfault 3 months ago

  • Blocks deleted (Feature #11684: Add support for VeraCrypt volumes in GNOME Disks)

#11 Updated by segfault 3 months ago

  • Blocks deleted (Feature #14464: Add VeraCrypt support to GNOME Files)

#12 Updated by segfault 3 months ago

  • Parent task set to #14468

#13 Updated by segfault 3 months ago

  • Target version deleted (SponsorW_2017)

#14 Updated by segfault 3 months ago

  • Target version set to Tails_3.4

#15 Updated by segfault 3 months ago

  • Blocks Feature #11684: Add support for VeraCrypt volumes in GNOME Disks added

#16 Updated by segfault 3 months ago

#17 Updated by intrigeri about 2 months ago

  • Description updated (diff)

#18 Updated by segfault about 2 months ago

I added support to unlock and lock TrueCrypt and VeraCrypt volumes in udisks. The code is in my fork of udisks on GitHub in branch support-truecrypt.

Implementation of the unlocking/locking itself was easy, because this was already implemented in libblockdev, which is used in udisks.

It was harder to get a useful indicator for whether a device is a TC/VC volume or not. Unlike LUKS volumes, TC/VC volumes do not contain a plaintext header - they just look like random data. We started a discussion about how to handle this on tails-dev@.

#19 Updated by segfault about 1 month ago

  • Assignee changed from segfault to anonym
  • QA Check set to Ready for QA

I added a function block_seems_encrypted() which calculates the chi square value to determine whether the device seems to contain random data. Using this, I can display the unlock button in GNOME Disks only for random looking devices, which includes devices encrypted with TrueCrypt or VeraCrypt, but also other encryption types like dm-crypt in plain mode and loop-AES (see my email Re: TrueCrypt/VeraCrypt volumes undetectable on tails-dev@).

Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).

Could you review this anonym?

#20 Updated by segfault about 1 month ago

I continued working on this. To let the user choose which type an encrypted device is, I added radio buttons to the GNOME Disks unlock dialog, and use the chosen type in the udisks unlock function (currently only TrueCrypt and VeraCrypt, but I could easily add dm-crypt plain and Loop-AES too, if we decide that we want that).

Afterwards, I noticed that if cryptsetup's unlock is called with the VeraCrypt option, it also tries the TrueCrypt modes in addition to the VeraCrypt modes [1]. This means that if we would always use the VeraCrypt option to unlock possible TC/VC volumes, we can unlock both TrueCrypt and VeraCrypt option. So we don't actually have to ask the user whether a device is TrueCrypt or VeraCrypt encrypted. A disadvantage of this is that trying to unlock VeraCrypt volumes takes a lot longer than trying to unlock TrueCrypt volumes, especially if the password is wrong, so that all modes are tested [2]. This means that when a TrueCrypt user enters their password incorrectly, they would have to wait a lot longer [3].

[1] I asked on the dm-crypt mailing list to confirm that this is intentional.
[2] This is because VeraCrypt uses more iterations for the key derivation function, in order to make brute forcing harder. So this is a feature.
[3] On my system, cryptsetup unlock with the VeraCrypt option and an incorrect password takes 15 seconds, versus 0.2 seconds for TrueCrypt volumes.

Now I see three options, and I think we should balance the pros and cons:

1. Always use the VeraCrypt option to unlock devices which could be TC/VC volumes.

  • Pro: No additional options exposed to the user.
  • Con:
    • dm-crypt plain and Loop-AES encrypted devices unsupported
    • dm-crypt plain and Loop-AES encrypted devices are treated as TC/VC candidates (more false positives)
    • TrueCrypt users have to wait longer if they enter their password incorrectly

2. Let user choose from VeraCrypt, TrueCrypt, dm-crypt plain, and Loop-AES

  • Pro: None of the cons of 1.
  • Con: options exposed to the user

3. Let user choose from VeraCrypt, TrueCrypt

  • Pro: TrueCrypt users don't have to wait longer if they enter their password incorrectly
  • Con: All other cons of 1. and 2.

3 seems like the worst choice. I'm not sure about 1 or 2, but I lean towards 2. What do you think? Did I miss anything?

#21 Updated by anonym about 1 month ago

  • Status changed from Confirmed to In Progress
  • Assignee changed from anonym to segfault
  • QA Check changed from Ready for QA to Dev Needed

segfault wrote:

I added a function block_seems_encrypted() which calculates the chi square value to determine whether the device seems to contain random data. Using this, I can display the unlock button in GNOME Disks only for random looking devices, which includes devices encrypted with TrueCrypt or VeraCrypt, but also other encryption types like dm-crypt in plain mode and loop-AES (see my email Re: TrueCrypt/VeraCrypt volumes undetectable on tails-dev@).

Cool!

Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).

My understanding is that this is fixed; let me know if I have misunderstood!

Could you review this anonym?

All looks good until 1d4d37f5268a980774fbe358f20b2cc87e28b96d ("Set hint_encryption_type on successful decryption"), good job!

However, please don't rebase the branch while I'm still looking at it as it makes it hard for me to track the exact changes without taking extra steps.

I continued working on this. To let the user choose which type an encrypted device is, I added radio buttons to the GNOME Disks unlock dialog, and use the chosen type in the udisks unlock function (currently only TrueCrypt and VeraCrypt, but I could easily add dm-crypt plain and Loop-AES too, if we decide that we want that).

Afterwards, I noticed that if cryptsetup's unlock is called with the VeraCrypt option, it also tries the TrueCrypt modes in addition to the VeraCrypt modes [1]. This means that if we would always use the VeraCrypt option to unlock possible TC/VC volumes, we can unlock both TrueCrypt and VeraCrypt option. So we don't actually have to ask the user whether a device is TrueCrypt or VeraCrypt encrypted. A disadvantage of this is that trying to unlock VeraCrypt volumes takes a lot longer than trying to unlock TrueCrypt volumes, especially if the password is wrong, so that all modes are tested [2]. This means that when a TrueCrypt user enters their password incorrectly, they would have to wait a lot longer [3].

[1] I asked on the dm-crypt mailing list to confirm that this is intentional.
[2] This is because VeraCrypt uses more iterations for the key derivation function, in order to make brute forcing harder. So this is a feature.
[3] On my system, cryptsetup unlock with the VeraCrypt option and an incorrect password takes 15 seconds, versus 0.2 seconds for TrueCrypt volumes.

Thanks for getting to the bottom of this!

Now I see three options, and I think we should balance the pros and cons:

1. Always use the VeraCrypt option to unlock devices which could be TC/VC volumes.

  • Pro: No additional options exposed to the user.
  • Con:
  • dm-crypt plain and Loop-AES encrypted devices unsupported
  • dm-crypt plain and Loop-AES encrypted devices are treated as TC/VC candidates (more false positives)
  • TrueCrypt users have to wait longer if they enter their password incorrectly

2. Let user choose from VeraCrypt, TrueCrypt, dm-crypt plain, and Loop-AES

  • Pro: None of the cons of 1.
  • Con: options exposed to the user

3. Let user choose from VeraCrypt, TrueCrypt

  • Pro: TrueCrypt users don't have to wait longer if they enter their password incorrectly
  • Con: All other cons of 1. and 2.

3 seems like the worst choice. I'm not sure about 1 or 2, but I lean towards 2. What do you think? Did I miss anything?

I'm not sure either. I sort of like 1:

  • we (Tails) don't care about dm-crypt plain and Loop-AES support, and I expect few people do, and those that do are probably experts that don't depend on this functionality in GNOME Disks (personal anecdotes: I've only seen people use those for FDE of their system, not for removable media where having this kind of integration is convenient).
  • I would expect dm-crypt plain and Loop-AES volumes to be really uncommon (again, only used by "experts") so I'm not worried about them causing much confusion via false positives.
  • Since TrueCrypt is a legacy mode that people should migrate away from, the long waiting time in case of passphrase typos isn't so bad.

But 2 is not so bad, but I think TrueCrypt and VeraCrypt can be merged, per the argument of my last point above. By the same argument, 3 becomes the same as 1.

I think you should ask sajolida's opinion (and weigh it higher than mine :))!

#22 Updated by segfault about 1 month ago

  • Assignee changed from segfault to sajolida
  • QA Check changed from Dev Needed to Info Needed

anonym wrote:

segfault wrote:

Another problem I faced while working on GNOME Disks is that it showed the encryption type of TrueCrypt volumes as crypto_unknown even after decrypting the volume, although after successful decryption it is clear that the encryption type is TrueCrypt. I solved this by adding a hint_encryption_type property to the Encrypted interface, which I set on a successful decryption (in udisks).

My understanding is that this is fixed; let me know if I have misunderstood!

Well yeah, I found a solution. I'm not sure if it is the best one, because the D-Bus properties are reset after restarting the udisks2 service (i.e. after reboot). To persistently store the encryption type, it would have to be stored in (yet another) device config file. But this config file would also prove that a device is a TC/VC volume and that it has been accessed from the system, something that TrueCrypt and VeraCrypt try to avoid by default (i.e. if a volume is not set as a favorite).
So I think my solution is good enough for a start, and we'll see what upstream thinks about this.

All looks good until 1d4d37f5268a980774fbe358f20b2cc87e28b96d ("Set hint_encryption_type on successful decryption"), good job!

Cool, thanks for the review!

However, please don't rebase the branch while I'm still looking at it as it makes it hard for me to track the exact changes without taking extra steps.

Ok, sorry about that.

Now I see three options, and I think we should balance the pros and cons:

1. Always use the VeraCrypt option to unlock devices which could be TC/VC volumes.

  • Pro: No additional options exposed to the user.
  • Con:
  • dm-crypt plain and Loop-AES encrypted devices unsupported
  • dm-crypt plain and Loop-AES encrypted devices are treated as TC/VC candidates (more false positives)
  • TrueCrypt users have to wait longer if they enter their password incorrectly

2. Let user choose from VeraCrypt, TrueCrypt, dm-crypt plain, and Loop-AES

  • Pro: None of the cons of 1.
  • Con: options exposed to the user

3. Let user choose from VeraCrypt, TrueCrypt

  • Pro: TrueCrypt users don't have to wait longer if they enter their password incorrectly
  • Con: All other cons of 1. and 2.

3 seems like the worst choice. I'm not sure about 1 or 2, but I lean towards 2. What do you think? Did I miss anything?

I'm not sure either. I sort of like 1:

  • we (Tails) don't care about dm-crypt plain and Loop-AES support, and I expect few people do, and those that do are probably experts that don't depend on this functionality in GNOME Disks (personal anecdotes: I've only seen people use those for FDE of their system, not for removable media where having this kind of integration is convenient).
  • I would expect dm-crypt plain and Loop-AES volumes to be really uncommon (again, only used by "experts") so I'm not worried about them causing much confusion via false positives.
  • Since TrueCrypt is a legacy mode that people should migrate away from, the long waiting time in case of passphrase typos isn't so bad.

But 2 is not so bad, but I think TrueCrypt and VeraCrypt can be merged, per the argument of my last point above. By the same argument, 3 becomes the same as 1.

I think you're right and probably no one cares about dm-crypt plain and Loop-AES. So I'm totally fine with 1, but I'm also curious what upstream will say about this.

I think you should ask sajolida's opinion (and weigh it higher than mine :))!

Right. I'm assigning this to sajolida then.

#23 Updated by segfault about 1 month ago

Another thing I would like to get feedback on is my choice of the "crypto_unknown" labels. I chose "Possibly Encrypted" as the long description and "Encrypted?" as the short description in udisksclient.c. You can see how this is displayed in GNOME Disks in the attached screenshot. I'm not really happy with this, maybe you come up with something better.

If we would go with option 1, we could also drop the "crypto_unknown" type and treat every block device which passes the Chi-Square test as a TC/VC volume and set the description to "TCRYPT" or "TrueCrypt/VeraCrypt". Then we also wouldn't need the hint_encryption_type property, and wouldn't have to care about it not being persistent. On the other hand, it could of course lead to false positives, which would be confusing to the user. What do you think?

#24 Updated by sajolida 29 days ago

I hope I'm not going to be too much of a party pooper here, sorry in advance.

I scanned through this thread and it seems like you're discussion UI elements already and asking for my opinion on them. Disclaimer: I didn't took the time to read it in depth or understand your discussion. Since we have an in-person sprint scheduled in December to come up with a good UI for this feature I really want to save my time and energy for the sprint where it will be much fast to discuss all these issues and where being able to test our ideas as early as possible with users will also lead to much better results.

I'm afraid that, the more we discuss here, the more work might get questioned down the road and this might cause pain for everybody. It might as well be 100% fine but we won't know until we test our assumptions with users. We followed a process like this for the early design of Tails Server: discuss things amongst us over email until we had a beta, and I'm personally not very happy with the process we had back then. And that's why I proposed a different process this time.

I see that the "Target version" for my "Info Needed" is 3.4 which is in January. So if you can wait until the sprint, that's perfect!

Otherwise, for example if my opinion here is blocking you on "Evaluation of implementation cost", please clarify.

#25 Updated by intrigeri 18 days ago

sajolida wrote:

Otherwise, for example if my opinion here is blocking you on "Evaluation of implementation cost", please clarify.

segfault, what do you think?

#26 Updated by segfault 11 days ago

intrigeri wrote:

sajolida wrote:

Otherwise, for example if my opinion here is blocking you on "Evaluation of implementation cost", please clarify.

segfault, what do you think?

This is of course blocking almost all of the work on the whole VeraCrypt project, but I see that it makes sense to wait for the evaluation of the sprint.

Also available in: Atom PDF