Using DispVMs to maintain plausible deniability when working with hidden encrypted containers

[Qubes Fan]

Hi all,

I've been mulling this idea over for some time and decided to submit it to the group for feedback since I haven't seen it mentioned yet.

As I'm sure you all know, one of the primary problems with 'deniable encryption' is that even if the encryption software itself is done correctly, opening a hidden container and working with the data leaves traces strewn all over the disk. This is what Bruce Schneier and his team found back in the days of TrueCrypt 5.1a, which prompted the implementation of hidden operating systems. Since hidden operating systems aren't available in Linux environments, TrueCrypt's documentation recommends that Linux users use hidden volumes only with a live-CD so that all the data is written to a RAM disk. But, wait! Aren't Qubes' DispVMs kept entirely in RAM by default? Yes, they are (AFAIK)! So, does this make DispVMs perfectly suited for using deniable encryption? Well, what do you think?

[Joanna Rutkowska]

On 06/20/13 18:03, Qubes Fan wrote:
> Hi all,
>
> I've been mulling this idea over for some time and decided to submit it to
> the group for feedback since I haven't seen it mentioned yet.
>
> As I'm sure you all know, one of the primary problems with 'deniable
> encryption' is that even if the encryption software itself is done
> correctly, opening a hidden container and working with the data leaves
> traces strewn all over the disk. This is what Bruce Schneier and his team

> found <http://www.cs.washington.edu/homes/supersat/paper-truecrypt-dfs.pdf>back in the days of TrueCrypt 5.1a, which prompted the implementation of hidden
> operating systems <http://www.truecrypt.org/docs/hidden-operating-system>.

> Since hidden operating systems aren't available in Linux environments,
> TrueCrypt's documentation recommends that Linux users use hidden volumes

> only with a live-CD<http://www.truecrypt.org/docs/hidden-volume-precautions>so that all the data is written to a RAM disk. But, wait! Aren't Qubes'

> DispVMs kept entirely in RAM by default? Yes, they are (AFAIK)! So, does
> this make DispVMs perfectly suited for using deniable encryption? Well,
> what do you think?
>

Yes, I think so.

But, let's look at this from a different perspective -- if you assume
your client OS *can* be compromised (and so somebody can get access to
the unencrypted various system files from your system, such as swap),
then... the same attack can be used to subvert your plausible
deniability, no matter if all the crypto is not leaving traces on the
disk. They will just capture your keystrokes, or take a screenshot by
hooking into GUI server or GPU. Or something. In other words you cannot
achieve plausible dependability, no matter what.

On the other hand, if you assume your client system to be safe, i.e. not
compromised, then it should not matter if your plausible deniability
crypto scheme is leaving traces in some system files or not -- they
still are secure.

joanna.

[Qubes Fan]

Plausible deniability matters even if we assume that the client system is safe (not compromised) since the user can be compelled (physically forced, threatened, subpoenaed, or blackmailed) to decrypt the data. Here are three distinct scenarios off the top of my head:

