Software licensing

We all know that even well secured, big company software is cracked and used without paying. Generally if a software is distributed as a standalone application and people are going to want it without paying for it, it is going to be cracked sooner or later. In another words, the likelihood of application being cracked is far more proportional to its usefulness rather that the strength of the serial key handling introduced in that application.

Generally, making the software easier to buy than to steal is advisable, if possible. It includes providing some extra services or products for paid customers, for example online support, extra plugins, dedicated features etc. So selling not only an application but a bunch of services and products together. At the other side giving some limited functionality version to those who will anyway not pay for this, so making the software more popular, not loosing the sale at the same time. A good example here is Express software editions from Microsoft.

Then what is the reason for introducing the licensing mechanism in the application at all?

Simply to make sure the honest customers will not make a mistake and use not intended software, keeping in mind to not punish them with a system meant to prevent hackers, as hackers will crack it anyway. If your main customers group are big companies then you can be pretty sure that they will pay for you software reasonable price than having enormous punishment for using illegal copy.

Now I would like to present few licensing solutions I found on the internet

1. License file signed with private/public key
2. License file encrypted with symmetric key provide as serial key (my preffered)
3. Custom serial key generation
4. License server

There are of course a lot of third party commercial components for instance Ellipter, .Net Licensing Pro, Crypto Licensing for .Net, Intellilock and much more ready to use, but in this article we will try to focus on free, self made, solutions which should be enough for most applications.

1. License file signed with RSA key
   

   This solution has quite good support in .net framework, see SignedXml for details. We create a standard xml file and put all license related information in it. Then using, built in .net framework, RSA encryption we sign that file with a secure signature using private key encryption. The signature is computed of the hash of file content and attached at the end of license file. Public key is included into a software. Then we give the application with that license file to customer. When application runs it verifies the signature of the file with use of public key. If it is correct, which means the file was not altered since it was signed, then the license information is read and application is adjusted according to the customer permissions. The implementation of this solution can be found here.

   Pros: No serial key required, any kind and amount of data may be included in license file.

   Risk: Possible replacing public key hidden in application code.
   

2. License file encrypted with AES symmetric key key provide as serial key
   

   This is some modification of algorithm 1. License file’s content is encrypted with AES symmetric algorithm (AesCryptoServiceProvider). The key for the license file is saved in the application code encrypted with another key. This key is generated by our software and is used as a serial key. For the sake of simplicity and readability, it may be just an GUID. Then this key is provided to the customer, to be typed in application startup, so it should be easy to read and type. License file is stored among with the application. When user puts the serial key – encryption key, then license file key is decrypted, the content of the license file is decrypted and license information is read.
   Pros: Human readable serial key, encrypted content of the license file may contain some additional security rules
   Risk: License and serial key replacement possibility.
   

3. Custom serial key generation
   

   It seems to be very popular solution for serial key and license handling. The solution is based on a set of custom rules which applies to the serial key generation and validation. These rules may be just some mathematical functions applied to the key numbers. For instance: the sequence constructed of each 4’th number in the key determines the version of the application and must match the actual version; sum of some numbers divided modulo 10 gives the indication about the edition that is used; and so on.

   Pros: Simple security mechanism, no files, no “dialing homes”

   Risk: possibility to create key generator based on MSIL code.
   

4. License server
   

   This is most reliable solution but requires more implementation and infrastructure effort. More over it requires the software is dialing which is not always accepted. Unique serial key are generated for each customer. The list of already generated keys are stored on license server to be used for generating new key, so there is no chance to generate two same keys. User provide the serial key into the application, which then connects to the license server and retrieves the license data. Additional private/public key encryption may be introduced between application and license server to prevent using fake server.

   Pros: More secure

   Risk: Possibility to replace public key in disassembled code and connect to the fake server;

All of these solutions may seem to be good enough, but we must remember that hackers are also humans and since human creates the protection system, the human can break it. This is especially easy in managed code applications, like in .net framework using disassembling and reflection mechanism (See for instance excellent .net decompiler dotPeek from jetbrains which can easily decompile assemblies into a c# code files !). There is always a place in the application where it’s decided if application can run or should exit because of insufficient privileges. Then it is only a matter of bypassing that place and application is cracked.

Obfuscation is one of the technics which makes cracking application much more harder, but not much enough. Another way is making our application somehow dependent on external server managed by us. For example some crucial or key functionality of our application may be handled by the server. Some chunk of important code may be downloaded from the server after the application is activated. All of these solutions have its pros and cons, but its always good to think if it is worth investing effort and money in very sophisticated security protections.

Ok, let’s see how big companies handles the licensing topic. In Rose Vines post Windows Product Activation (WPA) we can read about the activation process which is, or at least was, used by Microsoft in Windows operation system. In principle WPA is base on licensing server which the Windows system connects to during activation process. In most common case user has 30 days to activate his copy of the product. During the activation the unique Installation ID is generated and provided to the activation server. Installation ID consists of Product Key provided with the Windows and the hardware hash. Hardware hash is some sort of hardware identifier which uniquely identifies the customer machine. It is constructed of some computer hardware information (for more details see  Inside Windows Product Activation A Fully Licensed Paper), for instance: volume serial number of operating system, network adapter MAC address, CPU serial number, RAM size etc. Activation server results with an activation key which is then stored in the Windows and informs the system as being activated.

The main disadvantage of this solution is that when user changes the hardware by for example adding more RAM, changing MAC address of the network card or even, what can often happen, installs another hard drive in his machine, he must apply to the Microsoft for the new activation key, so he is not installing the software on another machine.

Let’s see how the solution with activation via licensing server could be accomplished. Below diagram presents the flow of the actions performed on the client application and license server. Green arrows indicates positive answer and red negative.

In general this is accomplished by an encrypted communication between application and licensing server. The RSA encryption is used for the first time communication. Private key is stored on the server and the public part is included within the application. First message sent to the license server includes AES symmetric encryption key generated for this particular copy of the application and is then used for encrypting messages sent to and from license server. This is because the RSA encryption is slow and requires the license server would have the public part of application RSA key. HD_Stamp is generated from CPU serial number and Hard drive serial number. Hard drive serial would not be necessary here, but there is a possibility that on some mother boards user can switch off the CPU Serial so the HD_Stamp would then be null.

All license and encryption related data is stored in encrypted configuration file at application location using Windows DPAPI. So these data is as much secure as Windows user account is. That is enough for most cases, I think.

From the other hand the license server handles serial keys, customers and activation data. For each activated installation the HD_Stamp is stored and the count of activated instances is compared to the maximum in customer license.