US20100318789A1 - Method and system for license management - Google Patents

Abstract

System and method are disclosed for securing and managing individual end-user platforms as part of an enterprise network. The method/system of the invention has three main components: a security module, a manager appliance, and a console appliance. The security module enforces the enterprise licenses and security policies for the end-user platforms while the manager appliance provides secure, centralized communication with, and oversight of, the security module. The console appliance allows an administrator to access the manager appliance for purposes of monitoring and changing the licenses. Security is established and maintained through an innovative use of data encryption and authentication procedures. The use of these procedures allows the appliances to be uniquely identified to one another, which in turn provides a way to dynamically create unique identifiers for the security modules. These various components together form an infrastructure over the enterprise network to securely manage the end-user platforms.

Description

RELATED APPLICATIONS
• This application for patent claims priority to, and hereby incorporates by reference, U.S. Provisional Application No. 60/609,525, entitled “Method and System for License Management,” filed Sep. 13, 2004.
FIELD OF THE INVENTION
• The present invention relates to the field of enterprise computing management and, in particular, to a method and system for securely administering the licenses associated with the computers in an enterprise.
BACKGROUND OF THE INVENTION
• A typical enterprise (e.g., corporation, university, government agency, etc.) may have anywhere from 15 to 1,500 or more end-user platforms connected to its internal and/or external networks. These end-user platforms (e.g., laptops, desktops, workstations, servers, mobile phones, personal digital assistants (PDA), etc.) typically run one of several available operating systems (e.g., Windows®, Sun Solaris, Linux, etc.) and one or more software applications. For obvious reasons, it is important for the enterprise to ensure that these end-user platforms and the software applications running thereon are configured in a manner that complies with the appropriate licensing requirements.
• No licensing system is supportable, however, without a basis in security to prevent unauthorized access to, or modification of, the licenses. Thus, the biggest ongoing challenge for security professionals in enterprise computing management is first to secure the configuration of the end-user platforms, then maintain the security of the configurations. Each end-user platform must be secured in such a way that system user/operators can continue to perform their daily tasks as transparently as possible. Many vendors have attempted to meet this challenge by providing a security “overlay” application that enforces the security on the platform. While this is the right idea conceptually, the implementation, management, and impact on platform operators and security administrators have been less than ideal.
• The second biggest challenge is to provide a security solution that can be easily scaled across an enterprise network containing a heterogeneous mix of end-user platforms. While there are some host-based security products that can adequately secure individual platforms, these products do not scale easily or cost-effectively to a large number (e.g., 100, 500, 1,000, etc.) of platforms, as is common in many large enterprises. In order to be a cost effective security solution, a product must be effective at securing individual hosts, must contain a secure infrastructure for communicating with system security administrators, and must be easy to set up and maintain across a large number of end-user platforms.
• Accordingly, what is needed is an enterprise computing management solution that overcomes the shortcomings of existing solutions.
SUMMARY OF THE INVENTION
• The present invention is directed to a system and method for securing and managing individual end-user platforms as part of an enterprise network. The method/system of the invention has three main components: a security module, a manager appliance, and a console appliance. The security module enforces the enterprise licenses and security policies for the end-user platforms while the manager appliance provides secure, centralized communication with, and oversight of, the security module. The console appliance allows an administrator to access the manager appliance for purposes of monitoring and changing the licenses. Security is established and maintained through an innovative use of data encryption and authentication procedures. The use of these procedures allows the appliances to be uniquely identified to one another, which in turn provides a way to dynamically create unique identifiers for the security modules. These various components together form an infrastructure over the enterprise network to securely manage the end-user platforms.
• In general, in one aspect, the invention is directed to a method of establishing a secure environment for an end-user platform, and a system manager able to manage the end-user platform. The method comprises the steps of storing manager authentication information on the system manager, the manager authentication information being unique to the system manager, then generating end-user platform authentication information for the end-user platform using at least a portion of the manager authentication information, the end-user platform authentication information being unique to the end-user platform. The method further comprises the steps of transferring the end-user platform authentication information from the system manager to the end-user platform and establishing a secure connection between the system manager and the end-user platform using the manager authentication information and the end-user platform authentication information.
• In general, in another aspect, the invention is directed to a system for managing a plurality of computing platforms. The system comprises a network connecting a plurality of end-user platforms to each other and one or more appliances connected to the network and having appliance authentication information stored thereon that is unique to each appliance. The appliance authentication information for the one or more appliances is derived from a single source of authentication information such that any appliance is capable of authenticating any other appliance.
• In general, in still another aspect, the invention is directed to a method for authenticating a plurality of computing platforms. The method comprises the steps of generating platform level authentication information and using the platform level authentication information to generate appliance level authentication information. The appliance level authentication information is unique to each appliance and allows all appliances to authenticate one another. At least a portion of the appliance level authentication information is then used to generate client level authentication information, the client level authentication information being unique to each end-user platform and allowing the appliances to authenticate the end-user platforms.
• Additional aspects of the invention will be apparent to those of ordinary skill in the art in view of the following detailed description, made with reference to the drawings, a brief description of which is provided below.
BRIEF DESCRIPTION OF THE DRAWINGS
• A better understanding of the invention may be had by reference to the following detailed description when taken in conjunction with the accompanying drawings, wherein:
• FIG. 1 illustrates an exemplary system for providing enterprise-wide computing management according to embodiments of the invention;
• FIG. 2 illustrates an exemplary policy management implementation of the system inFIG. 1 according to embodiments of the invention;
• FIG. 3 illustrates an exemplary security group implementation of the system inFIG. 1 according to embodiments of the invention;
• FIG. 4 illustrates an exemplary backup manager implementation of the system inFIG. 1 according to embodiments of the invention;
• FIG. 5 illustrates an exemplary security group administration implementation of the system inFIG. 1 according to embodiments of the invention;
• FIG. 6 illustrates an exemplary hierarchy for a platform certificates group according to embodiments of the invention;
• FIGS. 7A-7C illustrate exemplary hierarchies for license certificates groups according to embodiments of the invention; and
• FIG. 8 illustrates an exemplary hierarchy for an administrator certificates group according to embodiments of the invention.
DETAILED DESCRIPTION OF THE INVENTION
• As alluded to above, embodiments of the invention provide a system and method of securing and managing individual end-user platforms as part of an enterprise network. Referring now toFIG. 1, asystem100 for providing enterprise-wide computing management according to embodiments of the invention is shown. The system includes a plurality of computing platforms, including end-user platforms102a,102b,102c,and102d(hereinafter “end-user platforms102”), a manager appliance104 (hereinafter “manager104”) connected to the end-user platforms102a-d,and a console appliance106 (hereinafter “console106”) connected to themanager104. Each end-user platform102 has arespective security module108a,108b,108c,and108d(hereinafter “client108”) residing therein that is in constant or almost constant communication with themanager104 while the end-user platform102 is connected to thenetwork110. Thenetwork110 may be any suitable network known to those having ordinary skill in the art, including wired and wireless networks. Briefly, theclients108 enforce the enterprise licenses and security policies (hereinafter “security policies”) for the end-user platforms102 while themanager104 monitors the operation of theclients108 and provides secure, centralized communication to theclients108. Theconsole106, which provides the only available access to themanager104, allows an enterprise administrator to log on to themanager104 for purposes of monitoring the end-user platforms102 and implementing policy changes, software upgrades, security event reporting, and the like. From theconsole106, an administrator may view all information about theclients108 as well as issue commands to eachclient108 as needed. Following is a more detailed discussion of these various components.
• Eachclient108 is a software module that, unlike existing solutions, runs in the operating system kernel of the platform102. This arrangement allows theclient108 to enforce the security policy of the enterprise on each end-user platform102 independently of any native operating system policies and security mechanisms. Once loaded into the kernel of the operating system, theclient108 is transparent to normal user operation of the platform102. Because theclient108 is running in the kernel of the operating system, it is able to protect each platform102 from both local attacks (e.g., via the keyboard) and remote attacks (e.g., across the network). Examples of operating systems for which theclient108 may be loaded into the kernel include Microsoft Windows® 2000, XP, and Server 2003, Sun Solaris®versions 7, 8, and 9, and other suitable operating systems. For more information regarding kernel-based security modules, the reader is referred to, for example, commonly-assigned U.S. patent application Ser. No. 10/294,268, entitled “Kernel-based Network Security Infrastructure,” filed Nov. 14, 2002, and incorporated herein by reference.
• In a networked environment, theclients108 are in constant or near constant secure communication with themanager104. To an external device, such as a network “sniffer,” the connection will appear as a standard virtual private network (VPN) connection. These communications are low-bandwidth communications that comprise mainly polling or ‘heartbeat’ information and system status information. In the event of a network-based attack, or if there is an attempted policy violation by the platform user, theclient108 forwards event messages to themanager104 for subsequent review by the administrator. If the end-user platform102 is removed from thenetwork110, for example, when a laptop is taken home at the end of the day, or if the network connection between theclient108 andmanager104 is disrupted, theclient108 continues to enforce its security policy and simply queues future messages until connection with themanager104 is restored. Such an arrangement provides a powerful management mechanism that can reach directly into the operating system of an end-user platform102 to enforce security policies.
• Themanager104 has two main purposes: (1) maintain a secure connection with each client, thereby forming a centralized communications hub, and (2) provide a repository for policies, client upgrades, and security event information. To this end, themanager104 maintains continuous or almost continuous electronic oversight of thesystem100 as well as the configuration management of all end-user platforms102. Themanager104 can issue commands and control changes, collect events, and/or perform complete updates/upgrades of the software running on the end-user platforms102. As part of the management process, themanager104 also stores policy configurations, event information, and updates/upgrades for thesystem100. Thus, asingle manager104 can easily support the entire licensing and security oversight needs of any typical enterprise.
• In a preferred embodiment, themanager104 is a dedicated hardware appliance that includes a solid-state memory (not expressly shown) for storing the manager operating system and software. It is possible, however, to implement the manager operating system and software on a computer that is not specifically dedicated for the manager function. In any event, the term “manager” (as well as the terms “console” and “appliance”) are used herein to refer to both the hardware and software, whether dedicated or not. The manager operating system may be, for example, a Microsoft Windows XP® embedded operating system or Sun Solaris® operating system. Also stored in the solid-state memory are software applications, security policies, and other data needed for maintaining the security of thesystem100. Since there are few or no moving parts within themanager104 associated with any critical components in the preferred embodiment, themanager104 is essentially a solid-state device. In some embodiments, however, themanager104 may also (or alternatively) contain a magnetic or optical disk drive for storing the data and/or applications and various other information. Setup, configuration, and operation of themanager104 are accomplished via network interface (e.g., 10/100/1000 Ethernet interface) in themanager104 and theconsole106, described later herein.
• As mentioned above, one of the functions of themanager104 is to store and manage policy information for theclients108. The security policy is first created by the system administrator to meet the needs of the enterprise and then is stored under a user-defined file name. This policy may then be applied to allclients108 with an appropriate command from the administrator via themanager104.FIG. 2 illustrates the policy management aspect of themanager104. As can be seen, there are three separate policies that have been established by the administrator and subsequently implemented by the manager104: Default, Minimum, and Lockdown. The three policies represent varying levels of security, with one policy implemented on each of the end-user platforms102. When a change or update needs to be made to one of the policies, the administrator simply makes the desired change or update in the appropriate filename using theconsole106. Themanager104 thereafter carries out the change or update on the appropriate end-user platforms102.
• Before carrying out the change or update, themanager104 provides the administrator with two options: (1) apply new policy to existing clients, and (2) store policy under new name. Under the first option, themanager104 updates the old policy within themanager104 itself and then proceeds to update allclients108 that were enforcing the old policy with the new modified policy. This is illustrated by the dotted lines inFIG. 2, showing that the Lockdown policy for the third and fourth end-user platforms102cand102dhas been updated with the modified policy. Choosing the second option enables the administrator to store the new policy under a different name, for example, “Lockdown 2,” for future implementation. The above arrangement provides an easy, flexible, and consistent enterprise-wide implementation of the desired security policies.
• Amanager104 may also be configured to communicate withother managers104, as illustrated inFIG. 3. Here, Manager1 (104a) and Manager5 (104e) communicate with each other to share policy, event, and status information across the network. In general,managers104 andclients108 that share information in this manner may be referred to as “security groups.” A security group may be established by having two ormore managers104 exchange their clients' policy configurations, either during the initial communication between themanagers104 or sometime thereafter, so that eachmanager104 contains all the policy configurations from theother managers104 and vice versa. This type of manager-to-manager relationship is useful when scaling to support large enterprises because a single policy can be modified in onemanager104 and subsequently applied to thousands ofclients108. In addition, an administrator can log into any manager of the security group (via the console106) and access all components of thesystem100, includingother managers104,clients108, or even otheractive consoles106 that are part of the security group.
• In some embodiments, a backup or “rollover” manager may be designated in thesystem100 to provide additional reliability on an already highly reliable system. This optional arrangement can be used by administrators to compensate for unstable or often changing networks. Depending on the corporate network topology, theclients108 can be configured to communicate directly with a second manager if communications are lost with their normal or primary manager.FIG. 4 illustrates an exemplary implementation of the rollover manager embodiment of the invention.
• InFIG. 4, communication between theclients108 and their primary manager, Manager1 (104a) has been lost, as indicated by the broken lines. However, both theclients108 and Manager2 (104b) have been pre-configured for this contingency so that theclients108 automatically switch toManager2. Pre-configuration includes, among other things, the system administrator giving theclients108 the IP address ofManager2 and givingManager2 the authorization to establish secure communications with theclients108. Thus, when the connection betweenManager1 and theclients108 is lost, theclients108 automatically contact the backup manager,Manager2, and establish a secure connection withManager2. IfManager2 is still in communication withManager1, as shown thenetwork connection110 inFIG. 4, it forwards information about theclients108 toManager1. If no connectivity toManager1 remains, thenManager2 acts as the primary manager for the clients. As soon as the normal network paths are restored, theclients108 are configured to try and reestablish secure communications withManager1.
• Because many network topologies can be complex, eachmanager104 may include an option to force theclients108 to contact the backup manager (e.g., Manager2) as a test of the rollover feature. In this way, security administrators need not wait until a crisis strikes to verify that thesystem100 is configured to handle a network disruption. In the event that all communications are lost, theclients108 are configured to try and contact both the primary and backup managers. Theclients108 also queue event information as needed and continue to enforce their respective security policies, ensuring the security of individual end-user platforms102.
• The third component in thesystem100 is theconsole106, which is the main administrative interface for thesystem100. In a preferred embodiment, theconsole106 does not locally store information about thesystem100, since all system information is stored on themanager104. Rather, theconsole106 provides login access to themanager104 from which the data may be retrieved for display. Once logged in, the administrator may view various system parameters and perform configuration management of all system components as needed. Like themanager104, theconsole106 is a dedicated hardware appliance in a preferred embodiment, with the operating system and console software stored on solid-state memory (not expressly shown) for high reliability. Theconsole106 also includes an optical drive to allow installation of software and product licenses as well as allowing the administrator to create backup CD-ROMs of system configuration data if desired.
• In one embodiment, in order to be able to log in, an administrator must insert an electronic token, or e-token, into the console106 (e.g., via a USB port) and enter the proper passphrase in order to access themanager104. During the login process, the administrator can select from a list of authorizedmanagers104 based on information stored on the e-token. If themanager104 is part of a security group and the administrator has the proper access to the group, all themanagers104 and theirrespective clients108 may be visible and accessible from the single login. The administration of a security group via theconsole106 is illustrated inFIG. 5.
• As can be seen, there are two security groups in this example: security group1 (112a) having twomanagers104 managing sixclients108, and security group2 (112b) having onemanager104 managing fiveclients108. Once an administrator (e.g., Administrator A) has successfully logged into one of themanagers104 ofsecurity group1 by inserting the e-token into theconsole106 and entering the appropriate passphrase, the administrator can view and interact with all components of that security group, but not ofsecurity group2. After the administrator has logged off, another administrator (e.g., Administrator B) can plug in his/her e-token and log into themanager104 withinsecurity group2. From this login, the second administrator can view and interact with all the components that are part of this security group, but not ofsecurity group1. This architecture allows different administrators, with different e-tokens, to use the same console to log into different security groups without compromising the security of the system. This architecture also allows flexibility in creating security groups, assigning administrators, and using the e-tokens.
• Viewing of the components of a security group is accomplished via a graphical user interface in theconsole106, which is also typically provided with a high resolution LCD display and video driver that has been optimized for the graphical user interface. Using various graphical control mechanisms, the administrator can see and sort through all themanagers104,clients108, and evenother consoles106. Selecting aclient108 reveals many types of information, including connectivity status, active policy, and configuration history. Similar types of information may also be displayed for amanager104 if selected. Certain data fields (e.g., security policy names) may be directly edited, but attempting to edit other data fields prompts a data entry-like “wizard” by theconsole106. For example, changing the IP address of a manager interface can potentially affectmany clients108, so theconsole106 leads the administrator through the process to ensure thesystem100 continues functioning properly. Theconsole106 may also contain embedded electronic help documentation, with cross-links in some cases to allow an administrator to quickly access important information. When available, theconsole106 can also securely access support servers for downloading upgrades for the console software.
• To effectively enforce the enterprise security policies for the end-user platforms102, theclient108 uses a number of distinct policy mechanisms, including (1) file/directory restrictions, (2) file/directory visibility, (3) file integrity, and (4) packet filtering. Each mechanism is independent of any operating system security features or any third party security software already installed on a platform102. Also, because theclient108 is running in the kernel of the operating system, the policy mechanisms override any other policy that may be present. Following is a discussion of these policy mechanisms.
• The file/directory restriction mechanism restricts access to certain files and directories in a manner similar to that currently available in many operating systems. However, instead of being set by, for example, a Solaris® root level or Windows® administrator level privilege, these files and directories are only accessible to theclient108. Theclient108 can then enforce read, write, or execute attributes, in any combination, and on any file, as set by a properly authorized administrator via theconsole106. These attributes may then be modified by the administrator as needed and implemented as part of the security policy.
• The file/directory visibility mechanism allows the administrator to effectively hide a file or directory. Once hidden, the file or directory cannot be read from, written to, or executed by any means. The only way to access the file or directory again is via an appropriate command (e.g., unhide) from the client108 (via the console106).
• The file integrity mechanism employs the well known security concept of a message digest or “hash.” The message digest or hashing program reads in a variable length file and creates a fixed length output number called a digest or hash. The programs are specialized so that changing even one bit in the file creates a hash that is completely unrelated to the original file. By selecting certain files on which to enforce integrity checks (via the console106), the administrator can instruct theclient108 to create a hash for each of the selected files and store them in a secure location. Depending on the type of file that is being protected and how it is accessed, theclient108 subsequently rehashes the file and compares the new value to the stored value. For example, if the file winword.exe, a Microsoft Word file, is selected for integrity checks, it is only rehashed and tested when the Microsoft Word is started. If the hash values match, the file has not been altered. Otherwise, theclient108 notifies the administrator (via the console106).
• The packet filtering mechanism allows theclient108 to monitor inbound and outbound transmission packets. The administrator may select, via theconsole106, a number of options regarding the packet filtering mechanism, for example, the direction of the packets to monitor, the desired result, interface, protocol, IP addresses, source, and destination ports to build the packet filter policy statement. There may be multiple packet filter policies for a givenclient108, with each policy varying in complexity from the next. In a preferred embodiment, theclient108 enforces the packet filter where the packets come off the network interface card for inbound traffic and where the packets come off the operating system stack for outbound traffic, since these are the optimum points for protecting the platform from a network-based attack or for preventing a user from unauthorized activity across the network.
• These same four mechanisms may also be used internally by theclient108 itself where theclient108 has certain embedded policies that are not to be accessed by the administrator. For example, theclient108 may be hidden on the platform102 using the hide directory policy. Various files and kernel software modules may be identified for file integrity checks to ensure the security software itself is not compromised. There may also be embedded packet filters to look for malformed and other suspicious IP packets. In addition to theclient108, themanager104 andconsole106 may also use these security mechanisms to secure the platform102.
• Installation of theclient108,manager104, andconsole106 may be accomplished via simple “plug and play” installation so that the actions required by the administrator are both intuitive and straightforward, with any system setup complexity handled by the software for each component. The first step in setting up a new system is to configure themanager104 andconsole106, both of which must initially be connected to the same subnet of the network110 (e.g., via an Ethernet cable to the local subnet). After turning on themanager104, the administrator must insert the e-token, which is provided with themanager104, into the USB port on theconsole106. This e-token contains a digital certificate that allows secure and authenticated communication with themanager104. Theconsole106 thereafter prompts the administrator to select a manager from the menu (there can be up to20 managers identified on each e-token) and to enter an initial passphrase to be used for authentication. It is of course possible to require the administrator to simply insert the e-token without entering the passphrase, or vice versa, in order to access themanager104. In any event, once the administrator has selected amanager104 for theclient108, all additionalpotential managers104 naturally drop thatclient108 from their consideration queue.
• As the administrator is going through the above of setup process, themanager104 andconsole106 establish an initial secure connection with each other. Themanager104 periodically broadcasts special IP packets onto thenetwork110 that are picked up by theconsole106. These packets provide information about themanager104 that theconsole106 eventually uses to open a secure connection. Once the administrator has selected themanager104 and passphrase, theconsole106 contact the managers104 (it knows themanager104 is on thenetwork110 from the special packets), establishes an encrypted link, and authenticates themanager100 for via digital certificates, discussed later herein. The relationship between theconsole106 and themanager104 can be authenticated because the e-token is pre-loaded with the digital certificate for themanager104. At no time during this process, which conforms to IPSec standard, is sensitive information exchanged that is not encrypted.
• The reason themanager104 andconsole106 must be set up on the same subnet initially is to set the IP addresses of the two appliances. Once the administrator has successfully logged into themanager104, he/she can set these IP addresses. Theconsole106 andmanager104 can subsequently be relocated to different parts of thenetwork110 within the enterprise as desired, the IP addresses reset, and they will reestablish communication with each other as long as there is an open network path between the two components.
• As for theclient108, this installation process begins with an install program, referred to herein simple as “the client install program.” This small program, which may be copied from a file server, transferred via FTP (File Transfer Protocol), ghost imaged, or even “pushed” from themanager104 itself, must be loaded on every potential end-user platform102 and executed with the appropriate privileges (e.g., administrator privileges for Windows® administrator, root privileges for Solaris®. The client install program thereafter collects information about the potential client, looks for manager identification packets on the network, and sends the information to allmanagers104 that it is able to locate, a process which will be described in more detail later herein. As before, the information is encrypted and authenticated before transmission.
• Once the information is received by themanager104, it is stored in a queue awaiting review by the administrator. Based on the provided system information, such as IP address, operating system, system name, and so forth, the administrator can decide whether or not to install theclient108 and license it to the new platform102. Depending on what licenses were purchased, themanager104 may contain a fixed number of preinstalled server or desktop license packs for theclient108. If the administrator chooses to do an install, one of the licenses for theclient108 is issued and theclient108 is downloaded to the chosen platform102. At the time of initial install, the administrator must also choose a security policy for theclient108 to enforce. This can be either a custom policy built by the administrator, or a default policy developed by a third party.
• As mentioned above, thesystem100 uses an encryption and authentication procedure to secure all communications within the infrastructure. The two major cryptographic technologies used in thesystem100 are digital certificates and data transmission encryption. Thesystem100 makes use of the digital certificates and data transmission encryption technologies in a manner that complies with IPSec, which specifies the standards for authentication, encryption and hashing of files. These technologies are well known to those having ordinary skill in the art and will not be described in detail here. It is sufficient to simply say that, in a preferred embodiment, thesystem100 uses the RSA public key algorithm for authentication and digital signatures, the Triple Data Encryption Standard algorithm (3-DES) for encryption, and the Standard Hash Algorithm algorithm, SHA-1, for hashing of files, which produces a 160-bit hash. For the RSA algorithm, preferably 2048 and 1024-bit keys are used, but smaller or larger keys may also be used without departing from the scope of the invention. In addition, thesystem100 uses the Diffie-Hellman algorithm, which allows two unverified parties to generate and exchange a shared secret key, establish an encrypted link, and exchange messages.
• Authentication and integrity checking in thesystem100 relies on the use of digital certificates to exchange encoded authentication information. Such digital certificates are frequently used to distribute public encryption keys ensure the identify the issuer of the These certificates may be encoded, for example, using the standard Abstract Syntax Notation (ASN.1), and the keys and hashes used for encoding the digital certificates may be generated using the RSA and SHA-1 algorithms, respectively. The digital certificates themselves are then assembled in the format specified by, for example, the X.509 standard,version 3. The X.509 standard is entitled “Certificates and Certificate Revocation Lists” and is an ITU (International Telecommunication Union) and ISO (International Standards Organization) standard. This standard provides an exemplary format for the basic, pre-defined fields and extensions used in digital certificates, although other standards may certainly be used without departing from the scope of the invention. The X.509 standard data fields include the version of the certificate, certificate serial number, signature algorithm identifier, issuer, validity period, subject, subject public key, issuer unique identifier, subject unique identifier, and extensions. The subject in this case is the owner of the public key published in the certificate and the issuer is the organization or application that assembled and signed the certificate. The certificate may also contain additional information about the subject and issuer.
• Thesystem100 creates and uses many different types of digital certificates. Although each is unique, they can be grouped based upon their use as shown in Table 1 below.

• TABLE 1
  Group	Certificate
  System	Manager Certificate, Appliance Generation Certificate,
  	Console Certificate, Client Certificate, Install Certificate
  License	Product Certificate, Vendor Generation Certificate, Vendor
  	Certificate, License Certificate, Maintenance Certificate
  Other	Root Certificate, Administrator Generation Certificate,
  	Administrator Certificate

• The first group of digital certificates contains system information. Each of these digital certificates contains data fields that uniquely identify theclient108,manager104, orconsole106. These digital certificates are used to mutually authenticate theclient108 andmanager104 in the manner discussed earlier. The second group of digital certificates contains information used for software license management. The combination of these two groups of digital certificates determines what software the customer is authorized to load, run, and upgrade. Thesystem100 may also use the digital certificates to manage the licenses for the system's own software, and can extend this licensing mechanism to license third party applications to run over thesystem100. Finally, the administrator and root digital certificates contain information used for granting an administrator access to thesystem100. A detailed description of these certificates and their uses are provided in the following discussion.
• With respect to the Platform certificates, it should first be noted that the modular nature of IPSec allows for many forms of authentication. Thus, although embodiments of the invention use digital certificates because of their security, strength and flexibility, other forms of authentication information may certainly be used without departing from the scope of the invention. The Platform certificates in particular are used to mutually authenticate various components (e.g.,manager104,console106, and client108) of the infrastructure in thesystem100. These digital certificates (as well as the License and Other digital certificates) are defined in terms of the number of levels removed from a Root Certificate, which is the highest level (level 1) digital certificate used in thesystem100. The digital certificates for each level are then digitally signed using a private key affiliated with the next higher level digital certificate in the system hierarchy, as illustrated inFIG. 6.
• As can be seen inFIG. 6,level 1 is occupied by theRoot Certificate600, the private key from which is used to sign theAppliance Generation Certificate602, alevel 2 certificate. The private key from theAppliance Generation Certificate602 is then used to sign thelevel 3 certificates, namely, theManager Certificate604, theConsoles Certificate606, and the InstallCertificate608. The private key from theManager Certificate604 is then used to sign theClient Certificate610, which is alevel 4 certificate.
• To build the Manager Certificate, several system parameters are collected after themanager104 software is installed on themanager104 hardware. Formanagers104 running the Microsoft Windows® embedded XP operating system, for example, the Windows system ID (SID), Windows OS build, and microprocessor serial number are collected. These parameters together uniquely identify themanager104 and are difficult to change without major system rebuilding. This information is then embedded in the Manager Certificate and stored on themanager104. An example of some of the data fields along with sample data for theManager Certificate604 is shown in Table 2.

• 	TABLE 2
  	Field	Data
  	Serial Number	A47FA35E-53E696D7-09C9F455-10694156
  	Common Name	ECM Security Appliance
  	Description	Platform Type: Manager
  	Description	Windows Platform SID: S-1-5-21-1993962763-
  		789336058-1060284298
  	Description	Windows Operating System Build Number: 2600
  	Description	Processor Serial Number: 123456789

• In Table 2, the first column contains the names of data fields and the second column contains the data for each field. The data for the Serial Number field, for example, is the UUID (Universal Unique Identifier) of themanager104, the data for the Common Name field is the name of the product, and the unique manager parameters are used for each of the desired Description fields. The RSA algorithm is used to produce a public/private key pair that will only be employed by thismanager104. The public key is then inserted into theManager Certificate604 and the private key is stored in a secure location on themanager104. Finally, theentire Manager Certificate604 is digitally signed with a private key associated with thelevel 2 certificate, namely theAppliance Generation Certificate602, and stored on themanager104 along with theRoot Certificate600 and theAppliance Generation Certificate602. Themanager104 may then issue itsManager Certificate604 whenever it needs to authenticate itself to anothersystem100 component.
• As can be seen from the foregoing, the authentication process relies on the integrity of a series of public keys, one from each level of the certificate tree. In addition to eachmanager104 having its own public/private key pair, it also contains the public keys from theRoot Certificate600 and theAppliance Generation Certificate602 as part of its keychain. Because thesame level 2 private key is used to sign alllevel 3 Platform certificates, thelevel 2 public key from theAppliance Generation Certificate602 may be used to verify the digital signature of anotherlevel 3 certificate, for example, the certificate for anyother manager104. Once the digital signature is verified, the receiver is assured that the information in thelevel 3 certificate has not been altered. The receiver is also assured that thelevel 3 certificate truly came from the identified sender, in this case, anothermanager104, aconsole106, or a Client Setup program (discussed later herein), because only thelevel 2 private key could have been used to sign the certificates (e.g., during the manufacturing of the components).
• TheConsole Certificate606 is similar to theManager Certificate604 except that its platform type is “Console.” It is signed by thesame level 2 private key (e.g., during manufacture) and contains the correspondinglevel 2 public key as well.
• TheClient Certificate608 is somewhat similar in structure to the certificates of themanager104 andconsole106, but different in origin. Before discussing this certificate, it is instructive to understand how theclient108 software is installed. Theclient108 is a piece of software loaded on an end-user platform102 (e.g., a laptop, desktop, server, mobile terminal, etc.). The loading of this software is done from themanager104, but first themanager104 needs to obtain several parameters from the target end-user platform102. To facilitate this process, embodiments of the invention use a software application called a Client Setup program. This application should be loaded by the enterprise system administrator using any suitable technique, for example, ghost images, copying across the network from a shared file server, or copying the Client Setup program machine-by-machine from a CD-ROM. Regardless of the installation technique, the Client Setup program should be run with the appropriate level of privilege, for example, root privileges on a Solaris® platform or administrator privileges on a Windows® platform.
• The Client Setup program is designed to collect certain types of information from the target end-user platform102, establish an initial secure session with the manager104 (e.g., via IPSec), and assist in the installation of theactual client108 software. The types of information collected from the target end-user platform102 include, for example, the Windows SID and the Windows OS build for Microsoft-based systems and the Host ID and Solaris version for Solaris-based systems. Once this information is gathered, the Client Setup program attempts to establish communications with themanager104. If theclient108 is on the same subnet as themanager104, it automatically discovers themanager104. If themanager104 is located beyond the local subnet, the IP address of themanager104 must be provided to the Client Setup program (e.g., by the administrator). This IP address can be provided with the copy of the Client Setup program, that is, with the ghost image or file server copy, or it can be entered interactively from theclient108 itself.
• After initial communication is established, the Client Setup program (via the target end-user platform102) and themanager104 establish a secure link with each other (e.g., via IPSec). Thereafter, authentication from the Client Setup program to themanager104 is accomplished using the InstallCertificate608. This certificate is included with the Client Setup program and contains information about the Client Setup program, but more importantly, is signed by thesame level 2 private key used to generate the certificates for the Client Setup program and themanager104. When the Client Setup program passes the Install Certificate to themanager104, themanager104 can use the public key from itsAppliance Generation Certificate602 to authenticate the Client Setup program. Once authenticated, the Client Setup program sends the end-user platform102 specific information it has collected across the secure link to themanager104. This information is then queued for review by an enterprise administrator for approval.
• Upon approval of the enterprise administrator, themanager104 begins installing theclient108 software. In a preferred embodiment, themanager104 first checks with the License Certificate (described later herein) stored on themanager104 to make sure that there are proper client licenses available of the given type (e.g., laptops, desktops, servers, etc.). Next, themanager104 takes the end-user platform specific information passed by the Client Setup program and generates theClient Certificate610. Unlike themanager104,console106, and Client Setup program that have their digital certificates generated by a common source (e.g., the manufacturer), theClient Certificate610 is dynamically generated by themanager104. This digital certificate looks very similar to those used by themanager104 andconsole106, except that the data fields describe the end-user platform102 as a desktop or server, Sun or Windows platform, and so forth. Samples of the data fields used in theClient Certificate610 for a Solaris server are shown in Table 3.

• 	TABLE 3
  	Fields	Data
  	Serial Number	BCB45690-5C47B890-DF436713-BDB5F5B6
  	Common Name	ECM ® Platform Client
  	Description	Platform Type: Server
  	Description	Solaris Version: 5.9
  	Description	Solaris HostID: 830c3b8b

• For the Serial Number, themanager104 uses the UUID that uniquely identifies the target end-user platform102. The Common Name and Description fields are also filled in with the appropriate information. Themanager104 then generates alevel4 public/private key pair for thenew client108 and embeds the public key in theClient Certificate610. Themanager104 then hashes theClient Certificate610, encrypts the hash with itslevel3 private key, and digitally signs the certificate by appending the encrypted hash. Thislevel4 certificate may now be used by thenew client108 for all future authentication of thenew client108.
• As a final step, themanager104 pushes theentire client108 software, along with theManager Certificate604, theClient Certificate610, theRoot Certificate600, and thePlatform Generation Certificate602, across the secure link to the target end-user platform102. Once the transfer is complete, the Client Setup program shuts itself down on the target end-user platform102 where it has been running, and theclient108 software starts up in the kernel of the operating system. Theclient108 may thereafter establish a new secure connection (e.g., via IPSec) with themanager104 using theManager Certificate604 andClient Certificate610 to thereby become an active component of thesystem100.
• In addition to the Platform certificates that are used to establish secure communication within thesystem100, thesystem100 also uses License certificates to secure the software applications that are being run on thesystem100. The License certificates are used to: (1) ensure non-compromised software is running on the end-user platforms102, (2) ensure the software is properly licensed/purchased, and (3) provide a mechanism for software maintenance enforcement. To ensure non-compromised software is running on the end-user platforms102, embodiments of the invention provide a Product Certificate. To ensure software is properly licensed/purchased, embodiments of the invention provide a License Certificate. To provide a mechanism for software maintenance enforcement, embodiments of the invention provide a Maintenance Certificate. And to ensure future extensibility to third-party developers, embodiments of the invention also provide software licensing over the secure connection established using the Platform certificates to third parties. Indeed, the software used by the various components of thesystem100 may be licensed using this same mechanism. These various License certificates are illustrated with respect toFIGS. 7A-7C.
• As can be seen inFIG. 7A, certificates are again defined in terms of the number of levels removed from the Root Certificate. Thus, at the highest level is theRoot Certificate600, the private key from which is used to sign a Vendor Generation Certificate700 (alevel 2 certificate). TheVendor Generation Certificate700 may then use its private key to sign aVendor Certificate702 for purposes of verifying the identity of the vendor of the software running on themanager104. TheVendor Certificate702 may then use its private key to sign aProduct Certificate704 for each piece of distinct software running on themanager104. TheProduct Certificate704 may then be used for purposes of verifying the integrity of the software associated with the certificate.
• EachProduct Certificate704 includes the public key from theVendor Certificate702 and is signed using the corresponding private key of theVendor Certificate702. In particular, when a new release of software is ready for distribution, aProduct Certificate704 is produced by hashing the software's binary file and obtaining a hash value using the SHA-1 algorithm. This hash value, along with the software release information, is embedded in theProduct Certificate704. Examples of the data fields used in the Product Certificate for themanager104 software application are shown in Table 4.

• TABLE 4
  Fields	Data
  Serial Number	678BEC1E-11BCE45D-034EC3A8-CC678123
  Common Name	ECM ® Product Certificate
  Description	Product: ctManager
  Description	Vendor: CoreTrace
  Description	Product Version: XDTEAL-9-1-12
  Description	Date: 2004022700000OZ
  Description	SHA1: e9a6b7dfb77170f03160404371f8ed5f952713f4

• The Serial Number field again contains the UUID for just this software release; the Common Name shows this certificate is a product certificate; and the Description fields are expanded to show the unique parameters for this software release. A key field in this certificate is the hash value, which ideally remains the same for all releases of the software. As such, the various software in the system are developed in a controlled manner such that a source file compiled in the future should have an identical binary file to one that was compiled previously. This kind of software control is needed to produce a unique hash value that is repeatable for each piece of software. Once completed, theProduct Certificate704 may be used to test and verify the integrity of the software associated with the certificate.
• Embodiments of the invention provide two distinct aspects to testing software integrity. The first test determines whether the binary file on the disk is a legitimate, non-compromised system application. The second test determines whether the image of the software running on themanager104 is the same as the file stored on themanager104. During assembly of themanager104, themanager104 software application binary file and itsaffiliated Product Certificate704 are loaded onto the solid-state memory of the manager104 (or a hard drive in some cases). Then, as part of the startup process, and at certain intervals while themanager104 software application is running, the certificate handling subroutines of themanager104 software performs an integrity test. In one implementation, themanager104 uses the public key from theVendor Certificate702 to verify the digital signature on theProduct Certificate704. The certificate itself is then hashed and the hash value checked to ensure it has not been compromised. Because the image of themanager104 software application in memory is doing the testing, the integrity of that image first needs to be tested. Accordingly, the image in memory is also hashed, the binary file stored in the solid-state memory (or hard disk) is hashed, and the two hash values are compared. If the hash values match, it may be assumed that the image in memory has not been corrupted from the original file. If there is no match, themanager104 is designed to cease operations immediately. Assuming the hash values match, they are next compared to the hash value from the Description field SHA1 in theProduct Certificate704. If these two match, then it may be assumed that the binary file has not been modified from its original form, either in memory or as stored.
• In addition to theProduct Certificate704 for each piece of software, there may also be aLicense Certificate706 and aMaintenance Certificate708, as illustrated in,FIG. 7B. TheLicense Certificate706 is used to determine whether the user has obtained the right to run the software and theMaintenance Certificate708 is used to determine whether the user has obtained the right to upgrade the software. Like theProduct Certificate704, theLicense Certificate706 and theMaintenance Certificate708 are signed by thelevel 3 private key of the Vendor Certificate702 (e.g., during manufacture) used for vendor identification.
• Turning now to theLicense Certificate706, the certificate is used to authorize the use of specific software on a specific computing platform. Table 5 shows examples of the data fields used in theLicense Certificate706 for amanager104 software application.

• 	TABLE 5
  	Fields	Data
  	Serial Number	A47FA35E-53E696D7-09C9F455-10694156
  	Common Name	ECM ® License Certificate
  	Description	Product: ctManager
  	Description	Vendor: CoreTrace
  	Description	Platform Type: Manager
  	Description	License Count: 1
  	Description	License Serial No.: 2CFB97EA-DD2C6486-
  		BE8B577A-5D4DE791
  	Description	License Pack: False
  	Description	License Pack Serial Number:

• As can be seen, this certificate is somewhat different than previously described certificates in that the Serial Number field is not the UUID for this certificate. Instead, the Serial Number field contains the UUID of the computing platform, namely, themanager104, on which this software is allowed to run. It is the License Serial Number field that contains the unique UUID for theLicense Certificate706. The remaining fields show that this certificate is for amanager104 software application and that one copy is licensed to run.
• TheLicense Certificate706 is then used as part of another self-test following the integrity checks (using theProduct Certificate704 described earlier). First, the integrity of theLicense Certificate706 is determined using the public key from theVendor Certificate702. Next, the platform UUID from the Manager Certificate604 (seeFIG. 6) is compared to the platform UUID in theLicense Certificate706. If the two UUIDs match, then it can be assumed that the software is authorized to run on thismanager104. Finally, the product name and the vendor name are compared to those in theProduct Certificate704 to ensure that the correct product is running.
• There may be multiple licenses stored on themanager104. For example, in addition to the license for themanager104 software application itself, themanager104 may contain licenses for all of theclients108 managed via themanager104. Thus, embodiments of the invention also provideLicense Pack Certificates710 instead or in addition to theLicense Certificate706, as illustrated inFIG. 7C. TheLicense Pack Certificate710 contain data fields that allow themanager104 to install and issue multiple copies of theclient108 software, which may be sold in license packs with specific numbers of copies (e.g., 50, 100, 250, 500, etc.). ALicense Pack Certificate710 for these license packs may be pre-installed (e.g., at the time of manufacturer) or the customer can purchase additional license packs as needed. Examples of the data fields used in aLicense Pack Certificate710 in Table 6.

• TABLE 6
  Fields	Data
  Serial Number	A47FA35E-53E696D7-09C9F455-10694156
  Common Name	ECM ® Product License
  Description	Product: ctClient
  Description	Vendor: CoreTrace
  Description	Platform Type: Desktop
  Description	License Count: 50
  Description	License Serial No.: 2CFB97EA-DD2C6486-BE8B577A-
  	5D4DE791
  Description	License Pack: True
  Description	License Pack Serial No.: 2CFB97EA-DD2C6486-
  	BE8B577A-5D4DE791

• Note that the Serial Number field in Table 6 contains the same UUID as in the previous example, indicating that this license pack can only be used on thesame manager104 as before. The particularLicense Pack Certificate710 shown here allows themanager104 to install 50 copies of the desktop version of theclient108 software application. Note also that the License Pack Serial Number field in Table 6 contains the same UUID as the License Serial Number. This License Serial Number is subsequently included in alevel 5License Certificate712 generated by themanager104 when it installs each copy of theclient108 software. The main difference between thelevel 5License Certificate712 andlevel 4License Certificate706 ofFIG. 7B (and the corresponding Maintenance Certificates) is that thelevel 4 versions are used for the software of themanager104 and theconsole106, whereas thelevel 5 versions are used for theclient108.
• For each copy of theclient108 software application, themanager104 generates alevel 5License Certificate712 to go with that copy of theclient108 software application. TheLicense Certificate712 is similar to theClient Certificate610 discussed previously (seeFIG. 6) except that this certificate is signed by the private key from theLicense Pack Certificate710 instead of the private key from theManager Certificate604. TheLicense Certificate712 may then be transferred to the target end-user platform102 (along with the level 1-4 License certificates), then used for controlling theclient108 software from themanager104. Note that the level 1-4 License Certificates must be authenticated in order to make any change to the licensing of theclient108 software. Examples of the data fields used in theLicense Certificate712 are shown in Table 7.

• 	TABLE 7
  	Fields	Data
  	Serial Number	BCB45690-5C47B890-DF436713-BDB5F5B6
  	Common Name	ECM ® Product License
  	Description	Product: ctClient
  	Description	Vendor: CoreTrace
  	Description	Platform Type: Server
  	Description	License Count: 1
  	Description	License Serial Number: 8785C432-67BCD241-
  		777FDE45-45E32178
  	Description	License Pack: False
  	Description	License Pack Serial No: 2CFB97EA-DD2C6486-
  		BE8B577A-5D4DE791

• For the most part, this certificate is similar to the License Certificate706 (seeFIG. 7B) described earlier for licensing themanager104 software application. Note, however, that the License Pack Serial Number field is filled in with data linking this certificate back to theLicense Pack Certificate710 from which it came from. The Serial Number field contains the UUID for the target end-user platform102 and the License Serial Number field contains the unique UUID for theLicense Certificate712 itself.
• As for theMaintenance Certificate708, referring back toFIG. 7B, eachsoftware License Certificate706 is preferably accompanied by one ormore Maintenance Certificates708. These certificates are issued when the users buy their initial or continuing software maintenance support and are consulted by themanager104 to determine if the user is eligible to upgrade his/her software. Examples of the data fields used in the Maintenance Certificate for atypical client108 software application are shown in Table 8.

• 	TABLE 8
  	Fields	Data
  	Serial Number	BCB45690-5C47B890-DF436713-BDB5F5B6
  	Common Name	ECM ® Maintenance License
  	Description	Product: ctClient
  	Description	Vendor: CoreTrace
  	Description	License Serial No.: 8785C432-67BCD241-
  		777FDE45-45E32178
  	Description	Valid Start: 2004010100000OZ
  	Description	Valid End: 20041231235959Z

• The Serial Number field in Table 8 reflects the UUID of the target computing platform, namely, the end-user platform102. The License Serial Number corresponds to the License Certificate for theclient108 software application in the previous example. The most important data fields in this certificate are the Valid Start and Valid End dates of the maintenance period. The user is allowed to download the latest software (e.g., thelatest manager104 software application) via themanager104 at any time during this period. Outside this period, the user may still be able to download latest software, but themanager104 will only execute the previous version (based on the date in the product version field of theProduct Certificate704 of the software) and not the new version.
• AMaintenance Pack Certificate714 corresponding to theLicense Pack Certificate710 is also available for downloading multiple updates of theclient108 software application. Themanager104 consults theMaintenance Pack Certificates714 to see which target end-user platform'sclient108 software application is eligible for upgrade. Each download of the latest version of theclient108 software application will be stored along with the previous version on themanager104. At the time of the download, a corresponding Product Certificate704 (seeFIG. 7A) is provided to ensure the integrity and authenticity of theclient108 software application in the manner mentioned earlier. It is possible someclient108 software application may have had their maintenance renewed and others have not. Themanager104 will check to see if the product release date from theProduct Certificate704 is in the Valid Start to Valid End window provided byMaintenance Pack Certificate712. If it is, then the user has a valid maintenance contract and themanager104 will allow the enterprise administrator to upgrade theeligible client108 software applications. If so, each approvedclient108 will receive upgraded software.
• The foregoing License certificates are used to assemble a keychain of public keys similar to the Platform certificates (FIG. 6). These keys, in turn, are used for authentication of the next higher level certificates. Thesystem100 uses thelevel 2 private key associated with the Vendor Generation Certificate to sign thelevel 3 the Vendor Certificate. This certificate along with its private key may then be produced for third-party developers interested in developing software for operating over thesystem100. The third-party developers may then produce theirown level 4 certificates for their specific products. Thesystem100 will recognize these certificates and enforce the appropriate licensing and maintenance policies. This scheme is already in effect for control of the software running the various components of thesystem100 and provides many added benefits for third-party developers.
• The final certificates that are discussed are the Root Certificate, the Administrator Generation Certificate, and the Administrator Certificate, the hierarchy for which is shown inFIG. 8. These keys are unique in both their creation and use in thesystem100. The private key affiliated with theRoot Certificate600 is used to sign alllevel 2 certificates in the keychain and the corresponding public key, which is contained in theRoot Certificate600 itself, is used to authenticate alllevel 2 certificates. The private key associated with theAdministrator Generation Certificate800 is used to sign theAdministrator Certificate802 and the corresponding public key, which is contained in the Administrator Generation Certificate itself, is used to authenticate theAdministrator Certificate802. TheAdministrator Certificate802 is used to identify various individuals to thesystem100 and manage their level of access to system resources via the e-token mentioned previously.
• With the above closed public-key infrastructure, there is no need for a separate Certificate Authority to issue and sign digital certificates. That is, theRoot Certificate600 may be self-signed using its own private key. To maintain the integrity of theentire system100, two-person control of Root Certificate private key should be maintained at all times. In addition, the Root Certificate private key should be loaded only as needed, and only onto a single, non-networked computer to generate and sign additional digital certificates. When not needed, this Root Certificate private key should be maintained under physical lock and key in a secure vault.
• As alluded to previously, embodiments of the invention use a two-part authentication scheme that includes an e-token (not expressly shown) that may be plugged into theconsole106 and in some cases a 32-character passphrase provided by the administrator. The e-token is designed to produce an RSA key pair from its on-board hardware and can also store certain electronic information in its on-board solid state memory. In addition, the e-token is designed to the very secure in that the private key cannot be extracted from the hardware except as used for authentication. This security allows the e-token to be used to generateadditional Administrator Certificates802 as needed, as explained below.
• Generation of theAdministrator Certificate802 is performed by the manufacturer of themanagers104, preferably at the same time themanagers104 are assembled. Information collected from themanager104 is then embedded in theAdministrator Certificate802. Examples of the data fields used in theAdministrator Certificate802 are shown in Table 9.

• 	TABLE 9
  	Fields	Data
  	Serial Number	542899F1-DAC43218-A1A1A1B2-986FC345
  	Common Name	ECM ® Admin
  	Description	Platform ID: A47FA35E-53E696D7-09C9F455-
  		10694156
  	Description	Platform P/N: ECM-3000-WO1
  	Description	Mac0: 08:00:20:1d:7d:83
  	Description	Mac1: 00:02:b3:c3:66:d0

• The Serial Number data field in the above table contains a UUID for this certificate and, as will be seen shortly, uniquely identifies this administrator during login. The Platform ID data field contains the UUID of themanager104 and the Mac0 and Mac1 data fields contain the MAC addresses of the two network interface cards on thisparticular manager104. TheAdministrator Certificate802 is different in form from the other certificates described thus far in that the embedded public key is that of the e-token and the certificate is signed by the private key affiliated with theAdministrator Generation Certificate800. Once theAdministrator Certificate800 to is assembled by the manufacturer, it is written to the memory of the e-token.
• To log in, the administrator inserts the e-token into theconsole106 to begin the login process. Theconsole106 extracts theAdministrator Certificate802 from the e-token and uses the public key from theAdministrator Generator Certificate800 to verify the extracted information. Then, using the MAC address information, or information cached on the electronic token, or user supplied information, theconsole106 sets up an encrypted link to theappropriate manager104 and sends theAdministrator Certificate802 to themanager104. Theconsole106 then prompts the administrator for a passphrase, performs a hash of the phrase, encrypts it with the private key from the e-token, and transmits it to themanager104.
• Themanager104 first verifies the information in the Administrator Certificate and extracts the public key of the e-token. When theconsole106 sends the encrypted hash of the passphrase, themanager104 uses the public key of the e-token to decrypt it and then compares the hash value with the value that the administrator last used to login. If the two match, the administrator has passed the two-part login, and themanager104 provides him/her with administrative access to thesystem100.
• The foregoing digital certificates are used extensively for infrastructure, licensing, and administrative management of thesystem100. The following table, Table 10, provides a quick summary of the primary use of the public key, private key, and data fields for each certificate. This table is not intended to be a comprehensive list, but simple reflect the above discussion.

• TABLE 10
  Certificate	Primary Uses

  MANAGER

  Root Certificate	Public Key - Authenticate the Appliance Generation Certificate, the
  	Vendor Generation Certificate, the Administrator Generation Certificate,
  	Software Checks
  Appliance Generation	Public Key - Authenticate the Manager Certificate, the Console
  Certificate	Certificate, the Install Certificate
  Manager Certificate	Public Key - Authenticate the Client Certificate
  	Data Fields - Identify Specific Manager
  	Private Key - Client Certificate
  Vendor Generation	Public Key - Authenticate the Vendor Certificate
  Certificate
  Vendor Certificate	Public Key - Authenticate the Product Certificate, License Certificate,
  	and Maintenance Certificate
  Product Certificate	Data Fields - Identify Specific Software Release
  License Certificate	Data Fields - Identify Specific Licensed Software
  Maintenance	Data Fields - Identify Specific Maintenance Period
  Certificate
  Administrator	Public Key - Authenticate Electronic Token
  Certificate	Data Fields - Identify Specific Administrator

  CONSOLE

  Root Certificate	Public Key - Authenticate the Appliance Generation Certificate, the
  	Vendor Generation Certificate, the Administrator Generation Certificate,
  	Software Checks
  Appliance Generation	Public Key - Authenticate the Manager Certificate, the Console
  Certificate	Certificate
  Console Certificate	Data Fields - Identify Specific Console
  Vendor Generation	Public Key - Authenticate the Vendor Certificate
  Certificate
  Vendor Certificate	Public Key - Authenticate the Product Certificate, License Certificate,
  	and Maintenance Certificate
  Product Certificate	Data Fields - Identify Specific Software Release
  License Certificate	Data Fields - Identify Specific Licensed Software
  Maintenance	Data Fields - Identify Specific Maintenance Period
  Certificate

  PLATFORM

  Root Certificate	Public Key - Authenticate the Appliance Generation Certificate, the
  	Vendor Generation Certificate, the Administrator Generation Certificate,
  	Software Checks
  Appliance Generation	Public Key - Authenticate the Manager Certificate
  Certificate
  Manager Certificate	Public Key - Authenticate the Client Certificate
  Client Certificate	Data Fields - Identify Specific Client
  Vendor Generation	Public Key - Authenticate the Vendor Certificate
  Certificate
  Vendor Certificate	Public Key - Authenticate the Product Certificate, License Certificate,
  	and Maintenance Certificate
  Product Certificate	Data Fields - Identify Specific Software Release
  License Certificate	Data Fields - Identify Specific Licensed Software
  Maintenance	Data Fields - Identify Specific Maintenance Period
  Certificate

• One additional use for the digital certificates in thesystem100 is to ensure all system components come up in the intended secure fashion when power fails, systems intentionally reboot, or when they are started for the first time. The various system software applications are designed to minimize the possibility of system compromise and licensing theft. Specifically, once a system software application is installed on a computing platform, it will only run on that particular hardware platform. On startup, themanager104 software will first go to its certificate file and read theRoot Certificate600. The certificate handling routine of themanager104 software sees the certificate is self-signed and will directly extract the public key from the certificate. Themanager104 software then uses this key to decrypt the signatures on both theAppliance Generation Certificate602 and theVendor Generation Certificate700, obtain their hash values, and compare those values against the hash values it calculated from the twocertificates602 and700. In addition, themanager104 software will check the data fields included within the certificate. This is done to verify the integrity and authenticity of the public keys that are extracted from these twocertificates602 and700.
• Assuming the certificates are correct, themanager104 software uses the public key of theAppliance Generation Certificate602 to decrypt the signatures of theManager Certificate604, and obtain its hash value. Assuming the hash value matches the expected value, themanager104 software loads the public key from this certificate into memory with the previous three keys and then perform its last integrity check. It will check the local system for Windows SID, Windows OS build, and Pentium CPU serial number. These values will be compared to those in the Manager Certificate. If they match, the application is running on the proper platform and has not been copied.
• If at any time during this startup process a security test or check does not pass, themanager104 software is designed to cease operating and, in a preferred embodiment, must be returned to the manufacturer for a replacement (and an investigation into the security breach).
• While the invention has been described with respect to a number of specific embodiments, those skilled in the art will recognize that the innovative concepts described herein can be modified and varied over a wide range of applications. For example, while the license management features herein have been discussed primarily with respect to software applications, the invention may be equally applicable to any type of electronic data, including application files (e.g., drivers, libraries, etc.), digital audio files, digital image files, digital video files, digital data files, and the like, whether executable or otherwise. Moreover, although the invention has been described primarily with respect to digital certificates, any type of digital authentication information, in any suitable format, may be used without departing from the scope of the invention. Accordingly, the scope of the invention should not be limited to any of the specific exemplary teachings discussed, but is instead defined by the following claims.

Claims (21)

1-26. (canceled)

27. A method for authenticating a plurality of computing platforms, the method comprising:

generating platform level authentication information;

using said platform level authentication information to generate appliance level authentication information, said appliance level authentication information unique to each appliance and allowing all appliances to authenticate one another;

using at least a portion of said appliance level authentication information to generate client level authentication information, said client level authentication information unique to each end-user platform and allowing said appliances to authenticate said end-user platforms;

generating administration level authentication information for allowing an administrator to be authenticated by said appliances; and

using said administration level authentication information to generate electronic token level authentication information, said electronic token level authentication information unique to an electronic token used by an administrator for logging in to said appliances, said electronic token level authentication information allowing said appliances to authenticate said administrator.

28. The method ofclaim 27, wherein the generation of administration level authentication information comprises storing an administrator certificate, said administrator certificate unique to the administrator and digitally signed via a private key unique to an administrator-generation certificate.

29. The method according toclaim 27, further comprising generating vendor level authentication information for allowing a vendor to authenticate said vendor's software products.

30. The method according toclaim 29, further comprising using said vendor level authentication information to generate product level authentication information, said product level authentication information unique to a software for verifying that said software is not corrupted.

31. The method according toclaim 28, further comprising using said vendor level authentication information to generate licensing level authentication information, said licensing level authentication information unique to an appliance for verifying that a software is authorized to be used by said appliance.

32. The method according toclaim 28, further comprising using said vendor level authentication information to generate maintenance level authentication information, said maintenance level authentication information unique to a software for verifying that said software is authorized to be maintained.

33. The method according toclaim 27, further comprising generating root level authentication, said root level authentication information being self-authenticating and usable to generate said platform level authentication information.

34. The method according toclaim 27, wherein all authentication information is in the form of digital certificates.

35. A method of establishing a secure environment for an end-user platform and a system manager usable to manage the end-user platform, comprising:

storing manager authentication information on the system manager, the manager authentication information unique to the system manager;

generating client authentication information on the system manager for the end-user platform, the client authentication information unique to the end-user platform and operable to be authenticated via the manager authentication information;

transferring the client authentication information from the system manager to the end-user platform;

storing vendor-generation authentication information on the system manager;

storing vendor authentication information, the vendor authentication information unique to a software vendor and operable to be authenticated via the vendor-generation authentication information;

generating license authentication information on the system manager, the license authentication information unique to an authorization of use of a software of the software vendor on a specifically-identified appliance, the software stored on the system manager, the license authentication information operable to be authenticated via the vendor authentication information;

wherein the specifically-identified appliance is at least one of the system manager and the end-user platform;

verifying that the software is licensed for use on the at least one of the system manager and the end-user platform, the verification comprising comparing the license authentication information to at least one of the manager authentication information and the client authentication information; and

wherein the system manager is resident on one or more computers having at least a processor and memory, the method being performed by the one or more computers.

36. The method according toclaim 35, further comprising loading installation authentication information on the end-user platform for allowing the system manager to verify that the end-user platform has been designated to be managed from the system manager.

37. The method according toclaim 36, wherein the manager authentication information and the installation authentication information are derived from a common source of authentication information.

38. The method according toclaim 35, further comprising storing console authentication information on a console operable to access the system manager, the console authentication information unique to the console for allowing the system manager to authenticate the console.

39. The method according toclaim 38, further comprising allowing the console to authenticate the system manager using the manager authentication information.

40. The method according toclaim 35, further comprising storing product authentication information on the system manager, the product authentication information operable to be authenticated via the vendor authentication information, the product authentication information unique to the software stored on the system manager, the product authentication information allowing the system manager to verify that the software stored on the system manager is not corrupted.

41. The method according toclaim 40, wherein the product authentication information further allows the system manager to verify that the software running in a memory of the system manager is not corrupted.

42. The method according toclaim 35, further comprising wherein the license authentication information comprises manager-license authentication information and the at least one of the system manager and the end-user platform comprises the system manager.

43. The method according toclaim 35, further comprising:

wherein the license authentication information includes information specifying one or more software to be managed by the system manager;

transferring the license authentication information to the end-user platform; and

wherein the at least one of the system manager and the end-user platform comprises the end-user platform.

44. The method according toclaim 42, wherein the software includes one or more of the following: application files, data files, audio files, image files, video files.

45. The method according toclaim 35, further comprising storing manager-maintenance authentication information on the system manager, the manager-maintenance authentication information operable to be authenticated via the vendor authentication information, the manager-maintenance authentication information uniquely identifying the software and allowing the system manager to verify that the software is authorized for maintenance on the system manager.

46. The method according toclaim 45, wherein the manager-maintenance authentication information includes information specifying one or more software authorized to be maintained via the system manager, further comprising generating an end-user platform maintenance authentication information for the one or more software authorized to be maintained and transferring the end-user platform maintenance authentication information to the end-user platform.

Images