Herein, "network" refers to any electronic communications network, including but not limited to the Internet, "Intranets", various wide area networks (WANs) and local area networks (LANs), connecting computer systems or "nodes", sometimes referred to here as a "computer". In addition, herein, "transactions" refer broadly to any transfer of information between any nodes of the network, including transfers of "data", "records" or other information, typically referring to what is apparent to a user at higher layer of network communication. These transactions may take place between virtually any entities each associated with one or more network nodes and may be used in a variety of applications such as electronic data interchange (EDI), electronic commerce, financial information and trading, health and governmental records and filing, and legal communications.
"Certificate" is herein defined as information issued by a "certificate authority", an entity generally holding a position of trust within the scope of application to which the certificate is relevant, to authenticate or certify that a transaction is associated with a particular entity. Particular types of certificates for which the invention may be used are described generally in draft ANSI X9.57, "Public Key Cryptography for the Financial Services Industry, Certificate Management", available from the American Bankers Association.
The Internet network provides connection among a large and growing number of entities including vendors of goods and services and their potential customers. Incentives to conduct business over the network are many and compelling, for example, the reduction or elimination of the need for physical travel, samples, and sales personnel in the selling process and the centralized provision of the latest product or services descriptions and terms, allowing inexpensive, uniform and timely updates at the point of sale. Using the Internet, small businesses can communicate with an audience of customers far beyond that previously available to them. For these and many other reasons, business is being conducted in increasingly large volumes over the Internet and other networks.
However, there are limitations and problems associated with sales and other transactions over the network. One fundamental concern is how to verify the identity of a party to a transaction (and whether that party is trustworthy), particularly in a transaction that results in the transfer of value to that party. In typical consumer credit card transactions for purchase of goods by mail order or telephone order, some of the risk is limited by allowing delivery of goods only to a physical address that has some associated trustworthiness (an owned home, as opposed to a post office box). This safeguard is absent where valuable information, such as software or proprietary databases, is made available on a network to the general public and may be downloaded anonymously. Even in the case of physical delivery, there is still the possibility that the addressee party may repudiate the transaction.
A general approach to assuring the identity of parties to a transaction and providing a basis for non-repudiation of a transaction in a network environment is the employment therein of a certification procedure in a "public key infrastructure" such as that exemplified in the draft X9.57 standard. This approach is built upon a public/private key or "asymmetric" encryption/decryption scheme defined, for example, in the ANSI X9.30 series of specifications covering "the Digital Signature Algorithm", available from the American Bankers Association.
General asymmetric or "public key" encryption/decryption mechanisms are well known in the art, such as those invented by Rivest, Shamir and Adleman ("RSA"). The concept is based upon the existence of algorithms that allow encryption/decryption using related "keys" that are associated with each other, but one of which, the "private" key, is extremely difficult to derive from the other, "public" key.
In one type of asymmetrically coded or encrypted communication, the message is encrypted using the public key, made available to any number of senders for use in such encryption, and only one recipient of the encrypted message may decipher the communication--the sole holder of the private key. This assures that there is only one recipient of decoded or deciphered information encrypted with the public key.
In another type of asymmetrically coded communication, the communication is encrypted using the private key, held only by one sender, and any number of recipients of the encrypted communication may decipher the communication using the public key made available to them. This assures that there is only one sender of information encrypted with the private key that is decipherable with a given public key and thus allows recipients to uniquely associate that sender with that public key. By applying this type of encryption to a shortened, unique representation of a communication generated by a "hash function", a "digital signature" can be generated that authenticates to holders of the public key that the sender/encoder of the communication is the holder of the associated private key.
The communication of a digitally signed message according to this approach is shown in FIG. 1. A message 10 is uniquely represented by a "hash value" or hash result 20 using a hash function 15, which may be a one-way hash function so that it is computationally infeasible to derive the original message from knowledge of the hash value. The hash result 20 is then encoded using the message sender's private key 35 in a signing function 25 to result in a digital signature 30 that is stored or transmitted with the original message 10. The process of transmission 40 may be by direct link or communication over a network and may itself involve encryption and decryption of the entire package. (One approach is to generate a random symmetric key using the Digital Encryption Standard DES, encrypt the entire package using that key, encrypt the symmetric key using the recipient's public key to create a "digital envelope" 41, and send the encrypted package with the digital envelope to the recipient.)
When the message 10 and its digital signature 30 are received (and decrypted) or retrieved, the message to is subjected to the hash function 45 (identical to hash function 15) to generate a new hash result 47. This is compared in the verification function 50 with the digital signature 30 as decoded using the public key 55 associated with the private key 35 (and previously sent on 60 or simultaneously sent on 40, possibly encrypted in a digital envelope 61), resulting in verification 67. This process assures that the message 10 was signed at 25 using the private key 35 associated with the public key 65 and that the message 10 was unaltered (otherwise the hash results would not match). The process thereby authenticates that message 10 was signed by the holder of private key 35 associated with public key 65 and thereby provides evidence against any repudiation by the private key holder that it signed message 10.
The scheme shown in FIG. 1, however, merely assures that message 10 is signed at 25 with the holder of the private key 35 associated with public key 55. There is no assurance provided in this framework that the holder of the private key/public key pair is who the recipient of verification 67 believes the holder to be. An impostor could send his own public key over communication link 60 and sign his own message with his corresponding private key. This possibility of fraud may be multiplied extensively in the relatively anonymous "cyberspace" of those connected to the Internet and has been viewed as an obstacle to commerce on the Internet.
The problem of verifying that signatures are authorized and authentic in the electronic communication context has been addressed, for example, in ANSI X9.57, with the use of "certificate authorities" (CAs). The CA acts as a digital analogue to a notary public--to certify that a digital signature in fact belongs to the entity identified in the certificate, according to criteria that would allow the use of that signature in the relevant application (such as credit card purchases over the Internet).
Typically, the CA provides a certificate including (a) information identifying the certified party, (b) the certified party's public key, and (c) information identifying the CA, digitally signed, that is, encrypted with the CA's private key. (The particular form of a certificate has been prescribed in a number of industry specifications, such as ITU Rec. X.509 (1993).vertline.ISO/IEC 9594-48: 1995.) The certified party can send such a certificate, for example, on medium 60, to any recipient who may decrypt the certificate using the CA's public key and extract the certified party's public key and thus have the CA's assurance that the certified party is as identified in the certificate.
Because the recipient can only be as assured as the recipient trusts the CA's signature on the certificate, the CA's signature in some applications will itself be certified by a higher level CA. The higher level signatures are copied onto each lower level certificate. In this way, layers of CA signatures are stored or written on certificates for lower level CAs. The path or "chain of trust" of signatures CAs that are stored on the certificate can be reviewed by the recipient of the certificate using the public keys provided with the certificate. At the highest level, there will be a "root CA", whose authority is trusted by the recipient. The root CA's public key is initially distributed in a trusted fashion generally "off-line", such as by face-to-face interaction or included in encryption software, and may be updated later using public key encryption.
The CA functions include (a) verification or qualification of identity--that a digital signature (public key) presented to it in fact belongs to the entity identified with the presentation--and (b) the issuance of a certificate under the CA's own digital signature. As in the case of a notary, the CA most likely does not have actual knowledge that a presented signature belongs to a particular entity, but relies on other tests to make such a determination.
In early models, CAs could have a "registration authority" (RA) function, for example, registering who within an organization was authorized with signing privileges relative to a certain level of transaction activity. A current application involves registering credit card holders with the CA so that the CA can later issue certificates to holders upon comparison and verification of data submitted with a certificate request against data previously registered. Alternatively, a CA that is not itself a credit card issuer and does not perform the registration function may have a secure communication link to access a credit card issuer's database in order to access registration data collected by the issuer. In each of these cases, the CA performs the identity verification function, albeit using the registration database.
Where the registration database has been created and historically maintained and used independently of the use of a CA, for example, a credit card issuer's databases of credit card holders and merchants, the maintainer of the database likely has more experience with for verification of the identity of the party. The database maintainer may have personnel trained to do the verification possibly in conjunction with proprietary statistical procedures. This suggests the possibility of separating the identity verification function from other CA functions.
ANSI X9.57 discloses the concept of a separate "Local Registration Authority" (LRA) interposed between the CA and the certificate requester that is an entity appointed by a CA to assist in applying for certificates. This scheme is shown in FIG. 2 as the prior art.
Requester 70 employs a public/private key pair generator 71 to generate the key pair, then prepares a certificate request data (CRD) submission 73, signed with the requester's private key, and sends it to the LRA 80 using secure means 75. The LRA 80 then verifies the identity of the requester according to the policy of the CA, which may include, for example, questions currently used to verify the identity of credit card number holders. LRA 80 then accepts CRD 73, checks it for errors or omissions and verifies the requester's signature, submitting it to CA 90 in a message signed by LRA 80 using secure means 81. CA 90 validates the request for a certificate, then prepares the certificate information, signs it with the CA's private key and distributes the certificate to subscribers 95 (if authorized) and back to the LRA 80 using secure means 83, with an "out-of-band" notification on channel 91. LRA 80 in turn receives the certificate creation confirmation and certificate from the CA 90 and verifies the CA's signature. LRA 80 then delivers a copy of the CA's public key and a copy of the certificate (signed by the CA) to the requester using secure means 77 with an out-of-band notification on channel 85 The public key of the LRA may be distributed to the requester in a similar manner as described about for the public key of the CA in certification without an LRA.
The LRA scheme described above allows for a requester database to be held securely at the LRA location and to divide responsibility for the functions of verifying the identity of the requester and issuing the certificate. However, the LRA approach requires the LRA to be an intermediary twice in a chain of secure communications links from the requester to the LRA to the CA back to the LRA and back to the requester, putting burdens on the LRA to provide for hardware, software, personnel and procedures to assure that each link with associated keys is secure. Where continuous access is an issue, such as in global credit card transactions, investment in redundancy would also be required at the LRA facility, which serves as the gateway to the CA. These infrastructure burdens are not warranted, for example, in the case of corporate authorizations (as in the original RA function) of corporate card holders.
Generally, the maintainer of a customer database has protected the integrity and confidentiality of that database and information contained therein by maintaining it in a secure physical plant with operational safeguards. For typical credit card authorizations or qualifications outside the CA context, electronic access to the database is limited to an operator intermediary's on-site or dedicated secure line access on a file-by-file basis. This minimizes the possibility of larger-scale compromise of the database.
The function of issuance of digital certificates, on the other hand, requires direct electronic access or link of the requester to the issuer under conditions that assure the integrity of the delivery of the digital certificate. In the context of a large marketplace, there may be many requesters, such as credit card holders and merchants, and there are many links, further multiplied by intermediary links on a "public" network, such as the Internet or a telecommunication network operated by a common carrier. Direct access through each of these links increases the possibility of attack over the network that could compromise crucial components of the issuer, namely, its private keys and certificates of its own signature. Protection of these crucial components in the network environment, compared to protection of a limited-access requester database, calls for a substantially different investment in hardware and software (for example, effective "firewalls" against network attack) and in secured physical plants and procedures for professional and support personnel for protecting relatively few, but critically important, encryption components.
It is an object of the present invention to provide a system for qualifying requests for and issuing certificates that may be used to authenticate electronic transactions.
It is another object of the present invention to separate the functions of qualifying requests for and issuing such certificates so that the functions can be provided separately using existing hardware, software, personnel and procedural infrastructures with a minimum of new investment and maximum cost-effectiveness of new investments in such infrastructures.
It is yet another object of the present invention to provide means whereby an owner of a confidential registration database can perform the qualification function while maximizing security for that confidential database using existing infrastructure.
Another object of the present invention is to provide a system in which new investments in security infrastructure are concentrated in the entity having the function of issuing such certificates so that different entities may separately perform the qualification function using different criteria and different registration databases, but utilize the infrastructure investment in the entity having the issuance function.
Another object of the present invention is to provide a system that flexibly accommodates a wide range of applications and secure communications means.
Yet another object of the present invention is to provide a system in which a database owner may appear to a certificate requester to be a CA without investment of the database owner in issuance infrastructure.
USPTO Backgrounds
USPTO Backgrounds