My name is Kenneth and I write cool Mac and iPhone software. This is my personal weblog where I post about stuff I find interesting. I usually write about Mac development, the business of shareware and the Mac community in general.

[NSBlog date:@"6 April 2008"].comments = 7;

One challenge that most developers face when nearing release of their first application is how to implement registration and piracy protection. This three-part article will describe three common types of registration schemes: Serial Numbers, Asymmetrical Cryptographic Keys and Product Activation.

Part Two: Asymmetrical Cryptography

Asymmetrical Cryptographic Keys are a great way to secure you app, because the code used to generate serials is not included in your app, thus removing the risk of a keygen. Using a private key, you sign (or encrypt) some of the user’s details. You then use this singed data as the key to your software, either in the form of a serial, a file, or even an image with the data embedded. You then verify that the signature is valid using the public key in your app.

Example

Start off by generating a set of private and public RSA keys. You can do this by using the following in Terminal.app:

openssl genrsa -out private.pem 2048 openssl rsa -in private.pem -out public.pem -outform PEM -pubout

You can use different size keys. Using a shorter key, such as 512 will make your software more vulnerable to brute-force attack, but has the advantage of making the signature smaller (Which is useful if you wish to display it in the form of a Serial Number).

I believe I used the following set of keys. The keys are also included as files in the source code of this example (available at the bottom of this article).

Next, we will create the generator. We will start by concatenating the details (full name and email address) into a single string:

First Last+email@address.com

Then, we will use RSA to sign this string using the private key generated above:

lFZpwJ6GPLXz8sDez033RIxJsN072lOEa0qF+8hQ5KCcZEPQqSBU4MKbW+UJxIfSmKMOBYnVfy/wwAoSxTtqn2JIuAPEJvsTlb0mGH5u7mpxH+FDj2TicoBKephWv7UXP9k10OPA45247+j/u4yKT1UZcq7WjChQ3JoE3wBtEoFucQm8vLk/VqvNaBM1TyNEgwT8FmrKlbK1FNUI8nQ0QOEJ9P8oMAblkWE5kALZZqWnAs6xE7c73sex73t5FvxYRqRDzRDzkjTwK0anXCv8dmeLvnaaHAFcfD5llx09oa89q+wzWucE7V1TsPRYKH1sZsSz5G2xTt2pZrjIoTw5ew==

Note: for this sample app, I explicitly turned off creating newlines in the base64 signature.

The code used for this generator is:

-(IBAction)generate:(id)sender
{
    NSData *privateKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"private" ofType:@"pem"]]];
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData privateKey:privateKeyData];
    [crypto setClearTextWithString:details];

    NSData *signedTextData = [crypto sign];
    NSString *string = [signedTextData encodeBase64WithNewlines:NO];

    [serial setStringValue:string];

    [crypto release];
}

As you can see, I used Septicus Software’s great SSCrypto framework for this task… It makes things so much easier… Unfortunately it doesn’t support base32 or DSA, which would both have helped make more human-friendly keys.

The other piece needed is the validator, used in your software to validate serial numbers. Include only the public key in your app, and use RSA to verify the key.

-(IBAction)validate:(id)sender
{
    NSData *publicKeyData = [NSData dataWithContentsOfURL:[NSURL fileURLWithPath:[[NSBundle mainBundle] pathForResource:@"public" ofType:@"pem"]]];
    NSString *details = [NSString stringWithFormat:@"%@+%@", [name stringValue], [email stringValue]];
    NSData *number = [[[serial stringValue] dataUsingEncoding:NSUTF8StringEncoding] decodeBase64WithNewLines:NO];

    SSCrypto *crypto = [[SSCrypto alloc] initWithPublicKey:publicKeyData];
    [crypto setCipherText:number];

    [crypto verify];

    if([[crypto clearTextAsString] isEqualToString:details])
        NSRunAlertPanel(@"Result", @"Good serial!", @"OK", nil, nil);
    else
        NSRunAlertPanel(@"Result", @"Wrong serial!", @"OK", nil, nil);

    [crypto release];
}

Important Note: In this sample code, I included both the generator and the validator in the same application. I included the private.pem file in the bundle. You should never do this. If the private key is ever leaked, it compromises the whole security of your application.

Making it safer

You can easily make it more secure by combining this technique with the technique explained in Part One. Instead of simple concatenating the details as I did here, you could use all the techniques applied in Part One, such as using a hash instead, or doing ROT13 on it, or rearranging the order of the characters.

Another thing you should do is to hardcode and obfuscate your public key. Having it as a file in the bundle makes you vulnerable to key substitution. (Basically, a cracker would replace the public key in your app by a different key they created using a private key they know, thus making their licenses valid instead of yours.)

Form Factors

While you may not realize it at first sight, this has become one of the most common methods in Mac shareware, thanks to the open-source framework AquaticPrime. AquaticPrime uses this technique behind the scenes, by embedding the signature in a plist file. AquaticPrime is a very easy way to use this. Unfortunately, if you decide to use AquaticPrime.framework in your app, it is very easy to replace the .framework file with a malicious one that will always claim your licenses are valid.

To date, as far as I know, there isn’t any HackuaticPrime.framework yet, but this might one day become a problem with AquaticPrime gaining popularity thanks to it’s extreme simplicity of implementation.

Update: Devon in the comments suggests implementing a hash check of the framework, which is a simple way of checking the framework’s integrity. Of course, there are still ways to get around it, but this makes it one step more difficult.

