4
$\begingroup$

I have recently started looking into creating secure, while not validating against an external server, software product keys.

The idea I have had is to create a key consisting of two parts firstly a section that contains some (but not all) details of the user; for example name, customer ID and maybe a salt this would then be ecoded one way or another, say a simple base64 just to obfuscate it. The second part would be an SHA1 signature for a hash of all the user data this would be mostly the same as above but would contain the entitled software version (i.e. 1.0) and maybe something else related to the program.

The deployment of this would work by the user entering the key and the software extracting the user details from the key, appending its own credentials (version number etc.) the generating a hash a verifying the signature using this hash.

If the user key has not been tampered and the user is entitled to user that version of the software all will pass and we can proceed. If this it not the case (say the version entitlement is wrong) the signature will not match the hash. Obviously the public key has to be contained within the software to verify the signature but at no point does the user have the entire hash.

I was discussing this with a friend who said they thought this would be inherently poor as the user could poke through the program find out how the key system works and then, given the structure and the public key generate any number of license keys that would appear valid, as they would control the signature to match the software generated hash of 'fake' credentials.

Is this really that easy to crack surely even if the user did create a hash of some fake details and ID number they could not generate a valid signature to match this? Sorry the question has ended up being much longer than I intended; i wasn't sure how to be clear shorter. I hope this all makes sense.

Improve this question
$\endgroup$
4
  • 2
    $\begingroup$ It's usually even simpler: most "stand-alone software" validation can be defeated by simply hooking into whatever code does the key validation, and replacing it by "this key is valid" (regardless of the key, of course). Unless said key is going to be used at some subsequent point in the program (e.g. as some authentication token for interaction with some remote server), that's it - you've "cracked" the software product, without even caring what validation mechanism was involved. I think you need to detail your specific requirements a bit more. $\endgroup$
    – Thomas
    Commented Sep 20, 2013 at 11:28
  • 1
    $\begingroup$ (note this is why most hardcore modern DRM is done through user accounts and remote validation and, for ultimate control, remote content distribution) $\endgroup$
    – Thomas
    Commented Sep 20, 2013 at 11:31
  • 2
    $\begingroup$ This is a better fit for Sec.SE $\endgroup$
    – rath
    Commented Sep 20, 2013 at 11:55
  • 1
    $\begingroup$ On Security.SE, I expect most answers to deal with the ease at which the program can be patched to jump over the check. $\endgroup$
    – Hendrik Brummermann
    Commented Sep 20, 2013 at 12:58

1 Answer 1

Reset to default
6
$\begingroup$

You're somewhat on the right track. A standard way to do this would be using an RSA sign/verify scheme.

On the server, user-specific and license-specific data is concatenated into a string and signed with the private key.

In the software, the signature is verified with the public key. The public key can not be used to create valid signatures, it can only verify them (this is the beauty of asymmetric cryptography).

Of course, as pointed out by Thomas, there's nothing to stop someone decompiling your software and modifying the source code, but that can't be avoided.

If you're going to use RSA, be sure to use a secure padding scheme like RSA-PSS.

Improve this answer
$\endgroup$
2
  • $\begingroup$ Hunter, thanks that's pretty much exactly what I had in mind, all be it with slightly different semantics. I'm a bit new to the whole cryptography realm in this sense. So am I right in the assertion that a it would be impossible to generate a valid signature (short of brute forcing) for a set of generated user-specific data (lets assume they can allows guess the license-specific data)? I realise that there is always a vulnerability to the code being decompiled and patched. $\endgroup$
    – MindStormer
    Commented Sep 20, 2013 at 12:39
  • $\begingroup$ @user8534 - I wouldn't go so far as to say it's impossible, but if you use a 2048+ bit key, it's a pretty safe bet. $\endgroup$
    – hunter
    Commented Sep 20, 2013 at 12:58

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.