I think the most convenient way would be the “truecrypt way of plausible deniability” - have two different passwords for LUKS. one will bring up the usual qubes OS and the other will mount a specific container with a vanilla regular/innocent linux. when asked for the password, give the second one and the examiner will have a clean OS to look at. use something that is configured to not log anything (I’m afraid of cookies/viruses or am a clean freak and like to start my internet browsing fresh) and so you explain why it looks so unused. I played with it many years ago on Truecrypt to see how it works but not since then so I have no real/recent experience.
3 Likes
So far, the only items I found and use that does all that is the Apricorn AGIS fortress.
With dble pswd access, and a panic one that wipe out the disk
As we all know, password is only good against time, so forensic will make several copy and run several bruteforce pwd try in parallel until crack,
But these fortress have the key card embeded in plastic mold, so if you open it you break it, leaving the disk useless … therefore no copy possible.
And 10 try wipes out the disk
and if asked (with insistance) the pwd, then the panic pwd is given and voila
As for the Qubes, it would be nice indeed to have two steps logging, first one to vanilla, then second one hidden to actual environment
Most “checker” won’t look further if you open your laptop without questioning, without problem, and check in whatever you put in there, emails, images, some documents, … they have many other customer to annoy
And if they have a hard on with you, then faking won’t do, they will strip you naked all the way anyway. Bust most of us are not that interesting for them
For now, the only solution I’m thinking about is:
in the boot sequence on-disk, direct to Vanilla OS,
If an SD card is inserted, then the boot sequence shows more option, including the actual QUBES
At check point, no SD, the laptop open up to vanilla “here goes nothing”
1 Like
But I haven’t managed to do the SD card /boot thing as of yet (many tries, all fail)
@Erica.vH
One of the problems with the “dual system” approach you described is the need to maintain the Vanilla OS. Since we’re using Qubes here, I would suggest that the system won’t show certain qubes (app-vm) unless said SD-Card is inserted. This way, the user will continually use the Vanilla qube for mundane uses, so there’s always some up-to-date browsing history to be found, while keeping hidden only the qubes that need hiding. Hiding in plain sight is always better.
2 Likes
- Is that possible to assign specific physical blocks range to specific files in NTFS? If so, then we theoretically can just use some big game files (which are supposed to be compressed\DRMed), as a shell - and pass “safe” ranges to luks (which cannot work like this at a time?). Except the SSD controllers will mess this up. And experts will detect lots of recent writes to blocks of these “game data archives”, which are supposed to be read-only. So file-legend should account for frequent writes as well as frequent reads.
- Encryption inside encryption to combat forensics. If whole disk is encrypted, and we decrypt just outer volume - the noise in disk image is expected. NTFS can be tricked to think the file weights more than it actually is. But also discoverable by experts.
- Outer volume is empty because you plan to sale the disk, but can’t find a buyer yet.
- Use microSD card you can eat in emergency, so you won’t have to prove anything to anyone.
- Boot-volume on microsd\encrypted and stored in cloud, data-volume is noise on “empty” drive.
1 Like
Hum … that’s an interesting one.
Does that implies to install the qube on a separate disk ?
Not sure how that would work ?
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