0

We have a simple C#9/WPF app that we're releasing on .NET 5 Core on which we need to introduce licensing. From what I'm reading, one of the most common patterns to do so is asymmetric encryption, aka public/private key encryption.

From what I understand, you as the developer encrypt the customer's licensing info using a private key which only you know, save the results to a file or send it in an email to the customer. Then upon app launch, you use the public key--which you ship along with your application--to verify that no one has tampered with the license file. Makes sense.

They also always say you don't need to worry about protecting your public key because it can only be used to decrypt data generated from your private key, which you have safe and protected.

My question is... what's to stop someone from just replacing the public key stored within the app with their own?

In other words, couldn't a user use your public key to decrypt the license file, make any changes they want, then using their own public/private key set, re-encrypt it, then simply replace your public key with theirs using nothing more than a simple resource editor or binary/hex editor?

My thinking is you would also somehow have to hash your public key to ensure it hasn't been tampered with either because if you can't validate the app is using the expected public key, then that defeats the entire system.

Mark A. Donohoe
  • 103
  • 1
  • So when your app decrypts using the original key, and gets back gibberish, that should tell you something's up. –  Mar 27 '21 at 22:01
  • But that wouldn't happen because I'm asking about them replacing our public key with theirs. The only gibberish would be if they attempted to use the original license file, but they wouldn't have to as they could now generate their own any time they want with their own public/private key set. Does that make more sense? – Mark A. Donohoe Mar 27 '21 at 22:11
  • No it doesn't. I think you may have overlooked a few steps in those tutorials, or you should try to find better ones. One thing to note is that any piece of software can be reverse-engineered. –  Mar 27 '21 at 22:15
  • I'm not sure you're following what I'm asking. If you use a public key to validate data encrypted with a private key, you would also have to somehow ensure that the public key that's actually being used for this decryption is in fact yours/the correct one. If someone can easily usurp/replace your public key with the one from their own public/private set, then they can now create encrypted data files using their own private key which your app will now happily accept since it now has their public key. In other words, it's not that someone can read the public key, it's can it be replaced? – Mark A. Donohoe Mar 27 '21 at 22:20
  • So then your question is how to safeguard information in a managed assembly? –  Mar 27 '21 at 22:24
  • 2
    Yes, what you describe is a possible vector to crack your software. The question is how likely it is that someone really goes that route. Ask yourself what's the audience of you program? Could they really do such things on their own? Hiring some developers to do the job might be more expense than just paying the license. How "honest" is the audience? Most people are. Or Is the software popular enough that crackers could make money out of it on their own? I mean if they are eager enough they can also just patch any license check away... But is it likely? – sticky bit Mar 27 '21 at 22:26
  • @stickybit, all great points, and exactly what I've been thinking. Our software is definitely expensive, but the end-users are generally not computer savvy, and it is a somewhat niche market too so I think for those reasons, we're safe. The other thing is we'll be updating our software regularly, so even if they replaced the keys, we'd just re-replace them with the next update. Still... you did answer my question which was 'Is that a possible attack?' since I'm trying to understand this more. That said, mind putting this in an answer and I'll mark it as such? – Mark A. Donohoe Mar 27 '21 at 22:29
  • You're trying to keep the honest people honest, you could say, though ideally you can at least expand that group to include "script kiddies and other amateur hackers". –  Mar 27 '21 at 22:32
  • Yeah, I'm thinking some sort of simple hash against the binary that contains the public key would go a long way there too. I'd just have to work that into our build scripts. – Mark A. Donohoe Mar 27 '21 at 22:35

1 Answers1

1

Yes, what you describe is a possible vector to crack your software.

The question is how likely it is that someone really goes that route. After all the public key needs to be stored somewhere where it is accessible to the program. And if that program runs on the computers of your customers, they can potentially can access that area too and change it.

But Ask yourself:

  • What's the audience of your program? Could they really do such things on their own? Hiring some developers to do the job might be more expense than just paying the license. And they'd need to redo that for every update.

  • How "honest" is the audience? Most people are.

  • Do you offer support and is it likely users, at least occasionally, need it? Usually support is bound to a license. And if someone phones for support and you look them up and discover you haven't issued them a valid license... Call the lawyers.

  • Or is the software popular enough that crackers could make money out of it on their own?

I mean if someone's eager enough, they can also just patch any license check away... But is it likely?

sticky bit
  • 126
  • 1