Certificate distribution via license files

Description

CROSS REFERENCE TO RELATED APPLICATION

Cross reference is made to U.S. patent application Ser. Nos. 10/231,957, filed Aug. 30, 2002, now U.S. Pat. No. 7,216,363, entitled “Licensing Duplicated Systems”; 10/232,507, filed Aug. 30, 2002, now U.S. Pat. No. 7,228,567, entitled “License File Serial Number Tracking”; 10/232,508, filed Aug. 30, 2002, entitled “License Modes in Call Processing”; 10/231,999, filed Aug. 30, 2002, entitled “Flexible License File Feature Controls”; 10/232,906, filed Aug. 30, 2002, entitled “Remote Feature Activator Feature Extraction”; 10/232,647, filed Aug. 30, 2002, entitled “Software Licensing for Spare Processors”; 10/348,107, filed Jan. 20, 2003, entitled “Remote Feature Activation Authentication File System”; 10/387,182, filed Mar. 11, 2003, entitled “Temporary Password Login”; 10/811,412, filed Mar. 25, 2004, now U.S. Pat. No. 7,272,500, entitled “Global Positioning System Hardware Key for Software Licenses”; 11/051,316, filed Feb. 2, 2005, entitled “Generation of Persistent Licenses in a Customer Environment”; and 10/947,418, filed Sep. 21, 2004, entitled “Secure Installation Activation”, each of which is incorporated herein by this reference.

FIELD OF THE INVENTION

The invention relates generally to software and/or hardware and particularly to the application of cryptographic algorithms to software and/or hardware licensing.

BACKGROUND OF THE INVENTION

Distributed software systems that operate over an open network, particularly a Wide Area Network such as the Internet, often have the need for secure communications over the network and authentication between system elements to prevent spoofing and other security breaches. Various protocols have been used to provide such security. Exemplary protocols include the Secure Sockets Layer or SSL, Transport Layer Security or TLS, Secure-HTTP, and IP Security or IPSEC.

Instrumental in these protocols are cryptographic mechanisms. Two primary cryptographic mechanisms are secret key and public key cryptography. Secret key is a type of symmetric encryption in which both parties know and use the same or shared secret key to encrypt and decrypt communications. Encryption algorithms, or ciphers, based on the secret key, mathematically transform or encrypt the plain text in the message into cipher text. The same key and algorithm are used by the other party to decrypt the cipher text. Public key cryptography is a type of asymmetric encryption that uses pairs of different keys, one for encryption and one for decryption. One of the keys or private key is kept secret by a party and the other key or public key is provided freely to other parties. When plain text is converted into ciphertext or encrypted using the private key, it may be converted back into plain text only using the public key and vice versa. The Rivest-Shamir-Adleman or RSA algorithm is one of the most widely used public key algorithms.

The SSL protocol uses the Public Key Infrastructure or PKI, a form of public key cryptography, to secure communications over otherwise unsecured networks. RSA, together with the X.509 standard for digital certificates, form the basis of PKI. A certificate 200 according to the X.509 standard is shown in FIG. 2. The standard portion 202 of X.509 includes the version 204 (which indicates the particular version of the X.509 standard), serial number 208 (which is assigned by the certificate authority and uniquely identifies the certificate), signature algorithm 212 (which identifies the algorithm used to in the digital signature), issuer or signer 216 of the certificate (which identifies the certificate authority that issued the certificate), period of validity 220 for the certificate (which identifies both the earliest and latest times that the certificate is valid), the subject or owner 224 of the public key, and the public key 228 of the owner of the certificate. Extensions 232 provide a location for issuers to add their own private information to the certificate. It can include authority and subject key identifiers, key usage, private key usage period, and a list of permitted use and restrictions on usage for the certificate. The certificate 200 further includes the digital signature field 236 (encrypted using the private key of an issuing entity). The digital signature field includes the signature algorithm identifier 212, a secure hash of the other fields in the certificate, and a digital signature of that hash. When a certificate has been issued and signed by the same entity, that certificate is known as a self-signed certificate or a root certificate. In a certificate chain or chain of trust, a root certificate is at always at the top of the chain and is used to validate each of the other lower certificates in the chain. A trusted third-party, such as Verisign™, that issues digital certificates used to create digital signatures and public/private key pairs is known as a certificate authority or CA. As can be seen from the foregoing, to implement PKI each system element in the distributed network requires a unique digital certificate and associated private key.

