WO2001080479A1

WO2001080479A1 - Delayed commitment scheme to prevent attacks based on compromised certificates

Info

Publication number: WO2001080479A1
Application number: PCT/US2001/008654
Authority: WO
Inventors: Wu Wen
Original assignee: Wu Wen
Priority date: 2000-04-14
Filing date: 2001-04-13
Publication date: 2001-10-25
Also published as: AU2001255183A1

Abstract

A secure computer network (40) service based on public key cryptography enables communication between a client (28, 29 and 30) and a server (22) running on any node of the computer network to communicate critical information in a secret and integral manner against compromised certificate based attacks, such as an 'ex-employee' attack on the Secure Socket Layer (SSL) handshake protocol. A two-step delayed commitment scheme is implemented, whereby in the first step, only partial information concerning a pre-master secret encrypted with server's public key is initially sent, and in a second step, full commitment to the pre-master secret encrypted with the server's public key is not performed until after an intervening communication from the server containing random information is received, thereby stopping the attacker from performing 1) switching of a compromised certificate and 2) re-encryption of a learned pre-master secret with the public key of the legitimate certificate during a single protocol run, thus preventing such an attack. The method integrates the two-step delayed commitment scheme to current authentication and key exchange protocols, requiring only minimum changes to the current protocol, yet providing enhanced security against attacks using compromised certificates.

Description

DELAYED COMMITMENT SCHEME TO PREVENT ATTACKS BASED ON COMPROMISED CERTIFICATES

CROSS-REFERENCE TO RELATED APPLICATIONS This application claims priority from U.S. Provisional Patent Application Serial. No. 60/197,398 filed on April 14, 2000 by Wu Wen, the disclosure of which is incorporated herein by reference .

BACKGROUND OF THE INVENTION Field of the Invention:

The present invention relates to computer networks, and more particularly, to improving the security and privacy of communications between networked computers . The invention also has applicability to networked consumer appliances such as mobile phones, wireless PDAs and other networked home appliances. Description of the Related Art:

To securely conduct business over the Internet, various cryptographic mechanisms and protocols have been proposed. Two very important objectives of security protocols are that of authentication and key exchange, in which the communicating parties establish the identity of their respective counterparts and exchange a secret key. The secret key is used to conduct future private communications between the authenticated parties. Protocols designed to achieve the above two objectives usually employ a mixture of public key and symmetric key cryptography for scalability and efficiency. A simple authentication and key exchange protocol using password and public key devices is disclosed by Halevi and Krawczyk, "Public- key Cryptography and Password Protocol," ACM Transactions on Information and System Security, vol. 2, no. 3, pp. 230-268 (1999) , the disclosure of which is incorporated herein by reference. A more sophisticated authentication and key exchange protocol is the Secure Socket Layer (SSL) protocol, disclosed in United States Patent No. 5,657,390 to Elgamal et al . , the full disclosure of which is expressly incorporated into the present application by reference. A successor protocol to SSL is the Transport Layer Security (TLS) protocol, details of which have been disclosed by T. Dierks and C. Allen, "The TLS protocol: Version 1.0," RFC 2246, January 1999, the disclosure of which is also incorporated herein by reference.

The advantage of public key cryptography over symmetric key cryptography for authentication and key exchange is that there is no need for a shared secret between the communicating parties to exist prior to the initiation of the protocol. In fact, the very purpose of the authentication and key exchange protocol is to establish such a shared secret securely without any prior communications between each of the parties. Commonly, a randomly chosen key (pre-master secret) N^* _c is generated by an initiator C and sent securely to the receiver S after the pre- master secret is encrypted with the receiver's public key K⁺ _s. Only a receiver in possession of the corresponding private key K_s ^' can obtain the key N^* _c thus achieving authentication and key exchange. The pre-master secret may then be used by both C and S for generating a symmetric key (master secret) K_cs under which subsequent communications are conducted.

Unfortunately, things are rarely so simple. The security of the authentication and key exchange protocol now rests on the security of the public-private key pair. This raises two significant questions: (1) Does the public key K*_s actually belong to the named party S who owns the private key K_s ^'? (2) Is the private key K₈ ^" corresponding to the public key K⁺ _s still secure? If someone other than S also has access to the private key K_s ^' , he can decrypt any messages encrypted with K*_s and hence the security of the protocol is broken.

To remedy the first problem, and to ensure that the public key K_s* and the name of its owner S are securely binded, the concept of certificates was introduced, as described by L. Kohnfelder, "Towards a Practical Public-key Cryptosystem, " Technical Report, MIT (1978) . With this cryptosystem, a certificate { S, K⁺ _s}_Ka- is provided comprising the pair name S and the public key K*_s signed by a trusted third party CA known as the Certificate Authority using CA ' s private key K^ .

The solution to the second problem, which is known as freshness proof, has conventionally required additional support provided by the Public Key Infrastructure (PKI) . If the private key corresponding to the public key contained in the certificate becomes known to a non-trusted third party, the certificate is said to have been compromised. To prove that a given certificate is not compromised, a Certificate Revocation List (CRL) needs to be consulted before the certificate can be trusted and used.

Thus, to prove the validity of the certificate, the CA ' s verification key can be used, and since validity is a static property, validity checking needs only to be performed once. By contrast, freshness proof is a dynamic property and must be checked every time the certificate is used.

