1

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.

Mark O'Connor
  • 76,015
  • 10
  • 139
  • 185
AdamNYC
  • 19,887
  • 29
  • 98
  • 154
  • 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. Or installing your Tamper-resistant hardware (http://www.emc.com/emc-plus/rsa-labs/standards-initiatives/what-is-tamper-resistant-hardware.htm). So, no, Docker deployment does not protect your code. – osgx Mar 05 '15 at 02:00
  • Also, check answer http://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.*" – osgx Mar 05 '15 at 02:01
  • Example of easiest breaking into docker from user with `docker` group (the one who installs new docker container) - https://www.andreas-jung.com/contents/on-docker-security-docker-group-considered-harmful - with "*"Only trusted users should be allowed to control your Docker daemon"*" quote from https://docs.docker.com/articles/security/#docker-daemon-attack-surface and "*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.*" – osgx Mar 05 '15 at 02:49
  • @osgx: thanks for great info. Could you move your comments into answer so that I can upvote/accept it? 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) or use Tamper resistance hardware if we have to. – AdamNYC Mar 05 '15 at 04:32
  • 1
    The entire premise of this question is misguided. There is literally nothing you can do to stop me from reverse-engineering your software. You can make it more challenging, but you'll be wasting your own time, increasing the complexity of your product, and actively making your product less useful. If you have "intellectual property" issues, use property law (like copyright) to fix it, not DRM. – slang Oct 10 '16 at 07:15

1 Answers1

0

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.

Community
  • 1
  • 1
osgx
  • 90,338
  • 53
  • 357
  • 513
  • 1
    AdamNYC, TrustZone works only on ARM architecture, not on x86 or x86_64 (read Intel and AMD). TrustZone is not free to use as I know. And TPM (http://en.wikipedia.org/wiki/Trusted_Platform_Module) is present not on every PC or server, its chip may not be included by some server vendors, and it also can be disabled in some countries. It can be easier for you to buy software anti-piracy protection tool with support of TPM. – osgx Mar 05 '15 at 18:50
  • could you recommend a software anti-piracy protection tool with support of TPM? A 10' Google leads to dated research papers. Thanks a million! – AdamNYC Mar 05 '15 at 19:18
  • 1
    AdamNYC, no I never used anti-piracy tools to *protect* my own software; open source is better. And running software (fully or partially) in your own server/cloud (SaaS) may be better way. Please, read answers in http://programmers.stackexchange.com/questions/46434 as their authors have more experience than I. Also I know that flexlm in different versions was and is popular to protect software for Linux (older versions can be easily cracked; don't know about TPM support); the other possible google keyword HASP (hardware usb keys/tokens). Same pair in http://stackoverflow.com/questions/1073497 – osgx Mar 05 '15 at 19:31
  • Thank you for saving me tons of time attacking a very hard problem :) – AdamNYC Mar 05 '15 at 19:42
  • AdamNYC, what is the price of your software? Is it under 1000 USD or like 100 000 USD or more 1 000 000 USD? Don't apply too advanced protection if your program is cheap (HSMs are from 500$ for hackable USB tokens/HASPs; up to 5-15 k USD in 2006 for HSM server - [slide 14](http://www.febraban.org.br/7Rof7SWg6qmyvwJcFwF7I0aSDf9jyV/sitefebraban/cnab6-0315_anexoA.pdf), which only can secure store keys and can't be owned; but it will not run your software ). It will be better to provide good support/updates to the software, and this also can protect it from piracy. – osgx Mar 05 '15 at 20:03