Qubes Duress - Deniable Qubes Instalation

Emily you are so smart and I always like reading what you’ve typed when I am smart enough to understand it.

Myself and many others would like to know what you mean. Do you mean putting two OSes on a external drive with one that is Qubes and one not using the Veracrypt hidden OS guide? Do you mean something else?

2 Likes

@Qubes Modo. Sugestion:
I think it should be an option at Qubes install, to create a vanilla environment (or not: optional) that looks like a common OS.
Like the ability to create a WinLE envionment which will (minimally) run on surface.
When installing, if the option is selected, then Qubes will create a first screen environment (a Qubes outside of Dom0) that will pop-up when the computer is started, with a few basic applications, navigator, games, so whenever lambda officer at border open it to check it out, is starts right into this.
But somewhere inside that fake OS, there is a key to open the actual Qubes-os, with or without a code.

If someone wants to try to implement something, they could look at how Split Linux is doing a decoy OS

https://splitlinux.org/

2 Likes

Exactly !
That’s exactly what I had in mind … Qubes should have a front-screen/decoy OS

SplitLinux install a system with containers, in which the first container is not protected, and open up straight at login;
Unless loging-in with a login that leads to a protected container.
I’m wondering if Qubes would work if installed into one of those containers ?

Question:
If I install a vanilla OS how do I make it look like it takes up the 4TB of disk ?
Let say Suse leap 15, which would be thenonly one showing up in the boot menu since Qubes /boot would be on a separate USB
How do I install Suse so when an agent opens it, they see its size is the entire disks (2TB+2TB+512Go) would an expandable LVM works ?
Actual install = 64Go, make-beleive install = 4,5To
Or is it too much trouble for no result, as it would be too easy to spot ?

In order to resist to the basic searches (like border inspection), why not having a simple dual-boot managed by the UEFI, with a default boot to the “decoy” OS ?

And then if one would like to boot into an alternate OS, they have to be able to reach the UEFI boot menu that they will protect by a password. Then if during a short search the inspector ask for the boot menu password (it feels unlikely), simply state that it’s a corporate laptop and only your employer will have the UEFI passwords.

Also, in order to keep the “decoy” OS credible, it’s possible to start physically installed OS into VM. So simply make a VM with it (I’m not sure how to proceed with Xen, I’ve made this with VirtualBox and KVM) and perform low security tasks on them.

Of course, this will be useful only against basic inspections. For everything which involves real forensic, the threat protection will require much more creative solutions, but also many good pratices, and will need to be adapted to your threat actors.