4

I develop a license server and a license client system (Java based applications).

The flow is the following:

  1. The license is stored on the license server
  2. The client application includes a license client component.
  3. The license client connects to the license server via HTTPS to retrieve the license information.
  4. The license is not passed to the license client – only the information if the license enabled.
  5. If the license is enabled the license client returns to the client application the licensed status and it is possible to use the client application.
  6. If the license is not enabled, the license client starts the evaluation period (for example 30 days). During this period we recommend to our customers to purchase the license.
  7. If the evaluation period is passed, the license client returns to the client application the unlicensed status and it is not possible to use the client applications.

I have dilemma how to persist the start evaluation time, since if a customer can compromise it and the evaluation period will start once again. I store the license status in the database using AES-256 algorithm, so I do not think a customer will be able to decrypt the information. Also, if a customer will remove the license status from the database it is not possible to use the client application, so I do not care about it.

Similar, I store the start evaluation time in the database using AES-256 algorithm, so I do not think a customer will be able to decrypt the information. But I have a problem if a customer will remove the start evaluation time from the database. In this case I will start the evaluation period from the beginning.

I do want to store the information in the database (to be able in the future to scale up using database replication). Also, I do not want to store start evaluation time on the license server – since it is client issue. More detailed: in the future we want to support the license (and the evaluation time) for different type of permissions. For example, license to execute a job or license to edit a document. Therefore, the customer can be fully licensed to execute a job, but can be in the evaluation period to edit a document.

Any suggestions are more than welcomed.

Michael
  • 1,457
  • 1
  • 18
  • 36
  • The license server is at the customers place or somewhere in the net? – Dr.Ü Apr 16 '13 at 08:47
  • 1
    _"The license client connects to the license server via HTTP to retrieve the license information"_ Why not https? You should use an encrypted connection, an own certificate (don't use the system store), and don't use the connection when another certificate is used. Having a daemon reply with "Yup you're valid" is the easiest attack vector for this kind of system. Your other problem it that it's Java, basically giving the sourcecode away, but I don't see any way to remediate that. – Luc Apr 16 '13 at 08:57
  • @Dr.Ü, The license server is at the customers place (I have detailed the question related to the start evaluation and server) – Michael Apr 16 '13 at 09:04
  • @Luc, of course it is HTTPS (I have fixed the questions). Yes, it is Java. I will not be able to prevent the Java code decompilation. I want to prevent simple database manipulations – Michael Apr 16 '13 at 09:07
  • 1
    @Michael You can't change the specification so the license server is somewhere in the net and fully under your control? But i would recommend to use the servertime to set the evaluation beginning. Otherwise clients will set their time somewhere in the future and suddenly you have an expiration somewhere future + 30 days... ;-) – Dr.Ü Apr 16 '13 at 09:28
  • @Dr.Ü, Probably I will not be able to change the specification and I need to store the start evaluation time on the client. In addition I do not think that if the evaluation will expire the user will move the client time _back_. The customer needs to generate reports with the real time. Any suggestions are more than welcomed. – Michael Apr 16 '13 at 10:05
  • @Michael sorry maybe a missunderstanding... if you turn your clock forward(!) on step 6, you will get a license which expire far far far in the future + 30 days... After this, the can turn back the date and time settings and work normal with real time... – Dr.Ü Apr 16 '13 at 10:17

1 Answers1

1

You need a timestamping service. The license server should track information about the client that ensures that the same client can not request a license more than once. You can use any number of factors for this such as hard drive serial numbers, windows activation codes, etc.

When an evaluation license is issued, you can timestamp the key and have the application check against a clock to see if the license is still valid. (Use an asymmetric algorithm on the license server to sign a timestamp and the information that identifies the computer.) Note that they may still alter their local system time, so the best bet is to use an external clock. Your client then simply needs to know the public key of the license server so that it can verify the start time and computer ID for the license are valid prior to launching.

Do not rely on security through obscurity. Things like putting the values in an unmarked DB column, using symmetric encryption like AES or other such measures where the information to generate a license is stored on the client can easily be broken by doing a simple trace of the program's behavior to see what it accesses. As soon as someone comes to what looks like an AES key or a license being loaded in to memory, they will know what it is. This kind of thing is child's play for an experienced reverse engineer and will take a matter of minutes in most cases.

Instead, make sure that it doesn't do them any good to tamper with the license and deny them the ability to generate a valid license. Use asymmetric algorithms (public/private key) so that only the server knows how to generate a license and all the client knows how to do is validate it. Make sure that a time check is made against the signed timestamp in the license and that the license also contains a hard to fake identifier of the client machine so that it can't be used for more than one client. That way, copying or modifying the license is very difficult.

At that point, the most successful attacks against your system will either be reverse engineering the code to disable the license check (doing it multiple times throughout your application will make that harder) or figuring out a way to fake the client identifier checks to make multiple computers look the same (or make the computer look different so another trial license can be obtained.)

AJ Henderson
  • 41,816
  • 5
  • 63
  • 110
  • thanks! Why you see the problem if the license requested by the same client more than once? Let’s say I get the start evaluation time signed by the license server. Where should I store it? If I will store it on the client side – the customer can remove it. Also (as I have explained in the question) I do not want to store it on the server. I get to conclusion to store it in the column with the name without a meaning. For example, xyCoordinates. Do you have better suggestions? – Michael Apr 17 '13 at 10:48
  • @Michael - It doesn't matter if the client can remove the license, you can store the license anywhere. The trick is that you keep a unique identifier of the client that can not be easily changed by the client and prevents a new license being issued for that machine. Trying to hide where you store a license will not be effective because it will look like you are storing a license. In the question you said you didn't wish to store the start time on the license server. My suggestion is not doing that, it is storing a record of licenses granted which is exactly what a license server MUST store – AJ Henderson Apr 17 '13 at 12:54
  • Also, you are using symmetric algorithms, this is a horrible security issue for a license system. You are giving the client the keys to encrypt their own license. The client should never have access to the information necessary to generate a valid license. You must use asymmetric encryption, not symmetric. – AJ Henderson Apr 17 '13 at 12:56