Secure communications are essential for delivering business-critical applications over the Internet. The element that has emerged as the foundation for secure communications over the Internet is the Public Key Infrastructure (PKI). PKI facilitates the authentication and encryption of messages transmitted over a public medium, such as the Internet.

At the heart of the PKI system is a public/private key pair that is unique to each user in the PKI system. Each user's private key is stored locally and maintained confidentially by the user whereas the public key is made publicly available. The public/private key pair may then be used for authenticating and encrypting communications within the PKI system.

To authenticate a message within a PKI system, a hash function is applied to the message to be sent and the resulting message digest is then signed with the sender's private key thereby forming a digital signature. Upon receiving the message and the associated digital signature, the recipient applies the sender's public key to the digital signature to retrieve the message digest. If the message digest retrieved from the digital signature matches the message digest the recipient calculates directly, then the recipient may be certain that the message came from the sender having control over the corresponding private key.

In addition to authentication, the public/private key pair of the PKI system is also used to encrypt messages. To encrypt a message for secure transmission to a recipient, the sender uses the intended recipient's public key to encode the message so that only the recipient can decode the message with the recipient's corresponding private key.

The reliability of digital signature verification and message encryption depends on the reliability of the recipient's copy of the sender's public key (and the sender's copy of the recipient's public key for the case of encryption). Typically, the sender transmits the sender's public key along with the original message. As a result, it is possible for an impostor to undermine the digital signature technique by creating a message purportedly from the original sender and encrypting a digest of the message according to a different private key. The impostor would then send the message to the recipient with the new encrypted digest and with the public key corresponding to the impostor's private key. By using the public key that came with the message to verify the digital signature, the recipient will incorrectly conclude that the message came from the original sender.

One known method for preventing this kind of subversion involves the use of digital certificates, for example as set forth in International Telecommunication Union, "Recommendation X. 509--Information Technology--Open Systems Interconnection--the Directory: Authentication Framework"November 1993 ("Recommendation X. 509"), incorporated herein by reference. According to this standard, the sender transmits the original message and encrypted digest in conjunction with a digital certificate containing the sender's public key.

Referring now to FIG. 1, there is shown a block diagram of a prior art system 100 for creating a digital certificate. System 100 includes a browser device 101 operated by a user.

Device 10 1 may be, for example, a personal computer operating browser software that generates a public/private key pair at the user's request. The public key is then sent to a Registration Authority (RA) server 102 that initiates the process of forming a digital certificate for use with the user's public key. RA server 102 may authenticate the requesting user by accessing a user authentication database 103. In addition, RA server 102 may access a directory 104, such as an LDAP, for retrieving user identifying information such as, by way of non-limiting example, the user's name and email address, to be included in the digital certificate. RA server 102 then formulates a Certificate Signing Request (CSR) that includes the user's public key and identifying information and the CSR is then signed with a private key generated by private key card 105 associated with RA server 102. RA server 102 then encrypts the CSR with a public key belonging to a Certificate Authority (CA) 106. The encrypted CSR is then sent to CA 106 for creating the requested digital certificate. CA 106 decrypts the CSR with its private key, verifies the CSR with the public key of RA server 102 (corresponding to the private key from card 105) and generates a digital certificate for the requesting user. The digital certificate is then signed, encrypted and returned to RA server 102 so that it is available for use by the user. An example of a Certificate Authority that creates digital certificates in this manner is Verisign (www. verisign. com). Once the user's digital certificate is created, the user sends an intended recipient the user's digital certificate along with the message. The recipient can then verify the sender's identity by requesting verification of the sender's digital certificate from CA 106.

A drawback of the certification scheme described above is that in cases where the Certificate Authority is operated by a third-party (i. e. not the sender or recipient), it requires that the recipient trust the Certificate Authority in verifying the sender's digital certificate. It is possible, however, for the Certificate Authority to associate with a digital certificate a public/private key pair and represent that the particular digital certificate belongs to a certain entity when in fact neither the digital certificate nor the public/private key pair belong to the entity. The CA can then use the digital certificate and pose as the entity in communications with recipients. The possibility of an untrustworthy CA can therefore undermine secure communications over the Internet.

Accordingly, it is desirable to provide a system and method for verifying the authenticity of digital certificates.

SUMMARY OF THE INVENTION The present invention is directed to overcoming the drawbacks of the prior art. Under the present invention a method and system is provided for authenticating a digital certificate issued by a certificate authority for being used in conjunction with a user's public key and initially includes the step signing a message digest derived from the public key with an anti- forgery private key thereby forming an anti-forgery signature. Next, the anti-forgery signature is inserted into a request for the digital certificate. Finally, the request for the digital certificate is forwarded to the certificate authority.