Many practical and social problems face today's PKI. For example, there is no efficient and practical way to cross-certify certificates issued by different countries, governments or even companies. Further, users are not familiar with the intricate problems compromised certificates can engender. Thus, an owner of a certificate is not only responsible for maintaining absolute secrecy of his own certificate, but he is also responsible for constantly checking the certificates of the persons he communicates with. The SSL/TLS protocol is so far the most robust authentication and key exchange protocol designed, but clearly, more ingenious protocols are needed to deal with the problems discussed above.

FIG. 1 is a diagrammatic illustration of a client-server system 20 to which the teachings of the present invention are applicable. More specifically, the system is constituted by a headend facility 22 with a server terminal 24 and associated file storage 26. The file storage can include any of various interactive or non-interactive content, such as HTML documents, image and/or sound files, CGI scripts, etc. which are delivered by the server to various multiple participants 28, 29 and 30 which request the services provided by the headend facility 22. The headend facility 22 is typically interconnected over a highspeed Tl line with other similar servers, so that the headend facility 22 serves not only as a content provider but also as the gateway through which access to any of multiple servers can be established.

The participants 28, 29 and 30 are each equipped with corresponding computing units, wherein such units may be embodied as different types of devices. For example, the participant computing units are illustrated as a desktop computer 32, a mobile telephone unit 33, and a home appliance device 34 one example of which is a set-top box having a digital video recording capability. It shall be understood that other digital processing mechanisms that are capable of handling digital data supplied by the server may also be used. Similarly, the devices are expected to upload data to the server 24 which may include sensitive and/or confidential information requiring a secure connection.

The participant units 32, 33 and 34 are interconnected to the server 24 via a network, represented by network cloud 40. The network 40 may be in the form of a wireless network, such as a satellite or cellular phone network, a wire-based network, such as low-bandwidth telephone lines, or a higher-bandwidth cable or DSL network, or any combination thereof.

Typically, the desktop computer 32 and home appliance 34 will connect to the network 40 over modem devices 36, 38 which may be conventional or high-speed cable modems, or any other known connecting devices, such as wireless or satellite systems, for establishing connections to the network 40. Of particular interest to the present invention are mobile telephones 33 which establish a wireless connection with the network 40 and operate using so-called WAP and I-mode standards in which Internet functions are made possible, such as sending and receiving of email messages, or viewing and interacting with Internet content via an integrated browser program and display screen 37 incorporated into the mobile telephone unit 33.

Although not illustrated, small handheld computing devices known as Portable Digital Assistants (PDAs) may also be used. Such devices also possess Internet functions such as email and web browsing and establish connections to the network 40 using wireless systems or modem lines.

For certain types of content which are delivered by or via the server 24, for example when connecting to an on-line bank, it is necessary for a secure connection with a server to be established. Current SSL/TLS technology provides a program layer for managing the security of message transmissions over the network 40. As described in U.S. Patent No. 5,657,390, the programming for keeping messages confidential is contained in a program layer between an application (such as a web browser) and the Internet's TCP/IP layers. SSL/TLS is an integral part of the known Netscape and Internet Explorer browsers, so that when a web site on a given server is identified as requiring a secure connection, SSL/TLS can be enabled.

FIG. 2 shows the steps involved in the handshake protocol implemented under the conventional SSL/TLS method. The basic and most widely implemented mode of the SSL/TLS handshake protocol is the "named-server anonymous-client" version of the protocol, in which only the server, such as an Internet shopping mall, is authenticated and uses a certificate. The basic function of the protocol is to generate and transfer a shared "pre-master secret" between an anonymous client and a named server. As described in U.S. Patent No. 5,657,390, the "pre-master secret" (referred to under different terminology in Elgamal et al . as a "master key") is typically a randomly generated number which is used by the client and server to produce a symmetrical key (the so-called "master secret") which later is employed to actually encrypt/decrypt all data to be transferred through a known type of IP sockets connection.

The following notations are used in describing the handshake protocol shown in FIG. 2:

c Client s Server

CA Certificate Authority

Α Timestamp generated, by principal i

Ni Random nonce generated by principal i

Public encryption key for principal i

Secret key of principal i i's public key certificate

