So I'm trying to build a licensing server, where the licenses of the applications need to be checked when logging in or when the application gets used. But some of those application work offline most of the time, so I need to have some sort of 'caching' of the last check of the license with a date where the license should next be checked(let's say like every week). For the moment I'm storing this in the database of the application, but I need to make sure that that 'next check date' can't be changed by the user of the application.

So I came up with the following idea: When a license needs to get checked(because it has been more than a week), the server will check the license and will decide the 'next check date'. He will then encrypt that date and send it to the application which will store it in the database. Then when the application will be used, it will get that encrypted date, then decrypt it and check it. So when the application tries to encrypt a date himself, he won't be able to decrypt is because he doesn't use the same key that the server used to encrypt.

At first thought I came up with a private key on the server and public key on the application, but then it wouldn't be encryption but signing, and that would involve sending the date in clear text, which is not what I want. Or is there a way to use signing that the application can't change the date?

  • 1
    You're confusing encryption and digital signature. The first is to ensure confidentiality, the second, authenticity. – Stephane Oct 8 '15 at 8:27
  • This is a variant of DRM, can't ever be done perfectly. – Natanael Oct 8 '15 at 8:41
  • @Natanael Yeah now that I'm thinking about it, it does sound like something DRM like, though I have no idea how I should implement something like that... Any ideas? It doesn't have to be the most secure thing in the world, I just don't want users to simply go in the database and chance the date... – kev02468 Oct 8 '15 at 8:57
  • @kev02468 Don't try to invent something new. If you need license protection, use an existing product. It'll be cheaper and more resilient than trying to cook something up yourself. Also, DRM (and license protection) is very hard to get right as there are many, many ways to make it fail in a bad way (as in "customers are unsatisfied and sue you"). Every major company that tried it encountered critical issue for long period of time. Some of them never managed to get it right either. – Stephane Oct 8 '15 at 9:40

Despite your question title, you still want digital signatures, not encryption. You want something that the client can verify but not produce by itself; this is exactly what signatures are about. Trying to think about it in terms of encryption will only lead to more confusion.

The basic working of a license file is that it contains some vendor-chosen information that the vendor signed; the client uses the vendor public key to verify that the license file is genuine, then applies whatever policy is incarnated by the information in the license file. Typically, a license file would identify the customer and the allowed range of usage dates, possibly along with a unique identifier for the machine on which the software may run. The client code will then refuse to work if the current date is not in the allowed range, or if the local machine identifier does not match that what was specified in the license file.

As was pointed out, licensing can always be defeated in the case of software, because the code that enforces the license policy runs on the user's machine. If the user wants to bypass the license, he can reverse-engineer the code to simply deactivate the license check; this is about as impossible to prevent as music and video copying. Changing the local clock is the simplest form of "reverse-engineering", and even users with very little knowledge of programming can do that. If you want to enforce usage rules and licensing, then make it so that part of the code runs on your servers, not on the user's machine (but then, the software is no longer usable when offline).

  • Yes, I do realise that reverse-engineering code is an issue and if people really want, they can make the software ignore the check, I just don't want to make it them that easy. The caching though is mostly for offline usage, but not always, so when they're connected to the internet, I will try to use internet time instead of the clock. Most of the applications won't use caching though. – kev02468 Oct 8 '15 at 9:40

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.