Deniable encryption

[andrewdavidwong]

On 2016-10-26 16:19, tonyinfinity@tutanota.com wrote:

Usecase: If you are unexpectedly legally or extra-legally coerced to decrypt your laptop.

In order of most desired to least:

1. Deniable FDE
   e.g. TrueCrypt/VeraCrypt-style hidden OS. I'm also not sure if these deniable encryption tools currently work with Qubes as is?

2. Deniable encrypted partitions

3. Deniable encrypted VMs

[quber]

Deniable encryption come with social danger and must not be include before serious thinking and discuss and community approve first.

In mailing list::

I will cough up my passphrase at the mere suggestion of torture. I would probably give up my passphrase if a scary person were to just ask nicely for it.

If Qubes were to incorporate any deniability features, I (and anybody who dislikes being tortured) would require a means to show absolutely that such features were not enabled. These are dangerous features because the moment they are incorporated we would all be using them, whether we are or not.

https://defuse.ca/truecrypt-plausible-deniability-useless-by-game-theory.htm

Read link before even thinking to work on this.

As far as I'm concerned, I'll take my chances and vote for having plausible deniability on Qubes-OS.

To reply to quber: Say I simply work on something sensitive / valuable (knowledge) and I'm not under suspicion of anything. A way to login to Qubes-OS without having the "attacker" know about my "normal" work session would be very useful, no negative side effect.

Also maybe a better example, look at the trend at the border control where they ask to see "inside" every electronic you have. In that case again, should someone be asked to open their laptop there's nothing to lose at having a way to login to an "under duress session".

[andersonarc]

I have conducted some research and developed a PoC implementation for deniable encryption. Issues mentioned in #4444 have been addressed by effectively making Qubes a 'live' OS while keeping unpriviliged qubes in a deniably encrypted, multi-volume partition. The current approach is rather hacky and involves splitting and reassembling qubes.xml during the initramfs stage (more information in README). The system has been tested locally and performs reasonably well, but there's still a lot of work to be done. Due to a significant amount of modifications, I am not sure whether this is fit for being included in Qubes by default. However, if approved, a better integration could be achieved by incorporating some of the features, namely:

• Live mode as per implement live boot by porting grub-live to Qubes - amnesia / non-persistent boot / anti-forensics #4982. We do not need it to be fully functional, just functional enough to run the system qubes. The current implementation requires patching create-snapshot.sh to avoid loading huge images into memory. Volatile images are also moved to a separate pool (/run/volatile) to avoid overwhelming OverlayFS.
• Split qubes.xml, e.g. by checking for domains.xml in storage pools flagged with 'external'. Currently implemented via a simple concatenation script.
• Stricter decoupling of qubes from each other, e.g. copy restrictions on hidden qubes - could be done via policy, if I understand correctly.
• Randomized QID for hidden, or even all qubes (if a user creates several hidden qubes and then a normal one, booting 'under duress' will reveal a suspicious gap in QIDs otherwise).