3

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?

Chris Stryczynski
  • 141
  • 4
  • Might be useful to read up on Qubes OS and why it’s so important that the hypervisor and dom0 are protected/non-malicious. – Steve Mar 15 '18 at 20:29
  • In theory, you could use SGX to protect the guest from the hypervisor, but that would require a rather complex setup. – forest Mar 16 '18 at 06:35

1 Answers1

2

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.

Steffen Ullrich
  • 184,332
  • 29
  • 363
  • 424
  • I have tried to add additional information to the question. Could you possibly elaborate on what you mean by 'gets inside your vm', would this mean via for example a linux login prompt? The potential attacker is indeed the VM host. I'm also trying to determine if a Host VM has access to the `decrypted` filesystem (if we pretend he doesn't know about the decryption key hiding in plain sight). – Chris Stryczynski Mar 15 '18 at 18:48
  • @ChrisStryczynski: with inside the VM I mean that the attacker could use some vulnerability in your VM (like the HTTP interface) to be able to execute code inside the machine. Assuming that the attacker has full access to the VM host but pretending that he will find the decryption key is probably a false assumption. – Steffen Ullrich Mar 15 '18 at 18:54
  • It's fairly easy to find encryption keys in the memory of a running VM, if you control the hypervisor. – Michael Hampton Mar 15 '18 at 19:01
  • Could you point me to any resources on how this would be achieved? @MichaelHampton The only thing I can think of is watching the part of memory that gets accessed frequently. – Chris Stryczynski Mar 15 '18 at 19:10
  • @ChrisStryczynski The search space is so small you could just brute force it. – Michael Hampton Mar 15 '18 at 19:23
  • @MichaelHampton: If the key is inside the VM the attacker could just clone the VM and then have everything. If the key is outside the VM the attacker has just to monitor how you start the VM to see where the keys are read from or what you enter. – Steffen Ullrich Mar 15 '18 at 19:42
  • @SteffenUllrich The key is in RAM while a volume is actively being used. Searching, e.g. 4GB of space for a 256-bit key is pretty easy. – Michael Hampton Mar 15 '18 at 21:25