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 Of Product Definitions
Runtime Library API Compatibility
Packaging For C/C++ Platform Support
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.
The key themes behind the new features that were introduced in EasyLicenser 2.0 are:
Floating license model support for the Orion network license server.
Built-in security mechanisms for faster integration and enhanced key security.
Enhanced anti-spoofing mechanisms for faster integration and enhanced application license management security.
Improved eCommerce deployability for hosted environments.
Usability improvements to user interface and API's.
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.
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.
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.
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.
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.
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.
Operating System Enforcement And User / Host Name Parameter: the run time user / host name parameter can be specified to be null if the key is known to have been generated with operating system level enforcement enabled.
Windows And User / Machine Name Case Sensitivity: on Windows, the run time library performs a case-insensitive comparison of the key contents against the operating system parameters when operating system enforcement is in effect.
Custom Key Handler Invocation: the custom key handler is invoked unconditionally if a custom key handler is specified, regardless of whether a custom key is found in the license key. The invocation occurs after the license check is completed and all its contents are retrieved, so if you provide the license context as the application context, your customer key handler will be able to see all key parameters.
License Context And Repeated License Checks: should it be required, you can perform multiple license key checks against the same license context without having to reallocate a new context for each check.
Improved Protection From System Clock Changes For Basic Runtime API:
The basic API's provide reliable protection from changes to the system clock
for all application execution scenarios. The secure API's, which already provided
reliable detection of system clock changes, are further protected from
tampering with the underlying mechanisms.
Both the basic and secure API's are available in versions that allow you to
control the location of the internal hidden file that is used to perform
system clock checks, as well as to disable system clock checking for
perpetual keys. By default, system clock checking is enforced for all keys.
Tolerance For System Clock Drift: In order to accommodate the very real possibility that the system clock will in fact drift over time and will require periodic adjustments, a tolerance of up to a 6 hr. discrepancy is built into the run time so that applications continue to function following a reasonable system clock correction.
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.
This is applicable only to the License Manager user interface.
Backward compatibility: The EasyLicenser 2.0 License Manager GUI can be used to import, export, view details and otherwise process existing product definitions that were created with EasyLicenser 1.1.
Forward compatibility: The EasyLicenser 1.1 License Manager GUI can be used to import, export, view details and otherwise process product definitions that are created with EasyLicenser 2.0 provided the products don't have application passwords associated with them, and provided the products' option names don't contain the ':' character.
Key compatibility has two aspects: the License Manager user interface and the run time libraries.
License Manager backward compatibility: The EasyLicenser 2.0 License Manager GUI can be used to import, export, publish, view details and otherwise process existing keys that were generated with EasyLicenser 1.1.
License Manager forward compatibility: The EasyLicenser 1.1 License Manager GUI can be used to import, export, publish, view details and otherwise process keys that are generated with EasyLicenser 2.0 provided the keys are not based on product definitions having application passwords defined on them.
Runtime library backward compatibility: The Java and C/C++ EasyLicenser 2.0 runtime library will correctly process keys that were generated with EasyLicenser 1.1.
Runtime library forward compatibility: The Java and C/C++ EasyLicenser 1.1 runtime library will correctly process keys that are generated with EasyLicenser 2.0 provided the keys are not based on product definitions having application passwords defined on them.
The new runtime library introduces additional API calls while continuing to support existing API signatures.
API backward compatibility: A Java or C/C++ application can use the new runtime library with no source code modifications. From the perspective of the application logic, the existing semantics are preserved for the current API calls.
API forward compatibility: Not applicable by definition. If the application uses any of the new API calls, it needs to be packaged with the new runtime library.
The product packaging has been revised to accommodate new functionality and to streamline multiplatform support for C/C++ run time libraries as follows:
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.
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.
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.
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.