System and method for generation of a signature certificate in a public key infrastructure

BACKGROUND

Field of the Invention

This invention relates to Public Key Infrastructures (PKI), and more specifically to generation of signature certificates in a PKI.

Background Information

A public key infrastructure (PKI) is a collection of servers and software that enables an organization, company, or enterprise to distribute and manage thousands of unique public/private cryptographic keys in a manner that allows users to reliably determine the identity of the owner of each public/private key pair. When each member of an enterprise has a unique key, paper-based business processes may be transitioned to an online, electronic equivalent. Public/private key pairs have the property that for any given public key there exists one and only one private key, and vice versa. Public key cryptography (i.e., the ability to publicly distribute the encryption key) can be used to digitally sign documents. If a particular message can be decrypted using one member of the key pair, then the assumption is that the message must have been encrypted using the other member. If only one person knows the key used to perform the encryption of a document in the first place, then the recipients that can decrypt the document can be sure that the sender of the document must be that person.

However, for a digital signature to be meaningful, the recipient of an object signed with the digital signature must first be able to reliably determine the owner and integrity of the key used to sign the object. Public infrastructures accomplish this using an electronic document called a digital certificate. Certificates may contain information identifying the owner of the key pair, the public component of the pair, and the period of time for which the certificate is valid. The certificate may also identify technical information about the key itself, such as the algorithm used to generate the key, and the key length. Certificates are generated by organizations, companies, or enterprises that are responsible for verifying the identity of individuals (or in some instances organizations) to which certificates are issued. The certifying organization is known as a certificate authority. The certificate authority signs each certificate using a private key known only to the certificate authority itself. This allows users of the PKI to verify both the integrity of the certificate and the identity of the authority that issued it. By issuing a certificate, a certificate authority is stating that it has verified that the public key that appears in the certificate (and, by extension, the corresponding private key) belongs to the individual listed in the certificate. The integrity with which the registration process operates is, therefore, of great importance. The process must provide mechanisms for reliably identifying the individual and for verifying that the public key listed in the certificate belongs to that individual.

Fig. 1 shows a block diagram of an example PKI system architecture. Current PKIs that provide strong authentication of user identity accomplish this via the use of a local registration authority officer (LRAO) 12. LRAO 12 operates at a work station or server platform 14 that runs a local registration authority software application 16. Server platform 14 may be any known computing device that may serve as a server, e.g., computer, workstation, etc. The local registration authority application 16 interfaces to other server platforms that may contain applications such as a certificate authority application 18, a registration authority application 20, and/or a key recovery authority application 22. Each application may be on the same server platform, or on separate individual server platforms 14. A user 10, that is using or desires access to the PKI system architecture, accesses the system via a web browser 22 on a client platform 24. A hardware token 26, such as a smart card, may also be operably connectable to client platform 24. Typically in current systems, user 10 presents a photo I.D. or other documentation to the local registration authority officer 12 in order to authenticate the user's identity. Local registration authority officer 12 then uses workstation 14 and local registration authority application 16 to signal a registration authority application 20 to register new user 10 in the system. Local registration authority application 16 may be off-the-shelf product software that comes typically bundled with a certificate authority application 18, registration authority application 20, and key recovery authority 22 software.

