0

I have some code and other resources which run in a container or VM ("black box") on a host machine. The host uses this as a service to process some files which are highly sensitive and they don't want them off their premises (so no cloud). However, suppose I do not trust the host: I do not want the host to be able see the resources or code in the black box: ideally the host starts it like a server, and can only interact with it via an API. The analogy I have in my head is the driver of car who can use their key to start the engine to drive the car but can't access or see inside the engine.

I'm new to security so I'm out of my depth but I've so far been able to discover the "separation kernel" but I don't think that's quite what I'm after since that's about protecting multiple OSes which don't trust each-other running on a single machine which they all together trust. In my scenario I don't trust the machine on which my code is running. Ultimately, I suppose the black box needs to use the host CPU so the host will have to see at least machine code going in and out of the black box. But:

  1. What are the theoretical limits? And
  2. What options are currently available in this scenario (even if it's just obfuscation like wrapping the container encrypted in a binary which contains the key)?
Alex
  • 109
  • A **running** *container* or *VM* lives in host memory. The host always has access. An encrypted VM only protects a non-running container. – user10216038 Aug 08 '21 at 15:16
  • "The analogy I have in my head is the driver of car who can use their key to start the engine to drive the car but can't access or see inside the engine." Good analogy. Can you think of any production cars where this is possible? – Joseph Sible-Reinstate Monica Aug 08 '21 at 15:27
  • 3
    Does this answer your question? [How can a VM handle a compromised host?](https://security.stackexchange.com/questions/214426/how-can-a-vm-handle-a-compromised-host), [How to prevent a hosting company from accessing a VM's encryption keys?](https://security.stackexchange.com/questions/215920/how-to-prevent-a-hosting-company-from-accessing-a-vms-encryption-keys). – Steffen Ullrich Aug 08 '21 at 15:46
  • 1
    [AMD SEV-ES](https://docs.vmware.com/en/VMware-vSphere/7.0/com.vmware.vsphere.security.doc/GUID-F1F913CB-05F9-4D4F-B8A7-970A43532003.html) seems to be the closest to what you need. – nobody Aug 08 '21 at 16:19
  • Thanks @SteffenUllrich and nobody . AMD SEV seems good and maybe this could be combined with key management to verify it's running on the right hardware? [ https://developer.ibm.com/technologies/containers/articles/enabling-advanced-key-usage-and-management-in-encrypted-container-images/ ]. I still wonder though if this is an under-researched area and what theoretical limits there may be to this problem. – Alex Aug 08 '21 at 17:30
  • @JosephSible-ReinstateMonica I'm sure Mission Impossible or Q could come up with some clever idea: The car could self-destruct if the driver tried to access the engine! At the very least it may require special tools, effort or expertise (analogous to obfuscation perhaps I suggested in my question). – Alex Aug 08 '21 at 17:47
  • I assume you want a solution in real life, and not in a work of fiction. My point was just like there's no production cars that work like that in real life, you're not going to find a solution you like to this problem either. – Joseph Sible-Reinstate Monica Aug 08 '21 at 17:53
  • @JosephSible-ReinstateMonica The car analogy is not great. I think this is actually quite a common problem for businesses. And AMD SEV looks like a solution, albeit rather expensive and complicated. I'm left wondering how much this problem has been studied theoretically and what potential solutions there may be one day. – Alex Aug 08 '21 at 17:58

0 Answers0