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:

  1. The license server is really our application and not something that just simulates it; and
  2. 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.


Some hints:

  1. Use a password when signing your assemblies (you're signing them, aren't you?).

  2. 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.

  3. 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.

  4. 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.

  5. Obfuscate the code.

  6. 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.

  7. 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.

  8. 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.

  • Thank you for your response. Your suggestions are very helpful. However, I was wondering about the signed key. Yes, the assemblies are signed and I already though about using this for some validations. However, I do not understand why the key should have a password. Could you elaborate a bit about that? – Pieter van Ginkel Nov 8 '12 at 11:52
  • @Pieter: The key should have a password in order for a third party to not being able to change the key. This being said, signed assemblies (even with passwords) are not enough: one can change the executable itself, so it would accept the tampered libraries. Signed assemblies are rather useful in a context in which you have a total control over the executable, but not the DLLs. – Arseni Mourzenko Nov 8 '12 at 14:03
  • One suggestion I would like to add myself which builds on the automatic updates is that in the communication with the server, something could be done with the currently installed version, requiring the latest version to be installed. This again would make it much more cumbersome to keep everything operational which was mostly the point of my question. – Pieter van Ginkel Nov 9 '12 at 20:53

Two possibilities come to mind:

  • Have the license server run on a physically secured box you provide
  • Have the license server be a dumb proxy through which the other applications communicate with your hosted license app, basically a VPN tunnel.

If you just think decompiling a .net app is a bit too easy, compile it to native or use an obfuscator. But I think you're probably worrying needlessly. The scenario that someone at a company you have a "trust relationship" with would have the necessariy skills, the motivation and the willingness to commit a crime seems very unlikely to me.

  • The whole reason for having the application on site would be to not have outage when the internet goes out. The first would solve the issue, but may be a bit too much. – Pieter van Ginkel Nov 8 '12 at 10:58

I am unsure this is actually truly possible. A bit of a stretch but a similar question I posted came to the that conclusion. You may want to try utilizing the OS for achieving what you want, perhaps store a cert in a folder only your application has access to. That way any non-administrator would not be able to get to it and thus could never represent themselves as your application.

  • I'm not actually looking for a 100% secure solution. As I said, there is a trust relationship with our customers. The suggestions given by MainMa are actually quite good and I think they offer enough protection for my situation. – Pieter van Ginkel Nov 9 '12 at 20:50

Your Answer

