@Rootbeer - If you want to pursue this PM me.
2 Likes
I wanted to mention a option: One option for this might be xen vtpm. It seems to already be in the linux kernel and xen. You can read about it here:
xen-vtpm(7) — xen-utils-common — Debian bookworm — Debian Manpages
(Note: the mini-os they talk about seems to be git cloneable from here: git://xenbits.xen.org/mini-os.git )
This supposedly allows a stubdom to create a unique virtual TPM key for the guest domU, then encrypts the data that normally goes inside the hardware TPM in the stubdom, but then encrypts the stubdom information using a encryption key that it got from the actual hardware TPM of the Xen computer.
Erasing the entry for that stubdom from the hardware TPM, should make the erased as unreadable as removing a disk with full disk encryption that used TPM.
This could be combined with, or instead of a password.
Note: I believe the Qubes team does not like TPM for some reason I have not looked into, so if going in this direction, people may want to first look up their reasoning to see if there are concerns about TPM in being unsafe storage in general.
If doing one or the other, then question would be if a password would be less recoverable when being erased from your TPM or if it would be less recoverable when you erase it from your password manager that you keep the password to decrypt the disk in.
This could potentially work for your use case as well
One of the ways I do per-qube encryption is different LUKS volumes on different ZVOL in a qube dedicated to ZFS. When the unencrypted LUKS devices are exposed in /dev/mapper/ those devices are attached to other qubes and within those qubes the ext4 or xfs is mounted.
Sometimes when traveling I don’t bring specific hardware keys with me. See Shufflecake: plausible deniability for multiple hidden filesystems on Linux.
I think Shufflecake should become part of a standard bootloader used by almost every distro. If everyone has Shufflecake then the adversary has much less to discern who is using their standard Linux distro as normal and who has Qubes hiding somewhere in a Shufflecake-managed volume. There are ways (simple ways that can be scripted out) to use Shufflecake to secure LUKS headers and use plain LUKS in a “second stage”.
I do remember users asking the “what if I go through an airport run by hostile glowies?” question. Shufflecake is part of the ultimate answer to that question.
2 Likes
On that topic: How to create an encrypted secondary storage to lock/encrypt individual qubes
Let me know what you think about my approach.
excellent post, completely agree
not having per-VM encryption is one of the most annoying aspects of Qubes
even with something as sketchy as VirtualBox, which is sketchy because to make it usable many install closed source components, there is per VM encryption
i really hope this does happen
i hope this has happened or is happening.
I really wish I could open Qubes up, leave it open, and not be concerned about someone physically getting access to the device with everything unlocked. And yes, there are things like LUKS and other ways to encrypt to avoid that problem, but they take so long to implement and use each time.
I would like to be able to type an email at a coffee shop and if my laptop were grabbed, the main loss is hardware.