• The user is a wealthy and/or powerful individual, or one with valuable knowledge, who is subject to a sophisticated, targeted robbery. The criminals enter his home and force him to decrypt his system, including any encrypted volumes they find on it. They have the technical ability/expertise to check the filesystem and disks for traces of the data they're looking for (account numbers, corporate secrets, passphrases, etc.). It's likely that he will be seriously injured or killed if he does not comply with the command to decrypt, but it is not as likely that he will be as seriously injured, or at least killed, for claiming that no hidden volumes exist ("Are you crazy? I don't store any of that stuff here! It's all on company servers, so that I'm not a target for people like you!"), since the criminals cannot know whether he is telling the truth (if deniable encryption is being properly implemented). For various economic and legal reasons, they have less to gain and more to lose by killing him over data which potentially does not exist on the system. (Side note: What about rubber hose cryptanalysis? Think about it as a prisoner's dilemma, and you'll see that the dominant strategy is to use the deniable encryption because your adversary, who can't be sure, will torture you anyway.)
• The user is an individual engaged in morally justified activity who is being surveilled by a corrupt government. (Any resemblance to real persons, living or dead, is purely coincidental! :P) One day, agents show up at her door with a warrant for all 'electronic storage devices'. [One or more of the following is the case: (1) She powered down her system last night before going to sleep and was just now woken up by the doorbell. (2) She is in the habit of powering down her system before answering unexpected knocks at the door. (3) The system is powered on, but all hidden encrypted containers are dismounted, all DispVMs in which data from those volumes have been processed have been closed, and no data from hidden volumes remains in RAM.] The agents seize her systems and disks. At some later point, she is legally compelled by the courts to provide passwords and/or decrypt her data. The techies are then free to comb through her installation of Qubes and every bit of the disk(s), but she can plausibly deny that there are any hidden containers to decrypt. (Side note: What if your government is so corrupt that suspicion is sufficient for conviction? Then you're screwed. But even a government which spies on its own citizens, say, by listening to their phone calls, collecting their emails, and analyzing their social networks, wouldn't convict a person over data that they can't even prove is there... right?)
• You're stopped at the border of a country which requires you to decrypt the contents of your laptop before being allowed to enter. You neglected to set up a dummy OS (standard unencrypted Windows installation with the real real encrypted OS behind it; boot partition of the real OS on a microSD card sewn into the lining of your carry-on luggage), or you have reason to believe that the customs officials are smart enough to detect a dummy OS, or the consequences for being caught lying to the authorities in this country are so severe that you'd rather not risk it. (The rest is self-explanatory by now, I think. Deniable encryption saves your secrets, etc.)

(NB: As a fiction author, I have an overactive imagination, and I only discuss this because I need fodder for my novels. Also, no one should ever do anything illegal, ever! Anyone who gets the impression that I have suggested otherwise has misinterpreted my words.)

[Joanna Rutkowska]

> - The user is a wealthy and/or powerful individual, or one with valuable

> knowledge, who is subject to a sophisticated, targeted robbery. The
> criminals enter his home and force him to decrypt his system, including any
> encrypted volumes they find on it. They have the technical
> ability/expertise to check the filesystem and disks for traces of the data
> they're looking for (account numbers, corporate secrets, passphrases,
> etc.). It's likely that he will be seriously injured or killed if he does
> not comply with the command to decrypt, but it is not as likely that he
> will be as seriously injured, or at least killed, for claiming that no
> hidden volumes exist ("Are you crazy? I don't store any of that stuff here!
> It's all on company servers, so that I'm not a target for people like
> you!"), since the criminals cannot know whether he is telling the truth (if
> deniable encryption is being properly implemented). For various economic
> and legal reasons, they have less to gain and more to lose by killing him
> over data which potentially does not exist on the system. (Side note: What
> about rubber hose cryptanalysis? Think about it as a prisoner's dilemma,
> and you'll see that the dominant strategy is to use the deniable encryption
> because your adversary, who can't be sure, will torture you anyway.)

> - The user is an individual engaged in morally justified activity who is

> being surveilled by a corrupt government. (Any resemblance to real persons,
> living or dead, is purely coincidental! :P) One day, agents show up at her
> door with a warrant for all 'electronic storage devices'. [One or more of
> the following is the case: (1) She powered down her system last night
> before going to sleep and was just now woken up by the doorbell. (2) She is
> in the habit of powering down her system before answering unexpected knocks
> at the door. (3) The system is powered on, but all hidden encrypted
> containers are dismounted, all DispVMs in which data from those volumes
> have been processed have been closed, and no data from hidden volumes
> remains in RAM.] The agents seize her systems and disks. At some later
> point, she is legally compelled by the courts to provide passwords and/or
> decrypt her data. The techies are then free to comb through her
> installation of Qubes and every bit of the disk(s), but she can plausibly
> deny that there are any hidden containers to decrypt. (Side note: What if
> your government is so corrupt that suspicion is sufficient for conviction?
> Then you're screwed. But even a government which spies on its own citizens,
> say, by listening to their phone calls, collecting their emails, and
> analyzing their social networks, wouldn't convict a person over data that
> they can't even prove is there... right?)

> - You're stopped at the border of a country which requires you to

> decrypt the contents of your laptop before being allowed to enter. You
> neglected to set up a dummy OS (standard unencrypted Windows installation
> with the real real encrypted OS behind it; boot partition of the real OS on
> a microSD card sewn into the lining of your carry-on luggage), or you have
> reason to believe that the customs officials are smart enough to detect a
> dummy OS, or the consequences for being caught lying to the authorities in
> this country are so severe that you'd rather not risk it. (The rest is
> self-explanatory by now, I think. Deniable encryption saves your secrets,
> etc.)
>
> (NB: As a fiction author, I have an overactive imagination, and I only
> discuss this because I need fodder for my novels. Also, no one should ever
> do anything illegal, ever! Anyone who gets the impression that I have
> suggested otherwise has misinterpreted my words.)
>

Ok, I agree you might have a point here.

joanna.

[Joanna Rutkowska]

And, BTW, I think discussions such as this might be better suited for
the qubes-devel list.

joanna.

[Qubes Fan]

Agreed. I was just thinking that I should have posted it to that list instead. If there's a way to move it over, please feel free.

Anyway, given that this sort of functionality might be important and valuable to some people, I wonder about the practicality of implementing it. For example, I installed tcplay in my Fedora template, but I didn't see it in the list of applications to select for an AppVM.

I imagine it's just a matter of customizing the DispVM to contain this program (or one like it) and preferably no network access. Then, I guess, use inter-VM file transfer to get the encrypted volume into the DispVM, open the hidden volume in there, do your work, close it, and use inter-VM file transfer to put it back into your 'vault' domain? I suppose it would be faster to somehow leave the volume in the vault domain but open it from inside the DispVM. Not sure if there's a way to do that safely, though.

[Qubes Fan]

On second thought, both of these methods are technically vulnerable, since they leave at least a forensically recoverable version of the volume prior to any changes in addition to the current volume post-changes. To avoid this, you would have to create a new volume (with a new hidden volume inside of it) in the DispVM and transfer the files from the previous respective volumes into them each time you make a change.

[FR]

Scenario.

AFAIK the brain is the deniable encrypted container to use

(unless like keepass you dont want to know you own passwords for the said sere reasons)

It seems risky to pass the frontier with the data in the deniable container in qubes os in your computer.

I would separate them on different flights :

- the expert with the knowledge : what you know

- the qubes os installer in a physically hidden sd card : what you are

- the HCL laptop but with windows xp on it :P : what you have

then reassemble the body of proof behind the bad police lines.

I think that Qubes os is for facebook, linkedin, the cloud and you bank account

on the same time.

I dont think that the said expert really want to engage in facebook or meetic at lunch 

or after work. Generation Y perharps ?

the invisible things lab blog informed that there are other confidential OS

with bell-lapadula features. And that Qubes os in more mainstream.

FR.