{^•»>*r Signed by principal i with key K^~

{-}_κt Encrypted with principal j's public key Kf

Table 1: Notations Used to Describe SSL/TLS Handshake Protocol

More specifically, as described in more detail by T. Dierks and C. Allen, "The tls protocol: Version 1.0" referred to above, the basic protocol is made up of six messages transferred between client and server. In message M_{l r} the client C terminal sends a timestamp T_c and a client-side nonce N_c to the server S . A "nonce" is a known term in the art meaning a random number used to ensure channel integrity. In reply to message M_λ , the server returns a message M₂ similarly made up of another timestamp T_s and a server-side nonce N_s . Directly thereafter, in message M₃ , the server sends its authenticated certificate { S, K⁺ ₃}ic_a to the client which, as noted above, is made up of the server's public key binded to the server name S and authenticated by the digital signature of a trusted Certificate Authority.

Message M₄.is a critical step in the handshaking process, since it is at this stage that the "pre-master secret" N^* _c generated on the client side is transmitted to the server S, with the pre-master secret being encrypted under the server's public key K⁺ _s . Since the pre-master secret N^* _c is used for generating the actual symmetrical key ("master secret") K_cs under which all subsequent sensitive communications flow between the client and server, one should at once suspect that if the pre-master secret were to fall into the hands of an imposter, the integrity of the handshake could be compromised. Precisely how such a compromise can occur, which is essential to an understanding of the present invention, shall be described in much greater detail to follow.

In particular, the master secret K_cs is calculated as a function of the pre-master secret N^* _c , and the client and server nonces N_c and N_s, according to the following equation: Kcs = f (Nc> N₈, N^* _c ) . . . ( 1 )

Messages ₅ and M₆ are confirmatory steps performed under the encryption of the master secret K_cs (generated from the pre- master secret N^* _c as described above) to verify the integrity of the communication between the client and server. More specifically, in its server_done message M₅ , the server sends a hash function H(K_CS, CS₅ , [M₁, M₂ , M₃ , M_i] ) of the master secret K_cs, a tag CS₅ indicating the server_done protocol stage, and all preceding messages M_{l t} M₂ , M₃ and M sent between the server and the client, wherein the hash H is encrypted under the master secret K_cs. In a complementary client_done message ₆, the client sends a hash function H(K_CS, CS₆ , [M , M₂ , M^ , M_A] ) of the master secret K_cs, a tag CS₆ indicating the client_done protocol stage, and all preceding messages M_{l f} M₂ , ₃ and M₄ sent between the client and the server, wherein again the hash H is encrypted under the master secret K_cs . The purpose of messages ₅ and M_β is to prevent attacks that are based on interception and faking of messages, by enabling the respective parties to check the hash of all previous messages against messages known to have been already sent and received.

Having confirmed the integrity of the above messages, the client and server are now set up to encrypt all communications from this point on using the master secret K_cs (sometimes also referred to as the "session key" or "master key") which is a symmetrical key used between the client and server.

The SSL/TLS handshake protocol has as its underpinning the reliability of the server's public key, as certified by the certificate { S, ^}^. Unfortunately, certificates alone are not enough to provide the required security for electronic commerce in an open environment such as the Internet. A set of protocols along with methods to guarantee that certificates are fresh are required. Hence, the concept of a Public Key Infrastructure (PKI) was envisioned so that the validity of all certificates could be verified by the possession of the root verification key. Further, to solve the problem that valid certificates can become invalid over time due to various reasons, a Certificate Revocation List (CRL) was also provided in the PKI. In theory, any principal who believes that his certificate has been compromised can revoke that certificate by putting it on the CRL. An entity who wishes to make a secure communication with the principal can check the validity of its certificate by searching through the CRL. However, as a practical matter, having to comb through all the CRLs before knowing if a given certificate is valid is an impossible burden. Moreover, it is foreseeable that a CRL in the possession of a communicating entity (for example at an Internet cafe) may not be the most recently available, and hence is unreliable.

Although attempts to alleviate the problem of requiring the client to comb through all the CRLs have been proposed, such as the Online Certificate Status Protocol (OCSP) , as of today, there is still no solution which can provide an absolute guarantee for certificate freshness proof at any time. On the other hand, commercial products such as the popular Netscape browser or the Internet Explorer have incorporated certificate based authentication protocols such as the above-described SSL and TLS. However, in such basic applications of SSL/TLS, freshness of the certificates is not checked against a Certificate Revocation List, or if checking against a CRL is done (such as in the Internet cafe example) it may be conducted using a local CRL which has become outdated, thereby exposing such systems to potential security holes. Moreover, even if access to fresh CRLs could be provided, it would still be cumbersome and expensive to link to such CRLs and provide proof of freshness for all certificates, particularly for small devices such as mobile phones and PDAs.

As described above, public key based security protocols depend on the freshness of the server certificate for their reliability. Since the SSL/TLS protocol does not itself check the freshness of the certificates used under the protocol, the conventional wisdom is that freshness should be guaranteed by some other protocol, such as OCSP. However, in reality, such guarantees can be very difficult and expensive to implement. With even wider applications of public key certificates, such as proposed by the public key infrastructure (PKI) , it is clear that the number of certificates will increase, the areas where such certificates are expected to be used will broaden, automated uses of certificates will become more standardized, and as a consequence, CRLs will become even more unmanageable. Such facts lead to the conclusion that as use of certificates increases, the reality of compromised certificates will become more widespread and more difficult to discover and manage.

In most of the discussions to date on analysis of security protocols, the case of compromised certificates has been either overlooked or the present state of affairs declared unsafe. The security of public-key based protocols such as SSL/TLS, which have been analyzed under assumed conditions of perfectly fresh certificates only, must be reevaluated in light of the existence of compromised certificates.

A serious security lapse has been discovered by the inventor in the "named-server anonymous-client" version of the SSL/TLS protocol most widely used in internet commerce applications. Particularly, the conventional SSL/TLS protocol is vulnerable to an attack by an individual (for example, an "ex- employee") who comes into possession of a compromised server certificate which might not yet have been placed on the Certificate Revocation List (CRL) to which the client application refers, even though the server uses a new certificate. A compromised server certificate also enables an attack against various client applications which, for reasons of economy or speed, simply do not refer to any CRL. Such an attack allows the illegitimate certificate holder to eavesdrop on subsequent communications between the client and the server because, as shall be described later, the intruder can intercept the pre- master secret and thereby derive the master secret used to decrypt all communications between the client and server.

SUMMARY OF THE INVENTION It is therefore a principal object of the invention to provide an improved public key security protocol which provides extra protection against the problem of compromised certificates.

The present invention aims to resolve the problem of freshness of certificates by requiring the client and server, during the handshaking process, to undertake additional steps which will reveal if a compromised certificate is being used. This offers a significant advantage in that the client is not required to refer to any CRL to determine certificate freshness.

The attack on the conventional SSL/TLS protocol requires an attacker to do two things: a) first, switch the valid certificate with a compromised certificate and learn the pre- master secret from the client; and b) once learned, then re- encrypt the pre-master secret with the server's legitimate public key so the server is unaware that the switch has taken place.