In an exemplary embodiment, the step of signing the public key with an anti-forgery signature includes the steps of decoding the public key, extracting a portion of the decoded public key, signing the portion with the anti-forgery key thereby forming the anti-forgery signature and encoding the anti-forgery signature.

In another exemplary embodiment, the digital certificate has an object identifier field and wherein the step of inserting the anti-forgery signature into a request for the digital certificate includes the step of designating the anti-forgery signature for placement into the object identifier field of the digital certificate.

In yet another exemplary embodiment, the request for the digital certificate includes the user's public key.

In still yet another exemplary embodiment, the request for the digital certificate includes the user's identifying information.

In an exemplary embodiment, the identifying information includes the user's name and email address.

In another exemplary embodiment, the step of forwarding the request for the digital certificate to the certificate authority includes the steps of signing the request for the digital certificate with a private key and encrypting the request for the digital certificate with a public key belonging to the certificate authority.

In another exemplary embodiment, the digital certificate including the anti-forgery signature in the object identifier field is generated by the certificate authority.

In yet another exemplary embodiment, the digital certificate including the anti-forgery signature in the object identifier field is received from the certificate authority.

In still yet another exemplary embodiment, the anti-forgery signature is retrieved from the object identifier field of the digital certificate. Next, a first message digest based on the anti-forgery signature and a corresponding anti-forgery public key is generated. Next, a second message digest based on the hash function and the user's public key is generated.

Finally, it is determined that the digital certificate is authentic if the first message digest equals the second message digest.

In an exemplary embodiment, the step of retrieving the at least a portion of the public key from the anti-forgery signature includes the step of decoding the anti-forgery signature.

In another exemplary embodiment, the step of decoding the public key includes the step of decoding said public key using base64 and the step of encoding the anti-forgery signature includes the step of encoding the anti-forgery signature using base64.

In yet another exemplary embodiment, the step of decoding the anti-forgery signature includes the step of decoding the anti-forgery signature using base64.

Under the present invention, a method for authenticating a digital certificate issued by a certificate authority where the digital certificate being used in conjunction with a user's public key, the digital certificate includes an anti-forgery signature, the anti forgery signature is formed from at least a portion of the user's public key, an anti-forgery private key and a hash function and the anti-forgery private key has a corresponding anti-forgery public key.

According to the method, a first message digest is generated based on the anti-forgery signature and the corresponding anti-forgery public key. Next, a second message digest is generated based on the hash function and the user's public key. Finally, it is determined that the digital certificate is authentic if the first message digest equals the second message digest.

Under the present invention, a system is provided for authenticating a digital certificate issued by a certificate authority where the digital certificate is used in conjunction with a user's public key. The system includes an anti-forgery private key card for generating an anti-forgery private key. The system also includes a registration authority server for issuing a request for the digital certificate to the certificate authority. The registration authority forms an anti-forgery signature from at least a portion of the user's public key, an anti-forgery private key and a hash function. The registration authority then inserts the anti- forgery signature into the request for the digital certificate and forwards the request for the digital certificate to the certificate authority.

In an exemplary embodiment, the digital certificate has an object identifier field and the anti-forgery signature is designated by the registration authority for placement into the object identifier field of the digital certificate.

In another exemplary embodiment, includes a private key and wherein the registration authority signs the request for the digital certificate with a private key and encrypts the request with the certificate authority's public key before forwarding the request to the certificate authority.

In yet another exemplary embodiment, the registration authority receives from the certificate authority the digital certificate including the anti-forgery signature.

In still yet another exemplary embodiment, the system includes an authentication engine that retrieves the anti-forgery signature from the object identifier field of the digital certificate. The authentication engine also generates a first message digest based on the anti- forgery signature and the corresponding anti-forgery public key. The authentication then generates a second message digest based on the hash function and the user's public key. The authentication engine then determines that the digital certificate is authentic if the first message digest equals the second message digest.

Under the present invention, a computer executable program code residing on a computer-readable medium is provided wherein the program code comprises instructions for causing the computer to authenticate a digital certificate issued by a certificate authority, the digital certificate being used in conjunction with a user's public key; sign a message digest derived from at least a portion of the public key with an anti-forgery private key thereby forming an anti-forgery signature; insert the anti-forgery signature into a request for the digital certificate and forward the request for the digital certificate to the certificate authority.

Accordingly, a system and method is provided for verifying the authenticity of digital certificates.

The invention accordingly comprises the features of construction, combination of elements and arrangement of parts that will be exemplified in the following detailed disclosure, and the scope of the invention will be indicated in the claims. Other features and advantages of the invention will be apparent from the description, the drawings and the claims.

