4 ms·

Generating Cryptographically Secure License Keys in 2021

14 points by ezekg 5y ago

imdev0 5y ago
And these are the facts: 1. The new version of the application no longer verifies the 0th subkey. 2. The new version of the application now verifies the 1st subkey. 3. The 1st subkey is located at indices 10 and 11: 0000-0000-00XX-0000-0000. 4. We possess the parameters to generate a valid 1st subkey: 10, 0, 56. See a pattern? Oddly, this gave me goosebumps. Very well written. I was happy to see Ed25519.
- ezekg 5y ago
  Appreciate it. I'm a big fan of Ed25519 as well.
ezekg 5y ago
Author here. I've been working on this post for about a week now, excited to share it with HN. Let me know your thoughts.
- deleted 5y ago
  [deleted]
BugsJustFindMe 5y ago
The entire premise presented here becomes moot if the software connects to the internet for key verification which has been a viable option for decades now as OP well knows because their entire business is being that server (and the service looks very tempting tbh). A system that requires keys to not only be algorithmically valid but also pre-registered at time of purchase with a central authority (buy online and we'll email you your key) makes key generators implausible, because you don't just need to generate something that matches the algorithm, you need to hit an exact target from a set of keys that happen to currently exist in a presumably secured central database of customer keys. At that point the kind of key you use is completely irrelevant, because algorithmic generation of valid keys is meaningless when faced with pinpointing which of umpty gazillion key possibilities actually exist in a remote database before the server cuts off your access for spamming invalid keys or for providing a key that 10000 other people have also provided. You could concatenate a few calls to rand() for all it matters then. Also, this comparison is flawed: > "It's also worth mentioning that keygens are much more valuable to bad actors than cracks, because a keygen can be used on the real application, vs the bad actor having to distribute a modified, cracked version of the application." You don't have to distribute the cracked application. You can distribute the binary patching tool which also can be used on the real application. (What does "real" mean here anyway?) A keygen is only more valuable if applying the binary patch is harder than discovering the key algorithm across version updates. I guess this is where OS application certificates have to step in. Hurray for our code-signing gatekeeper overlords.
- ezekg 5y ago
  > Anyway, the entire premise presented here becomes bogus if the software connects to the internet for key verification which has been a viable option for decades now. This would seem true to most people, and I had the same assumption over 5 years ago when I started Keygen. But you would surprised at how many software vendors, and end-users, do not consider an online-only licensing system a viable option. Take Sublime Text -- as far as I know, they do not use a licensing server that "calls home" (I'd bet their user base revolt against such a thing.) There is a sizeable portion of my customer base that rarely even uses the API -- they use Keygen to generate signed offline-first license keys which they distribute to end-users. They only use the API for customer support and reporting purposes. I like having the best of both worlds -- an online-first, offline-capable licensing system. But to be offline-capable, your key algorithm has to be secure, otherwise bad actors will just go offline to avoid the part of your system that works.
  - BugsJustFindMe 5y ago
    And I think your service looks very good, but the barrier that fancy keys provides vs unfancy keys is against the subset of pirates in an adamantly-offline-only community who don't want to modify their executables. It's not an entirely trivial difference, but it's also not really mentioned in the blog post.
    - ezekg 5y ago
      Appreciate the kind words. The blog post is on generating cryptographically secure license keys (focused on offline-only), so discussing anything else would have been off-topic. Perhaps I'll cover it in another post. But regardless, the API supports generating more typical, or unfancy, license key formats, e.g. XXXX-XXXX-XXXX-XXXX, but those are online-only.
no_time 5y ago
Would be a real shame if someone used mitmproxy modify the validation request in transit. Looking at one of the provided examples [0] it does not have any mention of certificate pinning. With all due respect this service seems to alleviate the most simple to implement parts of a licensing scheme while not solving the actually challenging parts. Even combined with a sophisticated obfuscating tool it leaves a lot of holes to be filled by the end user. [0]: https://github.com/keygen-sh/example-cpp-license-validation https://github.com/keygen-sh/example-cpp-license-validation Edit:I guess this is slightly offtopic since the article talks about the offline activation method not the online one.
- ezekg 5y ago
  You can use request signatures to combat MITM attacks quite easily. Certificate pinning is not really needed. All requests are signed the same way license keys are, so without a crack to change the embedded public key, forging a request is essentially impossible. That particular C++ example does not include signature verification, but there is another example repo [0] for that. [0]: https://github.com/keygen-sh/example-cpp-request-signature-verification https://github.com/keygen-sh/example-cpp-request-signature-v...
  - no_time 5y ago
    From a cursory glance that version while better, looks vulnerable to replay attacks since I don't see any mention of timestamps or MAC Of course this requires the attacker to purchase at least one license so its a partial victory :^)
    - ezekg 5y ago
      The response body itself for key requests, such as for license validations, contains a timestamp to prevent replay attacks. You can also send nonces, which will be echoed back. :) But it is worth mentioning -- I am working on improving the request signature header to include more info such as current token and date. Just need to finish some other stuff on the roadmap first.

14 points by ezekg 5y ago

And these are the facts: 1. The new version of the application no longer verifies the 0th subkey. 2. The new version of the application now verifies the 1st subkey. 3. The 1st subkey is located at indices 10 and 11: 0000-0000-00XX-0000-0000. 4. We possess the parameters to generate a valid 1st subkey: 10, 0, 56. See a pattern? Oddly, this gave me goosebumps. Very well written. I was happy to see Ed25519.

ezekg 5y ago
Appreciate it. I'm a big fan of Ed25519 as well.

ezekg 5y ago

Author here. I've been working on this post for about a week now, excited to share it with HN. Let me know your thoughts.

deleted 5y ago
[deleted]

BugsJustFindMe 5y ago

The entire premise presented here becomes moot if the software connects to the internet for key verification which has been a viable option for decades now as OP well knows because their entire business is being that server (and the service looks very tempting tbh). A system that requires keys to not only be algorithmically valid but also pre-registered at time of purchase with a central authority (buy online and we'll email you your key) makes key generators implausible, because you don't just need to generate something that matches the algorithm, you need to hit an exact target from a set of keys that happen to currently exist in a presumably secured central database of customer keys. At that point the kind of key you use is completely irrelevant, because algorithmic generation of valid keys is meaningless when faced with pinpointing which of umpty gazillion key possibilities actually exist in a remote database before the server cuts off your access for spamming invalid keys or for providing a key that 10000 other people have also provided. You could concatenate a few calls to rand() for all it matters then. Also, this comparison is flawed: > "It's also worth mentioning that keygens are much more valuable to bad actors than cracks, because a keygen can be used on the real application, vs the bad actor having to distribute a modified, cracked version of the application." You don't have to distribute the cracked application. You can distribute the binary patching tool which also can be used on the real application. (What does "real" mean here anyway?) A keygen is only more valuable if applying the binary patch is harder than discovering the key algorithm across version updates. I guess this is where OS application certificates have to step in. Hurray for our code-signing gatekeeper overlords.

ezekg 5y ago
> Anyway, the entire premise presented here becomes bogus if the software connects to the internet for key verification which has been a viable option for decades now. This would seem true to most people, and I had the same assumption over 5 years ago when I started Keygen. But you would surprised at how many software vendors, and end-users, do not consider an online-only licensing system a viable option. Take Sublime Text -- as far as I know, they do not use a licensing server that "calls home" (I'd bet their user base revolt against such a thing.) There is a sizeable portion of my customer base that rarely even uses the API -- they use Keygen to generate signed offline-first license keys which they distribute to end-users. They only use the API for customer support and reporting purposes. I like having the best of both worlds -- an online-first, offline-capable licensing system. But to be offline-capable, your key algorithm has to be secure, otherwise bad actors will just go offline to avoid the part of your system that works.
- BugsJustFindMe 5y ago
  And I think your service looks very good, but the barrier that fancy keys provides vs unfancy keys is against the subset of pirates in an adamantly-offline-only community who don't want to modify their executables. It's not an entirely trivial difference, but it's also not really mentioned in the blog post.
  - ezekg 5y ago
    Appreciate the kind words. The blog post is on generating cryptographically secure license keys (focused on offline-only), so discussing anything else would have been off-topic. Perhaps I'll cover it in another post. But regardless, the API supports generating more typical, or unfancy, license key formats, e.g. XXXX-XXXX-XXXX-XXXX, but those are online-only.

no_time 5y ago

Would be a real shame if someone used mitmproxy modify the validation request in transit. Looking at one of the provided examples [0] it does not have any mention of certificate pinning. With all due respect this service seems to alleviate the most simple to implement parts of a licensing scheme while not solving the actually challenging parts. Even combined with a sophisticated obfuscating tool it leaves a lot of holes to be filled by the end user. [0]: https://github.com/keygen-sh/example-cpp-license-validation https://github.com/keygen-sh/example-cpp-license-validation Edit:I guess this is slightly offtopic since the article talks about the offline activation method not the online one.

ezekg 5y ago
You can use request signatures to combat MITM attacks quite easily. Certificate pinning is not really needed. All requests are signed the same way license keys are, so without a crack to change the embedded public key, forging a request is essentially impossible. That particular C++ example does not include signature verification, but there is another example repo [0] for that. [0]: https://github.com/keygen-sh/example-cpp-request-signature-verification https://github.com/keygen-sh/example-cpp-request-signature-v...
- no_time 5y ago
  From a cursory glance that version while better, looks vulnerable to replay attacks since I don't see any mention of timestamps or MAC Of course this requires the attacker to purchase at least one license so its a partial victory :^)
  - ezekg 5y ago
    The response body itself for key requests, such as for license validations, contains a timestamp to prevent replay attacks. You can also send nonces, which will be echoed back. :) But it is worth mentioning -- I am working on improving the request signature header to include more info such as current token and date. Just need to finish some other stuff on the roadmap first.