Licensing and Piracy

Licensing

No licensing or anti-piracy method is ever going to be 100% effective. In designing or choosing a licensing system, its important to keep your paying customers at the forefront of every decision you make.

It may be heresy to say so- but it really doesn't matter if someone manages to break the anti-piracy measures on your software. So- they got a free copy of the software? But they were never going to buy it anyway, there's no hit to your bottom line. And on the scale most of us micro-ISVers work on, no-one's going to take the effort to distribute cracked versions all over the internet, you're not going to lose any paying customers as a result.

My requirements for the licensing in Cancellation Checker were pretty clear:

1. Must support a trial mode with limited functionality.
2. Strong preference for client-side checking of license - unreachable activation servers can cause a lot of heartache and annoyance.
3. Activation code linked to driving license number (a unique value for a specific user). This means that having bought the software, they can't use it to find their friends or siblings tests using the same activation code.
4. Activation code should not be limited to one machine, one install or in any other way.
5. It should be free- when I went live, I had no idea if I'd even sell one copy of the software, so paying for a licensing system was not an option I wanted to consider.

I settled on using a reversal of the normal public/private key encryption scenario:

Normally when Tom wants to send Dick a private message, he can encrypt it using Dick's public (shared) key. This message can then only be decrypted with the use of Dick's private key, which only Dick has access to.

Our scenario is a little different though:

I wanted to sign someone's driving license number using a private key. This would then be verified using my public key inside Cancellation Checker, and checked against the driving license number they enter into the application

This is a bit similar to signing your dll's with a snk file - its a way of ensuring that the activation code came from us and not from anyone else.

How to do it:

.NET has some pretty powerful classes built in to deal with these scenarios- unfortunately they are not suitable for use in server side shared hosting environments as they would compromise the server's private keys- try to use them and you'll just see permissions errors.

I found the solution here:

http://www.codeproject.com/KB/security/EZRSA.aspx?fid=473703&df=90&mpp=25&noise=3&sort=Position&view=Quick&select=2292015

public static string Sign(string plaintext)

{

ASCIIEncoding ByteConverter = new ASCIIEncoding();

byte[] sign_this = ByteConverter.GetBytes(plaintext);

AlpineSoft.EZRSA csp = new AlpineSoft.EZRSA(512);

csp.GenerateKeyPair(17);

csp.FromXmlString(GetPrivateKeyFileString());

byte[] sign = csp.SignData(sign_this, new SHA1CryptoServiceProvider());

return Convert.ToBase64String(sign);

}

Using the AlpineSoft dll, the code is really very simple as you can see above. Then on the client side we just:

public static bool Validate(string plaintext, byte[] sign)

{

ASCIIEncoding ByteConverter = new ASCIIEncoding();

byte[] validate_this = ByteConverter.GetBytes(plaintext);

AlpineSoft.EZRSA csp = new AlpineSoft.EZRSA(512);

csp.FromXmlString(GetPublicKeyFileString());

bool valid = csp.VerifyData(validate_this, new SHA1CryptoServiceProvider(), sign);

return valid;

}

The beauty of this approach is that a user is uniquely identified by their driving license number, and this number is an integral part of the workings of the software. So, everyone in the UK has an activation code that is unique to them.

So far- I've had no complaints, but I'd be interested to hear what approach other micro-ISVers take to protecting their software