A public/private key pair is generated by either the local registration authority application 16 or the registration authority application 20 (depending on products chosen and depending on how they've been configured). The public key is sent to certificate authority application 18 to be signed, thereby, generating a certificate for new user 10. A backup copy of the private key may also be sent to key recovery authority application 22, however, normally the private key is kept on a token 26, or at client platform 24 by user 10. Once the public key is sent to a certificate authority 18 and signed, a user certificate is generated and provided to a local registration authority server. Local registration authority officer 12 copies the certificate (including the private key) onto a floppy disk, hardware token, or other storage medium, and then provides the certificate and private key to the user.

Current public key infrastructures for generating digital certificates have some problems. First, for large organizations, the cost to implement systems similar to that shown in Fig. 1 are high due to the need for multiple local registration authority officers to handle the large number of users that may reside at various locations. Generally, certificate requests are submitted via some method (paper, email, web, etc.) to the local registration authority. The certificate requests are queued for working off by the local registration authority officers. Current systems are inefficient because request queues will be subject to human intervention. The normal certificate issuance process involves actions by the requester and the local registration authority. After some time and effort, the requester receives the digital certificate. This time may be dependent on the number of requests in the queue and/or the efficiency of the local registration authority officers.

Moreover, current systems are less secure because a relationship between the requester and the local registration authority officer does not necessarily exist and, therefore, presents opportunity for an intruder to exploit. In addition, current systems are less secure since without a manager of the user (or some other individual who may personally know the user), in the process flow, there is no definitive proof who the pin and password (required for generation of digital certificates) given to the user is issued to.

Therefore, a need exists for a PKI system and method that provides an inexpensive and reliable mechanism for implementing a face to face meeting as part of a new user registration process for generation of a digital certificate for the user.

SUMMARY

The present invention is directed to a method for generating a signature certificate in a Public Key Infrastructure (PKI). Data about a new user is entered into a database. The new user may request access to an enterprise server. A personal registration authority queries the database for new user information. The new user is sent a first piece of information required for generation of a signature certificate for the new user. A personal registration authority is sent a second piece of information required for generation of a signature certificate for the new user. The second piece of information is delivered to the new user by the personal registration authority in a face-to-face meeting. The first piece of information and the second piece of information are provided to the registration authority by the new user. The new user is registered by the registration authority. A key pair for the new user that includes a public key and a private key are generated. The public key is provided to a certification authority. A signature certificate for the new user is generated and digitally signed by the certification authority. The signed signature certificate that includes the public key is sent to the database.

The present invention is further directed to an article comprising a storage medium having instructions stored therein, the instructions when executed causing a processing device to perform: querying a database for new user information; sending the new user a first piece of information required for generation of a signature certificate for the new user; sending a personal registration authority a second piece of information required for generation of a signature certificate for the new user; receiving the first piece of information and the second piece of information from the new user; registering the new user; and signaling a client platform to generate a key pair for the new user comprising a public key and a private key.

The present invention is also directed to a system for generating a signature certificate in a Public Key Infrastructure (PKI). The system includes: one or more servers operably connected to a network; a database operably connected to the network where the database contains information on at least one user; a directory operably connected to the network where the directory contains the same information as the database but provides faster access to the information; one or more client platforms operably connected to the network where the one or more users requests access to the one or more servers from the one or more client platforms; and a registration web server operably connected to the network where the registration web server sends the new user a first piece of information required for generation of a signature certificate for the new user and also sends a personal registration authority a second piece of information required for generation of a signature certificate for the new user. The second piece of information is delivered to the new user by the personal registration authority in a face-to-face meeting. The first piece of information and the second piece of information are used by the new user in a process for generation of public and private keys and a signature certificate for the new user.

BRIEF DESCRIPTION OF THE DRAWINGS

The present invention is further described in the detailed description which follows in reference to the noted plurality of drawings by way of non-limiting examples of embodiments of the present invention in which like reference numerals represent similar parts throughout the several views of the drawings and wherein: <ul id="ul0001" list-style="none" compact="compact"><li>Fig. 1 is a block diagram of an example PKI system architecture;</li><li>Fig. 2 is a block diagram of an exemplary system architecture in which PKI processes may be practiced according to an example embodiment of the present invention; and</li><li>Fig. 3 is a flow chart of an example process for generation of a signature certificate in a public key infrastructure according to an example embodiment of the present invention.</li></ul>

DETAILED DESCRIPTION

The particulars shown herein are by way of example and for purposes of illustrative discussion of the embodiments of the present invention. The description taken with the drawings make it apparent to those skilled in the art how the present invention may be embodied in practice.

Further, arrangements may be shown in block diagram form in order to avoid obscuring the invention, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements is highly dependent upon the platform within which the present invention is to be implemented, i.e., specifics should be well within purview of one skilled in the art. Where specific details (e.g., circuits, flowcharts) are set forth in order to describe example embodiments of the invention, it should be apparent to one skilled in the art that the invention can be practiced without these specific details. Finally, it should be apparent that any combination of hard-wired circuitry and software instructions can be used to implement embodiments of the present invention, i.e., the present invention is not limited to any specific combination of hardware circuitry and software instructions.

Although example embodiments of the present invention may be described using an example system block diagram in an example host unit environment, practice of the invention is not limited thereto, i.e., the invention may be able to be practiced with other types of systems, and in other types of environments (e.g., servers).

Reference in the specification to "one embodiment" or "an embodiment" means that a particular feature, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the invention. The appearances of the phrase "in one embodiment" in various places in the specification are not necessarily all referring to the same embodiment.

Fig. 2 shows a block diagram of an exemplary system architecture 100 in which Public Key Infrastructure (PKI) processes may be practiced according to an example embodiment of the present invention. The present invention is not limited to the system architecture 100 shown in Fig. 2. The boxes shown in Fig. 2 represent entities that may be hardware, software, or a combination of the two. The entities are operably connected together on a network. Entities not shown as being connected to the network represent one or more human beings that perform the function denoted inside the box.

System architecture 100 includes Data Entry 102 which performs a data entry function for Authoritative Database 104. Authoritative Database 104 is resident on server platform 106. A server platform 106 is referred to in this description but it should be understood that the present invention is not limited to any particular server architecture. Server platform 106 may be, for example, UNIX or Windows NT servers. Authoritative database 104 contains information about members of the group or enterprise (e.g., company) for which PKI services in accordance with the present invention may be performed. The present invention is not limited by the structure of the group or enterprise for which information is stored in the authoritative database 104. The information contained in Authoritative database 104 may include, for example, the name, address, telephone numbers, manager's name, employee identification, etc., of the members of the group or enterprise. Directory 108 contains the same information contained in database 104, but is optimized for fast look-up of the information stored therein rather than fast data entry. The information contained in Directory 108 may be accessed faster than accessing the information from database 104. Directory 108 functions similar to an on-line quickly accessible phone book, containing reference information about the members of the group or enterprise stored in authoritative database 104.

Certificate authority 110 may be conventional off-the shelf software executed on server platform 106. Certificate authority 110 provides storage of certificates and related information. This will be described in more detail hereinafter. Registration authority 112 may also be off-the shelf software executable on server platform 106. Registration authority 112 will also be described in more detail hereinafter. Key recovery authority 114 may also be off-the shelf server software executable on Server Platform 106, and may provide the function of recovering keys (e.g., archived or lost keys) for members of the group or enterprise.

A Windows 2000 Domain Certificate Authority (CA) 116 is shown with a dotted line connection to the network and may or may not be part of a system according to the present invention. Windows 2000 is able to use PKI certificates for network single sign-on, but Windows 2000 is designed to use only the Windows Certificate Authority Windows. Therefore, a system according to the present invention may include a conventional Certificate Authority 110 as well as a 2000 Domain CA 116.

Legacy server 118 executes legacy application programs 120. Legacy server 118 may be, without limitation, a main frame, mini-computer, workstation or other server capable of hosting legacy software applications. Legacy software applications generally may not be designed to be inherently interoperable with a PKI. Legacy applications 120 may be accessible on the client side by a custom client 128 such as an emulator or custom database Graphic User Interface (GUI). Examples of emulators are terminal emulators of an IBM 3270 or terminal emulators of a vt100.

Registration web page 122, which may be one or more pages, functions as the user interface to system architecture 100 shown in Fig. 1. Web Server 124 is a software application that serves Web Pages (such as web page 122) or other HTML outputs to a web browser client (such as web browser 126). Web Server 124 may be any software application that serves Web Pages or HTML outputs such as, for example, Apache, Microsoft Internet Information Server application, etc.

Web browser 126 is resident on client platform 128 which may be any user computer or computing device. Web browser 126 may be a client software application for browsing web pages such as, for example, HTML protocols, XML protocols, or other protocols. Web browser 126 may be programmed to operate with PKI certificates issued by certificate authority 110. Examples of web browsers which have this capability include Netscape Navigator and Microsoft Internet Explorer. The token 130 may be a smart card, a device with a Universal Serial Bus (USB), or other hardware token device capable of generating, storing, and/or using PKI certificates.

A user 132 is a person that uses or desires access to system architecture 100. User 132 may transition through a number of states which include, for example, a new user, a current user, and a former user. A former user is no longer a member of the group or enterprise. System architecture 100 is described with reference to two levels of security with each level corresponding to a different security requirement. The number of the levels of security is not a limitation of the present invention. The level 1 search engine 134 may be a search engine that is permitted to search system architecture 100, but is allowed access to only level 1 data which is the lowest level of security. Level 1 data may be, for example, data which is freely distributable whereas level 2 data may be considered to be proprietary. A Level 2 search engine 136 may be a search engine which is allowed to search both level 1 and level 2 data. A Level N search engine (not illustrated) may be a search engine which is allowed to search through servers possessing Levels 1 through N data.

A secured level server with Level 1 data may be a web server containing only level 1 data that is secured so that users may need to have level 1 access (at least) to access the level 1 servers. A secured web server with level 2 data 140 may be a web server that contains level 2 data that has been secured so that users must have at least level 2 access to access the level 2 servers. A user with level 2 access may have access to both level 1 and level 2 servers. A secured web server with level N data (not illustrated) is a web server that contains level N data which is accessible by users with level N or above. Users with level N or above access may have access to all levels of data up through level N data.

VPN Extranet 142 may be a software application which functions as a network gateway, which as illustrated, may be either to legacy server 118 and legacy application 120 or to an external network such as the Internet. Personal revocation authority 144 may be one or more people that are in charge of revocation of members from system network 100. Personal registration authority 146 may be one or more people that are in charge of registration of members in system network 100. Personal recovery approval 148 may be one or more people that are in charge of obtaining recovery of certificates. A Recovery Agent 150 may be one or more people that perform recovery of certificates and may only recover a certificate if the certificate has first been designated as recoverable by another person. Personal role approval 152 may be one or more people that approve different role functions within the system network 100. A web server administrator may be one or more people that are in charge of various web functions in system network 100.

Fig. 3 shows a flow chart of an example process for generation of a signature certificate in a public key infrastructure according to an example embodiment of the present invention. In this example embodiment, a company or enterprise that has a large number of employees or individuals desires to generate digital signature certificates for all of their employees or individuals. Once an individual is hired by the enterprise, or the individual becomes a part of the group, the individual (new user) will need access to the servers and other resources of the enterprise. Therefore, the new user data will be entered into an authoritative database S1. The authoritative database contains information about all members of the enterprise. The member information includes data necessary to send registration materials to new users, e.g., home and/or work addresses, email addresses, telephone numbers, fax numbers, etc. The new user data entered into the authoritative database may be replicated into another directory database S2. The directory is structured to provide much faster access to the data than the authoritative database. Data in the directory is continually or periodically updated with the information in the authoritative database.

The new user attempts to access a server that is part of the enterprise S3. An enterprise web server requests the new user provide a signature for access to the enterprise server S4. Since the new user has no signature, the web server redirects the new user to a registration web page S5. The new user identifies itself to the registration web page by providing an identification number (ID), e.g., employee ID, social security number, etc. The registration web server uses the identification information from the user to query the directory for new user information S6. The directory provides information about the new user to the registration web server S7.

The registration web server now sends the new user a piece of information required to generate a new signature for the new user S8. This required information sent to the new user may be in the form of a personal identification number (PIN), a password, etc. The registration web server sends a different piece of information, required to generate a new signature for the new user, to a personal registration authority S9. This second piece of information may also be in the form of a PIN or password. The PIN or password sent to the new user may be sent to the new user's home address, email address or work address. The PIN or password sent to the personal registration authority may be sent to the personal registration authority's email address (in encrypted form), work address or home address. The precise delivery mechanism is unimportant, provided that it is independent of the mechanism used to deliver the password to the user. Use of separate delivery mechanisms is designed to minimize the possibility of interception of the both pieces of registration information by a party other than the new user. The personal registration authority delivers the second piece of information to the new user at a face to face meeting S10. It is preferred that the personal registration authority be a manager or supervisor of the new user, or another individual familiar with the identity of the new user. When this situation exists, the potential of an intruder fraudulently getting the second piece of information is eliminated.

The new user now revisits the registration web page and provides the two registration pieces of information to the registration web server S11. The registration web server verifies the information as valid, and then signals a registration authority to register the new user S12. The registration authority signals the web browser, or other resource, on the client platform to generate a private/public key pair S13. The public/private key pair may also be generated by a token or other device, or other application, at the client platform or elsewhere, and still be within the spirit and scope of the present invention. The browser at the client platform (or other source) generates the key pair for the new user and sends the generated public key to a certification authority to be digitally signed S14. The certificate authority signs the certificate and sends the signed certificate, that includes the public key, to the directory S15. The new user now has a signature certificate whereby others can access the public key of the new user to verify documents digitally signed by the new user with the private key of the new user. Once a certificate is generated for the new user, any PINs or passwords used in the generation process may be no longer valid (i.e., they have a one time use).

Digital signatures may be used in a number of ways. It is not necessary that digital signatures be implemented by encrypting an entire document. For example, a document sent from a user to a second person may be passed through a one way hashing algorithm to produce a smaller document, referred to as a digest. The digest is created by the user. The digest may be encrypted using the private key of the user. The user's private key serves as the user's (i.e., author's) private "signing key" to produce the document's digital signature. The digital signature (i.e., encrypted digest) may be appended to the document and both sent to the second person.

The second person (or any others) can then verify the digital signature on the document as being from the user by stripping the digital signature from the document and re-computing the hash function on the document to produce an "as received" digest. The second person may then access the user's public key from the directory. The second person uses the user's public key to decrypt the digest of the document as sent, and compare the decrypted digest to the as received digest. If the two digests match, the digital signature of the user is validated. If the two digests do not match, either the public key does not match the signer's (i.e., user's) private key, or the document has been modified since it was signed.

System and methods for generation of a signature certificate in a public key infrastructure according to the present invention is advantageous in that it provides cost savings and improved security. Costs are saved in that the present invention reduces paper work by incorporating an electronic process, shortens business process time lines since minimal amount of human intervention is required, and promotes remote collaboration amongst the members of the enterprise. Security is improved since eavesdropping is protected against, spoofing is protected against, and a system according to the present invention authenticates a user identity, including hostile insiders. The advantages of the present invention are accomplished since manual processes that current PKI systems use have been replaced with automated processes that accomplish many of the same tasks. System and methods according to the present invention provide a very inexpensive mechanism for implementing a face to face meeting as a part of the new user registration process, therefore, providing improved security while at the same time not adding significantly to the cost of the system (e.g., labor costs).

It is noted that the foregoing examples have been provided merely for the purpose of explanation and are in no way to be construed as limiting of the present invention. While the present invention has been described with reference to a preferred embodiment, it is understood that the words which have been used herein are words of description and illustration, rather than words of limitation. Changes may be made within the purview of the appended claims, as presently stated and as amended, without departing from the scope and spirit of the present invention in its aspects. Although the present invention has been described herein with reference to particular methods, materials, and embodiments, the present invention is not intended to be limited to the particulars disclosed herein, rather, the present invention extends to all functionally equivalent structures, methods and uses, such as are within the scope of the appended claims.