I’m not an expert in encryption, but why use separate disk? why not try encryption within encryption? maybe there will be some price to pay with CPU usage but I don’t see a reason why this shouldn’t work. You can test it with standalone App-VM and VeraCrypt with key file on external SDcard. However, I have no idea how to make this “special” qube invisible and not showing in menu.
1 Like
Can someone give us a couple of scenarios in which they think it would be beneficial to have a deniable Qubes OS installation (in any configuration)?
We already have:
- ”Pull out your laptop and let me click around for a few minutes, and I know nothing about computers” inspections at checkpoints
- Snooping partners/colleagues opening your computer when you’re not around
- “I’m just going to clone your hard drive” inspections
- “My laptop was seized by authorities/my employer/someone else, and I don’t want them finding my Qubes OS”
- This one’s a bit odd, to be honest, but hey, it’s a valid use case… - “I’ve been kidnapped by people who say they will torture me if I don’t ‘unlock my computer’, but thankfully they don’t know I use Qubes OS”
- “I’ve been kidnapped by people who say they will torture me if I don’t unlock my computer for them, and they do know that I have Qubes OS installed on that laptop”
Have I missed any?
3 Likes
I wish to hide from anyone that I use qubes.
2 Likes
Sadly, for too many people around the world, having their computer seized by the authorities is a real threat. In such a scenario, the best outcome is for the investigating body to discover a computer that seems ordinary enough so they let the person go and not push the investigation further.
1 Like
I know people who had their computer seized and booting into a vanilla OS isn’t going to help you, the people who do data forensics are not idiots who don’t know what they are doing. They are going to know the computer wasn’t used and that the data they are looking for is either encrypted or deleted, it would be the same as if you didn’t give them the password.
This would be the same as not cooperating with law enforcement, in some countries this can increase your punishment, and in others it could get you killed.
The only way deniability works, is if you give then the password to your primary OS, and the hidden OS is what you use for whatever you want to keep hidden.
2 Likes
If you have already been targeted for “data forensics” I agree with renehoj you are likely screwed. (though countermeasures may exist if ,for instance, you truly comprehend
https://web.archive.org/web/20100915130330/http://iq.org/~proff/rubberhose.org/
Quick search of the forum turns up Feature Request: Peace of mind when crossing borders
- Best
1 Like
Yes! This is not a joke.
1 Like
To be fare if you really wished to keep data out of someone hands, is to not keep it localy. If I had to do something that I would love to hide it, I would do it on a remote server and get rid of any traces that I connected to it.
2 Likes
This solution turned out not practical because of shaky connections, plus the server was still subject to seizure.
Veracrypt pd vaults on external drives + binding redirects to the pd vaults is working currently. A bunch of scripting has to be done to make it practical, but it works. Hopefully pd at the qubes level will make it into an update soon.
1 Like
Can you explain a bit more what you mean by pd?
1 Like
Plausible deniability:
All data footprints get bound to the hidden vault once its open. The qubes function flawlessly with the binding or without. There’s a few anomalies with dom0 binding I’ve ran into, but overall it works.
1 Like
Not if pd is at the qubes level.
1 Like
@Emily It looks as if you solved the issues that you were having with
this approach.
It would be useful to other users if you could provide those scripts.
It would also be beneficial for you in allowing more eyes to review your
approach and identify any shortcomings: remember Linus’s law.
I never presume to speak for the Qubes team.
When I comment in the Forum or in the mailing lists I speak for myself.
3 Likes
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
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.