encryption of all vms

[john]

currently dispvms are protected against local forensic by keeping them
in ram (per default on in the global settings).

this can cause a high ram usage and ONLY protects dispvms.
what if i am working over some time with sensitive data and want to
delete it after my work is done?

i want to propose a different approach:
each vm image is encrypted.
the encryption and decryption is done in dom0.
pass-phrases (if user-provided) are entered in dom0.
the encryption is transparent to the vm.

there are three options where the key is stored:
1) for dispvms the key is kept in ram.
2) for sensitive vms the user may choose to provide a pass-phrase.
This pass-phrase is required each time the vm is started.
The key is stored on disk (encrypted by the pass-phrase).
3) if the user does not provide a pass-phrase, the system generates one
and stores it and the key (encrypted by the pass-phrase) on disk.

auto generated pass-phrases could be encrypted by a master pass-phrase.
i think this would only provide a minor benefit if the user does not
change this pass-phrase regularly, since anyone who gets access to dom0,
can get the master pass-phrase.
if the master pass-phrase is changed regularly it would protect against
restored pass-phrase files if they are old enough.

in case of 2) the user can choose anytime to remove the provided
pass-phrase (a new pass-phrase is generated by the system and stored on
disk).
in case of 3) the user can provide a pass-phrase and replace the system
generated pass-phrase.

It is obvious how 1) and 2) are protecting the user's data.

in case of 3) only the pass-phrase has to be deleted to render any
stored data unreadable.
since the pass-phrases require much less space they can be deleted quickly.
If the pass-phrases are stored on a hdd (instead of a ssd) they can be
deleted reliably.

this approach requires less ram for dispvms. (this is good when dispvms
are used to download or edit big files)
of course this approach causes more cpu load and slows things slightly down.

to balance this out the user could be given the option to disable the
encryption of some images/vms.

if a vm is cloned, all cloned images should be encrypted with a
different key and a new pass-phrase should be used (if this phrase was
auto-generated).

whether template-vms should be encrypted should be discussed. (the
normally hold no data, but maybe config files /installed software could
be considered sensitive).


in advance:
i know some things about crypto in theory, but never really look how the
things are implemented in linux. so everything i write for the
implementation may not be correct. (but is to the best of my knowledge)

implementation:
i think it should be easy using luks partitions and storing the auto
generated pass-phrases in files.
all pass-files should be stored in different files (one per pass-phrase)
to make it easy to overwrite the files.
it should be possible to symlink the folder to a different device, e.g.
a hdd. (this should work by default)
the vm backup now has to backup the pass-phrase files, too.

in my opinion this approach can add additional security, only has low
overhead (as all security does) and should be easy to implement.
what do you think about this?
-john

[Andrew David Wong]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Thanks for sharing your thoughts! There's actually been some pretty
extensive discussion about this idea over the years. It's being
tracked in this issue (to which I've just added a link to your post):

https://github.com/QubesOS/qubes-issues/issues/904

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org
-----BEGIN PGP SIGNATURE-----

iQIcBAEBCgAGBQJXPWQmAAoJENtN07w5UDAwmF0QAMYoxLYbxgGIgYXe7B85Fi8n
Nq9JzF6MeZS8wt5Q9k2k6iwJu6/00iPY7hUYZZDs+vIKMbMpDOBuSlfnWO7eavL3
1JgbmfxnWFLnkHJA5Aii1cTmbNFYEdPFXh6fJm5cBB57nmFT3FE6yC+MObIp5gpE
Yf+j19Bm3I5BDgxj+9wsbA4V9f4vuO/CMMm5/VAZXZPiGg4/5iTdvR0XRZCHdLb+
YJ4WwJ3xym7+1yUCHDyY1qRvG5gvZYI8EJYdLXFHYvIO2FVzIPT/P0Zz0VU4/Aaa
ioaSSyf4u6KXmaQJ9Z1lf4xx7PuzCB9cTS0K91GSF/bWOUx3IvDIPwfpg4K14BCB
5OnlHy0hIqLn6CS4/wP9tNz4GigHXhZ1pcvNFuWuXsLNmO4cyzT5xPNuyNdC58++
uq9vfEmnbo1GdwJg4Dq8I8zmR46C6TgBi7ZGTiJRdJUhbPZhR5vnNnlPCYOwGl5B
xVXoBEP6pUY9f+IC4Ocku+VUq4yhWLIdcHAw3QVENlc6pRo3lSZVUjxvEUCeyG/M
/n4IshiQuE7Wf32O60R9IYEpYtJ6HTScj+JHs9QWpAqFQSnEFMYhSsbvU898bnXk
WtLmQMlO5aO5c81tpja3WrCOVPLzlmRKFZEODrc+7TxFBfr+fUJ1Klazk+j8ey2k
IjR52EOcAZax+/PtFfji
=QN1e
-----END PGP SIGNATURE-----