Another common form factor for Asymmetrical Cryptographic Keys is custom URL schemes. That’s actually a very clever and convenient way of doing it. To register, the users get to simple click on a link which looks like this: (All the user sees is a nice “Click here to register” link)

myapp://name:email:key

Another clever, but controversial form factor is Agile Web Solution’s 1Password License “Cards”.

And of course, if you find a way to make short base32 signatures (I hear DSA makes short signatures), you can even use longer Serial Numbers.

AHJ53-5HGJZ-8DG8R-284DF-56FJB-74FH4-FJUEH

Sample Code

The code used in this article can be downloaded here.
As always, licensed under MIT license. If you do use it, mention it in the About Box or readme.txt.

Part One: Serial Numbers
The next part will be coming soon.

Registration Schemes: Serial Numbers

[NSBlog date:@"3 April 2008"].comments = 7;

Part One: Serial Numbers

Serial numbers are the simplest, most practical option. However, they are also the least secure. It consists of taking at least one of the customers’ details, and creating a serial number from it. The serial number is usually tied to either the customer’s name, or his email address, preferably both.

For example, let’s say the customer’s name “First Last” and his email address is “email@address.com”. The first step would be to strip his name and email address of any non-alphabetical characters, concatenate it and convert it to uppercase. (I put the email address first, because it’s less recognizable) Here’s what we get:

EMAILADDRESSCOMFIRSTLAST

Now map this string onto a XXXX-XXXX-XXXX-XXXX-XXXX key. If there are any character leftovers, just discard them. If there aren’t enough characters to fill all the Xs in, leave them as something constant. (they don’t have to be all the same, but they have to be the same for each position all the time. You could for example say you’re mapping it onto an QRST-ABCD-IJLK-EFGH-MNOP key, and leave unfilled spaces as is)

EMAI-LADD-RESS-COMF-IRST

Then, we’d apply ROT13 on it.

RZNV-YNQQ-ERFF-PBZS-VEFG

Lastly, we could replace any swearwords in the key by some random other constant text, just in case.

Another example, using a similar method: Using the same customer, here’s what we’d do. Take his details, concatenate and salt them:

First Last+random salt+email@address.com

Then, MD5 the result and add another salt:

salt+0fb61d4a0f894c63d3ddbd8388404b6c

Next, SHA1 the result:

28a8275bdcbca542f567efef9cc4db2150c38900

And finally, uppercase it and map it onto a XXXX-XXXX-XXXX-XXXX-XXXX serial:

28A8-275B-DCBC-A542-F567

When you have decided on a serial scheme, implementing it is easy. Upon registration, you take the buyer’s name and email address, and generate a serial from it. He then has to input this serial into you app, along with his name and email address. All you have to do in you app is take the name and email address he gave you, generate a serial from it, and check it against the serial he gave you.

Making it more secure

For security reasons, one important step to take is obfuscating how you create those serials, in case anyone tries to create a keygen for you app. The easiest way is adding dummy maths code in the middle of the code where you work out your serial. It will not affect your serial, but it will show up in the assembly code in case anyone tries to gdb your app (more on that in another blog post I have planned).

Another quick thing you could do is shuffle the characters a bit on a set pattern to make them less obvious.

For example you could use this pattern:

ABCD-EFGH-IJKL-MNOP-QRST

becomes

TMLN-DQGA-ISPC-BEOK-FJRH

Stand-alone serials

Sometimes, your serials cannot be tied to any of the customer’s data, for example for retail sales. In that case, you’d need a different serial scheme. You need to choose certain characteristics / rules that make a serial valid. It could be as simple as checking that the 19th character is a W.

Here’s a set of example rules you could use:

The ASCII value of the first character of all five blocks of four characters have to add up to 100.
The last character of all five blocks of four characters have to be vowels.
The first character of either block 3 or 4 has to be E.
The ASCII value to the third character of every block have to be even numbers.

In your apps, just check the serial against the rules, and if it’s correct, you can assume it is a correct serial.

For your generator, you can have a pre-made list of valid serials, and assign them to a customer or print them on a retail copy when needed. The problem with this method is that you can eventually run out of valid serials. In which case you would have to generate a new batch of serials, or reassign already used serials to a second customer.

Another (better) way of doing stand-alone serial numbers is splitting the serial number in two, and basing the second part on the first part. [thanks to tomasf from the #macsb IRC channel for this method]

For example, in a serial number ABCD-EFGH-D07A-A959-F269, separate the first eight characters from the rest of the serial:

ABCDEFGH

Salt it:

saltyABCDEFGH+123

MD5:

d07aa959f269104ab28e2a748c415c5c

Map it onto XXXX-XXXX-XXXX:

D07A-A959-F269

And check it against the second part of the serial. In this example, the serial is correct.

Part Two: Asymmetrical Cryptographic Keys
The last parts will be coming soon.

PhotoMate released!

[NSBlog date:@"1 April 2008"].comments = 0;

For the past eight months, I have been hard at work on my newest and hottest project, PhotoMate.

Today is a big day for me, as it marks the release of PhotoMate to the public.

OmniDelicious PhotoMate is a new, professional application aimed to replace application such as TextMate, Pixelmator, or Adobe Photoshop. It provides an elegant all-in-one interface that is second to none in ease of use.

Check out brand new PhotoMate at omnidelicious.info.

Update: As I’m sure most of you figured out, this was an April Fool!