3 ms·
I think you can solve this with public key cryptography, your public key ships with the program. Then you sign (HMAC) something unique to the user (such as ema
by eterm 5y ago
I think you can solve this with public key cryptography, your public key ships with the program.
Then you sign (HMAC) something unique to the user (such as email address) along with an expiry date.
That signed message becomes the 'key' they enter.
The software validates the message at the same time as parsing out their email address and the key expiry date from the message.
This doesn't require any phoning home.
This doesn't stop multiple use unless you start requiring an initial phone home where hardware IDs are provided and incorporated into the hashed+signed message. That only requires phoning home once and doesn't need phoning home every start.
- g_p 5y agoYou shouldn't use an HMAC here, since that's symmetric and the key sits inside the app. You should use public key crypto as you suggested - sign the serialised per-user information (technically you generally sign the hash of it, but don't roll your own crypto, use a proven library), and give the user that signature (along with the message that's signed) as a "license file". Patching this requires modifying every future version of the software, since it isn't feasible for most people to generate a false licence. You could include a maximum version field in the licence, or an expiry date (which relies on the user's local clock, but could also check against the time of a given build as a sanity check).
- eterm 5y agoThanks for the correction, I didn't realise HMAC was only symmetric and thought it generally covered signing of hashed messages.