Qubes Duress - Deniable Qubes Instalation

Did you consider Librem Key, which has free firmware?

1 Like

ive just researched librem key and it is very appealing. thx for your insights. do you know if anyone has had success integrating this with qubes?

Looks like it does not work out of the box, but it’s a software problem in Qubes:

I would like to see this feature available. To approach this, we need to answer the following:

  1. Are there any existing tools that provide deniable encryption?
  2. Can these be integrated into Qubes?
  3. If 2=yes: What work needs to be done to integrate them?
  4. If 2=no: How much work needs to be done to create a solution?

@adw Has created a github issue already on this matter, see:

*Further to this topic*

I would like to see some additional improvement in the current encryption offerings.

Specifically:
Support for layered/encapsulated encryption (option to choose different algorithms/implementations).
Further, support for hardware keys (ideally U2F challenge response support) - with the option to assign the algorithm also.
The exact same disk encryption functionality offering for the VMs.

AFAIK functionality regarding disk encryption isn’t great across the OS-world, so this may require some dev. work - but it’s something I’d really like to see, and I think many would value.

I have seen this, also:
Integrate 2FA/YubiKey into LUKS · Issue #2712 · QubesOS/qubes-issues · GitHub

As the separate issues raised here on the thread and on github are all related, I think that these ought to be combined into a unified github project. (That is, of-course, once the above questions have been answered and the Core Qubes Team can allocate some time and set a release target).

2 Likes

As someone who has been forced to surrender their electronic devices at a border crossing for several hours (and wasn’t allowed to be present while they were inspecting them), I can definitely say this would be useful for this use case, under the following assumptions:

  • The parties performing the inspection aren’t too tech-savvy, or are not necessarily interested in a “deep” inspection.
  • There is no reasonable threat of torture or physical harm.

If I was threatened with torture or physical harm, I don’t know how useful it would be.

I will point out that I have been asked to do this on more than one occasion, at multiple border crossings, and the methodologies and approaches/procedures have differed wildly.

  • Some asked me to unlock the devices in front of them while on being recorded on CCTV.
  • One took my devices into another room, and they presented me with a wireless keyboard to type my passwords into. I couldn’t see what it was connected to.
  • Another plugged my devices into another machine and attempted to side-load forensic software (it didn’t work, because my “iPhone” wasn’t really an iPhone :wink:, and they got SUPER angry at me :laughing:)
  • I said I didn’t know the password for one of my devices (a total lie, but it was worth a shot…), and that device got confiscated. To this day, I don’t know what they did to it (with a duress password, I could have potentially made the device “phone home” after they confiscated it).
  • I was able to convince one customs officer (who clearly knew his way around a computer, but had never touched code in his life) that a hidden partition at the end of a drive was a Chia plot,which was kind of an epic win :innocent:

I don’t need to imagine this, unfortunately… :sunglasses:
As of 2017, there is at least one person at every border checkpoint that is trained in basic Linux Terminal commands (mostly Ubuntu) and Windows Powershell (but thankfully the variance in skill of the officers remains very broad). One guy didn’t delete his history logs, and typed in Ubuntu commands in dom0 (apt and lsb_release were entered 30+ times :sweat_smile:). There is also a remote unit that can supposedly “remotely” inspect devices at every border crossing (I don’t know anything more than this).

They also are aware to some extent of the existence of Qubes OS, however your average border agent still appears to have some difficulty detecting it (thankfully).

They’re usually looking for things like Tor Browsers, Crypto Wallets, VPN configs. That sort of stuff.

SOURCE: The border guards tell me things.

Indeed, this may be the case, and would be useful when the actors aren’t exactly sure of exactly what it is they’re looking for.

Would indeed be incredibly handy. “I don’t know what that is. It was just there when I installed the OS, officer…”

YES!

I couldn’t think of a better place for them :slight_smile:

Not any more :wink:

I like. If I ever have enough money, I’d so make this.

I have managed to get it working in Debian templates as a 2FA. Will attempt it with Fedora and dom0 when I have the time.


Usefulness

