Abstract:
A method to exchange and authenticate public cryptographic keys between parties that share a common but secret password. The parties exchange public keys, where the public keys are accompanied by hashed values based on the keys, the password, and random numbers. Each party then encrypts its random number using the public key of the other party, and the encryptions are exchanged. Based on the received encryptions and the known password, each party then re-computes the hashed value received from the other party, and compares the re-computed hashed value with the received hashed value. If the two are the same, the public key that accompanied the hashed value is judged authentic.

Description:
CROSS REFERENCE TO RELATED APPLICATIONS 
   Reference is made to the inventors&#39; commonly assigned U.S. patent applications “Method for Distributing and Authenticating Public Keys Using Hashed Password Protection,” and “Method for Distributing and Authenticating Public Keys Using Random Numbers and Diffie-Hellman Public Keys,” which were filed on the same day as the present application. 
   FIELD OF THE INVENTION 
   The invention relates to the field of data security, and more specifically to the field of distributing and authenticating public cryptographic keys. 
   BACKGROUND 
   Cryptography is the science of securing data. Various mechanisms have been proposed to accomplish this purpose and to defend against attacks on the security and privacy of electronic transmissions over communication channels. The most commonly used algorithms encrypt data according to a key that is known only to the sender and receiver of the transmission. These are called symmetric key algorithms, in that both the sender and the receiver share the same key, which must be kept secret. Several symmetric key algorithms are well known, perhaps the most notable among them being the Data Encryption Standard (DES) algorithm sponsored by the National Institute of Standards and Technology, and described by Schneier in  Applied Cryptography , John Wiley and Sons (second edition, 1996). Because a symmetric algorithm&#39;s encryption key must be kept secret, the key is often distributed using public key cryptography. Public key cryptography was first proposed by Diffie and Hellman (“New Directions in Cryptography,” IEEE Trans. Information Theory, vol. IT-22, no. 6, pp. 644-654, November 1976). Other public key algorithms are well known, including, for example, the RSA algorithm, as described by Rivest, Shamir, and Adelman (“A Method for Obtaining Digital Signatures and Public Key Cryptosystems,” Comm. of the ACM, vol. 21. no. 2, pp. 120-126, February 1978) and the elliptic curve cryptosystem, as described by Koblitz (“Elliptic Curve Cryptosystems,” Mathematics of Computation, vol. 48, no. 177, pp. 203-209, 1987) and by Miller (“Use of Elliptic Curves in Cryptography,” Advances in Cryptology—Crypto &#39;85 Proceedings, Springer-Verlag, pp. 417-426, 1986). 
   In public key cryptography, which employs an asymmetric algorithm, each user has a public key, which may be published and widely known, and a private key, which must be kept secret. The efficacy of public key cryptography follows from the difficulty of deriving a private key from its associated public key. 
   As mentioned above, an important application of public key cryptography is the distribution of symmetric encryption keys. Symmetric encryption keys that are distributed with the help of public key cryptography can be trusted to be secure and valid if all the protections are implemented and executed properly. Nevertheless, a question arises as to whether the public keys themselves can be trusted. For example, a party that publishes a public key may not in fact have possession of a corresponding private key, or the published public key may be corrupted or invalid. Encrypting sensitive data such as a symmetric encryption key using a somehow-bogus public key may result in a loss of privacy and diminished security. 
   Consequently, it has become important to authenticate public keys before using them, in order to ensure that public keys belong to legitimate parties. Authorities that can be trusted to do this have been set up. These authorities verify that public keys are correct and that they in fact belong to the parties claiming their ownership. Such an authority is often called a Certification Authority (CA). A CA validates a public key by issuing a certificate, which the CA signs using its own private key. A recipient of a signed certificate may then authenticate the certificate using the CAs public key to verify the signature. 
   This CA-based solution is often called a Public Key Infrastructure (PKI). A PKI includes the CAs, parent CAs capable of authenticating other CAs, and finally a root CA, which ultimately must be trusted, to authenticate the parent CAs. The various CAs and other parties that are part of the PKI act together according to agreed protocols and procedures. For example, ITU-T Recommendation X.509 (Information Technology—Open Systems Interconnection—The Directory: Authentication Framework, June 1997) is a widely accepted PKI standard that defines data formats and procedures pertaining to the distribution of public keys via public key certificates that are digitally signed by CAs. 
   Unfortunately, despite its many benefits, an X.509 PKI requires a massive and expensive infrastructure with complex operations. Thus there is a need for an alternative to the X.509 PKI that provides the same benefits but demands less in the way of bandwidth, storage, and complexity. 
   SUMMARY 
   The present invention provides an improved way to distribute and authenticate public cryptographic keys. 
   According to the invention, a client concatenates its ID, its public cryptographic key, a secret password known by the client and a server, and a random number known by the client, and hashes the concatenation. The client then forms an extended concatenation comprising the ID, the client&#39;s public key, and the first hashed value. The resulting extended concatenation is sent to the server. Likewise, the server concatenates the ID, its public cryptographic key, the password known by the client and a server, and a random number known by the server, and hashes the concatenation. The server then forms an extended concatenation comprising the ID, the server&#39;s public key, and the second hashed value, and sends the extended concatenation to the client. The client receives the extended concatenation from the server, reads the second hashed value and the server&#39;s public key, encrypts the random number known by the client using the server&#39;s public key, and sends the encryption to the server. Likewise, the server receives the extended concatenation from the client, reads the first hashed value and the client&#39;s public key, encrypts the random number known by the server using the client&#39;s public key, and sends the encryption to the client. The client receives and decrypts the encryption from the server, and hashes the ID, the server&#39;s public key, the password, and the random number known to the server, to provide a third hashed result, and compares the second hashed result with the third hashed result. If the two are the same, the client accepts the server&#39;s public key as valid. Likewise, the server receives and decrypts the encryption from the client, and hashes the ID, the client&#39;s public key, the password, and the random number known to the client, to provide a fourth hashed result, and compares the first hashed result with the fourth hashed result. If the two are the same, the server accepts the client&#39;s public key as valid. 

   
     BRIEF DESCRIPTION OF THE DRAWINGS 
       FIG. 1  shows steps of the method according to the present invention for distributing public cryptographic keys. 
       FIGS. 2-4  show steps of the method according to the present invention for authenticating public cryptographic keys distributed according to the method discussed with reference to  FIG. 1 . 
   

   DETAILED DESCRIPTION 
   The invention is described below in the context of a server and a client, although the invention is not limited to this context, but applies generally to two machines. In the description that follows, the client may be a user&#39;s machine, and the server may be a service provider&#39;s machine. A secret password, which may be distributed over a secure channel, is assumed to be known by both the client and the server. The password is assumed to be sufficiently long so that a random guess by either an unauthorized user or a rogue service provider is highly unlikely to be correct. Such assumptions are made today with great evident success in the context of banking. For example, a banking user may receive his or her ATM-card and its associated password separately through the mail; the password is required to have at least a specified minimum number of characters. Perhaps more apropos to the present invention, however, banks, brokers, and others rely on these same general principles to provide secure transmission of identifiers and passwords to clients using Secure Socket Layer (SSL) applications. 
   In the description that follows, the following notation is used:
     ID—client&#39;s user identifier, which need not be kept secret;   PW—secret one-time-use password that is known by both the client and the server;   PKc—initial public key component of the client&#39;s public/private key pair;   SKc—initial private key component of the client&#39;s public/private key pair;   PKs—initial public key component of the server&#39;s public/private key pair;   SKs—initial private key component of the server&#39;s public/private key pair;   eA(B)—data B encrypted with a symmetric key A using an agreed-upon symmetric encryption algorithm;   ePK(B)—data B encrypted with an asymmetric public key PK, using an agreed-upon asymmetric encryption algorithm;   eSK(B)—data B encrypted with an asymmetric private key SK, using an agreed-upon asymmetric encryption algorithm;   Rc—a secret random number generated by the client or on behalf of the client; and   Rs—a secret random number generated by the server or on behalf of the server.   

     FIG. 1  shows steps of the method according to the present invention for distributing public cryptographic keys. As shown in  FIG. 1 , a password PW, which may be random, is generated using current practices (step  100 ), and distributed securely to the client and to a server (step  105 ). For example, the server may generate and send the pair (ID, PW) to the client using conventional mail, email, or telephone. Although the term password is used here, a pass phrase may be used instead, the difference between the two being only a matter of semantics regarding the number of characters involved. 
   The client generates a random number Rc (step  110 ), or reads such a random number generated on its behalf, and concatenates the client ID, the public key of the client PKc, the password PW, and the random number Rc to provide an argument ARGc, where ARGc=ID,PKc,PW,Rc (step  115 ). The client hashes the argument ARGc to provide a hashed value Hash(ARGc) (step  120 ). The hash function may be any collision-resistant hash function drawn from the art of cryptography. A preferred embodiment of the invention uses the Secure Hash Algorithm SHA-1, which is described by Schneier (op cit). Although the order of the concatenation that provides the argument ARGc is shown here for descriptive convenience as ID,PKc,PW,Rc, other permutations of the constituents of the argument ARGc may also be used. For example, the concatenation Rc,PW,PKc,ID may be used as the argument ARGc of the hash function instead of ID,PKc,PW,Rc. The client then forms an extended concatenation EXTc=ID,PKc,Hash(ARGc) (step  125 ), and sends the extended concatenation EXTc to the server (step  130 ). Again, the order of the constituents of the extended concatenation is not important. 
   In a similar way, the server generates a random number Rs (step  135 ), or reads such a random number generated on its behalf, and concatenates the client ID, the public key of the server PKs, the password PW, and the random number Rs, to provide an argument ARGs, where ARGs=ID,PKs,PW,Rs (step  140 ). The server hashes the argument ARGs to provide a hashed value Hash(ARGs) (step  145 ). The hash function may be any collision-resistant hash function drawn from the art of cryptography. A preferred embodiment of the invention uses the Secure Hash Algorithm SHA-1, which is described by Schneier (op cit). Although the order of the concatenation that provides the argument ARGs is shown here for descriptive convenience as ID,PKs,PW,Rs, other permutations of the constituents of the argument ARGs may also be used. For example, the concatenation Rs,PW,PKs,ID may be used as the argument ARGs of the hash function instead of ID,PKs,PW,Rs. The server then forms an extended concatenation EXTs=ID,PKs,Hash(ARGs) (step  150 ), and sends the extended concatenation EXTs to the client (step  155 ). Again, the order of the constituents of the extended concatenation is not important. 
     FIG. 2  shows steps of the method according to the present invention for authenticating public cryptographic keys distributed according to the method discussed above with reference to  FIG. 1 . As shown in  FIG. 2 , the client receives the extended concatenation EXTs from the server (step  200 ), and now has tentative knowledge of the server&#39;s public key PKs and of Hash(ARGs). The client then encrypts the client&#39;s random number Rc using the server&#39;s public key PKs, to provide ePKs(Rc) (step  210 ), and sends ID,ePKs(Rc) to the server (step  220 ). Likewise, the server receives the extended concatenation EXTc from the client (step  230 ), and now has tentative knowledge of the client&#39;s public key PKc and of Hash(ARGc). The server then encrypts the server&#39;s random number Rs using the client&#39;s public key PKc, to provide ePKc(Rs) (step  240 ), and sends ID,ePKc(Rs) to the client (step  250 ). 
   As shown in  FIG. 3 , the client receives ID,ePKc(Rs) from the server (step  300 ), and decrypts ePKc(Rs) (step  310 ). The client now has tentative knowledge of the server&#39;s random number Rs as well as the server&#39;s public key PKs and Hash(ARGs). The client then forms the concatenation ARGs′=ID,PKs,PW′,Rs, using the client&#39;s own knowledge of the password, which is called PW′ here for clarity (step  320 ), and computes the hashed value Hash(ARGs′) (step  330 ). The client compares the received hashed value Hash(ARGs) with the computed hashed value Hash(ARGs′) (step  340 ). If the two are the same, the client concludes that server knows the password and has used it properly, and therefore accepts the server&#39;s public key PKs as authentic (step  350 ). Otherwise, i.e., the two versions of the hashed value are not the same, the client rejects the server&#39;s public key (step  360 ). 
   Likewise, as shown in  FIG. 4 , the server receives ID,ePKs(Rc) from the client (step  400 ), and decrypts ePKs(Rc) (step  410 ). The server now has tentative knowledge of the client&#39;s random number Rc as well as the client&#39;s public key PKc and Hash(ARGc). The server then forms the concatenation ARGc′=ID,PKc,PW″,Rc, using the server&#39;s own knowledge of the password, which is called PW″ here for clarity (step  420 ), and computes the hashed value Hash(ARGc′) (step  430 ). The server compares the received hashed value Hash(ARGc) with the computed hashed value Hash(ARGc′) (step  440 ). If the two are the same, the server concludes that client knows the password and has used it properly, and therefore accepts the client&#39;s public key PKc as authentic (step  450 ). Otherwise, i.e., the two versions of the hashed value are not the same, the server rejects the client&#39;s public key (step  460 ). 
   Thus the server has authenticated the client, and the client has authenticated the server. Now the client and the server can use public key cryptography further, with confidence that the public keys are authentic. The client and the server may discard the password PW, as it is not used again. Neither the client nor the server accept any further messages supposedly protected according to PW. Moreover, at this point there is no longer any need to keep PW secret, as PW has been used only for authentication rather than for encryption of sensitive data. 
   In the embodiment of the invention described above, the client authenticates the server, and the server authenticates the client. It is not a necessary condition of the invention that both the server and the client be authenticated. For example, the client may authenticate the server as described below, without requiring that the server also authenticate the client. This may be done with a subset of the steps of the first embodiment of the invention, as follows: 
   The client generates a random number Rc ( FIG. 1 , step  110 ), or reads such a random number generated on its behalf, and concatenates the client ID, the public key of the client PKc, the password PW, and the random number Rc to provide an argument ARGc, where ARGc=ID,PKc,PW,Rc (step  115 ). The client hashes the argument ARGc to provide a hashed value Hash(ARGc) (step  120 ). The client then forms an extended concatenation EXTc=ID,PKc,Hash(ARGc) (step  125 ), and sends the extended concatenation EXTc to the server (step  130 ). This embodiment of the invention requires sending PKc to the server; sending any of the other constituents of EXTc to the server is optional in this embodiment. 
   The server generates a random number Rs (step  135 ), or reads such a random number generated on its behalf, and concatenates the client ID, the public key of the server PKs, the password PW, and the random number Rs, to provide an argument ARGs, where ARGs=ID,PKs,PW,Rs (step  140 ). The server hashes the argument ARGs to provide a hashed value Hash(ARGs) (step  145 ). The server then forms an extended concatenation EXTs=ID,PKs,Hash(ARGs) (step  150 ), and sends the extended concatenation EXTs to the client (step  155 ). 
   The client receives the extended concatenation EXTs from the server ( FIG. 2 , step  200 ), and now has tentative knowledge of the server&#39;s public key PKs and of Hash(ARGs). Likewise, the server receives the extended concatenation EXTc from the client (step  230 ), and now has tentative knowledge of the client&#39;s public key PKc and of Hash(ARGc). The server then encrypts the server&#39;s random number Rs using the client&#39;s public key PKc, to provide ePKc(Rs) (step  240 ), and sends ID,ePKc(Rs) to the client (step  250 ). 
   The client receives ID,ePKc(Rs) from the server ( FIG. 3 , step  300 ), and decrypts ePKc(Rs) (step  310 ). The client now has tentative knowledge of the server&#39;s random number Rs as well as the server&#39;s public key PKs and Hash(ARGs). The client then forms the concatenation ARGs′=ID,PKs,PW′,Rs, using the client&#39;s own knowledge of the password, which is called PW′ here for clarity (step  320 ), and computes the hashed value Hash(ARGs′) (step  330 ). The client compares the received hashed value Hash(ARGs) with the computed hashed value Hash(ARGs′) (step  340 ). If the two are the same, the client concludes that server knows the password and has used it properly, and therefore accepts the server&#39;s public key PKs as authentic (step  350 ). Otherwise, i.e., the two versions of the hashed value are not the same, the client rejects the server&#39;s public key (step  360 ). 
   Thus the client has authenticated the server. In another embodiment, the server may authenticate the client using the same logic. More generally, a first machine, which may also be called a receiving machine, may authenticate a second machine, which may also be called a distributing machine, without regard to either machine&#39;s role in any client-server context. 
   It is important to note that the flows described above can be added to the top of current Secure Socket Layer (SSL) architectures to provide public key distribution without affecting the underlying applications. Since most SSL applications require password-based authentication of the client, the client can then generate a password PWc and send it to the server as the concatenation ID,ePKs(PWc,Rc),eSKc(Hash(ID,PWc,Rc)). This allows current SSL applications to continue using their current password-based authentications as well, since the additions will be transparent to the existing application. 
   The method described above may be used to recover when either the client or the server has knowledge that its private key SKc or SKs, respectively, is compromised. If the client&#39;s private key SKc is compromised, the client sends an “SKc compromised” message to the server in the concatenation ID,“SKc compromised”,eSKc(Hash(ID,“SKc compromised”)). If the server has the client&#39;s public key, the server verifies the signature. If the signature is valid, the client and server suspend the exchange of data while the client determines a new public key and private key. The client then sends its new public key to the server as described above. If the server does not have the client&#39;s public key, or if the signature is invalid, the server ignores the message. 
   If the server&#39;s private key SK is compromised, the server sends an “SKs compromised” message to the client in the concatenation ID,“SKs compromised”,eSKs(Hash(ID,“SKs compromised”)). If the client has the server&#39;s public key, the client verifies the signature. If the signature is valid, the client and server suspend the exchange of data while the server determines a new public key and private key. The server then sends its new public key to the client as described above. If the client does not have the server&#39;s public key, or if the signature is invalid, the client ignores the message. 
   From the foregoing description, those skilled in the art will now appreciate that the present invention provides an economical alternative to an X.509 PKI for distributing and authenticating public cryptographic keys. The foregoing description is illustrative rather than limiting, however, and the invention is limited only by the claims that follow.