In accordance with the present invention, additional steps to the handshaking protocol provide for a two-step delayed commitment which effectively prevents the attacker from accomplishing these two things as the same time. The attacker can only do one but not the other, and thus the attack is stopped.

The above and other objects, features and advantages of the present invention will become apparent from the following description when taken in conjunction with the accompanying drawings in which preferred embodiments of the present invention are shown by way of illustrative example.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 shows a basic network configuration in which different types of client devices can establish secure connections with a server terminal over a network.

FIG. 2 shows the steps involved in the handshake protocol implemented under the conventional SSL/TLS method.

FIG. 3 is a description of the steps making up the conventional SSL/TLS protocol, together with detailing the steps by which an intruder in possession of a compromised certificate can learn the master secret K_cs . FIG. 4 illustrates a basic first-step approach toward preventing the "ex-employee" attack against the named-server anonymous-client version of the SSL/TLS protocol.

FIG. 5 shows a further development of the approach illustrated in FIG. 4, and illustrates the steps of a handshake protocol possessing greater integrity which overcomes a potential attack on the embodiment shown in FIG. 4.

FIG. 6 shows a still further embodiment, based on the same principles as the handshake protocol depicted in FIG. 5, but modified so as to minimize the changes necessary to integrate the present invention with the current conventional SSL/TLS protocol.

FIG. 7 shows yet another embodiment of an improved handshake protocol according to a different method from that shown in FIGS . 5 and 6.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS Before entering into a detailed discussion of the improvements to the handshaking protocol implemented by the present invention, it is important first to discuss some basic assumptions about certificate verification and compromised certificates, and thereafter to describe the types of attacks possible under known SSL/TLS schemes, which attacks are defeated using the teachings of present invention.

As described in the background section, two aspects of certificate security need to be considered. The first is certificate validity, which is a static property and can be verified using the CA ' a verification key, and need only be checked once when the certificate is first used. This prevents any attempt to substitute an attacker's public key for that of the legitimate owner, because the attacker cannot generate the signature necessary to bind his public key to the legitimate server name. The second aspect of public key security is the freshness property. A legitimate certificate becomes compromised when the private key corresponding to the public key contained in the certificate is known to any non-trusted third party. The freshness property, moreover, is dynamic and must be checked every time the certificate is used. Theoretically, a certificate revocation list (CRL) can be provided which publishes all revoked certificates. However, for reasons mentioned above, reliable access to the CRL cannot be assured. In reality, therefore, it is both technically difficult and financially very expensive to provide freshness proof.

For example, a client browser used in an Internet cafe may not be set up to check the freshness of the server certificate as required. Further, in browsers used in cellular telephones, or in portable digital assistants (PDAs) which have internet-access functionality, because of program size and data handling restrictions in such environments, it is not easily feasible to provide a means of access to a CRL, and hence in such applications, freshness of certificates is generally left unchecked.

On the other hand, when a server's certificate { S, ^}^ becomes compromised, this means that the private key (i.e. the key which enables a person to decrypt messages encrypted under the public key of the server K*_s ) is known to someone other than the owner of the certificate. Thus, although it is not possible for an ill-willed third party to fake a certificate with a proper CA signature, it is nevertheless possible for the third party to acquire the ability to decrypt messages encrypted under the certified public key K⁺ _s . Moreover, while it may be assumed that the owner of the certificate knows when his certificate has become compromised and immediately acts to revoke the certificate by placing it on the CRL, the practical reality is that not all clients will have access to the most recent CRL or may not have the resources to check the certificate against any CRL at all .

The fact that today's Internet is shared and open leads to various opportunities for determined attackers bent on gaining unauthorized access. Such opportunities include abilities to: a) overhear and store a copy of the messages transmitted between client and server; b) intercept or steal the message from its intended receiver; c) decrypt a message encrypted with an encryption key for which the intruder has its corresponding decryption key; d) store such intercepted messages and replay them at any time; and e) make up new messages using a learned secret such as a stolen nonce.

There are three types of attacks which can be considered: 1) An impersonation attack in which the intruder attempts to conduct a protocol run with the intruder interposing himself in the communications between the parties; 2) the passive eavesdrop in which the intruder comes into possession of the master secret used in the communication channel, so that he does not need to actively manipulate the channel in order to gain access to the messages; and 3) a so-called MIM (man-in-the-middle) attack in which the intruder must actively manipulate the communication channel to gain access to messages; for example, he must use different keys to talk to each party throughout the communication while the two parties assume one key is being used.

It will be appreciated that an MIM attack is very difficult to maintain for any sustainable time period. The passive eavesdrop is much easier to carry out than a sustained man-in- the-middle attack, since the latter requires the attacker to decrypt and re-encrypt all communications between the client and server, which is an almost impossible feat. However, if a short impersonation attack involving interception and faking of messages can be conducted across a few message transfers, which enables the intruder to come into possession of the master secret K_cs, thereafter the intruder will easily be able to siphon and store all subsequent communications between the client and server and decrypt them at his leisure. Such a scenario raises even greater concerns when one considers that in the typical electronic commerce transaction, critical sensitive data, such as the user's credit card number and expiration date, are transmitted under encryption by the master secret K_cs after the handshaking protocol has taken place .