I seriously doubt duress passwords would be helpful in cases of “I know those files are on this computer, and you’re going to give them to me, whether you like it or not *sharpens knife, prepares some sort of venomous animal, and removes hot coals from furnace*”, but it would definitely be useful for “Sir/Madam, please step this way, this is just a random inspection…”

True, but I would love the ability to have it, though. :upside_down_face:

As long as the users fully understand its limitations and use cases, I think it would be very “peace of mind” feature to have of Qubes OS.

Potential Other Applications

  • Alternate password for remote wipe, “monitor/honeypot mode”, masqueraded boot process (the Windows logo and spinny thing, booting to a Windows-looking desktop), removing PCI devices via the kernel on boot, etc. (Or even custom other things)
  • Anyone who can be subject to “random inspections” that are superficial (school teachers, boyfriends/girlfriends [not necessarily infidelity, maybe you are trying to hide a birthday surprise? Just saying…], low-level law enforcement, etc.)

In any case, I’d love to help out in making this a reality.

5 Likes
2 Likes

I still don’t see much advantage over OpSec on border controls.

E.g. why not hide your data somewhere on the Internet and either take an empty laptop or none at all with you on border controls?

And if you fear tough controls asking you to show that Internet volume, you may still keep your data on the Internet inside a hidden trucrypt volume or use other steganogrophy.

If the Internet is blocked inside that country, go with some super small data storage. SD card? Maybe use Truecrypt hidden volumes/steganography on it. Make sure you can destroy it “accidentally”.

So why does Qubes need all that, if you can achieve a better solution by changing your behaviour?

If you’re checked on and think that the checkpoint modified your hardware, you’ll have to buy new one anyway.

To avoid that the checkpoint notices you mounting that super secret storage volume from some forensically restorable Qubes OS logs (assuming they are hyper sensitive and can read them), you should probably do that with disposable VMs only and maybe even deploy the disposable VMs in RAM only.
There’s an open Qubes issue for the in-RAM thingy, but even that is currently already possible for those people with a bit of work & technical knowledge. If the checkpoint then notices you to have that setup, they might become more interested. But it’s always a cat & mouse game…

1 Like

P.S.: As a first step one would probably just disable the logs monitoring your mounting behaviour…

1 Like

Touché… :kissing: All I can think of is the “inconvenience” of loading an empty machine afterwards. But I suppose that would have been taken into account when considering your threat model…

So maybe a Qubes contrib steganography package, then?
(Just brainstorming…)

Hide it inside a “smart light bulb” or anything with a microchip in it (toaster, hairdryer, fridge, prosthetic leg, etc.)
(definitely agree here)


All valid points. Agreed.

Checkpoints aren’t actually the only places duress passwords would be useful.

  • xscreensaver passwords that would put you into a vanilla environment.
  • Duress passwords for individual qubes (particularly for work qubes) might be useful for some people, particularly anyone who is not particularly tech-savvy

I’ve tried to find the exact clip, but I haven’t (yet)…

Basically, James Bond is held at gunpoint, and an attacker has his phone, and asks for the password. Bond then tells him his duress password, and the phone tazers the attacker.

I’m not saying we should make Qubes OS tazer anyone (although, in fairness, that would actually be pretty cool, and totally possible with the right hardware).

But I do think that there would be use cases, even as a contrib package…

2 Likes

“All I can think of is the “inconvenience” of loading an empty machine afterwards.”

For the tech-savy people Qubes offers [salt] for the basic setup (I need these VMs on my machine configured in that way).

If you’re tech-savy & super lazy on loading Internet storage into your VMs, you might want to look into [qcrypt] (disclaimer: I’m the maintainer.).
But it can be observed to be installed on your machine incl. the fully automated configuration of loading your remote volumes (assuming you use qcryptd), i.e. if you don’t want to raise any suspicions at all on checkpoints, it’s probably better to not have it installed and do all of that manually inside a disposable VM or just install it later when you feel safer.

[salt] Salt (management software) | Qubes OS
[qcrypt] GitHub - 3hhh/qcrypt: multilayer encryption tool for Qubes OS

4 Likes

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
  1. 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.
  2. 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.
  3. Outer volume is empty because you plan to sale the disk, but can’t find a buyer yet.
  4. Use microSD card you can eat in emergency, so you won’t have to prove anything to anyone.
  5. 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