Providing each system element with a unique certificate can be achieved by secure communications between the system element and a certificate authority. In this approach, the system element generates a public/private key set and makes a certificate request to the certificate authority. Secure distribution of the private key is not an issue because no distribution is needed (the private key is generated on the target system element). However, this approach is not practical in many cases, since it requires direct communication between the system element and a certificate authority. This approach also presents security issues, since the certificate request sent from a given system element can be difficult to validate. If the certificate is granted without sufficient validation, the security that the certificate provides is compromised. More thorough validation is time consuming and potentially expensive.

SUMMARY OF THE INVENTION

These and other needs are addressed by the various embodiments and configurations of the present invention. The present invention is directed generally to the use of a shared or common file, such as a license file, to distribute cryptographic information, such as a digital certificate and private key.

In a first embodiment of the present invention, a process for licensing a computational component or system elements (which can be hardware and/or software) in a distributed processing network includes the steps of:

(a) the licensing provider assigning a private and public key pair to the computational component;

(b) the licensing provider creating a digital certificate for the computational component, the digital certificate being signed with a private key of the licensing provider, the licensing provider's private key being different from the computational component's private key;

(c) the licensing provider creating a license file to be installed on the computational component; and

(d) the licensing provider transmitting the license file and the computational component's signed digital certificate and/or private key to the computational component. This embodiment can provide certificate provisioning when the computational component has no network connectivity to the certificate authority, generate certificates in advance for known network identities, and can assign certificates to known network identities. When the license file is installed on the computational component, the unique certificate and/or private key are also installed. The process is particularly useful when each computational component to be licensed requires a unique or nearly unique license file.

The process can effectively and securely distribute PKI information to the computational component even when the licensing provider and computational component are located remotely from one another in the network. For example, the licensing provider and the computational component can be connected by a wide area network, such as the Internet.

In one configuration, the PKI information is included in or appended to the license file. For systems requiring multiple certificates in a single license file, the solution provides a mechanism that can ensure unique and secure distribution of the certificates to various elements of the system.

In one configuration, the license provider installs a single license file on a licensed server in a customer's enterprise network, and the licensed server in turn supports licensing of multiple computational components on the network. In such systems, the various system elements needing software licenses make license requests (e.g., requests for permission to run a given set of software) to the licensed server, which in turn grants permission, provided that the request is allowed within the bounds of the software license. Before the present invention if certificates were to be provided via the license file, a single license file must contain multiple certificates because a single license file supports multiple computational components. This presents a problem of how to uniquely (a given computational component always gets the same certificate) and securely (no compromise of the private key) distribute certificates and associated private keys from the licensed server to the remotely located computational components.

When the single license file for the enterprise is generated, information in the license file defines the maximum number of computational components. This information is used to determine the number of certificates to be included in the license file (one is typically included for each licensed computational component plus a certificate for the licensed server). The license provider creates the required number of certificates and includes them in the license file. Each certificate commonly includes the enterprise customer's license identifier that uniquely identifies each customer. Also included in the license file is the private key associated with each certificate. The private keys are encrypted in the license file to prevent the keys from being discovered. When the license file with certificates is installed on the license server, the license server extracts its certificate and private key for use in authentication and secure communications with other computational components.

To address the concern of unique (a given computational component always receiving the same certificate) and secure (no compromise of the private key) distribution, each valid computational component that is entitled to a certificate is administered on the license server by the customer. The administered data for each computational component can include the serial number, MAC address, IP address, and/or other electronic address of the associated hardware (when the computational component is software). When administration of a computational component is completed, the licensed server assigns a specific certificate from the license file to the computational component.

Next, each valid computational component is configured with the IP address or other electronic address of the licensed server and appropriate authentication information to allow it to claim its unique certificate from the license file. Once configured, a given computational component makes a license request to the licensed server to enable the licensed software. Once the software is enabled, the computational component makes a certificate request to the licensed server. In response to the certificate request, the licensed server authenticates the computational component (using the information previously administered on the licensed server) and returns the assigned certificate and encrypted private key to the computational component. The certificate request and response can be carried over a secure link, such as SSL, to protect the authentication and certificate information. When the certificate and encrypted private key have been transferred from the licensed server to the computational component, the computational component installs the certificate and decrypts the private key. The computational component has the appropriate key for this decryption built into the software and secured against hackers using the scatter-gather method or other techniques.

From the foregoing, it can be seen that this configuration of the present invention includes at least the following features:

(a) only valid computational components as established by the enterprise can obtain a certificate;

(b) each valid computational component is assigned a specific certificate from the license file;

(c) to avoid the private keys from being compromised, they are encrypted in the license file when the license file is transmitted over the network;

(d) the encryption key used to protect the private key is built into the licensed server (either in firmware or software) so that only the licensed server can be used to obtain the private key;

(e) the licensed server will only decrypt the private key if a valid license has been granted, thereby preventing pirated software from being used to discover private keys;

(f) certificates include the enterprise customer's license ID number to allow identification of computational components with certificates from outside the enterprise network;

(g) because the present invention includes or appends a certificate and private key in or to a license file before the license is installed on a computational component, the certificate and private key can be generated and provided to a computational component even before the computational component is assigned an electronic address; and

(h) because the manufacture and/or provider is the issuing authority, the certificate creation and validation process does not require the involvement of a recognized issuing authority, such as Verisign, thereby avoiding substantial costs and delays in provisioning computational components.

In a further embodiment of the present invention, the system could be used to provide secure and unique certificate distribution from a common file without the licensing portions.

These and other advantages will be apparent from the disclosure of the invention(s) contained herein.

The above-described embodiments and configurations are neither complete nor exhaustive. As will be appreciated, other embodiments of the invention are possible utilizing, alone or in combination, one or more of the features set forth above or described in detail below.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a licensing architecture according to an embodiment of the present invention;

FIG. 2 depicts the format of a digital certificate;

FIG. 3 depicts a chain of trust according to an embodiment of the present invention;

FIG. 4 is a flowchart depicting a license generation process according to an embodiment of the present invention; and

FIG. 5 is a flowchart depicting a license installation process according to another embodiment of the present invention.

DETAILED DESCRIPTION

Overview of the Remote Feature Activation System

Referring to FIG. 1, the remote feature activation or RFA system 100 comprises a remote feature activator 104 to supervise creation, encryption and delivery of master license files to primary media servers, a license generation agent 108 that generates standard license files in response to requests from the RFA system 104, an issuing authority 116 (which is typically a crypto-accelerator or smart card) to digitally sign certificates included in requests for media server certificates, and a cryptographic mechanism generating agent 112 (which is usually a daemon) that generates and queues (in advance) public/private key pairs and generates and forwards requests for media server certificates.

The RFA system 100 is in communication, with an Enterprise Resource Manager or ERM (not shown) and databases (not shown). The operation of the ERM is discussed in detail in copending U.S. application Ser. No. 10/232,507 entitled “License File Serial Number Tracking.” The ERM is configured to cause the addition, update, modification, and validation of entries in the databases based on predetermined rules or policies. The database comprises a plurality of records corresponding to hardware (e.g., processors or IP services interface cards) sold to customers. In particular, the database typically includes a serial number, serial number status or licensing state, client or purchaser, material code(s) (e.g., a material code in SAP that defines the hardware having the serial number), an Enterprise System ID or ESID that identifies uniquely the enterprise that is the subject of the record, a Module ID or MID that identifies a module in the associated enterprise record, and a System ID that identifies uniquely a system in the associated enterprise record. A selected media server is identified uniquely by the combination of the SID and MID. The database further comprises a plurality of records associated with hardware and software corresponding to each customer order. Each order entry typically includes an order number, customer name, address, and contact information, and a series of quantity, material code, and description fields identifying the contents of each order. The databases and data structures are further described in copending U.S. patent application Ser. No. 10/232,906, filed Aug. 30, 2002, entitled “Remote Feature Activator Feature Extraction”.

The RFA system 100 is further in communication, via network 146, with an enterprise network 150. The enterprise network 150 includes a master license server 154 and media servers 158, a network 162, and a terminal 168.

The media servers 158 can be any converged architecture for directing circuit-switched and/or packet-switched contacts to one or more communication devices. Typically, the media server is a stored-program-controlled system that conventionally includes interfaces to external communication links, a communications switching fabric, service circuits (e.g., tone detectors and generators, announcement circuits, etc.), memory for storing control programs and data, and a processor (i.e., a computer) for executing the stored control programs to control the interfaces and the fabric and to provide automatic contact-distribution functionality. Illustratively, the media server can be a modified form of Avaya Inc.'s Definity™ Private-Branch Exchange (PBX)-based ACD system; Avaya Inc.'s IP600™ LAN-based ACD system, or an S8100™, S8300™, S8500™, S8700™, or S8710™ media server running a modified version of Avaya, Inc.'s Communication Manager™ voice-application software with call processing capabilities and contact center functions. Other types of known switches and servers are well known in the art and therefore not described in detail herein. The media servers 158 can serve a variety of functions, including acting as main server, Local Spare Processors or LSPs, WAN spare processor, or PPN, and Enterprise Survivable Server or ESS.

