Secure Handling of Encrypted Drives

[Sam Hentschel]

I am trying to figure out a way to securely handle my encrypted drives
without two things: connecting the USB directly to the Vault (as this is
obviously a bad idea for security), and decrypting the USB in sys-usb
(also obviously a bad idea).

As an example, I have some USB that I keep encrypted backups of my
important documents that I keep with me in case an emergency happens
(which now that I am using Qubes will probably also be in the Vault). I
have files on there that I need to move to Vault, and I need to be able
to continue to put files onto it (whether from Vault or from a scan I
have done. <note: I will be writing some documentation hopefully on
what I did giving DispVMs the sole ability to print and scan.> Which I
know is a whole different problem; so I want to focus on just the
encrypted storage.

Another example is my backup drives which are all encrypted, and that I
would like to have access to for the standard reasons. I have been
pointed to [1] a couple days ago by JPO and I believe this is part of
the soution, but not the whole thing.

My two solutions that I have thought through are: doing PCI patthrough
directly to the Vault (which is the least favorite of my ideas), and
creating a separate VM for encryption that only houses software for
encrypting and decrypting (dm-crypt or veracrypt). This way the USB
will be passed through to this VM and will never directly touch the
Vault (except through qvm-move-to-vm).

I had a third solution of adding this functionality to DispVMs, but I
can't PCI pass the USB to the DispVMs when they are running. So that
one is out.

Thanks in advance for the help; can't wait to see what I missed!

[1] https://github.com/rustybird/qubes-split-dm-crypt

--
Respectfully,
Sam Hentschel
FD6A 2998 5301 B440 D26B 7040 69D1 CE58 6FA5 BB5A

[Unman]

Hi Sam,

I'm obviously missing something here.

One of your two solutions fits completely within the current Qubes model
and matches exactly the specification you set; that is, qvm-block
attach the encrypted drive to a qube and decrypt it there.
Can I ask what more you are looking for?

There's no need to do this in a separate decryptionVM - you can use a
disposableVM for the purpose.

If you don't want to have the decryption software in a standard
template, then put it in a separate template, build a distinct
disposableVM from that template and use my hack to fire up that
disposableVM when you want to use a decrypted drive.

unman

[Sam Hentschel]

Unman,

I was just making sure I wasn't missing something or there wasn't a better way. Anyways, I can't set this up in a DispVM because you cannot PCI passthrough to a VM while it is running(?)

Very Respectfully,
Sam Hentschel

[Jean-Philippe Ouellet]

Your understanding is incorrect on the following details:

1) you *can* do pci passthrough to a vm while it's running. Depending
on if the device supports function-level-reset or not, you may need to
set pci_strictreset="False" for the VM in /var/lib/qubes/qubes.xml

2) qvm-block is distinct from and not implemented with pci
passthrough, it uses xen blk{front,back}. This is an entirely
different and believed to be less dangerous interface to expose than
PCI to your actual devices.


That said, you might prefer to use a normal unencrypted filesystem,
only interface with the filesystem in sys-usb, and use encrypted files
instead.

You could then use qvm-copy-to-vm to move the ciphertext from sys-usb
into your other vm, {decrypt, manipulate, re-encrypt} them there, send
back new ciphertext (again via qvm-copy-to-vm) to sys-usb, and put
them back on the flash drive from there.

This isolates your document processing from potential vulns in your
filesystem manipulation code (such as fuse-exfat which appears to be
the de-facto standard flash drive filesystem these days for maximum
interoperability).

This approach likely has a higher chance of protecting your
document-processing VM from being exploited by filesystem
vulnerabilities, which may be even easier to exploit if you consider a
malicious flash drive with compromised firmware (manipulating metadata
behind your back while the drive is mounted to potentially otherwise
"unreachable" code paths in the fs drivers) to be part of your threat
model.

Cheers,
Jean-Philippe

[Chris Laprise]

This is confusing a fairly simple issue.

What Sam is looking for is to use 'qvm-block -a' (or the attach menu in
Qubes Manager) which indeed has nothing to do with PCI passthrough.

>
> This approach likely has a higher chance of protecting your
> document-processing VM from being exploited by filesystem
> vulnerabilities, which may be even easier to exploit if you consider a
> malicious flash drive with compromised firmware (manipulating metadata
> behind your back while the drive is mounted to potentially otherwise
> "unreachable" code paths in the fs drivers) to be part of your threat
> model.

He said /encrypted/ volume. Even an infected drive wouldn't have access
to the filesystem.


--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

[Sam Hentschel]

That has definitely cleared up some of my misinformation. Certainly it would be safer to do it file by file, and I could use qvm-copy to move it back and forth to vault and back. However, I still need to be able to open the drives in the first place before I can even do that. So I think using qvm-block to attach the device to an encryption VM (specifically for decrypting drives) and then passing the files to and from vault before detaching should suffice.

What are your thoughts on this solution? I believe this should only keep ciphertest on sys-usb, the unencrypted stuff on the encryption VM (which would be disconnected from the network) and files would be safely moved to and from vault via qvm-move-to-vm.

[Sam Hentschel]