Moreover, if an intruder possesses the master secret K_cs for the record layer, he will be able to insert, delete or modify messages at will because the receiver, whether it be the client or the server, will decrypt and verify such altered messages while believing them to be authentic. This type of attack is particularly dangerous for financial transactions. In addition to destroying confidentiality, the ability to alter messages which are supposed to be secure destroys at its core the integrity and non-repudiation properties of the SSL/TLS protocol.

Next, the attack on the named-server anonymous-client SSL/TLS protocol, which is the standard used in electronic commerce transactions between a client browser and a server such as an Internet shopping mall, shall be described. More specifically, FIG. 3 details the steps showing how an intruder with a compromised certificate can learn the master secret K_cs even if the server has updated its own certificate. In FIG. 3, on the left-hand side of the figure, the direction of the communication between client C and server S is shown, C —> S indicating a communication from the client C to the server S and S —> C indicating a communication from the server S to the client C. Further, a message in the form of ... → (X) I indicates that a message intended for X is intercepted by I, whereas a message in the form of (X) I —> ... indicates a message faked by I and misrepresented as originating from X.

The prime marker ' in

indicates a compromised certificate of S, while a fresh and valid certificate of S is indicated by { S, ^}^ . M is a message intercepted by the intruder and M'[ is a message which is faked by the intruder. Such messages are otherwise identical in format with M .

As discussed above, one scenario in which an intruder may come into possession of a compromised certificate is that of a disgruntled or former employee of the service provider, and thus is a sophisticated individual who has access to, or is able to acquire through malfeasance, the server's former private key κ'_s ^~ . Since the client is unable to reliably confirm the freshness of the certificates, the intruder deceives the client into decrypting its messages under the server's former, now compromised, public key K'⁺ _s which the intruder can readily decrypt using K'_s ^~ .

Thus, the intruder is able to effect the attack as follows: Messages _x and M₂ are sent in plain text in identical fashion to the prior art SSL/TLS protocol discussed previously. In message M'₃ the valid certificate for S is intercepted, and next, in message M"₃ , the intruder substitutes the valid certificate { S, K s}_κ^ with the compromised certificate { S^' } ^ . Hence, in the following message M'₄, the client C unwittingly encrypts the pre- master secret N^* _c under the compromised public key K'⁺ _s enabling the intruder, upon interception of the message M , to decrypt and learn the pre-master secret. The intruder then re-encrypts the pre-master secret under the server's valid public key K_s, and sends the pre-master secret N^* _c on to the server S in the faked message M"₄ . At this point, neither the client nor the server is aware of what has taken place, and more importantly, since the intruder is now in possession of N_c, T_c, N_s, T_s and N^* _c , the intruder is able to calculate the master secret K_cs .

Interception and faking of the last four messages M'₅ , M"₅ , 's and M"₆ is now possible, and is in fact required, since both C and S are expected to maintain a consistent record of past messages. Note that in the above-described attack, from either one of the client's or the server's sole perspective, the past messages appear to be consistent, despite the different versions of M₃ and M_A kept by C and S respectively.

The improved handshake protocol which serves to defeat the above type of attack shall next be explained in detail . The above-described "ex-employee" attack against the named-server anonymous-client version of the SSL/TLS handshake protocol succeeds because the intruder learns the pre-master secret N^* _c , along with the other two nonces N_c and N_s which are transmitted in plain text. From this information, the intruder can calculate the master secret K_C3 and succeed in faking the client_done and server_done messages. Because of the three facts that (1) the client is anonymous and therefore cannot generate authenticated messages, (2) the server certificate is itself compromised, and (3) adequate checking of certificate freshness against a CRL is infeasible, it may appear impossible to prevent this type of attack without requiring the client to have its own certificate.

FIG. 4 illustrates a basic first-step approach toward preventing the "ex-employee" attack against the named-server anonymous-client version of the SSL/TLS protocol. The notations used in FIG. 4 are the same as shown in FIGS. 2 and 3 as well as Table 1.

As shown in FIG. 4, to provide a certain unique identity for the "anonymous" client, a new private-public key pair is generated by the client for each session. The public key K_c of the key pair, which is sent in the client_hello message M together with the client nonce N_c and timestamp T_c, will be used by the server to encrypt the server nonce N_s in the server_hello message M₂.

From equation (1) , the master secret K_C3 is derived from N_c, N_s and N^* _c . However, according to the protocol shown in FIG. 4, even if the intruder learns N^* _c because he has control over the compromised server certificate, the intruder is still unable to learn the server nonce N_s encrypted with the client public key K_c because he does not have the private key generated by the client for this particular session.

However, the intruder can nevertheless interpose himself between the client-server communication in the initial phase of the handshake while generating his own public key pair, to replace the client public key with that of his own, as follows:

