Project

General

Profile

Feature #17033

Allow using VeraCrypt hidden volumes without having a dedicated option in the UI

Added by op_mb 2 months ago. Updated 2 months ago.

Status:
Confirmed
Priority:
Low
Assignee:
-
Category:
-
Target version:
-
Start date:
Due date:
% Done:

0%

Feature Branch:
Type of work:
Code
Blueprint:
Starter:
Affected tool:

Description

The current unlock dialogs have a dedicated "hidden" option, which could raise attention to the hidden volume feature to someone coercing a user to unlock their VeraCrypt volume.

Original description by @ob_mb:

hey all,

i read through some vera docs, about plausible deniability,
seems to me that giving an option for a hidden volume tick in tails goes against plausible deniability principle -

if condition exists where you have to revieal the password for the outer volume, you get a pop up asking you to tick the hidden volume. this goes agains the veracrypt specification:

"... VeraCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored (i.e. bytes 65536–131071 ..."

so ticking the hidden volume dialog, when providing the password, is not only redundunt (as per specification), but can also be dangerous in that case.

i mean, the code is in tails os already, right? so logic would be something like:

//
if (veracrypt_outer_password() false) {
if(veracrypt_inner_password() false)
return tails :: error;
else
return tails :: success;
} else return tails :: success;

//

what do you think?

p.s. i added the pic, couldnt take the pic of the veracrypt utility, so i took the pic from diskutil

Screenshot from 2019-09-08 15-51-23.png View (121 KB) op_mb, 09/08/2019 04:19 PM

History

#1 Updated by intrigeri 2 months ago

  • Assignee set to segfault

Hi @segfault, can you please triage this one?
I'm not sure what to do about it.

#2 Updated by op_mb 2 months ago

@//
if (veracrypt_outer_password() false) {
if(veracrypt_inner_password() false)
return tails :: error;
else
return tails :: success;
}else return tails :: success;
//@

#3 Updated by op_mb 2 months ago

code didnt format, i give up,lol

#4 Updated by op_mb 2 months ago

@segfault hey, cool-cool, will do :)

#5 Updated by op_mb 2 months ago

oh crap, i mustve accidently clicked assign, was a mistake, this is kust for discussion, i cant unedit it, lol

#6 Updated by segfault 2 months ago

op_mb wrote:

hey all,

i read through some vera docs, about plausible deniability,
seems to me that giving an option for a hidden volume tick in tails goes against plausible deniability principle -

I don't see why having an option to unlock the hidden volume instead of the outer volume would be a problem for plausible deniability - except if you're being watched while unlocking the volume, but then whoever watches you would probably also see you do something with the hidden volume's content, which would be different from the outer volume's content.

if condition exists where you have to revieal the password for the outer volume, you get a pop up asking you to tick the hidden volume. this goes agains the veracrypt specification:

"... VeraCrypt first attempts to decrypt the standard volume header using the entered password. If it fails, it loads the area of the volume where a hidden volume header can be stored (i.e. bytes 65536–131071 ..."

Yeah, that's from the VeraCrypt documentation. But cryptsetup, which we use to unlock VeraCrypt volumes, behaves differently. You have to tell cryptsetup which header to use, it doesn't automatically try the hidden header if the outer one can't be unlocked (which I see as a feature, it's the reason why you only have to wait half the time in Tails when you mistype your password, compared to VeraCrypt application).

so ticking the hidden volume dialog, when providing the password, is not only redundunt (as per specification), but can also be dangerous in that case.

Why would it be dangerous?

#7 Updated by op_mb 2 months ago

dangerous not in the sense of data analisys, but in the sense of, eg:

you get your machine visually examined, on demand or voluntarily,
examiner doesnt know much about encryption, when you put in the password, examiner sees the 'hidden volume',
straight away, question is - whats that, whats a hidden volume, how do i know you dont have one?

how do you prove you do/dont have one? it raises questions when it shouldnt.

its dangerous, because it raises the question of 'something might be hidden' to the visual examiner, not
to some cybertech person, who knows, it cant be proven whether it exists or not,
but try to explain it to somone who doesnt know, just puts you into a harder position when it shouldnt

#8 Updated by op_mb 2 months ago

You have to tell cryptsetup which header to use, it doesn't automatically try the hidden header if the outer one can't be unlocked

i understand what you mean,
would it be easy to implement a switch that just calls cryptsetup with the if/else condition?

// pseudo

if (cryptsetup_outer_password() false)
{
 if(cryptsetup_inner_password() false)
      return tails :: error;
 else
      return tails :: success;
}else return tails :: success;

#9 Updated by op_mb 2 months ago

p.s.:
also,

i understand that total run time is important.

p.p.s:

script that will switch cryptsetup

#10 Updated by op_mb 2 months ago

p.p.p.s.:

or maybe if you execute cryptsetup_outer volume and cryptsetup_hidden volume in parallel?

#11 Updated by segfault 2 months ago

  • Subject changed from VeraCrypt hidden volume to Allow using VeraCrypt hidden volumes without having a dedicated option in the UI
  • Category deleted (Continuous Integration)
  • Status changed from New to Confirmed
  • Assignee deleted (segfault)
  • Priority changed from Normal to Low
  • Type of work changed from Discuss to Code

its dangerous, because it raises the question of 'something might be hidden' to the visual examiner, not to some cybertech person, who knows, it cant be proven whether it exists or not, but try to explain it to somone who doesnt know, just puts you into a harder position when it shouldnt

OK, I understand that threat model, but I'm not sure how realistic it is. And I'm unsure about the trade-off regarding usability - unlocking a single VeraCrypt header takes up to 15s on my system (it takes that long when I enter an incorrect password and all the possible encryption and hash algorithms are tried), so if we automatically try to unlock the hidden volume afterwards, it will always take at least 15s to unlock a hidden volume, and take 30s if an incorrect password is entered for any kind of VeraCrypt volume.

Also, implementing this change and upstreaming this in both unlock dialogs which allow unlocking VeraCrypt volumes will be quite some effort. That's why I set the priority to low.

or maybe if you execute cryptsetup_outer volume and cryptsetup_hidden volume in parallel?

That could reduce the UX impact, but would be even more work to implement and upstream.

#12 Updated by segfault 2 months ago

  • Description updated (diff)

#13 Updated by intrigeri 2 months ago

OK, I understand that threat model, but I'm not sure how realistic it is. And I'm unsure about the trade-off regarding usability - unlocking a single VeraCrypt header takes up to 15s on my system (it takes that long when I enter an incorrect password and all the possible encryption and hash algorithms are tried), so if we automatically try to unlock the hidden volume afterwards, it will always take at least 15s to unlock a hidden volume, and take 30s if an incorrect password is entered.

Also, implementing this change and upstreaming this in both unlock dialogs which allow unlocking VeraCrypt volumes will be quite some effort. That's why I set the priority to low.

FWIW: I fully agree with this assessment. Thank you @segfault!

Also available in: Atom PDF