Previous section.

Systems Management: Software License Use Management (XSLM)
Copyright © 1999 The Open Group

Authentication and Data Integrity

This chapter defines the aspects of security that must be supported by a XSLM-compliant licensing system. The use of these security mechanisms is optional on the part of the application software publisher.


An XSLM-compliant licensing system provides the following security features:

Security Mechanisms Deployed

This XSLM Technical Standard relies on public-key technology to provide the integrity and authenticity features identified above.

There are a number of different public-key schemes that can be used. These algorithms share the common characteristic that keys exist in pairs, "k" and "K". Key k is kept secret by its owner and is called the private key, while key K is published and available to all interested parties and is called the public key. The operation called signing requires the possession of the private key and of the data being signed. The operation called verification requires the possession of the public key and of the signed data. If successful, the verification operation proves that the signature was created by an entity in possession of the private key at the time of signing, and that the data in question has not been altered. These signing and verification operations might involve the use of a cryptographically sound hash function, and the use of cryptographically sound encryption and decryption functions. The description and definition of these functions and operations is outside the scope of this Technical Standard. In XSLM, all other kinds of authentication, integrity, and security are the responsibility of the licensing system, and of the supporting environment in which the application executes.

The trust which can be placed in the verification operation resides in the trust which can be placed in the association between the public key and the owner of the private key who signed the data. This trust can be established by an external framework (referred to as Public Key Infrastructure, or PKI) in which one or more Certification Authorities (CA) can issue authentication certificates (or digital certificates), in which the association between a public key and the entity owning the corresponding private key is made. The authentication certificates are signed by the CA and then made available through public lists, so that anyone trusting the CA and in possession (in a trusted way) of the public key of the CA can verify the authenticity of the certificate and obtain, in a trusted way, the public key of the party of interest.

All of the above clearly relies on the basic assumption of security, that is, "the secret is secret", or in other words the private key is never compromised.

Additional aspects of the functionality needed for security are assumed to be provided by the licensing system in an implementation-dependent way, or by the environment in which the licensing system and/or the application execute. These are outside the scope of this Technical Standard.

License Certificate Integrity

The license certificate integrity (and authenticity) is assured by the application software publisher by signing the certificate at the time it is created. The certificate integrity (and authenticity) is verified by the licensing system at the time the certificate is installed in the license data base, by using the public key of the application software publisher which created the certificate.

It is assumed that the licensing system is a legitimate one and has not been compromised, that is, the binary code has not been patched in order to have a different behavior.

An optional data element on the license certificate, called authentication section, contains all the information needed by the licensing system for the verification operation. If the data element is not present, the licensing system is not required to perform any validation.

Three cases arise:

License Certificate Authenticity

At run time, whenever a license is requested (by means of an xslm_basic_request_license() or xslm_adv_request_license() API call), an application can dictate the behavior of the licensing system by setting the appropriate value of an input parameter:

In order for this validation to be trusted, in addition to the integrity of the licensing system, two further assumptions have to be made:

Otherwise the licensing system could be directed not to perform any check, or could be provided with a false key, equal to the one provided in a completely forged license certificate.

Licensing System Authentication

The goal of this authentication scheme is to allow an application (or a management tool) to check both the integrity and the authenticity of each message (that is, input and output parameters) passed between the application and the licensing system which the agent is communicating with. If an application software publisher chooses to implement this scheme into an application, they will restrict the application to work only with those licensing system which have provided to the application the needed information prior to a license request (see below).

The authentication is based on a signature generated by the licensing system, where the data being signed is all the parameters received from the application and all the data returned to it, and returned to the application together with the licensing system's unique identifier. This identifier is used by the application to select the appropriate public key to be used for the verification of the signature.

The trust in this scheme is based on the association between the licensing system unique identifier and the public key available to the application for the verification, and therefore is reliable also in the presence of a non-secure communication network between the application and the licensing system. How this trusted association is achieved is outside the scope of this Technical Standard.

This scheme is only available to applications using the advanced application API. Applications using the basic application API can use, if available, an application broker statically linked with the application (see Application Broker), that implements this scheme on behalf of the application. This Technical Standard does not require that an implementation must provide such a broker.

Process Description

All licensing system publishers that want to be authenticated by an application using this scheme must provide to the application software publisher (in a trusted way, outside the scope if this Technical Standard) the information needed to successfully authenticate the data returned by the licensing system, namely:

It is recommended that licensing system publishers provide a library containing the appropriate authentication functions, to make the use of this scheme easier for an application publisher. To improve security, it is recommended that this library should be statically linked with the application. The public key could be embedded in this library or, better, could be provided on external removable media accessed by the application at run time.

The application software publisher embeds in the application the knowledge of the licensing system unique identifiers that the application will support, and for each API call will follow the steps described below.

Figure: Licensing System Authentication Process
Referring to the numbers in Licensing System Authentication Process:

  1. The application generates an arbitrary token, known only to the application, which can be any arbitrary number (for example, a timestamp, or a randomly generated number) which is different in each API call. The data signed by the licensing system will include this variable element, to provide protection against a possible "replay" of old messages by an imposter licensing system.

  2. The token is passed to the licensing system as one of the input parameters of the API call. All the management API functions and most of the advanced application API functions contain this parameter.

  3. The licensing system processes the request.

  4. If the value of the token was not set to 0 (meaning that no authentication was needed), the licensing system signs all the data transmitted in the API call (that is, all the input parameters as received by the application and all the output parameters just computed) using the private key of the licensing system publisher.

  5. The licensing system returns to the application the signature and the licensing system identifier, along with all the other output parameters.

  6. The application uses the value of the returned licensing system identifier to determine the verification technique and the public key to be used for verification.

  7. The application verifies the signature returned by the licensing system.

If the verification operation is successful then the application is assured that the licensing system is the intended one and that the data returned by the licensing system was received with integrity.

Why not acquire a nicely bound hard copy?
Click here to return to the publication details or order a copy of this publication.

Contents Next section Index