The master license server 154 can be any system operable to install and distribute licenses. Typically, the master license server 154 is a media server having network connectivity to the remote feature activation system 100.

The terminal 168 is a computer, such as a laptop or PC, that is connected to the media servers for user administration of the various system elements in the enterprise network. Administration includes the creation and distribution of allocation licenses as discussed more fully below.

Typically, networks 120 and 162 are local area networks while network 146 is a wide area network, such as the Internet.

The master license server 154 includes a license installation agent 172 that generates and forwards license files 180 to media servers. The license files typically include or are attached to a certificate and corresponding private key for the corresponding media server. The master license file 176 is generated and distributed by the remote feature activation system 100 and the server license files 180 by the master license server 154. Because the license file is not associated with a single media server, the enterprise has portability of the capacities between all the media servers in the enterprise. The agent 172 confirms that the sum of allocations among all of the enterprise media server license files 180 does not exceed the limits set forth in the master license file 176.

As will be appreciated, during the generation and transmission of licenses to the various servers 158 and later communications between and among the servers 154 and/or 158 and with the RFA system 100, it is important to provide adequate security to prevent spoofing and other security breaches. In a preferred embodiment of the present invention, PM and SSL or TSL are employed to provide the security. This, of course, requires each of the master license server 154 and other media servers 158 to have digital certificates and public/private key pairs. The provision of digital certificates and public/private key pairs is effected by the RFA system 100 during master license file 176 installation in the master license server 154. The provision of digital certificates and public/private key pairs to the various media servers 158 can be effected by including in the master license file 176 a plurality of certificates and key pairs, one for each of the media servers and/or by using a smart card or dongle as described in copending U.S. application Ser. No. 10/947,418, entitled “Secure Installation Activation”.

Other aspects of the architecture are described in the copending applications referenced above and incorporated herein by this reference.

The Master License File

Prior to discussing the process for providing a digital certificate and public/private key pair to the master license server 154, the PKI information included and not included in the master license file 176 will be discussed. The license file, in addition to the license terms and related information such as licensed feature and capacity codes, the serial numbers of licensed hardware devices, and the like, includes at least one (if not all) of the various digital certificates in the chain of trust and the unique private key assigned to the master license server 154 as well as the PKI information for each of the media servers 158. With reference to FIG. 3, the chain of trust is depicted. The manufacturer root certificate 300 is at the top of the chain. As noted, the root certificate is both issued to and signed by the private key of the manufacturer and/or supplier of the licensed software and/or hardware. The license generation agent or issuing authority certificate 304 is issued to the RFA system 100 and signed with the private key of the manufacturer and/or supplier. Finally, a different media server certificate 308 is issued to each media server and is signed with the private key of the RFA system 100. With further reference to FIG. 2, the PKI information 302 includes an encoded copy of the corresponding media server's private key 312.

The certificate 308 for the master license server includes a variety of information. For example, it includes the name of the licensed product and the ESID associated with the corresponding media server. The expiration date of the certificate is typically the expiration date of the enterprise wide license. The certificate 308 will commonly not have an IP address or domain name as part of its subject field. The reason is that, for this to be possible, the media server would have to be installed and assigned a name in the enterprise network. Then a certificate request would have to be generated and transmitted to the RFA system 100 for signing. Then the final certificate would have to be downloaded and installed on the server. This would delay unnecessarily and significantly the installation of servers.

Process for Generating and Installing Master License Files

With reference to FIG. 4, in step 400 the remote feature activator 104 receives a request for a master license file. The activator 104 forwards a license file generation request to the license generation agent 108. In step 404, the agent 108 retrieves records for the pertinent enterprise from the remote feature activator 104 and generates a license file. During the generation process, the agent 108 determines in decision diamond 408 whether the product release and platform type defined in the generic license input file requires a media server certificate. If not, the RFA system 100 proceeds to step 432 (discussed below). If so, the agent 108 forwards in step 412 a request for a certificate to the cryptographic mechanism generating agent 112. The certificate request includes one or more media server certificate(s) (in X509V3 format) populated using information from the generic license file. The certificate(s) are unsigned and do not include the corresponding media server's public key (which has not yet been assigned).

