0

Suppose I have a software which I sell to customer to use. I want to include a license that will be expired in let's say 1 year, so that customer need to renew their package.

I want to prevent the user (customer) from trying to bypass the expiration, so I decide to use a digital signature to protect the expiration date information where I keep the private key to myself only, and need to distribute the public key and expiration date along with the software.

But how can I store the public key with the software other than hardcoding it? Given that I only concern that they should not be able to modify the public key. It does not matter if they can read public key or the expiration date, only they must not be able to bypass or change that expiration date.

Sure I can hardcode the public key, but it sounds like a bad option. (and since I also need to replace the license for them from time to time, so hardcoding mean I may need to re-compile the whole software)

Improve this question
13
  • 7
    In short: you can't. You can make it more or less difficult, but as long as the user can execute the software in their own environment, on a normal computer, they can remove or change the validation routine.
    – vidarlo
    Apr 2, 2022 at 9:16
  • yes, I'm aware that, ultimately, someone would be able to break it anyway. But if I say, I want to make it just difficult enough that average user would just rather pay for it, how should I do it? (by average user, I mean any average computer user or user that have only up to basic level of programming/cracking)
    – Wasenshi
    Apr 2, 2022 at 9:33
  • 4
    Why does the software care for support maintainance expiry? If the customer comes to you with a support request, just check whether his contract is active or not.
    – Haukinger
    Apr 2, 2022 at 10:19
  • 1
    I'm not sure if I understand your question, probably due to missing context of how the "maintenance support" you offer works. I don't understand why you need to have the authoritative information of when the maintenance expires on the customer site in the first place. From my understanding it should be enough if you (not the customer) has access to this authoritative information when you are actually doing support, so it is sufficient that the authoritative information is kept by you.
    – Steffen Ullrich
    Apr 2, 2022 at 10:46
  • 1
    I see one mistake in your question: you write about the public key but you mean the signature. In the end you need three parts, the public key, the signature and the data with the expiration date that is covered by the signature. The public key does not change so hard-working it into the executable is not a problem.
    – Robert
    Apr 2, 2022 at 20:12

1 Answer 1

Reset to default
0

Hard code the public key of a root certificate. Then key material used to sign licenses can be chained back to the root certificate. What this buys you:

  • The root key should not change very often so programs need not be recompiled very often.
  • The application can determine that the public key used to sign the license is valid (by verifying the chain).
  • The license signing certificate can be changed if it is ever leaked, just chain the new certificate to the root.

If the customer is smart enough to find the public key of the root in the binary and change that, you're back to square zero. But I get the impression from the comments that this may be just beyond what you're worried about.

Another option I've discussed with clients who insist on offline DRM is USB keys. Good ones are not dead easy to circumvent or copy.

Improve this answer
1
  • That's a good enough solution. A straight answer to the question.
    – Wasenshi
    Apr 5, 2022 at 17:24

Not the answer you're looking for? Browse other questions tagged .