Re: [Openstack] Encrypted virtual machines
Hi Michael,I dunno how the integration is going regarding the encrypted images, but you can if you can use encrypted images with qemu/ qemu-kvm.If your disk is an encrypted qcow2 image, by typing "cont" in the qemu/ qemu-kvm monitor, you would see something like this :QEMU 0.11.0 monitor - type 'help' for more information(qemu) contide0-hd0 (encrypted.qcow2) is encrypted.Password: (qemu)By providing your password, the instance should boot normally. I haven't noticed any perf. issues, since once the image is decrypted, it acts like a normal image. Maybe you weren't thinking to that encryption ? Nuage Co - Razique Mahrouarazique.mahr...@gmail.com Le 26 avr. 2012 à 17:53, Michael Grosser a écrit :Hey,I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow.Any ideas? Cheers Michael ___Mailing list: https://launchpad.net/~openstackPost to : openstack@lists.launchpad.netUnsubscribe : https://launchpad.net/~openstackMore help : https://help.launchpad.net/ListHelp___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
Data left on broken disks would be unreadable. -- You don't have to worry about data destruction before selling/throwing out your disks. (That could be realized via encrypting the whole compute-node disk, but that's not quite what I want.) Another benefit would be, that you as a cloud user wouldn't have to worry about the provider accessing your data. (Encrypting every vms disk for additional security.) Or am I seeing this too worry-some? On Thu, Apr 26, 2012 at 6:05 PM, Matt Joyce m...@nycresistor.com wrote: From a security stand point I am curious what you see the benefit as? On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? Cheers Michael ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
I'm looking into it, but I'm not sure if that's really how I want it to be. ;) Thanks for the hint. On Thu, Apr 26, 2012 at 6:08 PM, Razique Mahroua razique.mahr...@gmail.comwrote: Hi Michael, I dunno how the integration is going regarding the encrypted images, but you can if you can use encrypted images with qemu/ qemu-kvm. If your disk is an encrypted qcow2 image, by typing cont in the qemu/ qemu-kvm monitor, you would see something like this : QEMU 0.11.0 monitor - type 'help' for more information (qemu) cont ide0-hd0 (encrypted.qcow2) is encrypted. Password: (qemu) By providing your password, the instance should boot normally. I haven't noticed any perf. issues, since once the image is decrypted, it acts like a normal image. Maybe you weren't thinking to that encryption ? *Nuage Co - Razique Mahroua** * razique.mahr...@gmail.com Le 26 avr. 2012 à 17:53, Michael Grosser a écrit : Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? Cheers Michael ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp NUAGECO-LOGO-Fblan_petit.jpg___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
+1 From a security stand point I am curious what you see the benefit as? On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? Cheers Michael ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
Data left on broken disks would be unreadable. -- You don't have to worry about data destruction before selling/throwing out your disks. I can certainly see the goal here. But this may be harder than you think. For example, if you encrypt the disk image, then launch the VM, are you sure that any unencrypted data is NOT being written back to the drive (e.g., through the host OS swap)? -bryan ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
On 04/26/2012 12:11 PM, Michael Grosser wrote: Data left on broken disks would be unreadable. -- You don't have to worry about data destruction before selling/throwing out your disks. (That could be realized via encrypting the whole compute-node disk, but that's not quite what I want.) Another benefit would be, that you as a cloud user wouldn't have to worry about the provider accessing your data. (Encrypting every vms disk for additional security.) Or am I seeing this too worry-some? No, I think that's the right level of worry-some - http://www.contextis.co.uk/research/blog/dirtydisks/ -Sean -- Sean Dague IBM Linux Technology Center email: slda...@us.ibm.com alt-email: sda...@linux.vnet.ibm.com ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
On Thu, Apr 26, 2012 at 9:05 AM, Matt Joyce m...@nycresistor.com wrote: From a security stand point I am curious what you see the benefit as? I think that long-term there is the potential to have a cloud where you don't have to trust the cloud provider (e.g. Intel Trusted Compute). However, there are a huge number of steps that need to happen first, so I don't know that encrypting the qcow disk image would get you very much today. However, you could encrypt your filesystem (inside the disk image), and have it prompt for a password on boot. Then you could go in via VNC (today) and unlock your disk image. Your cloud provider can still grab memory etc. But I think that's the best you can do today. One day we may be able to automate something similar, yet still have it be secure. Virtualized I/O performance is poor compared to CPU performance, so I guess you wouldn't even notice the hit! But this is pure speculation, A little plug - one of the pieces of the big picture is figuring out how to store secrets; at the design summit I proposed storing them securely in Keystone; I just wrote up the (first draft?) of the blueprint: https://blueprints.launchpad.net/nova/+spec/secure-secret-storage Justin ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an instance of that VM. So now people with access to the storage hosts cannot compromise any data. People with access to the virtualization hosts can only compromise data if the host has been authorized to use that disk image You would need to compromise the precise host the VM disk is being used on, or compromise the key server or the management service that schedules VMs (thus authorizing key usage on a node). NB this is better than relying on the guest OS to do encryption, since you can do stricter decryption key management from the host side. On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? I would like to extend the libvirt driver in Nova to make use of the qcow2 encryption capabilities between libvirt QEMU which I describe here: http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
As far as storage is concerned, certainly a cloud storage environment could be leveraged to store pre-encrypted data in such a way that would make it difficult bordering on impossible to seize or access without the consent of the owner. As far as compute hosts are concerned, it is a whole different matter. For the foreseeable future ( barring the invention of new widely distributed in CPU technology ) . Anyone with ring 0 execution access on a system ( ie root / sudo ) will be able to pull data from a running instance pretty much no matter what you do. You can certainly raise the bar on difficulty there, but the fundamental path of sniffing schedulers / paging memory / etc will be there for a fairly long time. Even trusted computing wouldn't be applicable to protecting a vm's scheduler from the hypervisors owner. So, I think functionally it should be assumed that a provider will be able to access anything that you access on a hosted VM. As far as a trust relationship goes in elastic computing, there must be an implicit trust of the cloud provider. And as with any trust relationship there is always going to be an element of risk. -Matt On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an instance of that VM. So now people with access to the storage hosts cannot compromise any data. People with access to the virtualization hosts can only compromise data if the host has been authorized to use that disk image You would need to compromise the precise host the VM disk is being used on, or compromise the key server or the management service that schedules VMs (thus authorizing key usage on a node). NB this is better than relying on the guest OS to do encryption, since you can do stricter decryption key management from the host side. On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? I would like to extend the libvirt driver in Nova to make use of the qcow2 encryption capabilities between libvirt QEMU which I describe here: http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
I think that Intel's trusted cloud work is trying to solve that exact compute host problem. It may already have the framework to do so even if the software hasn't caught up (i.e. if we still have some work to do!) It relies on a TPM chip, all code is measured before being run, and then there's a protocol to prove that a system is running that code (remote attestation). If you change the software stack by introducing a sniffer, you change the hash. So we'd need a stack with no root-access / back-doors. Once a back-door becomes known, the hash should no longer be trusted. I'm by no means an expert (I'm still learning about it), but I believe it is possible, having read this paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf I'm sure there are still exploits (hardware RAM taps?), and we rely on a total code audit, but we can raise the bar a long way. Anyone from Intel / familiar with Intel's trusted cloud work want to explain better than I can? Justin On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce m...@nycresistor.com wrote: As far as storage is concerned, certainly a cloud storage environment could be leveraged to store pre-encrypted data in such a way that would make it difficult bordering on impossible to seize or access without the consent of the owner. As far as compute hosts are concerned, it is a whole different matter. For the foreseeable future ( barring the invention of new widely distributed in CPU technology ) . Anyone with ring 0 execution access on a system ( ie root / sudo ) will be able to pull data from a running instance pretty much no matter what you do. You can certainly raise the bar on difficulty there, but the fundamental path of sniffing schedulers / paging memory / etc will be there for a fairly long time. Even trusted computing wouldn't be applicable to protecting a vm's scheduler from the hypervisors owner. So, I think functionally it should be assumed that a provider will be able to access anything that you access on a hosted VM. As far as a trust relationship goes in elastic computing, there must be an implicit trust of the cloud provider. And as with any trust relationship there is always going to be an element of risk. -Matt On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an instance of that VM. So now people with access to the storage hosts cannot compromise any data. People with access to the virtualization hosts can only compromise data if the host has been authorized to use that disk image You would need to compromise the precise host the VM disk is being used on, or compromise the key server or the management service that schedules VMs (thus authorizing key usage on a node). NB this is better than relying on the guest OS to do encryption, since you can do stricter decryption key management from the host side. On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? I would like to extend the libvirt driver in Nova to make use of the qcow2 encryption capabilities between libvirt QEMU which I describe here: http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Encrypted virtual machines
Functionally if the scheduler doesn't know what it's passing to the CPU or into paging memory a lot of optimization possibilities go out the window. If it does know one can infer a great deal about your datasets protected or not. -Matt On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara jus...@fathomdb.com wrote: I think that Intel's trusted cloud work is trying to solve that exact compute host problem. It may already have the framework to do so even if the software hasn't caught up (i.e. if we still have some work to do!) It relies on a TPM chip, all code is measured before being run, and then there's a protocol to prove that a system is running that code (remote attestation). If you change the software stack by introducing a sniffer, you change the hash. So we'd need a stack with no root-access / back-doors. Once a back-door becomes known, the hash should no longer be trusted. I'm by no means an expert (I'm still learning about it), but I believe it is possible, having read this paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf I'm sure there are still exploits (hardware RAM taps?), and we rely on a total code audit, but we can raise the bar a long way. Anyone from Intel / familiar with Intel's trusted cloud work want to explain better than I can? Justin On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce m...@nycresistor.com wrote: As far as storage is concerned, certainly a cloud storage environment could be leveraged to store pre-encrypted data in such a way that would make it difficult bordering on impossible to seize or access without the consent of the owner. As far as compute hosts are concerned, it is a whole different matter. For the foreseeable future ( barring the invention of new widely distributed in CPU technology ) . Anyone with ring 0 execution access on a system ( ie root / sudo ) will be able to pull data from a running instance pretty much no matter what you do. You can certainly raise the bar on difficulty there, but the fundamental path of sniffing schedulers / paging memory / etc will be there for a fairly long time. Even trusted computing wouldn't be applicable to protecting a vm's scheduler from the hypervisors owner. So, I think functionally it should be assumed that a provider will be able to access anything that you access on a hosted VM. As far as a trust relationship goes in elastic computing, there must be an implicit trust of the cloud provider. And as with any trust relationship there is always going to be an element of risk. -Matt On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an instance of that VM. So now people with access to the storage hosts cannot compromise any data. People with access to the virtualization hosts can only compromise data if the host has been authorized to use that disk image You would need to compromise the precise host the VM disk is being used on, or compromise the key server or the management service that schedules VMs (thus authorizing key usage on a node). NB this is better than relying on the guest OS to do encryption, since you can do stricter decryption key management from the host side. On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? I would like to extend the libvirt driver in Nova to make use of the qcow2 encryption capabilities between libvirt QEMU which I describe here: http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| ___ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net
Re: [Openstack] Encrypted virtual machines
I think one of us is misunderstanding the model. My understanding is that we produce software that we trust, and then prove to the caller that we're running that software. All optimizations remain possible. Check out section 6.1 of the paper! On Thu, Apr 26, 2012 at 3:24 PM, Matt Joyce m...@nycresistor.com wrote: Functionally if the scheduler doesn't know what it's passing to the CPU or into paging memory a lot of optimization possibilities go out the window. If it does know one can infer a great deal about your datasets protected or not. -Matt On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara jus...@fathomdb.com wrote: I think that Intel's trusted cloud work is trying to solve that exact compute host problem. It may already have the framework to do so even if the software hasn't caught up (i.e. if we still have some work to do!) It relies on a TPM chip, all code is measured before being run, and then there's a protocol to prove that a system is running that code (remote attestation). If you change the software stack by introducing a sniffer, you change the hash. So we'd need a stack with no root-access / back-doors. Once a back-door becomes known, the hash should no longer be trusted. I'm by no means an expert (I'm still learning about it), but I believe it is possible, having read this paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf I'm sure there are still exploits (hardware RAM taps?), and we rely on a total code audit, but we can raise the bar a long way. Anyone from Intel / familiar with Intel's trusted cloud work want to explain better than I can? Justin On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce m...@nycresistor.com wrote: As far as storage is concerned, certainly a cloud storage environment could be leveraged to store pre-encrypted data in such a way that would make it difficult bordering on impossible to seize or access without the consent of the owner. As far as compute hosts are concerned, it is a whole different matter. For the foreseeable future ( barring the invention of new widely distributed in CPU technology ) . Anyone with ring 0 execution access on a system ( ie root / sudo ) will be able to pull data from a running instance pretty much no matter what you do. You can certainly raise the bar on difficulty there, but the fundamental path of sniffing schedulers / paging memory / etc will be there for a fairly long time. Even trusted computing wouldn't be applicable to protecting a vm's scheduler from the hypervisors owner. So, I think functionally it should be assumed that a provider will be able to access anything that you access on a hosted VM. As far as a trust relationship goes in elastic computing, there must be an implicit trust of the cloud provider. And as with any trust relationship there is always going to be an element of risk. -Matt On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an instance of that VM. So now people with access to the storage hosts cannot compromise any data. People with access to the virtualization hosts can only compromise data if the host has been authorized to use that disk image You would need to compromise the precise host the VM disk is being used on, or compromise the key server or the management service that schedules VMs (thus authorizing key usage on a node). NB this is better than relying on the guest OS to do encryption, since you can do stricter decryption key management from the host side. On Thu, Apr 26, 2012 at 8:53 AM, Michael Grosser d...@seetheprogress.net wrote: Hey, I'm following the openstack development for some time now and I was wondering if there was a solution to spin up encrypted virtual machines by default and if it would be a huge performance blow. Any ideas? I would like to extend the libvirt driver in Nova to make use of the qcow2 encryption capabilities between libvirt QEMU which I describe here: http://berrange.com/posts/2009/12/02/using-qcow2-disk-encryption-with-libvirt-in-fedora-12/ Regards, Daniel --
Re: [Openstack] Encrypted virtual machines
Michael, IMO there are several encryption and key management things to consider so it really depends on your needs. If you are looking to allow VM owners to meet data at rest compliance or policies then allow them to manage their own encryption keys and rotation policies then a solution like Justin described encrypting inside the disk image does work and the performance impact is low. You can do some experimentation with ecryptfs and layer that on your existing storage. You can checkout the Ubuntu encrypted home directories as a reference. Now if you are a service provider and would like to disassociate yourself from any subpoenable content that may be stored on your servers, then you may want to do encrypt entire storage by default, then store your encryption keys in keystone maybe. For compute, as Matt mentioned protecting your in-memory data from root or from the hypervisor is not that easy you can make it harder, but there isn't a really good solution today. Longer term trust models that go from metal to hypervisor to tenants using technologies TPM, remote attestation will provide the extra security layers. -Eddie On Apr 26, 2012, at 5:34 PM, Justin Santa Barbara wrote: I think one of us is misunderstanding the model. My understanding is that we produce software that we trust, and then prove to the caller that we're running that software. All optimizations remain possible. Check out section 6.1 of the paper! On Thu, Apr 26, 2012 at 3:24 PM, Matt Joyce m...@nycresistor.com wrote: Functionally if the scheduler doesn't know what it's passing to the CPU or into paging memory a lot of optimization possibilities go out the window. If it does know one can infer a great deal about your datasets protected or not. -Matt On Thu, Apr 26, 2012 at 3:08 PM, Justin Santa Barbara jus...@fathomdb.com wrote: I think that Intel's trusted cloud work is trying to solve that exact compute host problem. It may already have the framework to do so even if the software hasn't caught up (i.e. if we still have some work to do!) It relies on a TPM chip, all code is measured before being run, and then there's a protocol to prove that a system is running that code (remote attestation). If you change the software stack by introducing a sniffer, you change the hash. So we'd need a stack with no root-access / back-doors. Once a back-door becomes known, the hash should no longer be trusted. I'm by no means an expert (I'm still learning about it), but I believe it is possible, having read this paper: http://www.research.ibm.com/trl/projects/watc/FredericStumpfPaper.pdf I'm sure there are still exploits (hardware RAM taps?), and we rely on a total code audit, but we can raise the bar a long way. Anyone from Intel / familiar with Intel's trusted cloud work want to explain better than I can? Justin On Thu, Apr 26, 2012 at 1:44 PM, Matt Joyce m...@nycresistor.com wrote: As far as storage is concerned, certainly a cloud storage environment could be leveraged to store pre-encrypted data in such a way that would make it difficult bordering on impossible to seize or access without the consent of the owner. As far as compute hosts are concerned, it is a whole different matter. For the foreseeable future ( barring the invention of new widely distributed in CPU technology ) . Anyone with ring 0 execution access on a system ( ie root / sudo ) will be able to pull data from a running instance pretty much no matter what you do. You can certainly raise the bar on difficulty there, but the fundamental path of sniffing schedulers / paging memory / etc will be there for a fairly long time. Even trusted computing wouldn't be applicable to protecting a vm's scheduler from the hypervisors owner. So, I think functionally it should be assumed that a provider will be able to access anything that you access on a hosted VM. As far as a trust relationship goes in elastic computing, there must be an implicit trust of the cloud provider. And as with any trust relationship there is always going to be an element of risk. -Matt On Thu, Apr 26, 2012 at 9:53 AM, Daniel P. Berrange berra...@redhat.com wrote: On Thu, Apr 26, 2012 at 09:05:41AM -0700, Matt Joyce wrote: From a security stand point I am curious what you see the benefit as? Consider that you might have separate people in your data center managing the virtualization hosts, vs the storage hosts vs the network. As it standards today any of those groups of people can compromise data stored in a VM disk image (assuming a network based filesystem). First you encrypt the disk image, so that a person with access to the storage hosts, or network sniffing can't read any data. Then you have a central key server that only gives out the decryption key to Nova compute nodes when they have been explicitly authorized to run an
