> Yes, of course you have to consider the notebook compromised at this point > and needs to be reset to a clean state afterwards. But that's another topic, > It's all about minimizing the damage done here. If the VM groups are > encrypted individually, at least you can have some peace of mind that non > critical data could have been stolen from another customer/vm-groups. > As I said I understand your point. However I think that *this* approach is too risky because it gives a false sense of security.
> Why would this be "risky" at all? It only adds to security imo since at the > moment everything is accessible once you gain access to dom0. So if anyone > manages to get access (ie. hidden camera to spy your password to dom0) > everything is in danger. Also it wouldn't change anything for the standard > VMs which would be by default in vm-group "none", meaning they are all > accessible just like they are right now. So you get encrypted vm-groups which > are more secure and can be unlocked when needed by the user in addition to > what we have right now. > Because it could create bad habits. Qubes doesn't really enforce any secure scheme. > Not sure if I understood this correctly but this sounds very impractical!? If > you have to shread and restore every time when you switch customers you are > going to lose a huge amount of time and you would also have to carry around > all your backups in order to restore them? I'd rather use the "decrypt when > needed" approach where you get instant access and don't have to wipe and > restore all the time. > Here an improvements of my proposal. It's effectively an hybrid: - You put the OS in a "state". There could be two "state", one where VMs are shreded and one where VMs are encrypted. To make things fast VMs could encrypted by default. However when in a "state" a specific user provided password is used. I write rapidly but I think you got the point.. - When you put in another state you could choose a paranoid mode (if the laptop was left alone) or simply Dom0 will decrypt other VMs (so the user password is asked, then forgotten). The point I'm trying to make clear is that the system should enforce this scheme. With your approach there is a false sense of security, because cokplexity (too password) and bad habits (one password for all, not restoring when it should be done and so on..). > In theory it would be also possible to use the user password for "unlocking" > vm-groups since the vm-groups would not be encrypted directly with the > password itself but rather with a master key stored in some encryption header > which is decrypted by the provided password (so you can change the password > without having to re-encrypt the whole vm-groupd rather than just the > encryption header). > You missed a PBKDF. However it's not the point, user password isn't really usable, as you said before. Furthermore every VMs in this way will be implicitly in one and only one group. This scheme is already degenerated. As I said it will create bad habits.. > Do you mean that each VMs data is encrypted with a unique VM-specific key by > default? I was under the impression that they are not encrypted at all and > you could mount the data partitions at any time in dom0. In theory you could > also mount data partitions from VM1 to VM2 without providing any keys etc.? > I mean that they are encrypted on the non-volatile support. If I remember correctly you were talking about data on a hard disk. Best Regards, Raffaele. -- 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/CdNEB0iOoj4O9KNysBgDZYWZxCAUg68HX6p83KBgwntHMnZqWxJPO5Kdtov8MZK_MdRK0hUax7qGhndNwxaplHtWUGI9nKlNMRUOsiV9rz8%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