C → I(S) (Nc,T_c, K+) (Mi) 1(C) → s (N_c,Tc, K'+) (M{) S → I(C) ({N_s}_K, Ts) (M₂) I(S) → c ({N_s}_{κ "} Ts) (Mi)

Such an attack enables the intruder to learn the server nonce N_s and then carry on with the rest of the "ex-employee" attack described in FIG. 3, ultimately leading to knowledge of the master secret K_cs, from whence the passive attack can be implemented. Thus the basic method of FIG. 4, while erecting certain additional barriers that the intruder must overcome before learning the master secret, should not be considered a fail-proof solution.

A handshake protocol possessing greater integrity, and which foils the above attack, is shown in FIG. 5. In the protocol shown in FIG. 5, the serverjhello message is broken into two parts, messages M₂ and M_{4 Λ} . The first part consists of a hash of the encrypted server nonce H( {N₃ }χ_j) whereas the second part of the message, bearing the encrypted server nonce {N_s }χ_j itself, is sent after message M₄.

An intruder seeking to raise an attack upon the protocol shown in FIG. 5 can, of course, still replace the client's public key with that of his own in message M , however, the intruder is unable to learn the server nonce N_s at step M₂ and re-encrypt it with the client's public key because he only possesses the hash of the encrypted server nonce. Before the client will agree to send message M₄, the intruder must make one of two choices: (1) either pass the hash of the encrypted server nonce H( {N_S } _ICC ) to the client as is, or (2) invent a completely new server nonce N'_s and send a hash of the encrypted faked nonce to the client. In the case of (1) , the intruder must also pass M_4ιl as is, in which case the client wil discover that M₂ and M₄₁ are encrypted with a different public key than the one he has. In the case of (2), the intruder is forced to invent both another private-public key pair and a faked server nonce, since the client expects both the hash of the encrypted server nonce H( {N_S }χ+_c ) and the encrypted server nonce {N_s } _K+_C itself before committing to the secure channel. As a result, the client and server will be using different server nonces N'_s and N_s respectively. Moreover, from equation (1) , we see that the master secret K_cs calculated by the server and K'_cs calculated by the client will be different.

Thus, the intruder is forced into sustaining a man-in-the- middle situation, which is extremely difficult to accomplish. Otherwise, the protocol will stop because the messages will not make sense after being decrypted. The intruder is therefore required to intercept each message from the server, decrypt them with K_cs, and then re-encrypt them with K '_cs . The intruder must also intercept each message from the client, decrypt them with K '_cs, and then re-encrypt them with K_C3. As described previously, this kind of attack is far more difficult than the passive eavesdrop attack, in which the intruder need only decrypt subsequent communications after learning the master secret K_cs and in which the intruder merely has to record the encrypted communications and then decrypt them off-line at a later time. Accordingly, the improved handshake protocol offers extra security by rendering the passive eavesdrop attack unattainable.

FIG. 6 shows a still further embodiment based on the same principles as the handshake protocol depicted in FIG. 5. More specifically, to minimize the changes that need to be made to the current conventional SSL/TLS handshake protocol, the approach described in relation to FIG. 5 is integrated into the conventional protocol by adopting the following tactics.

First, we let K⁺ _c be N_c . Instead of generating a random nonce, the client is required to generate its own private-public key pair and send the public key as the nonce N_c. In other words, the nonce N_c itself doubles in function as the client's public key K_c .

Secondly, we let H( {N_s }j^ ) be N_s. In addition to generating a random nonce N_s, the server is required to encrypt the nonce N_s using the client's public key K_c , received in message M_{l t} and send it as N_s. Thus, the nonce N_s serves the dual function of enabling the sending of a hash of an encrypted server-nonce to the client.

Notice that in the integrated version of the handshake protocol, as shown in FIG. 6, N_c and N_s are generated based on the above-described tactics, wherein N_s is an original nonce encrypted and sent in the form of the server nonce. Moreover, N_s is employed, along with the client nonce N_c and the pre-master secret N^* _c , for generating the master secret, so that the session master secret K_cs is still produced as a function of N_c, N_s and N^* _c as in equation (1) :

K_cs = f c N_{g ι} N_c ^* ) ... (1)

Notice also that the client learns the actual value of N_s only after message M₄ instead of learning it after message M₂ as in the conventional protocol. Thus, commitment to the protocol, and generation of the master secret K_CΞ, is delayed until both steps of a two-step commitment scheme have been implemented.

FIG. 7 shows yet another embodiment of an improved handshake protocol, according to a somewhat different method from that shown in FIGS. 5 and 6. More specifically, the method shown in FIG. 7 does not require the client to generate a private- public key pair as in the preceding embodiments.

To impose a computational burden on the client device to generate its own private-public key pair may be too expensive for small devices such as mobile phones or portable digital assistants (PDAs) . It also has the disadvantage of forcing the client to select a cipher suite before one can be agreed to with the server after exchange of the second message, whereas it is a feature of conventional SSL/TLS that the particular encryption scheme used should generally be selected by the server based on the client's available capabilities and needs.

In the method shown in FIG. 7, the intention is to protect the client-generated pre-master secret N^* _c . This goal is achieved by adding a new server-generated nonce N^* _s to the protocol, thereby forcing the intruder to fake a different N^* _c , so that the master secret N_C3 calculated therefrom will be different. Therefore, the method shown by FIG. 7 is similar to that of FIGS. 5 and 6 in that the aims of both methods are the same. However, the method shown by FIG. 7 can be implemented without requiring the client to perform the burdensome operation of generating its own public-private key pair, as well as avoiding the disadvantage of restricting beforehand choices for the cipher suite before negotiating with the server.

Note that, according to the method of FIG. 7, the session

"master secret" is now produced as a function of N_c, N_s, N^* _s and N^* _c as follows:

K_cs = f (N_c, N_B, N , N^* _c ) ... (2)

