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)

Wasenshi
  • 3
  • 3
  • 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 02 '22 at 09: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 02 '22 at 09:33
  • @Wasenshi If your only concern is the average user, you could just save the public key in a file in a obscure location, perhaps with some extra obfuscation like encrypting the file with a hard coded key). But it takes only one person to figure it out and post a crack online, and then everyone else can bypass your protection. – nobody Apr 02 '22 at 09:38
  • @nobody That's why I would like any advice on another way of doing it. In the end, that solution still involve hardcoding the key, right? (then I'd better hardcode the public key itself, since it's simpler and more secure to prevent modification of public key, isn't that right? So any alternative that would make it hard to modify the public key, even if someone know where and what it is) – Wasenshi Apr 02 '22 at 09:47
  • @Wasenshi It's not hard once they know where it is. Then it's three lines of powershell. – vidarlo Apr 02 '22 at 09:52
  • Perhaps some way for the software to verify that the public key is not modified? – Wasenshi Apr 02 '22 at 10:00
  • 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 02 '22 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 02 '22 at 10:46
  • Edited the question. As not to be misleading from original intention: It actually not about the maintenance support, that doesn't really matter in this question. – Wasenshi Apr 02 '22 at 11:44
  • @Wasenshi Businesses usually make the lions share of the money via support, not license sales –  Apr 02 '22 at 12:45
  • 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 02 '22 at 20:12
  • What stops the end-user from manipulating the clock? – ThoriumBR Apr 04 '22 at 21:55
  • @ThoriumBR good argument. Luckily for my case, because my software is acting as a server, so they shouldn't want to manipulate the server time. – Wasenshi Apr 05 '22 at 17:28

1 Answers1

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.

foreverska
  • 1,115
  • 11