How protected are files within a running encrypted VM on a possibly non secure hypervisor / host?

Question

I've got a set of source code files (compiled C#) that I want to prevent direct read access to. The program will be running on the VM. I was thinking of storing these in an encrypted hard disk VM, the VM would use these files in conjunction with a HTTP / TCP endpoint.

Some additional information:

• The files that need to be protected are compiled C# 'IL' files (I think it's called bytecode).
• The client will be running the VM within their own host/hypervisor environment.

The encryption would be disk encryption (relative to the VM) so taking the following from https://wiki.archlinux.org/index.php/Disk_encryption

Disk encryption ensures that files are always stored on disk in an encrypted form. The files only become available to the operating system and applications in readable form while the system is running and unlocked by a trusted user. An unauthorized person looking at the disk contents directly, will only find garbled random-looking data instead of the actual files.

Would this mean a VM host would not actually be able to view the files?

---

I would also look to prevent any other means of access besides the HTTP / TCP endpoint (so I'd remove any login prompt etc, possibly even remove the entire shell if that is possible).

I'm not too worried about the files appearing in 'memory', as I think it would be a difficult task to reverse engineer them back into files.

I can appreciate that this is not 100% secure, I'm just trying to make it as difficult as possible to access the source code (I'm already using source code obfuscation).

The main object here is to prevent read access / reverse engineering the source code of the application.

I suppose a summary of the above can be stated as: Is the above sufficient to make a 'secure' binary blob that is a VM image and it's only point of entry/interface would be a HTTP endpoint?

Answer 1

It is not clear from what kind of attacker your are trying to protect. But to make some guesses what could it be:

• If the attacker gets inside your VM all files are there in plain because they are transparently decrypted when read.
• If the attacker is root on the VM host instead he could capture the credentials you need to enter on start of the VM if the encryption key for the disk is password protected. If the encryption key is not protected and resides on the system where the VM is running it will be even simpler for root on the system to get it. Once the attacker has access to the credentials he could decrypt the disk.
• If the attacker is not root on the VM host then he should not be able to read your VM image in the first place, i.e. proper file permissions should be sufficient protection.

In other words: I don't think you gain much with your proposed method.