Padlock 1.x to 2.x Migration Guide

Overview

Padlock 2.x retains Validation compatibility with the 1.x series, meaning it is able to validate licenses created with previous versions of Padlock.  This was done with the strict requirement that existing 1.x licenses in the field must be able to validate with new versions of Padlock.

What's Changed:

• Padlock now signs licenses using DSA instead of RSA.  This was done for better compatibility with non SUN JVMs.  As a result, the keys used and the crypto calls within the API are different.
• The API has been tweaked.  While the API remains similar, no effort was made to keep method signature compatibility.  Instead an effort was made (based on experiences with 1.x) to make the API as straightforward and flexible as possible.  Some classes have been removed, while others have been added.
•  New features, such as hardware locking and validator plugins.

What Will Work:

• Validating 1.x licenses in 2.x - The Validator constructor supports both 1.x and 2.x validation. This happens implicitly during instantiation.  Padlock examines the public key to determine whether it's RSA or DSA based, and will use the appropriate validation code.
• Using Plugins when validating 1.x licenses - Padlock's Validator plugins will work equally well for both 1.x and 2.x licenses.

What Won't Work:

• Validating 2.x licenses in 1.x - Padlock 1.x is not equipped to handle the DSA based licenses in Padlock 2.x
• Hardware locking - There are no provisions in the Padlock 1.x license format for hardware locking.
• Importing 1.x keys into 2.x - This means you cannot sign 1.x licenses using the 2.x API.
• Managing 1.x licenses and keys with Padlock Manager - Padlock Manager only works with Padlock 2.x keys and licenses.  You'll need to continue to manage your 1.x keys and licenses in the older Padlock UI.

Suggested Migration Path:

For those who wish to upgrade to Padlock 2.x and keep their existing 1.x licenses in place:

Generate a new public/private key pair - The new pair is DSA based, and will be used to generate new licenses as well as validate them in the field.  Hold on to your old keypair as you will still need the public key to validate the older licenses.

Embed both sets of public keys into your application - It's suggested you simply place the version 2 public key directly under version 1.  Depending on the license being validated, you'll need to pass 1 of them into the Validator's constructor.

When validating a license, take note of the license's version number - Padlock 2.0 added a new method to the License instance - getLicenseVersion(). Your License instance automatically determines the version.  1 = Padlock 1.x and 2 = Padlock 2.x.  A simple tertiary should be all that's needed to use the proper key:

private static final PUB_KEY_V1 = "0123456789abcdef......";

private static final PUB_KEY_V2 = "0123456789abcdef......";

License l;

// Import either v1 or v2 license file here

String pubKey = (l.getLicenseVersion() == 1 ? PUB_KEY_V1 : PUB_KEY_V2);

Validator v = new Validator(l, pubKey);

The Validator works identically from this point on.  It's suggested that your property naming format remain the same between the old and new licenses, simply for the sake of simplicity.

This concludes the Padlock Migration Guide.  Please direct any questions or concerns to support@padlocksoftware.net.