Abstract:
A system for licensing a computational component in a distributed processing network is provided. The system includes a licensing provider  100  that is spatially remote from the computational component  154  and is operable to: (a) assign a private and public key pair to the computational component  154 ; (b) create a digital certificate  308  for the computational component  154 , the digital certificate  308  being signed with a private key of the licensing provider  100 , the licensing provider&#39;s private key being different from the computational component&#39;s private key  312 ; (c) create a license file  176  to be installed on the computational component; and (d) transmit the license file  176  and the computational component&#39;s signed digital certificate  308  and private key  312  to the computational component  154.

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&#39;s private key being different from the computational component&#39;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&#39;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&#39;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&#39;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&#39;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.&#39;s Definity™ Private-Branch Exchange (PBX)-based ACD system; Avaya Inc.&#39;s IP600™ LAN-based ACD system, or an S8100™, S8300™, S8500™, S8700™, or S8710™ media server running a modified version of Avaya, Inc.&#39;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&#39;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&#39;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&#39;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.