Reverse engineering a Docker deployment on private

问题:

I am working on a software that has to be deployed on private cloud of a client. The client has root access, as well as hardware. I don't want the client to reverse engineer our software.

We can control two things here:

1. we have access to a secure port of the server, which we can use to send tokens to decrypt the code, and shut it down if necessary;
2. we can do manual installation (key in a password at the time of installation) or use Tamper resistance device if we have to.

Can a Docker deployment prevent our client from reverse engineering our code? We plan to open a single port and use SSL to protect incoming and outgoing data.

回答1:

If user has root, or he able to use his custom kernel (or even kernel modules), he can do anything - dump memory, stop process, attach debugger - to start reverse engineering. If user has access to hardware, he also can get root or custom kernel. The only way to protect soft from user - is using good DRM, for example with help of TPM (Trusted Platform Module), or ARM TrustZone. SecureBoot will not fully protect your soft (on x86 it usually may be turned off). Other variant is using Tamper-resistant hardware (http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-tamper-resistant-hardware.htm), like what is used to store master encryption keys (to process pin-codes) in banks (http://en.wikipedia.org/wiki/Hardware_security_module), but this hardware have very high cost.

It is known that Docker does not give protection to the code from user: https://stackoverflow.com/a/26108342/196561 -

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.

Any user capable of deploying docker container (user from docker group) has full access to the container fs, has root access to the container processes and can debug them and dump their memory. https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful

Only trusted users should be allowed to control your Docker daemon

http://docs.docker.com/articles/security/#docker-daemon-attack-surface

Docker allows you to share a directory between the Docker host and a guest container; and it allows you to do so without limiting the access rights of the container.

So, Docker give no additional protection to your code from user; we can consider it just like other packaging system, like rpm and deb. Rpm and deb allows you to pack your code into single file and list dependencies, and docker packs your code and dependencies into single file.

Our solution is hosted on our client's cloud server, so they do have access to both root and the hardware. However, we have two advantages here: 1) we have access to a secure port, which we can use to send tokens to decrypt the code, and audit suspicious activities; 2) we can do manual installation (key in a token at the time of installation)

You can protect only the code you own, if it is running on the hardware you own (turn off all NSA/IntelME/IPMI/UEFI backdoors to own hardware). If user runs your code on his hardware, he will have all binaries and will be capable of memory dumping (after receiving the token from you).

Virtualization on his hardware will not give your code any additional protection.

Does "secure port" means SSL/TLS/SSH? It is secure only to protect data when it is send on network; both endpoints will have the data in plain, unencrypted form.

Manual installation will not help to protect code after you leave user's datacenter.

I think you can buy some usual software protection solution, like flexlm, may be with some hardware tokens required to run the software. But any protection may be cracked, early (cheaper) will be cracked easier, and modern (more expensive) protection is bit harder to crack.

You may also run some part of software on your own servers; this part will be not cracked.

or use Tamper resistance hardware if we have to.

You can't use tamper resistance hardware if there is no such hardware in the user's server. And it is very expensive.