On 07/31/2018 09:38 PM, Rusty Bird wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512David Hobach:On 07/29/2018 07:30 AM, 'awokd' via qubes-devel wrote:Check out https://github.com/rustybird/qubes-split-dm-crypt, it addresses some of that.The Readme also mentions the currently supported way: "[..] directly attaching an encrypted LUKS partition from a source VM such as sys-usb to a destination VM and decrypting it there [...]". [...] The added bonus of qubes-split-dm-crypt seems to be three-fold: A certain level of protection against exfiltration of data after a compromise via encrypted blocks. This however requires cooperation between source & destination VM [...]Sorry about the probably not very clear README (improvements welcome!) - With direct, non-split dm-crypt ("the currently supported way"), the malicious/exploited destination VM has full read-write access to the original block device, so it could _instantly_ exfiltrate _100%_ of the attached data to an attacker (who's going to physically seize the disk later): By saving the decryption key/passphrase to the block device, either in plain text or encrypted using a key known to the attacker. That's a tiny piece of data, so it should be easy to find some space on the block device. No cooperation from the source VM/disk is needed.
Without physical access it is needed. Adding a second layer of encryption for a disposable sys-usb would help against physical access as well, but is admittedly inferior to your solution as people tend to attach more than one device to sys-usb making it to more likely to be compromised in the first place. Now you could use qvm-usb and a dedicated VM, but oh well it's getting complicated...
Split dm-crypt prevents this by denying the destination VM knowledge of the key/password as well as access to the original block device. The malicious destination VM would require cooperation from a malicious source VM/disk to open a covert channel, and even then the two are still limited in bandwidth and unused storage space (because they'd have to exfiltrate interesting decrypted data blocks individually, instead of just the key/password to get everything at once).Some protection against luks parsing exploits. This is only useful if you want to protect data inside the destination VM which is not on the source device.The "header DisposableVM" is intended to (hypothetically, I hope) prevent an exploited cryptsetup from writing to the original block device and again exfiltrating the key/password.
Ok, for everyone considering data leakage in the way you describe (attacker being able to compromise and obtain physical read access afterwards) a high risk, there's definitely some added value by split-dm-crypt. It's a matter of threat/attacker model after all - that would be my suggestion for a README improvement: Describe the attacker that you're trying to defend against. In particular since it seems to deviate from the standard Qubes threat model which mostly ignores/gives up on covert channels [1]. Otherwise I think it's pretty good, thanks for supporting the Qubes community!
[1] https://www.qubes-os.org/doc/data-leaks/ -- You received this message because you are subscribed to the Google Groups "qubes-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/0fc1d069-4f9e-48b8-b422-cf36bd26650e%40hackingthe.net. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
