views:

2480

answers:

5

There have been a few timely posts about IP security and the like, but none that I can find that specifically address an algorithm. In one of my current projects, we've decided to go the route of an offline registration key system.

I imagine most of our eventual user base will be honest, so I don't think we have too much to worry about. On the other hand, I'd rather not have the casual cracker gain access without a good deal of sweat and tears.

So, what are some options for how to generate (and verify) the key? Hardware keying is most likely out because the install model is to run from a samba share on an intranet server. Also, how long should the key be?

Secondly, how big is the danger of the verification algorithm simply being Reflected out, even if it is obfuscated? Would it be better to write the algorithm in unmanaged code instead?

A: 

You might want to take a look at the answers to this question

Rowland Shaw
+2  A: 

Typically what you want to do is pick some data that you want to include in the key like who owns it and when it expires, possibly even some small pieces of code your application needs to work properly (thus making it hard to make it work without the key). Then use a digital signature scheme like RSA to digitally sign the key with your company's private key. Distribute the public key with the application executable. Then when you load the key, just verify the signature is valid and then use the data contained in the key. A 1024 or 2048 bit key should be plenty for this.

Of course no matter how sophisticated your code is someone will always be able to break it or get around it. So the question you have to ask yourself is how difficult do you want to make it (keeping in mind more difficult schemes are harder to code and maintain for you)? There is a point of diminishing returns, usually that is pretty low. As long as the program won't work without a key, and the key is complicated enough that you can't fake one (or change the expiration date etc) with a hex editor then you are probably fine.

SoapBox
Good idea and you've got a good point about the diminishing returns bit as well. The definition of "won't work without a key" is of course subjective, but like I keep finding, these keys are more about keeping honest people honest and making it "easier" to buy than crack.
lc
+1  A: 

As far as refactoring the key out, writting it in unmanaged might not help if they kill the call site from managed to unmanaged. One option you have with obfuscation if your using Dotfuscator professional is to enable their "Tamper Detection" essentially they tag your assembly and if someone modifies you can have your code do various things. Of course the hacker can remove this but its a lot more sweat and tears.

JoshBerke
+5  A: 

In my opinion, the key problem you'll face is not with your registration algorithm and level (or lack) of obfuscation.

Rather, it's this: At some point in your code it comes down to simple binary decision - to run, or to exit. Hacking your system only requires finding and tweaking this decision point.

Everything else - obfuscation, strong signing, tamper detection - is oriented to make this more difficult, but it can't make it that much harder.

Bevan
Good point, I guess it's more aimed at keeping honest people honest - making it "easier" to buy than crack.Also maybe that's why some people try to include some functionality in the key. Not sure how, unless you make the key very long, and leaves you open to data execution attacks, though, right?
lc
+1  A: 

I've only found one way to lock down code very well. Almost every form of serial validation can be cracked easily by your average second-year programmer.

The way I've done it is to use a License object in .NET. Within my home-grown license object, it reads a "license" file to find out where "home" is. That license is an encrypted string. The private key to the string is in the License object.

The License object then calls home with a secret password, also encrypted. The server decrypts the password and validates it... also logging the IP and user name in case of fraud investigation. If the server can validate the password, it responds with a secret response, encrypted again so that it cannot be spoofed. If it cannot be validated, the connection is dropped. No response is sent, thus the License object at the other end fails.

When the integrated License object fails, it will automatically throw an exception, forcing the application to fail and exit at the point that the license is called.

It took me about two work-days to write the server and the License object, so it's a bit of a workout, but not rocket science.

If you want some sample source, or more info, let me know. I'll be glad to get you what I can.

Jerry
Like everything else, this suffers the same issues Bevan outlined. And it punishes your legitimate users by making the software 'dial home' all the time.
Nick Johnson
Very true. I'm not really a fan of dialing home, but it does have its advantages, depending on the licensing model. I'm particularly looking for solutions that don't require an internet connection, however. I don't want to lock the users into being connected every time they want to run it.
lc