I need to implement something similar to a license server. This will have to be
ID: 642138 • Letter: I
Question
I need to implement something similar to a license server. This will have to be installed off site at the customers' location and needs to communicate with other applications at the customers' site (the applications that use the licenses) and an application running in our hosting center (for reporting and getting license information).
My question is how to set this up in a way I can trust that:
The license server is really our application and not something that just simulates it; and
There is no "man in the middle" (i.e. a proxy or something that alters the traffic).
The first thing I thought of was to use with client certificates and that would solve at least 2. However, what I'm worried about is that someone just decompiles (this is build in .NET) the license server, alters some logic and recompiles it. This would be hard to detect from both connecting applications.
This doesn't have to be absolutely secure since we have a limited number of customers whom we have a trust relationship with. However, I do want to make it more difficult than a simple decompile/recompile of the license server. I primarily want to protect against an employee or nephew of the boss trying to be smart.
Explanation / Answer
Some hints:
Use a password when signing your assemblies (you're signing them, aren't you?).
Provide an automatic update feature of the licensing server. The client company would have to choose between:
Keeping patching each new version of the licensing server with a hacker patch,
Disabling auto-update, given that if they contact your support one day, they would have a hard time explaining why are they disabling the free of charge updates,
Spending days automating the patching.
Provide a mixed licensing solution. For example the local licensing server serves only as a caching/proxy solution, while communicating directly with your own server when online. The local server validates the licenses itself only when offline, given that it will stop functioning if it is offline for too long.
For example, it would happen like this:
Client requests to validate the license,
Intermediary licensing server forwards the request to your own server,
Your own server responds that the license is valid,
Intermediary licensing server remembers that the license is valid (using hashes etc. to avoid being tampered easily),
The next time, if the intermediary licensing server is requested to validate the same license, if it is online, it still does a request to your own server. If it is offline, it checks for local cache.
If a different license (i.e. something which doesn't happen very often: either new software is installed or old software is deployed on a new machine) is requested and the intermediary licensing server is offline, it returns an error saying that it is impossible to validate the new license offline.
Rely on support. If the client is requesting for support, ask to install a tool which will collect and send you the information about the system (current version of the licensing server, etc.). This tool may also compute the hashes of the executable files of the licensing server; if they don't validate, the customer would have to explain why he changed those files, while it is explicitly forbidden by the license.
Obfuscate the code.
Actively report hacking attempts. For example, you don't need to hide the core licensing validation process; call it LicenseValidation.dll for example. But the original code which should run the code within LicenseValidation.dll should start by computing the hash of the file, and if it's wrong, report it to you.
There are chances that a lazy hacker will start by tampering the most obvious file, while forgetting to verify if the file is validated somewhere else.
Gather statistics. With lots of statistics which are primarily not intended to detect piracy (like profiling results or crash reports), you can still have some hints that a precise company has a large degree of piracy.
For example if the licensing server reports that the piece of software A is installed on two PCs, while you constantly received for the last two months profiler reports from twenty static IP addresses (same IP, same machine name, same OS, etc.), it's a good sign that something goes wrong there.
Have competitive pricing. Few companies would spend time hacking a CRM which costs $50 per user. If the same CRM costs $50 000 per server and the company expands to ten other servers, it's rather advantageous to hire a skillful hacker.