In step 416, the agent 112 generates a public/private key pair (which is preferably done using RSA) to be assigned to each of the media servers. The generation is made using open SSL library calls. For performance reasons, the agent 112 preferably generates key pairs in advance and queues them for assignment as requests are received. The corresponding public key is included in the unsigned media server certificate(s) and in step 420 is forwarded to the issuing authority 116 in a signature request for the media server certificate.

In step 424, the issuing authority 116 signs the media certificate(s) with its private key and in step 428 returns the signed certificate(s) to the agent 112. The agent 112 forwards the signed certificate(s), assigned private key(s) and license generation agent certificate 304 to the activator 104.

In step 432, the enterprise wide or master license 176 is generated from the generic license file, the signed certificate, assigned master license server private key and license generation agent certificate 304. The manufacturer root certificate 300 may be included in the license file before transmission or may be built in the licensed software. During step 432, the private key is encrypted with a first encryption algorithm and the entire license file with a second different encryption algorithm. The first and second encryption algorithms each use a secret key as is used in symmetric encryption and as further described in U.S. patent application Ser. No. 10/348,107, filed Jan. 20, 2003, entitled “Remote Feature Activation Authentication File System.”

In step 436, the encrypted master license file 176 is delivered to the master license server 154.

Referring to FIG. 5, the license file 176 is received by the license installation and configuration agent 172 and installed in step 500. In step 504, the file 176 is decrypted using the second encryption algorithm and stored in a first location. In step 508, the appropriate certificate is extracted from the license file 176, validated against the manufacturer's root certificate 300 (which is already on the server), and the root certificate 300 appended to the chain of trust. The PKI information (minus the private key) is stored in a second different location. Finally, the private key is decrypted using the first encryption algorithm and stored in a third different location.

A number of variations and modifications of the invention can be used. It would be possible to provide for some features of the invention without providing others.

For example in one alternative embodiment, the various modules referenced herein are implemented as software, hardware (e.g., a logic circuit), or a combination thereof.

In another alternative embodiment, the division of the various functions performed by the various modules described above are different.

In another embodiment, the primary media server certificate is a signing certificate and is used to sign certificate for the media servers. In this manner, the certificates do not need to be provided by the RFA system 100.

In another embodiment, the license distributed by the remote feature activation system 100 includes only the private key and not the digital certificate(s). Digital certificate requests can be generated by the master license server 154 and/or media servers 158 including enterprise-specific and/or device-specific information. The remote feature activation system 100 can use the various private key(s) issued to the identified enterprise to authenticate the certificate request. The request can then be signed by the appropriate certificate authority and returned to the enterprise network 150 for distribution to the appropriate server 154 or 158.

The present invention, in various embodiments, includes components, methods, processes, systems and/or apparatus substantially as depicted and described herein, including various embodiments, subcombinations, and subsets thereof. Those of skill in the art will understand how to make and use the present invention after understanding the present disclosure. The present invention, in various embodiments, includes providing devices and processes in the absence of items not depicted and/or described herein or in various embodiments hereof, including in the absence of such items as may have been used in previous devices or processes, e.g., for improving performance, achieving ease and\or reducing cost of implementation.

The foregoing discussion of the invention has been presented for purposes of illustration and description. The foregoing is not intended to limit the invention to the form or forms disclosed herein. In the foregoing Detailed Description for example, various features of the invention are grouped together in one or more embodiments for the purpose of streamlining the disclosure. This method of disclosure is not to be interpreted as reflecting an intention that the claimed invention requires more features than are expressly recited in each claim. Rather, as the following claims reflect, inventive aspects lie in less than all features of a single foregoing disclosed embodiment. Thus, the following claims are hereby incorporated into this Detailed Description, with each claim standing on its own as a separate preferred embodiment of the invention.

Moreover though the description of the invention has included description of one or more embodiments and certain variations and modifications, other variations and modifications are within the scope of the invention, e.g., as may be within the skill and knowledge of those in the art, after understanding the present disclosure. It is intended to obtain rights which include alternative embodiments to the extent permitted, including alternate, interchangeable and/or equivalent structures, functions, ranges or steps to those claimed, whether or not such alternate, interchangeable and/or equivalent structures, functions, ranges or steps are disclosed herein, and without intending to publicly dedicate any patentable subject matter.