Authentication and Data Integrity

Scope

• 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

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

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:

• 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:

  1. 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.

  2. The licensing system verifies the license certificate with the public key of the application software publisher, which it has just found in the verified authorization certificate.

• 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

• 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 authentication certificate.

• 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 software publisher.

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 license certificate.

Licensing System Authentication

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.

Note:

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

• The algorithms used for signing

• The corresponding public key to be used for verification

• A unique identifier of this specific licensing system.

Note:

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.

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.