Click to go to home page

What Was New In EasyLicenser 2.0


Preface

New Features

Support For Orion Network License Server

Enhanced Protection From Library Spoofing

Enhanced Protection From Cloning Keys

Built-in Protection From Key Use Across Products

Built-in Secure State Management

Improvements To The eCommerce API Usability

Improvements To The Runtime API Usability

Miscellaneous Security And Usability Enhancements

Compatibility Considerations

Compatibility Of Product Definitions

Key Compatibility

Runtime Library API Compatibility

Changes To Product Packaging

Utility Programs

Additional Demo Applications

Packaging For C/C++ Platform Support

Next Steps


Preface

The purpose of this document is to describe the new features that were introduced in the previous EasyLicenser 2.0 release, their benefits, how to use them, and where to look for detailed information. Target audience: existing EasyLicenser 1.1 users and developers upgrading to 2.5. The EasyLicenser 1.1 users should additionally review the What's New In EasyLicenser 2.5 document for information on new features introduced in EasyLicenser 2.5.

New Features

The key themes behind the new features that were introduced in EasyLicenser 2.0 are:

Support For Orion Network License Server

A new Floating license type is introduced under the User license model. When this license type is selected in the main license manager screen, you can add parameters (or accept default parameters) that are pertinent to Orion via a dialog box that is presented for the purpose.

License keys that are generated for Orion can have a special set of Orion-specific options defined for them. Rather than requiring you to manually enter the fairly long list of Orion parameters, the product creation screen is enhanced so that a product can be enabled for use with Orion at the push of a button.

License unit consumption for floating licenses is different from user and server licensing. For specific details, please refer to the EasyLicenser datasheet and web site.

License keys that are generated for Orion are published as usual and made available to an Orion administrator for inputting into the Orion system. The license keys are not intended for use by an EasyLicenser-enabled application.

In order to enable this functionality, you'll need to obtain EasyLicenser Pro keys from Agilis that are floating-license capable. Such keys can be used to recharge an evaluation edition of EasyLicenser 2.0 or an existing floating-license-enabled production edition of EasyLicenser Pro 2.0, but can't be used to add to an installation that was directly or indirectly derived from an EasyLicenser 1.1 key, or with an EasyLicenser 2.0 installation having an EasyLicenser Pro 2.0 key that is not floating-license-enabled.

Enhanced Protection From Library Spoofing

The EasyLicenser run time libraries can be digitally signed by you at your development site (or alternatively you may use the signatures distributed by Agilis), so your applications can securely verify their authenticity and integrity based on public key encrypted versions of the libraries' ISV-specific signatures and a secret password provided by you at the time of generating the signature.

If a rogue programmer reverse-engineers and alters the run time library or replaces it with a trojan horse, the digital signature checking mechanism will detect this by recomputing the signature of the actual run time library and comparing it with the expected signature such that the signature and encryption mechanisms themselves are secure from spoofing.

Digital signatures are platform and language specific. For example, a signature that is generated for a Java run time library can only be used with the Java library, and a C++ Windows run time library's signature cannot be used with a C++ Linux run time library.

For Java, digital signatures impact your configuration: they require that your classpath definition include not just the run time library but the directory that contains it. On Windows, there is another important constraint that applies to using digital signatures with the Java run time library: unless you specify a library name qualified by a path specifier, the directory path leading to the run time library should not contain whitespace characters.

Enhanced Protection From Cloning Keys

Previously, it was necessary to follow guidelines and write code in order to protect your generated keys from being cloned by programming-savvy customers: at the time of key generation, you needed to encrypt information that was a function of the customer-specific installation, a shared secret between your application, your key generator and your custom key handler, and a value that was a function of the time of key generation, and save the information in the custom key. At run time, your application's custom key handler needed to be able to decrypt this embedded information and match its contents with the run time environment. A customer was therefore prevented from using EasyLicenser to make cloned keys because they would not be able to view the contents of the custom key in order to produce equivalent content for a different machine at a different point in time.

EasyLicenser 2.0 eliminates this programming and at the same time enhances the level of security through the use of public key cryptography and access-controlled keys. At the time of key generation, the custom key, custom cookie and product option values are automatically encrypted by the key generation run time library with a private key that is derived from a secret password that you associate with your product and which you do not divulge outside your engineering organization. Correspondingly, the license manager provides you with the equivalent public key, which is what you embed in your application and also keep secret. At run time, your application uses a new license key checking API that also accepts a product name and the application password's public key. The reason for the product name is covered below; the application password public key is also used to decrypt the custom key, custom cookie and product options to produce the original values.