In message M₄₀, a hash of the client-generated pre-master secret N^* _c , which is encrypted under the server's secure public key, is sent to the server. Further, the server expects message M_{i 0} before it will send out the new server-generated nonce N^* _Ξ in step M_{4 1}. Thus, even in the event that an intruder intervenes and intercepts message M₄₀, at this point, since the intruder cannot determine N^* _c , the intruder must choose between (1) passing the hash of the encrypted pre-master secret as is, or (2) fake a different N^* _c . If the intruder tries (1) , the server will discover that the pre-master secret N^* _c was not encrypted with the server's current public key after message

M₄. On the other hand, if the intruder attempts (2) , there will be two versions of N^* _c (one real and one faked) known to the client and server, respectively, and thus we are back to the argument that the intruder is forced to commit to an active and sustained man-in-the-middle attack rather than the passive eavesdrop .

It shall be understood that the embodiment shown in FIG. 7 possesses the advantage that the client_hello and server_hello messages M_x and M₂ are not changed from the conventional SLL/TLS protocol, so that negotiation with the server over a cipher suite, based on client capabilities and needs, can be made. There is also no need for the client to expend the computational burden of generating its own private-public key pair.

The method shown in FIG. 7, however, does require the addition of two new messages M₄₀ and M₄₁ to the current protocol, as opposed to only a single new message as in the embodiment shown in FIGS. 5 and 6. Further, as shown in Equation (2) above, the function for calculating K_cs differs from the conventional SSL/TLS protocol . Despite these differences from the current SSL/TLS protocol, implementation of the handshake protocol shown in FIG. 7 can be easily facilitated, since use of the new messages M₄₀ and ₄₁ can be offered and declared as an option during exchange of the client_hello and server iello messages (i.e. during cipher negotiation) , so that the client and server can optionally choose to engage in the improved handshake protocol or simply ignore it. Such an option makes the improved protocol backwards compatible with current systems which may not be prepared to operate using the improved handshake. A similar type of optional election of the protocol can also be used with the embodiments of FIGS. 5 and 6. For example, should the client and server elect not to use the improved protocol, the client's public key K_c in message M is simply ignored, and subsequent messages are transferred in accordance with the conventional SSL/TLS protocol, thus achieving the same backwards compatibility with existing systems.

The embodiments of the invention shown in FIGS. 5 through 7 all effectively provide for a "two-step delayed commitment" scheme. More specifically, as described in connection with FIG. 3 above, it is possible for an attacker to intercept and switch the fresh certificate sent in message M₃ , and use the private key of the compromised certificate to learn the pre-master secret N^* _c after intercepting M₄. But to make this attack work, the attacker must also re-encrypt the stolen pre-master secret N^* _c with a legitimate public key. The two-step delayed commitment is designed to prevent an attacker from doing both at the same time.

In other words, referring again to FIG. 7, even if the attacker decides to switch the certificate in step M₃, the attacker is unable to generate a hash of the legitimate pre- master secret encrypted with the legitimate public key of the server. While it is still possible for the attacker to generate a hash of a faked pre-master secret encrypted with the legitimate public key of the server, this will lead to different master secrets calculated by the client and server respectively. Of course, if the attacker doesn't switch the certificate in step M₃, he is incapable of learning anything.

The "commitment" in the "two-step delayed commitment" scheme refers to the actions taken for committing to a certain pre-master secret N^* _c by encrypting it using the server's public key. According to the present invention, such a commitment is divided into two discrete steps . In the first step, only partial information is transmitted. For example, in the embodiment of FIG. 7, a hash of the encrypted pre-master secret is sent in message M_{4 0}. Only after receiving the second server nonce N_s ^* which serves to effectively separate these two steps, a full committed message with all information, (i.e. the encrypted pre-master secret of N^* _c ) is then transmitted in the second step.

It shall be understood by persons skilled in the art that the two-step commitment scheme is not limited to the scheme described herein which involves, in the case of FIG. 7, sending a hash of the encrypted pre-master secret in step one, then the encrypted entire pre-master secret in step two. For example, it is also possible to break the first message into two parts, bitwise, send the first half encrypted under the server's public key in a first step, and then send the whole part later. Or indeed, any other ways of transmitting only partial information of a message which is encrypted under the server's public key in a first step, followed by the whole message in the second step are sufficient to achieve the aims of the present invention. The only requirements are that the -first, partial message cannot be used to learn the whole message (a hash function, or any one-way function, can achieve this) , the partial message is encrypted under the server's public key, and the partial message can be used to unambiguously identify the whole message (again, any one-way function can achieve this) .

From an implementation point of view, in connection with the embodiment of FIG. 7, the present invention contemplates at least three methods of achieving such a "two-step delayed commitment" scheme.

(1) send the hash of an encrypted pre-master secret, interject a server nonce, followed by the encrypted pre- master secret;

(2) send half of the pre-master secret (bitwise) which is encrypted under the server's public key, interject a server nonce, followed by the encrypted pre-master secret; and

(3) send a predetermined portion of the pre-master secret which is encrypted under the server's public key, interject a server nonce, followed by the encrypted pre- master secret.

In the embodiments of FIGS. 5 and 6, since it is the server nonce which is sent in two parts, the present invention likewise contemplates analogous methods for achieving the "two-step delayed commitment" scheme.

(1) send the hash of an encrypted server nonce, interceded by the server's certificate and the encrypted pre-master secret, followed by the encrypted server nonce;

(2) send half of the server nonce (bitwise) which is encrypted under the client's public key, interceded by the server's certificate and the encrypted pre-master secret, followed by the encrypted server nonce; and

