@Rootbeer - If you want to pursue this PM me.
1 Like
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.