My threat model: not letting government agents know about some sensitive workloads that I run, which is why I need to run them in a hidden volume.
The best advice I have come across is Split veracrypt. Very well written guide and covers some of my use cases too.
However, the problem that I see here is that such a container would come off as a disproportionately large file (because it will have VM images in it) and would elicit more effort into looking at it. Instead, I would have liked to have almost the entire disk (other than /boot because that’s only possible on Windows) encrypted by Veracrypt. I would run my usual VMs in the “normal” partition, including somewhat sensitive workloads but nothing too important for me, and then I’d create a hidden volume as usual and run sensitive workloads in that.
I am aware that I’d have to switch off logging in dom0, yet to go through that.
Now, installing third-party software in dom0 is frowned upon. Then, how would I manage a veracrypt partition (and hidden volume) and run VMs on it through a DispVM? I am unable to understand how I could make this work without installing veracrypt in dom0.
I would really appreciate any suggestions you might have for me! Thanks
Split veracrypt was actually intended to produce containers of data, which could be decrypted and attached to regular VMs. It wasn’t the intent to actually put VMs in the container (which is how I interpret what you want to do–If I misread you please disregard this).
On the other hand nothing in split veracrypt precludes using a hidden container…of course you have to create it in the first place (which split veracrypt won’t help you with; it assumes existing containers).
However, a lot of the info in there could probably help people figure out how to do the latter; I imagine you’d have to attach a decrypted container to dom0 somehow, and get it to recognize VMs in another pool.
Ah, nihilist’s blog. Always a favourite to read. Thanks for the link.
To implement what he does there with Veracrypt, I would likely need to install Veracrypt in dom0 (which is against the recommendations of the Qubes OS team). I do not think that Veracrypt is malicious, but the best way would have been to try it the “Split Veracrypt way” of using it in a DispVM, which I estimate would be a hard/hacky to do.
The second problem is that unlike LUKS, Veracrypt doesn’t actually do FDE on Linux (but does it on Windows). As a FOSS enthusiast this kind of logic baffles me, but I’m sure they have their reasons. Regardless, if I only encrypt a certain partition on my hard-drive instead of the entire thing, it’s actually more suspicious to government agents (because now it definitely looks like you have something to hide) instead of doing FDE, in which case you’re just a cautious user trying to get rid of the low hanging prizes (thieves).
I am looking at LUKS seriously now instead of Veracrypt for this very reason. It seems that with a little bit of effort, LUKS can be made to have plausibly deniable partitions too (it’s just that it’s a bit of DIY work rather than Veracrypt which has this built in). If Veracrypt could do FDE I’d jump on it right away.
Yes, I did realize that. Veracrypt containers would be a great way to hold data (and explain to government agents) - you’re just taking precautions as a concerned user.
But as you pointed out, it won’t work that well (well, it probably could technically but it won’t pass off so easily, socially speaking) with VMs running in it.
Pasting what I wrote to the other commenter:
if I only encrypt a certain partition on my hard-drive instead of the entire thing, it’s actually more suspicious to government agents (because now it definitely looks like you have something to hide) instead of doing FDE
This is why “Split Veracrypt” doesn’t help my use-case that well (I will be using its concepts for data storage, of course). Thank you for the wonderful guide, I hope more marginalized people and journalists find your post and secure themselves better.
Hello, just giving an update even though i’m very late to the party.
I rewrote this one tutorial you mentionned for the 5th time recently, although i confess it wasn’t on Qubes, but on a Kicksecure Host OS, now that they fixed their ram-wipe luks problem and provided an ISO to install the OS directly. Here are the 5 updated tutorials on this topic, in order:
http:// blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd .onion/opsec/linux/index.html : installing kicksecure as a host OS
http:// blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd .onion/opsec/livemode/index.html : installing ram-wipe, and using the host OS in live mode to prepare for long-term sensitive use
http:// blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd .onion/opsec/veracrypt/index.html Full disk encryption using Veracrypt (but on a non-system drive)
http:// blog.nowherejezfoltodf4jiyl6r56jnzintap5vyjlia7fkirfsnfizflqd .onion/opsec/sensitivevm/index.html and finally the Sensitive VMs setup, where we just put whonix VMs in said veracrypt hidden volume.
This setup relies on 2 critical parts:
the Host OS being in live mode with ram-wipe activated makes it possible to erase all forensic proof that may remain in the system drive of the hidden volume presence’s on the non-system drive upon rebooting the computer
the veracrypt volume being on an entire non-system drive makes it so that the data actually gets saved even though the host OS is in live mode.
this is probably doable in qubes, i just didn’t explore it yet.
If your threat model includes people who would willingly harm/kill you, steer clear of veracrypt partitions.
It is statistically beneficial and therefore highly probable, to kill you if you have veracrypt partition at all.
The only way to avoid that outcome is to make sure you load a hidden partition with the data they will want and a non hidden partition with dummy data. This way you can give them the dummy volume password AND a the hidden volume password, removing any doubt that you are holding out.
If you make use of veracrypt and DON’T use a hidden container, you will never be able to prove that you have no secret partition and therefore they can torture you till death because they have nothing to lose and everything to gain.
Qubes is a security OS, not an anonymity/amnesiac OS.
If you have state level threat actors, you should definitely keep zero data on your qubes machine, you should keep zero data locally at all.
If you have that kind of threat, then you should spend the time to create a your hidden service that runs in another non related country from nothing that relates to you.
With this level of threat, and per your description of being unattended online, I’d assume I have an idea of what you are planning and I’d suggest that Qubes is not the Os for that.