DESCRIPTION OF THE DRAWINGS For a fuller understanding of the invention, reference is made to the following description taken in conjunction with the accompanying drawings, in which: FIG. 1 is a block diagram of a prior art system for creating a digital certificate; FIG. 2 is a block diagram of a system for authenticating a digital certificate according to the present invention; FIG. 3 is a flowchart of the process by which a digital certificate that can be authenticated is formed according to the present invention; FIG. 4 is a flowchart of the process by which an anti-forgery signature is formed according to the present invention; and FIG. 5 is a flowchart of the process by which a digital certificate formed in accordance with the present invention may be authenticated.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Referring now to FIG. 2, there is shown a block diagram of a system 200 for authenticating a digital certificate according to the present invention. Elements that are similar to elements contained in FIG. 1 are identically labeled and a detailed description thereof is omitted.

FIG. 2 includes a Registration Authority (RA) server 201 that includes an anti-forgery private key card 202. Anti-forgery private key card 202 generates an anti-forgery private/public key that is used by RA server 201 for authenticating digital certificates, as will be described below. In an exemplary embodiment, anti-forgery private key card 202 is a card that is inserted into a card reader and that generates a private/public key. An example of such a card and card reader is available from Chrysalis under the brand name of Luna (http://www. chrysalis-its. com/products/luna_ra. html). In an exemplary embodiment, each of private key card 105 and anti-forgery private key card 202 are Luna cards that are installed in a card reader for providing RA server 201 with private keys.

Referring now to FIG. 3, there is shown a flowchart of the process by which a digital certificate that can be later authenticated is formed. Initially, in Step 31, RA server 201 receives a request for a digital certificate from a user operating browser device 101. Next, in Step 32, RA server 201 prepares a CSR that is forwarded to CA 106. In addition to including the user's name, email address and public key, RA server 201 forms an anti-forgery digital signature for inclusion in the CSR (Step 33).

Referring now to FIG. 4, there is shown a flowchart of the process by which an anti- forgery signature is formed by RA server 201. Initially, in Step 41, the user's public key, which is encoded in a base64 format (in order to conform with the HTTP Transport Protocol), is decoded by RA server 201 using known decoding techniques. Alternatively, if an OpenSSL communication protocol is being used, then base64 encoding is not required. Next, in Step 42, a hash function is applied to the public key resulting in a message digest. In an exemplary embodiment, the hash function is an MD5 hash function that generates an MD5 hash. Next, in Step 43, RA server 201 generates an anti-forgery signature by signing the message digest with the anti-forgery private key generated by anti-forgery private key card 202 using known techniques such as, by way of non-limiting example, RSA's signature algorithm, elliptic curve or ElGammal. In Step 44, RA server 201 base64 encodes the anti- forgery signature so that the anti-forgery signature may be communicated using web-based protocols (such as HTTP). Alternatively, if an OpenSSL communication protocol is being used, then base64 decoding is not required.

Once the anti-forgery signature is formed, in Step 34 RA server 201 places the anti- forgery signature in the CSR request for inclusion in the digital certificate. In an exemplary embodiment, RA server 201 designates the anti-forgery field for placement in an Object IDentifier (OID) field of the digital certificate. Use of the OID field is preferred as opposed to placement of the anti-forgery field in the Distinguished Name (DN) section that includes unique identifying information about the user such as the user's name and email address. If the anti-forgery field is placed in the DN section and a user then requests (from RA server 201) a second digital certificate using a second public key, then the inclusion of an anti- forgery signature based on that second public key in the DN section will distinguish this request from a previous request and therefore enable the user to get a second digital certificate. The benefit of placing the anti-forgery signature in the OID field is that the contents of the OID field are not checked for uniqueness by RA server 201 or CA 106 so placing the anti-forgery signature in an OID field will not enable a user to get a second digital certificate.

Next, in Step 35, RA server 201 signs the CSR with a private key generated by private key card 105 and encrypts the CSR with a public key belonging to CA 106. In Step 36, RA server 201 communicates the CSR to CA 106 using any known communications medium and protocol, such as the Internet. Next, in Step 37, CA 106 decrypts the CSR with its private key and verifies the CSR with the public key of RA server 201. In Step 38, CA 106 generates a digital certificate, using known techniques, based on the user information provided in the CSR. The resulting digital certificate thus includes the anti-forgery signature being placed in an OID field according to a specification provided for in the particular CSR.

Next, in Step 39, CA 106 signs the digital certificate with its private key and encrypts the digital certificate with the public key of RA server 201. Finally, in Step 40, RA server 201 receives the digital certificate from CA 106, decrypts and verifies the digital certificate using its private key and the public key of CA 106, respectively, and makes the digital certificate available to the requesting user.

Because the anti-forgery private key is only known to RA server 201 and the anti- forgery signature is formed by signing the message digest of the user's public key with the anti-forgery private key, a digital certificate that includes an anti-forgery signature can have only been created based on a CSR originating from RA server 201. Even if CA 106 decides to revoke the digital certificate and reissue another digital certificate in its place, the anti- forgery signature of the original digital certificate cannot be recreated because the anti- forgery signature corresponds only to the public/private key pair associated with the original digital certificate. Accordingly, a digital certificate may be determined to be authentic, i. e., have originated from RA server 201, if it contains a valid anti-forgery signature in the OID field.

Referring now to FIG. 5, there is shown a flowchart of the process by which a digital certificate formed in accordance with the present invention may be authenticated. Included in RA server 201 is an authentication engine 203 that implements the process of validating an anti-forgery signature for authenticating a digital certificate. The authentication process begins with Step 51 in which the value contained in the OID field of the digital certificate to be authenticated is retrieved.

Next, in Step 52, the anti-forgery signature is base64 decoded. In Step 53, the particular user's public key is retrieved from the digital certificate being authenticated and, in Step 54, the encoded public key is base64 decoded for extracting the SubjectPublicKeyInfo value. (SubjectPublicKeyInfo is the name of the ASN. 1 data format for public keys as defined by the X. 509 standard). Next, in Step 55, authentication engine 203 generates a first message digest based on the decoded signature value to be verified and the anti-forgery public key. Next, in Step 56, a second message digest is formed from the SubjectPublicKeyInfo value using the hash function that was used to originally create the anti-forgery signature in the OID field. Next, in-Step 57, the first message digest is compared to the second message digest and, if in Step 58, they are found to be equal, then the digital certificate is authentic. If, however, the first message digest and the second message digest are not equal, then the digital certificate is not authentic (i. e. , was not created pursuant to a CSR originating from RA server 201) and was forged by a third party having access to the user's public key, identifying information and the private key of CA 106.

In an exemplary embodiment, authentication engine 203 is a software program that runs on RA server 201 for performing the authentication process. Alternatively, authentication engine 203 is a separate device, such as a computer, that is in communication with RA server 201 for receiving the anti-forgery key required for the authentication process.

Accordingly, a system and method is provided for verifying the authenticity of digital certificates. By including in the OID field of the digital certificate an anti-forgery signature that is formed from an anti-forgery private key that is only known to RA server 201, it can be determined whether the digital certificate was created pursuant to a CSR originating from RA server 201. Therefore, if a valid anti-forgery signature is found in the OID field, the digital certificate is deemed authentic. If a valid anti-forgery signature is not found in the OID field, then the digital certificate is a forgery. Thus, the anti-forgery signature may be used to verify the authenticity of digital certificates in situations where a third-party Certificate Authority is used.

A number of embodiments of the present invention have been described.

Nevertheless, it will be understood that various modifications may be made without departing from the spirit and scope of the invention. Based on the above description, it will be obvious to one of ordinary skill to implement the system and methods of the present invention in one or more computer programs that are executable on a programmable system including at least one programmable processor coupled to receive data and instructions from, and to transmit data and instructions to, a data storage system, at least one input device, and at least one output device. Each computer program may be implemented in a high-level procedural or object-oriented programming language, or in assembly or machine language if desired; and in any case, the language may be a compiled or interpreted language. Suitable processors include, by way of example, both general and special purpose microprocessors. Furthermore, alternate embodiments of the invention that implement the system in hardware, firmware or a combination of both hardware and software, as well as distributing modules and/or data in a different fashion will be apparent to those skilled in the art and are also within the scope of the invention. In addition, it will be obvious to one of ordinary skill to use a conventional database management system such as, by way of non-limiting example, Sybase, Oracle and DB2, as a platform for implementing the present invention. Also, network access devices can comprise a personal computer executing an operating system such as Microsoft Windows, Unit, or Apple Mac OSTM, as well as software applications, such as a JAVA program or a web browser. Browser device 101 can also be a terminal device, a palm-type computer, mobile WEB access device or other device that can adhere to a point-to-point or network communication protocol such as the Internet protocol. Computers and network access devices can include a processor, RAM and/or ROM memory, a display capability, an input device and hard disk or other relatively permanent storage. Accordingly, other embodiments are within the scope of the following claims.

It will thus be seen that the objects set forth above, among those made apparent from the preceding description, are efficiently attained and, since certain changes may be made in carrying out the above process, in a described product, and in the construction set forth without departing from the spirit and scope of the invention, it is intended that all matter contained in the above description shown in the accompanying drawing shall be interpreted as illustrative and not in a limiting sense.

It is also to be understood that the following claims are intended to cover all of the generic and specific features of the invention herein described, and all statements of the scope of the invention, which, as a matter of language, might be said to fall therebetween.