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
An XSLM-compliant licensing system provides the following security
License certificate integrity
to verify that a certificate
submitted to the licensing system was not changed after its creation.
License certificate authenticity
to verify that a certificate submitted to the licensing system
was created by the intended software application publisher.
Licensing system authentication.
to verify that the licensing system which an agent is
communicating with is the intended licensing system.
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
is kept secret by its owner and is called the
is published and available
to all interested parties and is called the
The operation called
requires the possession of the private key and of the data
being signed. The operation called
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
(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
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.
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
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:
The authentication section may contain an authorization
certificate, issued by a CA trusted by the licensing system.
In this case, the verification of the license certificate is
done in two steps:
The licensing system verifies the
authorization certificate. How the licensing system acquires the
public key of the CA is outside the scope of this specification.
The licensing system verifies the license certificate with
the public key of the application software publisher,
which it has just found in the verified
The authentication section may contain the request that the
licensing system should only validate the license certificate
by using an authorization certificate issued by
some trusted CA. How the authorization certificate and the CA
public key are made available to the licensing system is outside
the scope of this Technical Standard. There is however the requirement
that the application software publisher information contained in
the authentication certificate must be exactly the same information
which is provided in the license certificate.
The authentication section may contain only the
public key of the application software publisher (that is, it does
not contain any authorization certificate) which will be directly used
by the licensing system to verify the certificate.
This simple verification scheme can detect "naive" tampering
with the certificate,
but cannot detect the replacement of the entire certificate with
a forged one created and signed by a malicious party, and therefore
can not ensure that the license certificate is a valid one, issued
by the intended software application publisher.
It is recommended that this scheme is only used in conjunction
with the verification of authenticity, described below.
License Certificate Authenticity
At run time, whenever a license is requested (by means of an
API call), an application
can dictate the behavior of the licensing system by setting the
appropriate value of an input parameter:
In the simple case, the licensing system is not required
to perform any authenticity check of the license certificate.
In the second case, the licensing system is directed to
grant licenses only if they come from certificates whose authenticity
was verified by the licensing system through the use of an
In the final case, the licensing system is directed to
verify that a key received from the application (through another
parameter of the same request call) is equal to the public key
contained in the license certificate. Since the value of the key
provided by the application is defined by the application software
publisher, this check can ensure that the certificate installed
in the license data base was also created by the same application
In order for this validation to be trusted, in addition to the
integrity of the licensing system, two further assumptions have
to be made:
The application must be integer, that is, the
binary code of the application has not been patched in order
to change the value of these parameters.
The communication network between the application agent and the
licensing system is secure, so that no "man in the middle" can
intercept the call and change the values which are actually
provided to the licensing system.
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
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 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
- 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
that implements this scheme on behalf of the application.
This Technical Standard does not require that an
implementation must provide such a broker.
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:
The algorithms used for signing
The corresponding public key to be used for verification
A unique identifier of this specific licensing system.
- 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
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:
The application generates an arbitrary
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.
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
The licensing system processes the request.
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
The licensing system returns to the application the signature
and the licensing system identifier, along with all the other output
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.
The application verifies the signature returned by the licensing
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.