The process sounds more complicated than it really is: from your perspective, you define a password for your product, take the public key that is fed back to you, and embed it into your application to pass into the license key checking API call.

In order to be able to clone the contents of a key that contains machine specific parameters such as an Ethernet MAC address, it is necessary to first be able to view the contents in cleartext. In order to be able to view the product options or custom fields, it is necessary for a customer to know the application password public key. If for some reason the public key is obtained by the programmer-customer (for example by doing a Unix "strings" on your binary and making educated guesses), all he can do is to view the contents of the key. In order to use EasyLicenser to generate clone keys, he'd still need to know the original application password secret key which is not embedded in your application.

Built-in Protection From Key Use Across Products

Previously, it was necessary to add and check for a product name as an option or custom key value in order to prevent a customer from using keys generated for unrelated products with your product, if your keys did not contain other unique characteristics that differentiated them from keys used with other products.

Since EasyLicenser 2.0's new API's accept a product name and an application password as additional arguments to generate access-controlled keys, your application will automatically only accept keys generated for that combination of product and password.

Built-in Secure State Management

Previously, it was the application developer's responsibility to manage and securely save any application state pertaining to license management such as metered consumption to date.

Beginning with EasyLicenser 2.0, the secure license key check API is enhanced to automatically and securely manage metered consumption as well as arbitrary application-defined state information in its encrypted key cookie. The mechanism also tracks use counts for keys that are not quota limited. The only responsibility of the application is to manage the storage and retrieval of the key cookie in an application-specific persistent store such as a registry, file or database according to the application requirements and operating environment.

Improvements To The eCommerce API Usability

Prior to this release, if you wanted to use the eCommerce option to automatically generate keys, it was still necessary to install and run the License Manager GUI in order to be able to recharge the installation with production EasyLicenser license keys obtained from us. This created deployability issues in hosted environments where it was not usually an option to remotely run a desktop GUI application on a hosted machine.

EasyLicenser 2.0's license key generation API provides a method to programmatically recharge your EasyLicenser installation directly from your Java-based web site.

Improvements To The Runtime API Usability

Miscellaneous Security And Usability Enhancements

Compatibility Considerations

Backward compatibility is preserved between the two versions. In addition, forward compatibility is maintained to the maximum extent possible. The specific rules governing compatibility between EasyLicenser 1.1 and EasyLicenser 2.0 are enumerated below.

Compatibility Of Product Definitions

This is applicable only to the License Manager user interface.

Key Compatibility

Key compatibility has two aspects: the License Manager user interface and the run time libraries.

Runtime Library API Compatibility

The new runtime library introduces additional API calls while continuing to support existing API signatures.

Changes To Product Packaging

The product packaging has been revised to accommodate new functionality and to streamline multiplatform support for C/C++ run time libraries as follows:

Utility Programs

A makelibdigest utility is included for the purpose of creating digital signatures. The Java utility for creating digital signatures of Java jar files is available in the util directory. Each supported C/C++ platform has its distinct makelibdigest in the respective platform-specific subdirectory of cpp/util/bin, and is intended for creating digital signatures of the platform-specific shared library. Use of this utility is optional, since the product packaging includes the respective signature files for the corresponding EasyLicenser run time libraries.

Additional Demo Applications

The Java and C/C++ demos have been streamlined to each include three demo applications: a simple application, an application that utilizes the secure API's to automatically manage application license state, and an application that utilizes the secure API's, custom handlers and digital signatures to provide a high level of security from spoofing.

Packaging For C/C++ Platform Support

Beginning with this release, the C/C++ platform support that is included with the core packages is limited to Windows and Linux-Intel in order to expedite the availability of new releases for Java and the core C/C++ platforms as well as to contain the size of the download. Support for all other platforms including Solaris and HPUX is available in a separate download according to availability on a staggered schedule. Please refer to our web site's download page http://www.agilis-sw.com/ezlm/download.php for up to date information on platform availability for the C/C++ run time libraries.

Next Steps

Since you are upgrading to EasyLicenser 2.5, you will need to review the What's New In EasyLicenser 2.5 document for information on new features introduced in EasyLicenser 2.5 as well as upgrade procedures, and the corresponding next steps specified in that document.


Copyright © 2002+ Agilis Software LLC, Santa Clara, CA, USA. All rights reserved.