Is embedding the public key in client apps a bad idea?

I’m distributing a binary application (runs offline) to my customers and I give them license codes (created offline) as JWT tokens, signed with ES256. To verify the signature, I embed the public pair of the signing key in the binary itself.

Here’s the problem:
Even when inspected with simple utilities like strings, the executable discloses the public key, which in turn can be tampered using tools like sed. So an attacker can replace the public key with their own. Later they can generate their own tokens with their private keys using/editing the original payload of the original license code. When the app sees the token, it will happily accept the input as the verifier key inside is spoofed.

Really, what should I do in this current case?

Some friend suggested me to have a look at Diffie-Hellman Key Exchange, which I know nothing about, and let the client generate (what?) a key. I need an elaboration on this.

When you’re distributing the full application you’re basically entering an arms race against the possibility of someone using your app when they should not; you may look into DRM (Digital rights management - Wikipedia), but I’m afraid this is mostly out of scope for the Auth0 service.

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.