(3) send a predetermined portion of the server nonce which is encrypted under the client's public key, interceded by the server's certificate and the encrypted pre-master secret, followed by the encrypted server nonce.

As described herein, two basic approaches for preventing an "ex-employee" type of attack on the conventional SSL/TLS protocol are presented which require only slight modification to the current protocol . Extra security is achieved by requiring the intruder to use an active and sustained man-in-the-middle attack for all subsequent (i.e. post-handshake) SSL/TLS communications, rather than being able to engage in a passive eavesdrop.

Although the invention has been described in the context of the most widely implemented "named-server anonymous-client" version of the SSL/TLS protocol, it will be readily appreciated by those skilled in the art that the same improvements and advantages can be added to a "named-server named-client" version of SSL/TLS to achieve similar results. Since the present invention requires little change to the original protocol, the invention can be made to co-exist with the current version of SSL/TLS and, as described above, can be used as an option which is added to the "negotiated cipher" specification of the current SSL/TLS protocol, wherein the improved version of the handshake protocol according to the present invention will be used only if both client and server agree to do so.

The present invention is also applicable to a more recent version of the handshake protocol, adopted in the wireless transport layer security (WTLS) which is an adaptation of TLS for wireless applications. Apart from all versions used in conventional TLS, the WTLS has introduced a further version of the handshake protocol called the "optimized full handshake" (OFH) protocol. In the OFH protocol, instead of receiving a certificate each time a new session of WTLS is initiated, for efficiency, the client can choose to reuse a certificate possessed in the client's local environment. This protocol, however, is obviously more at risk because freshness of certificates is sacrificed for efficiency. The scheme according to the present invention solves the problem of freshness, making the OFH protocol a more viable option.

Yet another advantage of the enhanced handshake protocol according to the present invention is that, since the client is not required to check the freshness of the server certificates, it brings both technical and legal benefits to clients who otherwise would bear the burden and responsibility for checking server certificate freshness. Thus, since there is no liability for failure to check certificate freshness, products and systems incorporating the enhanced protocol will achieve an important commercial benefit.

In terms of the environments in which the improved protocol shall be implemented and used, though not limited thereto, a typical environment would be the same as that discussed in Elgamal et al . , U.S. Patent No. 5,657,390, wherein the handshake protocol is implemented as a sockets application program interface between the application and transport layers in a known IP sockets connection, such as the widely-used winsock transport control protocol (tcp) . The implementation details for the improved protocol will not differ substantially from those of conventional SSL/TLS already disclosed by Elgamal et al . , the disclosure of which has been incorporated herein by reference, and hence detailed discussion of such implementation details have been omitted from the present disclosure. It shall be understood that various modifications will be apparent and can be easily made by persons skilled in the art without departing from the scope and spirit of the present invention. Accordingly, the following claims shall not be limited by the description or illustrations set forth herein, but shall be construed to cover with reasonable breadth all features which may be envisaged as equivalents by those skilled in the art.

Claims

What is claimed is :

1. A method of conducting secure communications using both symmetric and public key cryptography between two entities, typically a client and a server, comprising the steps of: transmitting a message from a first entity to a second entity, wherein said message comprises partial information concerning a randomly generated pre-master secret which is used for generating a symmetrical master secret under which the secure communications are to be encrypted, said partial information including therein an encryption under a public key of said second entity; transmitting at least one intervening message from said second entity to said first entity, said intervening message comprising a random component generated by the second entity; and transmitting a further message from said first entity to said second entity, after receiving said intervening message from said second entity, said further message comprising the complete pre-master secret encrypted under said public key of said second entity, wherein said pre-master secret cannot be learned from said partial information but said partial information can unambiguously identify said pre-master secret, and wherein any alteration to said complete pre-master secret encrypted under said public key of said second entity can be revealed.

2. The method according to claim 1, wherein said partial information comprises a hash of said pre-master secret encrypted under the public key of said second entity.

3. The method according to claim 1, wherein said partial information comprises a bitwise half of said pre-master secret encrypted under the public key of said second entity.

4. The method according to claim 1, wherein said partial information comprises a predetermined bitwise portion of said pre-master secret encrypted under the public key of said second entity.

5. A method of conducting secure communications using both symmetric and public key cryptography between two entities, typically a client and a server, comprising the steps of: transmitting a message from a first entity to a second entity, wherein said message comprises the public key of a private-public key pair generated by said first entity; transmitting a message from said second entity to said first entity, said message comprising partial information concerning a nonce of the second entity encrypted under the public key of said first entity; transmitting a further message from said first entity to said second entity, said further message comprising a complete pre-master secret encrypted under a public key of said second entity; and transmitting a further message from said second entity to said first entity, said further message comprising complete information concerning said nonce of the second entity encrypted under said public key of said first entity, wherein said nonce of the second entity cannot be learned from said partial information but said partial information can unambiguously identify said nonce of the second entity, and wherein any alteration to said nonce of the second entity encrypted under said public key of said first entity can be revealed.

6. The method according to claim 5, wherein said partial information is a hash function of said nonce of said second entity encrypted under the public key of said first entity.

7. The method according to claim 5, wherein said partial information comprises a bitwise half of said nonce of said second entity encrypted under the public key of said first entity.

8. The method according to claim 5, wherein said partial information comprises a predetermined bitwise portion of said nonce of said second entity encrypted under the public key of said first entity.