Encrypted and secure docker containers

Question

We all know situations when you cannot go open source and freely distribute software - and I am in one of these situations.

I have an app that consists of a number of binaries (compiled from C sources) and python code that wraps it all into a system. This app used to work as a cloud solution so users had access to app functions via network but no chance to touch the actual server where binaries and code are stored.

Now we want to deliver the "local" version of our system. The app will be running on PCs that our users will physically own. We know that everything could be broken, but at least want to protect the app from possible copying and reverse-engineering as much as possible.

I know that docker is a wonderful deployment tool so I wonder: it is possible to create encrypted docker containers where no one can see any data stored in the container's filesystem? Is there a known solution to this problem?

Also, maybe there are well known solutions not based on docker?

Solution 1

What you are asking about is called obfuscation. It has nothing to do with Docker and is a very language-specific problem; for data you can always do whatever mangling you want, but while you can hope to discourage the attacker it will never be secure. Even state-of-the-art encryption schemes can't help since the program (which you provide) has to contain the key.

C is usually hard enough to reverse engineer, for Python you can try pyobfuscate and similar.

For data, I found this question (keywords: encrypting files game).

Solution 2

The root user on the host machine (where the docker daemon runs) has full access to all the processes running on the host. That means the person who controls the host machine can always get access to the RAM of the application as well as the file system. That makes it impossible to hide a key for decrypting the file system or protecting RAM from debugging.

Using obfuscation on a standard Linux box, you can make it harder to read the file system and RAM, but you can't make it impossible or the container cannot run.

If you can control the hardware running the operating system, then you might want to look at the Trusted Platform Module which starts system verification as soon as the system boots. You could then theoretically do things before the root user has access to the system to hide keys and strongly encrypt file systems. Even then, given physical access to the machine, a determined attacker can always get the decrypted data.

Solution 3

If you want a completely secure solution, you're searching for the 'holy grail' of confidentiality: homomorphous encryption. In short, you want to encrypt your application and data, send them to a PC, and have this PC run them without its owner, OS, or anyone else being able to scoop at the data. Doing so without a massive performance penalty is an active research project. There has been at least one project having managed this, but it still has limitations:

1. It's windows-only
2. The CPU has access to the key (ie, you have to trust Intel)
3. It's optimised for cloud scenarios. If you want to install this to multiple PCs, you need to provide the key in a secure way (ie just go there and type it yourself) to one of the PCs you're going to install your application, and this PC should be able to securely propagate the key to the other PCs.

Andy's suggestion on using the TPM has similar implications to points 2 and 3.

Solution 4

Sounds like Docker is not the right tool, because it was never intended to be used as a full-blown sandbox (at least based on what I've been reading). Why aren't you using a more full-blown VirtualBox approach? At least then you're able to lock up the virtual machine behind logins (as much as a physical installation on someone else's computer can be locked up) and run it isolated, encrypted filesystems and the whole nine yards.

You can either go lightweight and open, or fat and closed. I don't know that there's a "lightweight and closed" option.

Solution 5

I have exactly the same problem. Currently what I was able to discover is bellow.

A. Asylo(https://asylo.dev)

1. Asylo requires programs/algorithms to be written in C++.
2. Asylo library is integrated in docker and it seems to be feаsable to create custom dоcker image based on Asylo .
3. Asylo depends on many not so popular technologies like "proto buffers" and "bazel" etc. To me it seems that learning curve will be steep i.e. the person who is creating docker images/(programs) will need a lot of time to understand how to do it.
4. Asylo is free of charge
5. Asylo is bright new with all the advantages and disadvantages of being that.
6. Asylo is produced by Google but it is NOT an officially supported Google product according to the disclaimer on its page.
7. Asylo promises that data in trusted environment could be saved even from user with root privileges. However, there is lack of documentation and currently it is not clear how this could be implemented.

B. Scone(https://sconedocs.github.io)

1. It is binded to INTEL SGX technology but also there is Simulation mode(for development).
2. It is not free. It has just a small set of functionalities which are not paid.
3. Seems to support a lot of security functionalities.
4. Easy for use.
5. They seems to have more documentation and instructions how to build your own docker image with their technology.

View more solutions

Comments

[Aleksei Petrenko]

Hi! Thank you for this answer. Obfuscation is obviously a thing we consider, but it solves just one problem with reverse-engineering (and not entirely). What I really want to have is a sandbox container that looks like a blackbox from outside. You can interact with its inputs and outputs but cannot see whats inside. I wonder if it's possible with some kind of encrypted filesystem inside the container. Thank you for these links I'll check em out!

[remram]

If you encrypt the container, you still need the key to appear somewhere in what you ship to your users, or there will be no way to run it. And if you distribute it, there's a chance your users will find it...

[Aleksei Petrenko]

I understand that as well. But honestly I am not the first one who faces such problem. I know there should be some Linux distributions with such security features included - encrypted filesystems etc. Ok maybe I have to figure it out myself. Thank you anyway.

[remram]

The problem is that security through obscurity by essence isn't very popular in the open-source community. Best of luck to you though :)

[Aleksei Petrenko]

Andy, thank you for the answer. As I mentioned in the post: "We know that everything could be broken" - so I'm aware of that. I just thought there are "standard" ways of doing such things and I also hoped that there is a known solution based on docker. Now I think that we'll just have an obfuscation + some kind of license file - just a basic protection but more than nothing. Btw thanks for the link, I'll check this out.

[Aleksei Petrenko]

Good point. I don't want VM approach due to performance issues. I think in the end we will be more light and open rather than heavy and close :)

[remram]

A virtual machine would not help in this regard. It is as easy to mount the filesystem from an image as it is to find a container's root directory... And encrypting is still not an option.

[remram]

For Python specifically, have you read this question? Other than that, all I can say is that Docker won't help.

[Aleksei Petrenko]

Yep, I kinda figured it out (about homomorphous encryption) when I was investigating this topic. Thank you for this informative post by the way!

[mh8020]

Also, it is easy to dump the entire RAM of a running VirtualBox VM. So even if your customers cannot login and the file system is encrypted, they can easily access e.g. your Python source code once it is loaded. I think I used this command: $ vboxmanage debugvm "Name of your VM" dumpguestcore --filename ram.elf $ grep "Source code snippet" ram.elf wiki.yobi.be/wiki/RAM_analysis

[Jan Clemens Stoffregen]

I think you mean that the learning curve for Asylo is indeed steep :)