This seems about the same conclusion I came to in my reply to Jean-Philippe. Using qvm-block -a to attach it to an encryption or DispVM that would touch the plaintext and then copy to and from the vault.

[Andrew David Wong]

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

> This seems about the same conclusion I came to in my reply to
> Jean-Philippe. Using qvm-block -a to attach it to an encryption
> or DispVM that would touch the plaintext and then copy to and from
> the vault.
>

If you might back up and restore files from more than one VM and don't
want to mix security domains in your encrypted drive (which could be a
bad idea), then don't forget that you can store qvm-backup encrypted
backups on the encrypted drive and securely restore them later. This
is potentially much safer than qvm-copying confidential files in
plaintext into and out of various VMs.

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

iQIcBAEBCgAGBQJY9AVdAAoJENtN07w5UDAwXAsP/02EaZzqsch5KRYReePDmLhj
6bNstvfk/KVYwNHBZh/F2ZynwqC966mL8Z7C/2fvxi7v4H3Tpbb4wDZdh/y0iPZG
KG23cDvHL5f3dTqZ6umC6LkWrYpOLlQPAZCsbzjAWnXF9+dcaFfpQUFbq5PYlpcd
SbJq9EE1btCRfooHXnTD6vFr/kpO8RhwD3rYh3N+yc9idxshlb50SL0gOC+DCdNo
aPdt1cgDJui//OvCZvaKfuBVE4lehf94XEClDU4NLVlK7sWyBiESFcl6VUtbAmR0
yIGiy5l/zey2enHcBe4p4gbl+JaP1l3LWg6U7ZZHoe8aftT33FBL7xTZyYXqms1y
JasRnqK/u57Digon33GrkoAJk0xwOozypz6E4gbxJ/Zja8Dx1FchA0k7N8u5wVyX
gQQ69A8mJQ3YuQThTjHhYvbEs3CM571iCLh/ogWWpuAv2BYj3A7SMEPmSudTvmZH
JlVDFXL5O9dkfQ+jGDYqk+Zqwxv5PUfLCr45lONZ4D1fdZt5Ut/dXd7zBpNSM49j
tU+wCCBMtUhrgsdxufkeEIfnP1zMXOnd0ww3VuHW2M1BgkntvLZXoKs1LE0nU4Er
tsms3DCKP5FD5ocLMF+Y0mHPZuKxPt9O+msprL+dWeOky584t43Q2rwtD176JIZr
yXT5/JselcRi1zjHDV8K
=5MZE
-----END PGP SIGNATURE-----

[Jean-Philippe Ouellet]

And if you take that route, be aware that doing so (with the current
implementation) leaks (encrypted) metadata about *all* VMs that
existed at the time of backup[1][2], not just the VM you backed up,
and also that it is not currently safe to restore a backup unless you
fully trust the security of at least the dom0 of the machine that made
the backup at the time it did so [3].

[1]: https://github.com/QubesOS/qubes-issues/issues/2645
[2]: https://github.com/QubesOS/qubes-issues/issues/1747
[3]: https://github.com/QubesOS/qubes-issues/issues/2737

[Andrew David Wong]

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

What JPO says is technically accurate, but I'm not sure why he's
making it sound like these are dire bugs when they're really more like
design decisions (and perfectly reasonably ones, IMO). Basically, if
you're just backing up one of your own trusted Qubes machines in order
to restore later on one of your own trusted Qubes machines, you're
perfectly fine. :)

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

iQIcBAEBCgAGBQJY9S+GAAoJENtN07w5UDAwKhQQALUqhW0/5l/+wxB0ikcUqCO3
LFROZrxRPLyvsTSo+IUYVuaQwiqnB0JUJ/Sv78lFWxj0v8iEDhrqkCLXMF7iM66L
mkcKEFQgAS5x8ZV8IanrmEAZUxyN61Z5pfddKLDLbuOX36vacuCDD59smc4CwZvL
VpISnUBaPf8fsd76t+6RHahc9XA34iC4hhEGu9uiHrT+z1V0OAaTbFZSW3wiHMxP
5IR7lgb6e6qahJvY/ju+WVFJdc5diIMYMcrq6iti/VZccIhFs6Uxp4HwDwQJ+LWI
tPsb0QlIR8/juby8xSn8r0j7i6VIXcHsImnIxPLTkYwZORnu0JY6q1Grb/7hwunX
/DO1ZamxU/Xg/U6eVFDMK3rvZyfEZ4XgwDJspkDTUdlb6Qe1ERPpLQu3ET3gAIyz
UWO9v+y1A6pWQ6SSQYeAgBvO82oSs4kqm5JFcw+urLrI3FvQ9MqnWldyobY/VRT9
yl47FBxYpofmfrgcyXm4i16KCiOF3a2a/8AosRGeAhynARalVgsO9ipNn07PPRC+
xvGj6NFXykx3LfcuhB/WkZ6aibyVLdYvh9r6FrlzzVAsOXq1NMd401EdKf/Jmifp
3vUvL1R3WiGvYboWztmhQ4ACf30/oNgoiu+Jj1k56IXz8ub+c5Bf3ZHeIvgiJEWh
J/4u4YHHGqvuetUPIx0z
=X4hu
-----END PGP SIGNATURE-----