On Tue, Feb 21, 2017 at 02:42:51PM +0100, michaelof@xxxxxxxxxxxxxx wrote: > > Dear list members, > > > as a newbie I've read the detailed FAQ at https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions and > was deeply impressed by the carefulness of the author aubout the highly political various perilous aspects of > encryption. Great job, thank you !!! > > My intention for a usage of LUKS / cryptsetup are less political, but privacy. To get control back for my private data, > I'm running a Vserver with a complete mail server setup (postfix, dovecot, ...) plus owncloud and a couple of other free > software. > > My questions here are of a more general nature, hopefully not be seen as off-topic by the valued list members: > > As my Vserver is hardened against potential outside attacks as much as I've been able to, it's currently completely > unprotected against "internal" attacks. Means that anyone from the hosting company e.g. could clone this Vserver or > copy the unecnrypted virtual disks, even without my knowledge, and access all data on it. > > Of course I trust this hosting company, otherwise I wouldn't have chosen them. But I would like to "solve" this generic > issue, if possible, independent of a specific company. > > In the German IT journal "c't" I've found an interesting article about encrypting a home server against data theft, if > the home server get's physically stolen. Could easily be done by encrypting the whole disk(s), sure. But imho a very > nice idea of this article was a LXC container based setup. A non-excrypted base setup with more or less only sshd, and > an encrypted container for anything else. Nice idea, because this setup is able to "survive" a reboot after power-loss, > sending an email to the server-owner, notifying him to ssh-login and restart the inner container = entering the > deencryption password(s). > > Having read this article, I've started to think about if this scenario wouldn't also be perfectly suitable for my > Vserver requirements. > > But when asking the author of this article about some small questions left, he stated his personal opinion that any > encryption on an externally hosted vserver/VPS would be a waste of time. Because the to be entered at boot time > deencryption passwords would be stored in memory of the virtual machine (all is KVM based at this company), they could > easily be read from memory, in case of a "real" attack. > > Coming to the point: As this sounds reasonable, is there any chance to > circumvent this issue? If the attacker has access to the physical host while your VM is running, then (with current hardware) there is essentially nothing you can do to prevent a skilled person getting your master key out of VM memory. AMD recently announced a memory encryption feature that might make it possible to protect guest keys from a host attacker, but its still very early days in its developement & integration into virtualization technology, so a very long way off being available in any public hosting provider. Encrypting your VM's disks is still a useful thing todo, however, since there's plenty of ways to attack a VM hosting provider which don't involve access to the compute host itself. For example, if the hosting provider is storing your VM's disks on NFS or ISCSI, etc, and someone attacks the NFS / ISCSI server, they won't be able to read your encrypted data since the VM containing the keys in RAM is on a different host[1]. Similarly if the VM hosting provider's network is compromised and they're using an unencrypted network storage protocol, then using encryption in your VM prevents people sniffing the NFS/iSCSI network packets from seeing your data. Regards, Daniel [1] I'm assuming key passphrase is entered interactively on the console when the VM is booted. If you store key passphrase in an unencrypted partition of the disk, that throws away useful protection. -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
