Secure session capability using public-key cryptography without access to the private key

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application is a continuation of application Ser. No. 16/019,109, which is a continuation of Ser. No. 15/271,190, filed Sep. 20, 2016, now U.S. Pat. No. 10,009,183, which is a continuation of application Ser. No. 14/675,385, filed Mar. 31, 2015, now U.S. Pat. No. 9,450,950, which is a continuation of application Ser. No. 14/248,253, filed Apr. 8, 2014, now U.S. Pat. No. 8,996,873, which is hereby incorporated by reference.

FIELD

0002Embodiments of the invention relate to the field of secure network communications; and more specifically, to establishing a secure session (e.g., Secure Sockets Layer (SSL), Transport Layer Security (TLS)) using public-key cryptography where the server does not have access to the private key used during the secure session handshake.

BACKGROUND

0003Secure Sockets Layer (SSL) and Transport Layer Security (TLS), which is the successor to SSL, provide secure network connections. SSL and/or TLS are commonly used during web browsing (e.g., using HTTPS), email, and other Internet applications. SSL and TLS are described in several Request For Comments (RFCs), including RFC 2246 (describing TLS 1.0), RFC 4346 (describing TLS 1.1), RFC 5246 (describing TLS 1.2), and RFC 6101 (describing SSL 3.0).

0004An SSL or TLS client and server negotiate a set of parameters to establish a secure session in a process called a handshake. For example, the client transmits a hello message (referred to as a ClientHello message) that includes the following: an indication of the requested version of the SSL or TLS protocol, a requested session identifier used to identify the session connection, a list of the cipher suites (cryptographic options) supported by the client, a list of the compression methods supported by the client, random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.

0005In response, the server transmits a hello message to the client (referred to as a ServerHello message) that includes the version of the SSL or TLS protocol supported by the server, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the ClientHello message), the selected compression method (selected from the list of compression methods included in the ClientHello message), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may include a list of the extensions that the server supports.

0006Following the hello messages, the server transmits a list of its certificate(s) in a message referred to as a Certificate message (sometimes referred to as a Server Certificate message). The server then transmits a message indicating that the hello-message phase of the handshake is complete (referred to as a ServerHelloDone message). For some implementations, depending on which key exchange methods are used (e.g., implementations using Diffie-Hellman cipher suites), the server also transmits a message to the client (referred to as a ServerKeyExchange message) that conveys cryptographic information to allow the client to calculate the premaster secret. This message is signed using the private key of the server. The client then transmits a message to the server (referred to as a ClientKeyExchange message) that includes a random value typically generated by the client called a premaster secret or Diffie-Hellman parameters that allows the client and server to agree upon the same premaster secret. The premaster secret is used by both the client and the server to generate a shared secret (referred to as the master secret) that is used to generate session keys that are used to encrypt and decrypt information during the secure session. If the premaster secret is included in the ClientKeyExchange message, it is encrypted using the public key in the certificate sent by the server. By way of a specific example, if the Rivest-Shamir-Adelman (RSA) algorithm is being used for key agreement and authentication, the client generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the server. By way of another specific example, if a Diffie-Hellman implementation is used, the ClientKeyExchange message includes the client's Diffie-Hellman public value. By way of another specific example, if a FORTEZZA hardware encryption system is being used, the client derives a token encryption key (TEK) using the FORTEZZA Key Exchange Algorithm (KEA), which itself uses the public key from the server's certificate along with private parameters of the client, generates a random 48-byte value for the premaster secret and encrypts it using the TEK and transmits the encrypted premaster secret to the server.

0007If the server receives the encrypted premaster secret in the ClientKeyExchange message, it decrypts it with their private key. In an implementation where the ClientKeyExchange message includes cryptographic parameters to generate the premaster secret, the server generates the premaster secret using those cryptographic parameters (which also requires the use of the private key).

0008The client and server each perform a series of steps to generate a master secret from the premaster secret, using the random data included in the ClientHello and ServerHello messages (e.g., the ClientHello.random and ServerHello.random). The master secret is a shared secret that is used to generate session keys, which are symmetric keys that are used to encrypt and decrypt information during the secure session.

0009The client then transmits a message to the server informing it that future messages will be encrypted (referred to as a ChangeCipherSpec message). The client then transmits an encrypted message to the server for validation (referred to as a Finished message). The server transmits to the client a message that future messages will be encrypted (a ChangeCipherSpec message) and an encrypted message to the client for validation (a Finished message). From then on, the handshake is complete and the secure session is established such that future messages between the client and server are encrypted.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:

<figref idref="DRAWINGS">FIG. 1</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to one embodiment;

<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment;

<figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving an encrypted premaster secret from a secure session server according to one embodiment;

<figref idref="DRAWINGS">FIG. 4</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to another embodiment;

<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to one embodiment;

<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving a request to sign cryptographic parameters from a secure session server according to one embodiment;

<figref idref="DRAWINGS">FIG. 7</figref> illustrates another embodiment for establishing a secure session between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake;

<figref idref="DRAWINGS">FIG. 8</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to another embodiment;

<figref idref="DRAWINGS">FIG. 9</figref> is a flow diagram that illustrates exemplary operations performed by a key server according to one embodiment;

<figref idref="DRAWINGS">FIG. 10</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to another embodiment;

<figref idref="DRAWINGS">FIG. 11</figref> is a flow diagram that illustrates exemplary operations performed on a secure session server for establishing a secure session implemented with public-key cryptography between a client device and the secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment;

<figref idref="DRAWINGS">FIG. 12</figref> is a flow diagram that illustrates exemplary operations performed by a key server for establishing a secure session according to one embodiment;

<figref idref="DRAWINGS">FIG. 13</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to another embodiment;

<figref idref="DRAWINGS">FIG. 14</figref> is a flow diagram that illustrates exemplary operations performed on a secure session server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment;

<figref idref="DRAWINGS">FIG. 15</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving an encrypted premaster secret and other information to generate a set of session keys for a secure session between a client device and a secure session server according to one embodiment;

<figref idref="DRAWINGS">FIG. 16A</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key for the requested domain and where the key server generates and transmits to the secure session server the session keys used for the secure session according to one embodiment;

<figref idref="DRAWINGS">FIG. 16B</figref> illustrates exemplary operations for resuming a session according to the embodiment of <figref idref="DRAWINGS">FIG. 16A</figref>;

<figref idref="DRAWINGS">FIG. 17</figref> is a flow diagram that illustrates exemplary operations performed by a secure session server for establishing a secure session implemented with public-key cryptography between a client device and the secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment;

<figref idref="DRAWINGS">FIG. 18</figref> is a flow diagram that illustrates exemplary operations performed by a key server for establishing a secure session connection between a client device and a secure session server that will terminate the secure session connection according to one embodiment;

<figref idref="DRAWINGS">FIG. 19A</figref> illustrates another embodiment for establishing a secure session between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake;

<figref idref="DRAWINGS">FIG. 19B</figref> illustrates exemplary operations for resuming a session according to the embodiment of <figref idref="DRAWINGS">FIG. 19A</figref>;

<figref idref="DRAWINGS">FIG. 20</figref> is a flow diagram that illustrates exemplary operations performed by a secure session server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment;

<figref idref="DRAWINGS">FIG. 21</figref> is a flow diagram that illustrates exemplary operations performed on a key server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment; and

<figref idref="DRAWINGS">FIG. 22</figref> is a block diagram illustrating an exemplary computing device that may be used in accordance with embodiments of the invention.

DESCRIPTION OF EMBODIMENTS

0035In the following description, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In other instances, well-known circuits, structures and techniques have not been shown in detail in order not to obscure the understanding of this description. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

0036References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

0037In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

0038A method and apparatus for establishing a secure session (e.g., SSL or TLS) using public-key cryptography where the secure session server does not have access to the private key used during the secure session handshake is described. The secure session server is a computing device that transmits and receives Internet traffic to and from client devices and is the server in the secure session. For example the secure session server terminates the secure session. By way of a specific example that is used throughout this specification, the secure session server may receive and transmit traffic for the domain https://example.com. The traffic may be received at the secure session server as a result of a client network application of the client device (e.g., a web browser) attempting to visit https://example.com. In one embodiment, the secure session server may act as a server for multiple domains that may belong to one or more domain owners.

0039The secure session server does not have local access to the private key that is used during the handshake procedure when establishing the secure session between the client device and the secure session server. For example, for some cipher suites, the private key is used to decrypt the premaster secret that has been encrypted with the corresponding public key by the client device. As another example, for other cipher suites (e.g., cipher suites that use Diffie-Hellman for the key exchange), the private key is used to sign a message that contains cryptographic parameters that are used to generate the premaster secret. In embodiments of the invention, the required private key is stored (or accessible) from a device remote to the secure session server, which is referred herein as the “key server.” Upon a point during the handshake procedure where the private key is needed, the secure session server requests the key server to access and use the private key.

0040For example, if the premaster secret has been generated by the client and encrypted with a public key, the secure session server may request the key server to decrypt the premaster secret using the corresponding private key. The decrypted premaster secret is used by both the client device and secure session server to create a shared secret (referred to as a master secret) that is used when generating the session keys that are used to encrypt and decrypt data during the secure session. After receiving the encrypted premaster secret (which the secure session server cannot decrypt), the secure session server transmits the encrypted premaster secret to the key server, which has access to the private key that can decrypt the encrypted premaster secret. The key server decrypts and transmits the premaster secret to the secure session server. The secure session server, after receiving the decrypted premaster secret from the key server, generates the master secret and uses the master secret to generate the session keys that are used to encrypt and decrypt data during the secure session. The key server may transmit the decrypted premaster secret to the secure session server over a secure session or otherwise in an encrypted form. The secure session server and client finish the secure session handshake and establish the secure session.

0041As another example, if the selected cipher suite is a Diffie-Hellman cipher suite that requires the cryptographic parameters used when generating the premaster secret to be signed with the private key, the secure session server requests the key server to sign the cryptographic parameters with the private key.

0042<figref idref="DRAWINGS">FIG. 1</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device <b>110</b> and a secure session server <b>120</b> where the secure session server <b>120</b> does not have access to the private key used during the secure session handshake according to one embodiment. The client device <b>110</b> is a computing device (e.g., desktop, laptop, smartphone, mobile phone, tablet, gaming system, set-top box, server, etc.) that includes the client network application <b>115</b> (e.g., a web browser or other application) that is capable of accessing network resources and is capable of acting as a client in a secure session. It should be understood that the use of the term “client device” herein does not require that the device be an end-user client device. Rather, the term “client device” is used herein to refer to a computing device that operates as a client in the client-server relationship of a secure session (e.g., SSL and/or TLS).

0043The secure session server <b>120</b> is a computing device that includes the secure session module <b>140</b> that establishes and maintains secure sessions with client devices (and potentially the key server <b>130</b>). The secure session server <b>120</b> also includes one or more certificates <b>145</b>. By way of example, the certificate(s) <b>145</b> includes a certificate that is bound with example.com. The certificate that is bound with example.com includes a public key. The secure session server <b>120</b> does not store the private key that corresponds with the public key for example.com. The key server <b>130</b> is a computing device that includes the private key(s) <b>150</b>. By way of example, the private key(s) <b>150</b> include a private key that corresponds with the public key included in the certificate for example.com that is stored in the secure session server <b>120</b>. The secure session module <b>150</b> of the secure session server <b>120</b> is configured to, upon a point during the handshake procedure where the private key (e.g., the private key <b>150</b>) is needed, to transmit a request to the key server <b>130</b> to access and use that private key.

0044At operation 1.1, the client device <b>110</b> transmits a Client Hello message to the secure session server <b>120</b>. The Client Hello message begins the secure session handshake. The client device <b>110</b> may transmit the Client Hello message to the secure session server <b>120</b> as a result of the client network application <b>115</b> attempting to visit a website that begins with HTTPS (e.g., https://example.com). In one embodiment, the Client Hello message is transmitted to the secure session server <b>120</b> as a result of a Domain Name System (DNS) request for the domain the client device <b>110</b> is attempting to connect to resolving to an IP address of the secure session server <b>120</b>. The Client Hello message may include the following: an indication of the requested version of the SSL or TLS protocol, a requested session identifier used to identify the session connection, a list of cipher suites supported by the client device <b>110</b>, a list of the compression methods supported by the client device <b>110</b>, random data used for cryptographic purposes (ClientHello.random), and also may indicate whether and what type of extensions defined by the protocol that the client supports. A number of cipher suites may be used in embodiments described herein (e.g., TLS_RSA_WITH_RC4_128_SHA, TLS_RSA_WITH_RC4_128 MD5, TLS_RSA_WITH_3DES_EDE_CBC_SHA, TLS_RSA_WITH_DES_CBC_SHA, TLS_ECDHE_RSA_WITH_RC4_128_SHA; TLS_ECDHE_RSA_WITH_3DES_EDE_CBC_SHA; TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA; TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA; etc.).

0045In response to the Client Hello message, at operation 1.2 the secure session server <b>120</b> transmits a Server Hello message to the client device <b>110</b>. The Server Hello message may include the version of the SSL or TLS protocol supported by the secure session server <b>120</b>, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the Client Hello message), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may also include a list of the extensions that the server supports. The selected cipher suite defines the cipher specification to be used that specifies the pseudorandom function (PRF) used to generate keying material, the bulk data encryption algorithm (such as null, AES, etc.), the Message Authentication Code (MAC) algorithm, and other cryptographic attributes such as encrypted key length, MAC key length, fixed IV length, etc. As will be described in greater detail later herein, if the secure session server <b>120</b> supports session resumption without server-side state and intends to issue a ticket to the client with session state, the session identifier included in the Server Hello message may be empty. If the session identifier is not empty, then the secure session server <b>120</b> may be supporting stateful session resumption.

0046The secure session server <b>120</b> also transmits a Certificate message to the client device <b>110</b> at operation 1.3 (a server Certificate). The Certificate message includes a digital certificate for the requested domain. For example, if the requested domain is example.com, the Certificate message includes a digital certificate bound to example.com. The digital certificate includes, among other things, a public key. At operation 1.4, the secure session server <b>120</b> transmits a Server Hello Done message to the client device <b>110</b> that indicates that the hello-message phase of the handshake is complete.

0047At operation 1.5, the client <b>110</b> transmits a Client Key Exchange message to the secure session server <b>120</b>. The Client Key Exchange message includes a random value called a premaster secret that has been encrypted using the public key included in the Certificate message of operation 1.3. By way of a specific example, if the RSA algorithm is being used for key agreement and authentication, the client device <b>110</b> generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the secure session server <b>120</b>. As will be described below, the decrypted premaster secret is used to generate a shared secret between the client device <b>110</b> and the secure session <b>120</b> (called the master secret), which is then used when generating the encryption and decryption keys used to encrypt and decrypt data transmitted during the secure session. It should be understood that if the encrypted premaster secret cannot be decrypted, then the handshake will fail and the secure session will not be established.

0048The secure session server <b>120</b> does not have the private key to decrypt the premaster secret. However, the private key is stored on the key server <b>130</b> (as one of the private key(s) <b>150</b>). Although <figref idref="DRAWINGS">FIG. 1</figref> illustrates the key server <b>130</b> storing the private keys, in other embodiments the key server <b>130</b> has access to the private keys but those private keys are stored on a different device. At operation 1.6, the secure session server <b>120</b> transmits the encrypted premaster secret to the key server <b>130</b>. The key server <b>130</b> decrypts the encrypted premaster secret using the private key for the requested domain. The key server <b>130</b> then transmits the decrypted premaster secret to the secure session server <b>120</b> at operation 1.7. In one embodiment, the messages of operations 1.6 and 1.7 are transmitted over a secure connection <b>155</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or the encrypted premaster secret and the decrypted premaster secret are otherwise encrypted.

0049In one embodiment, the key server <b>130</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>130</b> may store or have access to the private key for example.com and example2.com. In such an embodiment, in conjunction with transmitting the encrypted premaster secret to the key server <b>130</b>, the secure session server <b>120</b> indicates the domain or zone in which the client device <b>110</b> is requesting a connection. For example, if the client device <b>110</b> is requesting a secure session with example.com, then the secure session server <b>120</b> indicates to the key server <b>130</b> that example.com is the requested domain. The client device <b>110</b> may specify the destination domain using the Server Name Indication (SNI) extension in the Client Hello message. SNI is described in RFC 3546, June 2003. If the destination is not specified by the client device <b>110</b> (e.g., the client device <b>110</b> does not support SNI), then the secure session server <b>120</b> matches the destination IP address of the client-hello message sent by the client device <b>110</b> with the corresponding hostname (e.g., the secure session server <b>120</b> may include a mapping of IP addresses and hostnames). The secure session server <b>120</b> may transmit the indication of the domain or zone name to the key server <b>130</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>130</b> accesses the corresponding private key and decrypts the encrypted premaster secret. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>120</b> may generate a fingerprint over the certificate included in the Certificate message of operation 1.3 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>130</b>. The key server <b>130</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>120</b>, the key server <b>130</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 1.3) to lookup the corresponding private key. As another example, the secure session server <b>120</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 1.3 and transmit that hash value to the key server <b>130</b>. The key server <b>130</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>120</b>, the key server <b>130</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0050The secure session server <b>120</b> uses the decrypted premaster secret to calculate the master secret. The client device <b>110</b> and the secure session server <b>120</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value.

0051The master secret is used by the client device <b>110</b> and the secure session server <b>120</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0052At operation 1.8, the client device <b>110</b> transmits a Change Cipher Spec message to the secure session server <b>120</b>. The Change Cipher Spec message from the client device <b>110</b> indicates that future messages transmitted by the client device <b>110</b> will be encrypted. At operation 1.9, the client device <b>110</b> transmits a Finished message to the secure session server <b>120</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake previously sent and received.

0053At operation 1.10, the secure session server <b>120</b> transmits a Change Cipher Spec message to the client device <b>110</b> that indicates that future messages transmitted by the secure session server <b>120</b> will be encrypted. At operation 1.11, the secure session server <b>120</b> transmits a Finished message to the client device <b>110</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received.

0054After the Finished message of operation 1.11, the handshake is complete and the secure session <b>160</b> is considered to be established. At operation 1.12, future messages of the secure session between the client device <b>110</b> and secure session server <b>120</b> are encrypted over the secure session <b>160</b>, which carry the application data of the connection.

0055As described above, the connection between the secure session server <b>120</b> and the key server <b>130</b> may be a secure connection for securely transmitting the decrypted premaster secret and optionally securely transmitting the encrypted premaster secret. As described above, a secure session (e.g., SSL or TLS) may be established between the secure session server <b>120</b> and the key server <b>130</b>. As part of establishing the secure session, the key server <b>130</b> may request a client certificate from the secure session server <b>120</b> and the secure session server <b>120</b> may transmit a client Certificate message that includes its certificate to the key server <b>130</b>. The data in the client Certificate message is used by the key server <b>130</b> to authenticate the identity of the secure session server <b>120</b>.

0056In some embodiments, the key server <b>130</b> may use IP address blocking to accept connections (such as from the secure session server <b>120</b>) from only certain IP addresses. For example, the key server <b>130</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>130</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>130</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>120</b> and the key server <b>130</b>.

0057Although a secure session has been described between the secure session server <b>120</b> and the key server <b>130</b> that is initiated by the secure session server <b>120</b>, in other embodiments the secure session can be initiated by the key server <b>130</b>.

0058In some embodiments, the messages transmitted by the secure session server <b>120</b> to the key server <b>130</b> are signed with a private key that is known only to the secure session server <b>120</b>. In such embodiments, the key server <b>130</b> verifies the validity of the signature of a message prior to acting on that message. By way of example, the message that includes the encrypted premaster secret at operation 1.6 may be signed with a private key known only to the secure session server <b>120</b>. The key server <b>130</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0059A combination of the security techniques described may be used to provide security for the connection between the secure session server <b>120</b> and the key server <b>130</b>. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>120</b> and the key server <b>130</b>.

0060In one embodiment, the secure connection <b>155</b> between the secure session server <b>120</b> and the key server <b>130</b> may be a Virtual Private Network (VPN) connection, which may be desirable in a firewalled environment.

0061<figref idref="DRAWINGS">FIG. 2</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to one embodiment. The private key is stored remotely from the secure session server (e.g., on a key server).

0062At operation <b>210</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name).

0063In response to receiving the message in operation <b>210</b>, the secure session server may perform a number of operations, including transmitting a digital certificate to the client device at operation <b>215</b>. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to transmitting the digital certificate, the secure session server may perform a number of other operations including transmitting a Server Hello message to the client device. If the message in operation <b>210</b> indicates the destination domain, the secure session server transmits the digital certificate bound to that destination domain. If the message in operation <b>210</b> does not indicate the destination host name, the secure session server transmits the digital certificate that is associated with the destination IP address of the message in operation <b>210</b>, which is bound to the requested domain. Flow moves from operation <b>215</b> to operation <b>220</b>.

0064At operation <b>220</b>, the secure session server receives from the client device a premaster secret that has been encrypted using the public key in the digital certificate transmitted in operation <b>215</b>. The encrypted premaster secret may be sent by the client device in a SSL or TLS Client Key Exchange message. Flow moves from operation <b>220</b> to operation <b>225</b>.

0065The secure session server does not have the private key that corresponds with the public key that encrypted the premaster secret. As a result, the secure session server cannot decrypt the encrypted premaster secret to obtain the premaster secret. At operation <b>225</b>, the secure session server transmits the encrypted premaster secret to a key server that has the private key that can decrypt the encrypted premaster secret. In one embodiment, the key server is located remotely from the secure session server. Moreover, in some embodiments, the secure session server and the key server may be owned and/or operated by different entities. For example, the secure session server may not be under physical control of the owner of the requested domain while the key server is under physical control of the owner of the requested domain. In one embodiment, the encrypted premaster secret is transmitted to the key server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted. Flow moves from operation <b>225</b> to operation <b>230</b>.

0066In response to receiving the encrypted premaster secret, the key server decrypts the encrypted premaster secret and obtains the premaster secret. <figref idref="DRAWINGS">FIG. 3</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving an encrypted premaster secret from a secure session server according to one embodiment. At operation <b>310</b>, the key server receives an encrypted premaster secret from the secure session server. For example, the key server receives the encrypted premaster secret transmitted by the secure session server in operation <b>225</b> of <figref idref="DRAWINGS">FIG. 2</figref>.

0067Flow then moves to operation <b>315</b> where the key server accesses a private key that corresponds with the public key that was used to encrypt the premaster secret. The key server may receive from the secure session server an indication of the domain or zone name in which the client device is attempting to establish a secure session for. This indication may be transmitted in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). The key server uses this indication to access the private key that corresponds with the public key that encrypted the premaster secret.

0068Flow then moves to operation <b>320</b> where the key server decrypts the encrypted premaster secret using the accessed private key. Flow then moves to operation <b>325</b> where the key server transmits the decrypted premaster secret to the secure session server.

0069As described above, the key server may transmit the decrypted premaster secret to the secure session over a secure session. As part of establishing the secure session between the key server and the secure session server, the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0070Referring back to <figref idref="DRAWINGS">FIG. 2</figref>, at operation <b>230</b>, the secure session server receives the decrypted premaster secret from the key server. In one embodiment, the decrypted premaster secret is transmitted to the secure session server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted such that the secure session server is able to decrypt the message. Flow moves from operation <b>230</b> to operation <b>235</b>.

0071After obtaining the decrypted premaster secret from the key server, the secure session server can proceed with the secure session handshake with the client device and establish the secure session. For example, at operation <b>235</b>, the secure session server generates a master secret using the decrypted premaster secret. The client device also generates the same master secret.

0072Flow then moves to operation <b>240</b> where the secure session server generates a set of session keys to be used in the secure session when encrypting and decrypting information. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0073Flow moves from operation <b>240</b> to operation <b>245</b> where the secure session server completes the handshake with the client device and establishes a secure session with the client device. For example, the client device and secure session server each may transmit a Change Cipher Spec message and a Finished message, as previously described herein. While the secure session is in operation, the client device and secure session server may exchange data securely.

0074<figref idref="DRAWINGS">FIG. 4</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device <b>410</b> and a secure session server <b>420</b> where the secure session server <b>420</b> does not have access to the private key used during the secure session handshake according to one embodiment. The embodiment described in <figref idref="DRAWINGS">FIG. 4</figref> describes the messages for establishing a secure session where the cipher suite chosen requires the use of a Server Key Exchange message (e.g., a Diffie-Hellman cipher suite is used such as ephemeral Diffie-Hellman RSA (DHE_RSA), ephemeral Diffie-Hellman Digital Signature Standard (DHE_DSS), Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) (e.g., (ECDHE) (e.g., ECDHE_ECDSA, ECDHE_RSA))). The client device <b>410</b> (including the client network application <b>415</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>420</b>, including the secure session module <b>440</b> and the certificate(s) <b>445</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>430</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0075At operation 4.1, the client device <b>410</b> transmits a Client Hello message to the secure session server <b>420</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref>. In response to the Client Hello message, at operation 4.2 the secure session server <b>420</b> transmits a Server Hello message to the client device <b>410</b>. This Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>420</b> also transmits a Certificate message to the client device <b>410</b> at operation 4.3 (a server Certificate). This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>, but it does not include enough data to allow the client device <b>410</b> to generate the premaster secret.

0076Although not illustrated in <figref idref="DRAWINGS">FIG. 4</figref>, the secure session server <b>420</b> has selected a cipher suite that has a key exchange in which the certificate message transmitted in operation 4.3 does not include enough data to allow the client device <b>410</b> to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) (e.g., ECDHE_ECDSA, ECDHE_RSA)). Because of this, the secure session server <b>420</b> will transmit a message to the client device <b>410</b> that conveys cryptographic information to allow the client device <b>410</b> and the secure session server <b>420</b> to each generate the same premaster secret. By way of a specific example where the key exchange mechanism is Diffie-Hellman such as DHE_DSS or DHE_RSA, the cryptographic information includes a set of cryptographic parameters that may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value of the server). As another specific example where the key exchange mechanism is Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). The message that conveys the cryptographic information is referred to as a Server Key Exchange message. The cryptographic information of the Server Key Exchange message may need to be signed with the private key <b>450</b> corresponding to the public key of the server transmitted in the Certificate message transmitted in operation 4.3 (e.g., if the key exchange mechanism is DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA). For example, private key <b>450</b> may be used to sign the set of cryptographic parameters, the ClientHello.random value, and the ServerHello.random value. As similarly described with respect to the embodiment discussed in <figref idref="DRAWINGS">FIG. 1</figref>, the secure session server <b>420</b> does not have local access to this private key <b>450</b>. As a result, the secure session server <b>420</b> cannot sign the Server Key Exchange message with this private key <b>450</b>.

0077Since the secure session server <b>420</b> does not have local access to the private key <b>450</b>, at operation 4.4 the secure session server <b>420</b> transmits a request to the key server <b>430</b> to sign the cryptographic parameters of the Server Key Exchange message with the private key <b>450</b>.

0078In one embodiment, the secure session server <b>420</b> generates these cryptographic parameters (and selects the server's private value used in the Diffie-Hellman operation) and transmits these cryptographic parameters and any other required information (e.g., the ClientHello.random and ServerHello.random values) to the key server <b>430</b> to sign using the private key <b>450</b>. In this embodiment, the private key <b>450</b> is typically an RSA key if the key exchange mechanism is DHE_RSA or ECDHE_RSA, and is typically a Digital Signature Algorithm (DSA) key if the key exchange mechanism is DHE_DSS or an ECDSA key if the key exchange mechanism is ECDHE_ECDSA.

0079The key server <b>430</b> transmits the result of the signed server key exchange parameters to the secure session server <b>420</b> at operation 4.5. In one embodiment, the messages of operations 4.4 and 4.5 are transmitted over a secure connection <b>455</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or are otherwise encrypted.

0080In one embodiment, the key server <b>430</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>430</b> may store or have access to the private key for example.com and example2.com. In such an embodiment, the secure session server <b>420</b> indicates the domain or zone in which the client device <b>410</b> is requesting a connection. For example, if the client device <b>410</b> is requesting a secure session with example.com, then the secure session server <b>420</b> indicates to the key server <b>430</b> that example.com is the requested domain. The client device <b>410</b> may specify the destination domain using the SNI extension in the Client Hello message. If the destination is not specified by the client device <b>410</b> (e.g., the client device <b>410</b> does not support SNI), then the secure session server <b>420</b> matches the destination IP address of the client-hello message sent by the client device <b>410</b> with the corresponding hostname (e.g., the secure session server <b>420</b> may include a mapping of IP addresses and hostnames). The secure session server <b>420</b> may transmit the indication of the domain or zone name to the key server <b>430</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>430</b> accesses the corresponding private key. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>420</b> may generate a fingerprint over the certificate included in the Certificate message of operation 4.3 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>430</b>. The key server <b>430</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>420</b>, the key server <b>430</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 4.3) to lookup the corresponding private key. As another example, the secure session server <b>420</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 4.3 and transmit that hash value to the key server <b>430</b>. The key server <b>430</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>420</b>, the key server <b>430</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0081At operation 4.6, the secure session server <b>420</b> transmits the Server Key Exchange message to the client device <b>410</b>, which includes the signed cryptographic parameters. The secure session server <b>420</b> also transmits a Server Hello Done message to the client device <b>410</b> at operation 4.7 that indicates that the hello-message phase of the handshake is complete.

0082The client device <b>410</b> authenticates the information in the Server Key Exchange message using the corresponding public key (e.g., the public key received in the Certificate message transmitted in operation 4.3). Assuming that the information is authenticated, the client device <b>410</b> generates the premaster secret using that information. The client transmits the Client Key Exchange message in operation 4.8.

0083Unlike the Client Key Exchange message of <figref idref="DRAWINGS">FIG. 1</figref>, this Client Key Exchange message transmitted in operation 4.8 does not include the premaster secret. Rather, this Client Key Exchange message includes the information necessary for the server (the secure session server <b>420</b>) to generate the same premaster secret (e.g., it includes the client's Diffie-Hellman public value). For example, in an embodiment where the secure session server <b>420</b> generates the Diffie-Hellman cryptographic parameters, the secure session server <b>420</b> generates the premaster secret using the client's Diffie-Hellman public value (received in the Client Key Exchange message) and its Diffie-Hellman private value.

0084The secure session server <b>420</b> uses the premaster secret to calculate the master secret. The client device <b>410</b> and the secure session server <b>420</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. The master secret is used by the client device <b>410</b> and the secure session server <b>420</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0085At operation 4.9, the client device <b>410</b> transmits a Change Cipher Spec message to the secure session server <b>420</b>. The Change Cipher Spec message from the client device <b>410</b> indicates that future messages transmitted by the client device <b>410</b> will be encrypted. At operation 4.10, the client device <b>410</b> transmits a Finished message to the secure session server <b>420</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake previously sent and received.

0086At operation 4.11, the secure session server <b>420</b> transmits a Change Cipher Spec message to the client device <b>410</b> that indicates that future messages transmitted by the secure session server <b>420</b> will be encrypted. At operation 4.12, the secure session server <b>420</b> transmits a Finished message to the client device <b>410</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received.

0087After the Finished message of operation 4.12, the handshake is complete and the secure session <b>460</b> is considered to be established. At operation 4.13, future messages during the session between the client device <b>410</b> and secure session server <b>420</b> are encrypted over the secure session <b>460</b>, which carry the application data of the connection.

0088As described above, the connection between the secure session server <b>420</b> and the key server <b>430</b> may be a secure connection. As described above, a secure session (e.g., SSL or TLS) may be established between the secure session server <b>420</b> and the key server <b>430</b>. As part of establishing the secure session, the key server <b>430</b> may request a client certificate from the secure session server <b>420</b> and the secure session server <b>420</b> may transmit a client Certificate message that includes its certificate to the key server <b>430</b>. The data in the client Certificate message is used by the key server <b>430</b> to authenticate the identity of the secure session server <b>420</b>.

0089In some embodiments, the key server <b>430</b> may use IP address blocking to accept connections (such as from the secure session server <b>420</b>) from only certain IP addresses. For example, the key server <b>430</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>430</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>430</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>420</b> and the key server <b>430</b>.

0090Although a secure session has been described between the secure session server <b>420</b> and the key server <b>430</b> that is initiated by the secure session server <b>420</b>, in other embodiments the secure session can be initiated by the key server <b>430</b>.

0091In some embodiments, the messages transmitted by the secure session server <b>420</b> to the key server <b>430</b> are signed with a private key that is known only to the secure session server <b>420</b>. In such embodiments, the key server <b>430</b> verifies the validity of the signature of a message prior to acting on that message. By way of example, the message that includes the request to sign the server key exchange parameters of operation 4.4 may be signed with a private key known only to the secure session server <b>420</b>. The key server <b>430</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0092A combination of the security techniques described may be used. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>420</b> and the key server <b>430</b>.

0093In one embodiment, the secure connection <b>455</b> between the secure session server <b>420</b> and the key server <b>430</b> may be a Virtual Private Network (VPN) connection, which may be desirable in a firewalled environment.

0094<figref idref="DRAWINGS">FIG. 5</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to one embodiment.

0095At operation <b>510</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name).

0096In response to receiving the message in operation <b>510</b>, the secure session server may perform a number of operations, including transmitting a digital certificate to the client device at operation <b>515</b>. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to transmitting the digital certificate, the secure session server may perform a number of other operations including transmitting a Server Hello message to the client device. If the message in operation <b>510</b> indicates the destination domain, the secure session server transmits the digital certificate bound to that destination domain. If the message in operation <b>510</b> does not indicate the destination host name, the secure session server transmits the digital certificate that is associated with the destination IP address of the message in operation <b>510</b>, which is bound to the requested domain. Flow moves from operation <b>515</b> to operation <b>520</b>.

0097In the embodiment of <figref idref="DRAWINGS">FIG. 5</figref>, the secure session server has selected a cipher suite that has a key exchange in which the certificate message transmitted by the secure session server does not include enough data to allow the client device to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA).

0098At operation <b>520</b>, the secure session server generates a set of cryptographic parameters used for generating the premaster secret for the selected key exchange message. By way of a specific example where the key exchange mechanism is Diffie-Hellman such as DHE_DSS or DHE_RSA, the cryptographic parameters may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the secure session server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value selected by the secure session server). As another specific example where the key exchange mechanism is Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). Flow moves from operation <b>520</b> to operation <b>525</b>.

0099The set of cryptographic parameters will be included in a message to be transmitted to the client device. Depending on the selected cipher suite, these cryptographic parameters may be required to be signed (e.g., with the private key that corresponds to the public key for the requested domain). The secure session server does not have local access to the private key (e.g., it is stored on a key server that is located remotely from the secure session server). At operation <b>525</b>, the secure session server transmits a request to a key server to sign the set of cryptographic parameters with a private key that corresponds to the public key for the requested domain. In addition to the cryptographic parameters, the request may also include one or more random values that are also signed (e.g., the ClientHello.random and ServerHello.random values). The signed set of cryptographic parameters and other random values will be included in a message to the client device in which the client device authenticates. Flow moves from operation <b>525</b> to operation <b>530</b>.

0100<figref idref="DRAWINGS">FIG. 6</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving a request to sign cryptographic parameters from a secure session server according to one embodiment. At operation <b>610</b>, the key server receives a request to sign cryptographic parameters from a secure session server. For example, the key server receives the request transmitted by the secure session server in operation <b>525</b> of <figref idref="DRAWINGS">FIG. 5</figref>.

0101Flow then moves to operation <b>615</b> where the key server accesses a private key that corresponds with the public key for the requested domain. The key server may receive an indication from the secure session server of the domain or zone name in which the client device is attempting to establish a secure session for. This indication may be transmitted in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). The key server uses this indication to access the private key that corresponds with the public key for the requested domain. Flow then moves to operation <b>620</b>.

0102At operation <b>620</b>, the key server signs the cryptographic parameters using the accessed private key. Flow then moves to operation <b>625</b> where the key server transmits the signed cryptographic parameters to the secure session server.

0103The key server may transmit the signed cryptographic parameters over a secure session. As part of establishing the secure session between the key server and the secure session server, the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a Virtual Private Network (VPN) connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0104Referring back to <figref idref="DRAWINGS">FIG. 5</figref>, at operation <b>530</b>, the secure session server receives, from the key server, a message with the signed set of cryptographic parameters. Flow then moves to operation <b>535</b> where the secure session server transmits the signed set of cryptographic parameters to the client device. The signed set of cryptographic parameters may be transmitted to the client in a Server Key Exchange message. Flow moves from operation <b>535</b> to operation <b>540</b>.

0105The client device will authenticate the information in the message (e.g., authenticate the signature) using the public key previously received from the server. Assuming that it is authenticated, the client device will generate the premaster secret using in part that information. The client device, however, does not communicate the premaster secret to the secure session server in this embodiment. Rather, it communicates the information necessary for the secure session server to generate the same premaster secret. For example, the client device transmits its Diffie-Hellman public value (generated in part from the set of cryptographic parameters received from the secure session server) to the secure session server. Thus, at operation <b>540</b>, the secure session server receives a public value generated by the client device based in part on the cryptographic parameters (e.g., the client device's Diffie-Hellman public value). Flow moves from operation <b>540</b> to operation <b>545</b>.

0106At operation <b>545</b>, the secure session server generates the premaster secret (which should be the same premaster secret as generated by the client device) using the received public value and at least some of the cryptographic parameters. By way of a specific example, the secure session server generates the premaster secret by computing y{circumflex over ( )}X mod p, where y is the public value of the client device, X is the private value of the secure session server, and p is the prime modulus value.

0107Flow moves from operation <b>545</b> to operation <b>550</b>, where the secure session server generates a master secret using the premaster secret. The client device also generates the same master secret. Flow then moves to operation <b>555</b>, where the secure session server generates a set of session keys to be used in the secure session when encrypting and decrypting information. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0108Flow moves from operation <b>555</b> to operation <b>560</b> where the secure session server completes the handshake with the client device and establishes a secure session with the client device. For example, the client device and secure session server each may transmit a Change Cipher Spec message and a Finished message, as previously described herein. While the secure session is in operation, the client device and secure session server may exchange data securely.

0109<figref idref="DRAWINGS">FIG. 7</figref> illustrates another embodiment for establishing a secure session between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake. Similar to the embodiment described in <figref idref="DRAWINGS">FIG. 4</figref>, the embodiment described in <figref idref="DRAWINGS">FIG. 7</figref> describes the messages where the cipher suite chosen requires the use of a Server Key Exchange message (e.g., a Diffie-Hellman cipher suite is used such as DHE_RSA, DHE_DSS, ECDHE_RSA, or ECDHE_ECDSA).

0110Unlike the embodiment described in <figref idref="DRAWINGS">FIG. 4</figref>, however, in the embodiment of <figref idref="DRAWINGS">FIG. 7</figref>, the key server generates the cryptographic parameters used during the key exchange. The client device <b>710</b> (including the client network application <b>715</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>720</b>, including the secure session module <b>740</b> and the certificate(s) <b>745</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>730</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0111At operation 7.1, the client device <b>710</b> transmits a Client Hello message to the secure session server <b>720</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref>. In response to the Client Hello message, at operation 7.2 the secure session server <b>720</b> transmits a Server Hello message to the client device <b>710</b>. This Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>720</b> also transmits a Certificate message to the client device <b>710</b> at operation 7.3 (a server Certificate). This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>, but it does not include enough data to allow the client device <b>710</b> to generate the premaster secret.

0112Although not illustrated in <figref idref="DRAWINGS">FIG. 7</figref>, the secure session server <b>720</b> has selected a cipher suite that has a key exchange in which the certificate message transmitted in operation 7.3 does not include enough data to allow the client device <b>710</b> to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA). Because of this, the secure session server <b>720</b> will transmit a message to the client device <b>710</b> that conveys cryptographic information to allow the client device <b>710</b> and the secure session server <b>720</b> to each generate the same premaster secret. By way of a specific example where the key exchange mechanism is Diffie-Hellman such as DHE_DSS or DHE_RSA, the cryptographic information includes a set of cryptographic parameters that may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value of the server). As another specific example where the key exchange mechanism is ECDHE such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). The message that conveys the cryptographic information is referred to as a Server Key Exchange message. The cryptographic information of the Server Key Exchange message may need to be signed with the private key <b>750</b> corresponding to the public key of the server transmitted in the Certificate message transmitted in operation 7.3 (e.g., if the key exchange mechanism is DHE_RSA, DHE_DSS, ECDHE_RSA, or ECDHE_ECDSA). For example, private key <b>750</b> may be used to sign the set of cryptographic parameters, the ClientHello.random value, and the ServerHello.random value. As similarly described with respect to the embodiment discussed in <figref idref="DRAWINGS">FIG. 1</figref>, the secure session server <b>720</b> does not have local access to this private key <b>750</b>. As a result, the secure session server <b>720</b> cannot sign the Server Key Exchange message with this private key <b>750</b>.

0113At operation 7.4 the secure session server <b>720</b> transmits a request to the key server <b>730</b> to generate and sign the cryptographic parameters to be used in the Server Key Exchange message. The key server <b>730</b> generates the cryptographic parameters (the secure session server <b>420</b> may transmit any other required information such as the ClientHello.random and ServerHello.random values that may be used when signing) and signs the result using the private key <b>750</b>. In this embodiment, the private key <b>750</b> is typically an RSA key if the key exchange mechanism is DHE_RSA or ECDHE_RSA, and is typically a DSA key if the key exchange mechanism is DHE_DSS or an ECDSA key if the key exchange mechanism is ECDHE_ECDSA.

0114At operation 7.5, the key server <b>730</b> transmits the signed server key exchange parameters back to the secure session server <b>720</b>. The secure session server <b>720</b> uses the signed parameters in the Server Key Exchange message transmitted to the client device <b>710</b> at operation 7.6. The secure session server <b>720</b> also transmits a Server Hello Done message to the client device <b>710</b> that indicates that the hello-message phase of the handshake is complete at operation 7.7.

0115In one embodiment, the key server <b>730</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>730</b> may store or have access to the private key for example.com and example2.com. In such an embodiment, the secure session server <b>720</b> indicates the domain or zone in which the client device <b>710</b> is requesting a connection. For example, if the client device <b>410</b> is requesting a secure session with example.com, then the secure session server <b>720</b> indicates to the key server <b>730</b> that example.com is the requested domain. The client device <b>710</b> may specify the destination domain using the SNI extension in the Client Hello message. If the destination is not specified by the client device <b>710</b> (e.g., the client device <b>710</b> does not support SNI), then the secure session server <b>720</b> matches the destination IP address of the client-hello message sent by the client device <b>710</b> with the corresponding hostname (e.g., the secure session server <b>720</b> may include a mapping of IP addresses and hostnames). The secure session server <b>720</b> may transmit the indication of the domain or zone name to the key server <b>730</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>730</b> accesses the corresponding private key. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>720</b> may generate a fingerprint over the certificate included in the Certificate message of operation 7.3 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>730</b>. The key server <b>730</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>720</b>, the key server <b>730</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 7.3) to lookup the corresponding private key. As another example, the secure session server <b>720</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 74.3 and transmit that hash value to the key server <b>730</b>. The key server <b>730</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>720</b>, the key server <b>730</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0116The client device <b>710</b> authenticates the information in the Server Key Exchange message using the corresponding public key (e.g., the public key received in the Certificate message transmitted in operation 7.3). Assuming that the information is authenticated, the client device <b>710</b> generates the premaster secret using that information. The client transmits the Client Key Exchange message in operation 7.8.

0117This Client Key Exchange message includes the information necessary for the key server <b>730</b> to generate the same premaster secret (e.g., it includes the client's Diffie-Hellman public value). The secure session server <b>720</b> transmits a request to the key server <b>730</b> to generate the premaster secret using the client's public value at operation 7.9. The key server <b>730</b> generates the premaster secret using the client's public value and transmits the premaster secret to the secure session server <b>720</b> at operation 7.10.

0118The secure session server <b>720</b> uses the premaster secret to calculate the master secret. The client device <b>710</b> and the secure session server <b>720</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. The master secret is used by the client device <b>710</b> and the secure session server <b>720</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0119At operation 7.11, the client device <b>710</b> transmits a Change Cipher Spec message to the secure session server <b>720</b>. The Change Cipher Spec message from the client device <b>710</b> indicates that future messages transmitted by the client device <b>710</b> will be encrypted. At operation 7.12, the client device <b>710</b> transmits a Finished message to the secure session server <b>720</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake previously sent and received.

0120At operation 7.13, the secure session server <b>720</b> transmits a Change Cipher Spec message to the client device <b>710</b> that indicates that future messages transmitted by the secure session server <b>720</b> will be encrypted. At operation 7.14, the secure session server <b>720</b> transmits a Finished message to the client device <b>710</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received.

0121After the Finished message of operation 7.14, the handshake is complete and the secure session <b>760</b> is considered to be established. At operation 7.15 future messages during the session between the client device <b>110</b> and secure session server <b>120</b> are encrypted over the secure session <b>760</b>, which carry the application data of the connection.

0122In one embodiment, the messages transmitted in operations 7.4, 7.5, 7.9, and 7.10 are transmitted over a secure connection <b>755</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or are otherwise encrypted.

0123As described above, a secure session (e.g., SSL or TLS) may be established between the secure session server <b>720</b> and the key server <b>730</b>. As part of establishing the secure session, the key server <b>730</b> may request a client certificate from the secure session server <b>720</b> and the secure session server <b>720</b> may transmit a client Certificate message that includes its certificate to the key server <b>730</b>. The data in the client Certificate message is used by the key server <b>730</b> to authenticate the identity of the secure session server <b>720</b>.

0124In some embodiments, the key server <b>730</b> may use IP address blocking to accept connections (such as from the secure session server <b>720</b>) from only certain IP addresses. For example, the key server <b>730</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>730</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>730</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>720</b> and the key server <b>730</b>.

0125Although a secure session has been described between the secure session server <b>720</b> and the key server <b>730</b> that is initiated by the secure session server <b>720</b>, in other embodiments the secure session can be initiated by the key server <b>730</b>.

0126In some embodiments, the messages transmitted by the secure session server <b>720</b> to the key server <b>730</b> are signed with a private key that is known only to the secure session server <b>720</b>. In such embodiments, the key server <b>730</b> verifies the validity of the signature of a message prior to acting on that message. By way of example, the message that includes the request to sign the server key exchange parameters of operation 7.4 may be signed with a private key known only to the secure session server <b>720</b>. The key server <b>730</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0127A combination of the security techniques described may be used. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>720</b> and the key server <b>730</b>.

0128In one embodiment, the secure connection <b>755</b> between the secure session server <b>720</b> and the key server <b>730</b> may be a Virtual Private Network (VPN) connection, which may be desirable in a firewalled environment.

0129<figref idref="DRAWINGS">FIG. 8</figref> is a flow diagram that illustrates exemplary operations for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake according to another embodiment. At operation <b>810</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name).

0130In response to receiving the message in operation <b>810</b>, the secure session server may perform a number of operations, including transmitting a digital certificate to the client device at operation <b>815</b>. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to transmitting the digital certificate, the secure session server may perform a number of other operations including transmitting a Server Hello message to the client device. If the message in operation <b>810</b> indicates the destination domain, the secure session server transmits the digital certificate bound to that destination domain. If the message in operation <b>810</b> does not indicate the destination host name, the secure session server transmits the digital certificate that is associated with the destination IP address of the message in operation <b>810</b>, which is bound to the requested domain. Flow moves from operation <b>815</b> to operation <b>820</b>.

0131In the embodiment of <figref idref="DRAWINGS">FIG. 8</figref>, the secure session server has selected a cipher suite that has a key exchange in which the certificate message transmitted by the secure session server does not include enough data to allow the client device to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA).

0132In contrast to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 5</figref>, the secure session server does not generate the set of cryptographic parameters used for generating the premaster secret. Instead, the key server generates these cryptographic parameters. At operation <b>820</b>, the secure session server transmits a request to generate and sign a set of cryptographic parameters used for generating the premaster secret to the key server. The request may also include one or more random values that will also be signed (e.g., the ClientHello.random and ServerHello.random values). Flow moves from operation <b>820</b> to operation <b>825</b>.

0133<figref idref="DRAWINGS">FIG. 9</figref> is a flow diagram that illustrates exemplary operations performed by a key server according to one embodiment. At operation <b>910</b>, the key server receives a request from a secure session server to generate and sign cryptographic parameters to be used during generating the premaster secret. For example, the key server receives the request transmitted by the secure session server in operation <b>820</b> of <figref idref="DRAWINGS">FIG. 8</figref>. Flow then moves to operation <b>915</b> where the key server generates the cryptographic parameters used for generating the premaster secret. By way of a specific example where the key exchange mechanism is Diffie-Hellman such as DHE_DSS or DHE_RSA, the cryptographic parameters may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the key server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value selected by the key server). As another specific example where the key exchange mechanism is ECDHE such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). Flow moves from operation <b>915</b> to operation <b>920</b>.

0134At operation <b>920</b>, the key server accesses a private key that corresponds with the public key for the requested domain. The key server may receive an indication from the secure session server of the domain or zone name in which the client device is attempting to establish a secure session for. This indication may be transmitted in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). The key server uses this indication to access the private key that corresponds with the public key for the requested domain. Flow then moves to operation <b>925</b>.

0135At operation <b>925</b>, the key server signs the cryptographic parameters using the accessed private key. Flow then moves to operation <b>930</b> where the key server transmits the signed cryptographic parameters to the secure session server.

0136Referring back to <figref idref="DRAWINGS">FIG. 8</figref>, at operation <b>825</b>, the secure session server receives a message with the signed set of cryptographic parameters from the key server. Flow then moves to operation <b>830</b> where the secure session server transmits the signed set of cryptographic parameters to the client device. The signed set of cryptographic parameters may be transmitted to the client in a Server Key Exchange message. Flow moves from operation <b>830</b> to operation <b>835</b>.

0137The client device will authenticate the information in the message (e.g., authenticate the signature) using the public key previously received from the server. Assuming that it is authenticated, the client device will generate the premaster secret using in part that information. The client device, however, does not communicate the premaster secret to the secure session server in this embodiment. Rather, it communicates the information necessary for the secure session server to generate the same premaster secret. For example, the client device transmits its Diffie-Hellman public value (generated in part from the set of cryptographic parameters received from the secure session server) to the secure session server. Thus, at operation <b>835</b>, the secure session server receives a public value generated by the client device based in part on the cryptographic parameters (e.g., the client device's Diffie-Hellman public value). Flow moves from operation <b>835</b> to operation <b>840</b>.

0138At operation <b>840</b>, the secure session server transmits a request to the key server to generate the premaster secret. This request includes the public value received from the client device.

0139Referring back to <figref idref="DRAWINGS">FIG. 9</figref>, the key server receives the request to generate the premaster secret in operation <b>935</b>. Flow then moves to operation <b>940</b> and the key server generates the premaster secret using the received public value and at least some of the generated cryptographic parameters. For example, the key server generates the premaster secret by computing y{circumflex over ( )}X mod p, where y is the public value of the client device, X is the private value of the key server, and p is the prime modulus value. Flow then moves to operation <b>945</b> where the key server transmits the premaster secret to the secure session server.

0140Referring back to <figref idref="DRAWINGS">FIG. 8</figref>, at operation <b>845</b>, the secure session server receives the premaster secret from the key server. Flow then moves to operation <b>850</b> and the secure session server generates a master secret using the premaster secret. The client device also generates the same master secret. Flow then moves to operation <b>855</b>, where the secure session server generates a set of session keys to be used in the secure session when encrypting and decrypting information. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0141Flow moves from operation <b>855</b> to operation <b>860</b> where the secure session server completes the handshake with the client device and establishes a secure session with the client device. For example, the client device and secure session server each may transmit a Change Cipher Spec message and a Finished message, as previously described herein. While the secure session is in operation, the client device and secure session server may exchange data securely.

0142The key server may transmit the signed cryptographic parameters and/or the premaster secret over a secure session. As part of establishing the secure session between the key server and the secure session server, the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0143In another embodiment, the secure session server may request the key server to generate and sign the cryptographic parameters necessary to generate the premaster secret and may also request and receive the key server's chosen private value used to generate the premaster secret. In such an embodiment, the secure session server can generate the premaster secret using the client device's Diffie-Hellman public value and the Diffie-Hellman private value chosen by the key server.

0144In another embodiment that is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 7</figref>, the key server also generates the master secret in addition to generating the premaster secret. In such an embodiment, the secure session server also transmits to the key server other information that may be necessary to generate the master secret in addition to the premaster secret such as the client's Diffie-Hellman public value (used to generate the premaster secret), the ClientHello.random value (included in the Client Hello message of operation 7.1), and the ServerHello.random value (included in the Server Hello message of operation 7.2) if not already transmitted to the key server. By way of example, the master secret is calculated using a pseudorandom function that takes at least as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. In such an embodiment, the key server may transmit the generated master secret to the secure session server which will proceed with the rest of the handshake without being required to generate the master secret.

0145In another embodiment that is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 7</figref>, the key server generates the master secret and generates the session keys that will be used in the secure session between the client device and the secure session server in addition to generating the premaster secret. In such an embodiment, the secure session server also transmits to the key server any necessary information to the key server to generate the master secret and the session keys in addition to generating the premaster secret. For example, this information may include the client's Diffie-Hellman public value (which the key server uses to generate the premaster secret), the ClientHello.random value, the ServerHello.random value, and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length) if they are not already transmitted to the key server.

0146The key server generates the premaster secret and the master secret as previously described herein. The session keys may be generated using the PRF that takes as input the master secret, the ClientHello.random value, the ServerHello.random value, and a label (e.g., a Key Expansion label) to generate a key block that is partitioned into the client write MAC key, server write MAC key, client write encryption key, and server write encryption key. The key server transmits the session keys to the secure session server for use in the secure session between the client device and the secure session server. The key server may also transmit the master secret to the secure session server for use verifying that the key exchange was successful and also for resuming sessions.

0147<figref idref="DRAWINGS">FIG. 10</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device <b>1010</b> and a secure session server <b>1020</b> where the secure session server <b>1020</b> does not have access to the private key used during the secure session handshake according to another embodiment. The embodiment described with reference to <figref idref="DRAWINGS">FIG. 10</figref> is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 1</figref> with the exception that in addition to transmitting the encrypted premaster secret to the key server, the secure session server <b>1020</b> also transmits the ClientHello.random value and the ServerHello.random value to the key server <b>1030</b>, and the key server <b>1030</b> decrypts the encrypted premaster secret and generates the master secret.

0148The client device <b>1010</b> (including the client network application <b>1015</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>1020</b>, including the secure session module <b>1040</b> and the certificate(s) <b>1045</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>1030</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0149At operation 10.1, the client device <b>1010</b> transmits a Client Hello message to the secure session server <b>1020</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref> and transmitted to the secure session server <b>1020</b> for similar reasons. The Client Hello message includes, among other data, a ClientHello.random value.

0150In response to the Client Hello message, at operation 10.2 the secure session server <b>1020</b> transmits a Server Hello message to the client device <b>1010</b>. This Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. The Server Hello message includes, among other data, a ServerHello.random value.

0151The secure session server <b>1020</b> also transmits a Certificate message to the client device <b>1010</b> at operation 10.3 (a server Certificate). This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>. The Certificate message includes a digital certificate for the requested domain. For example, if the requested domain is example.com, the Certificate message includes a digital certificate bound to example.com. The digital certificate includes, among other things, a public key. The secure session server <b>1020</b> does not store the private key that corresponds with the public key included in the certificate.

0152At operation 10.4, the secure session server <b>1020</b> transmits a Server Hello Done message to the client device <b>1010</b> that indicates that the hello-message phase of the handshake is complete.

0153At operation 10.5, the client device <b>1010</b> transmits a Client Key Exchange message to the secure session server <b>1020</b>. The Client Key Exchange message includes a random value called a premaster secret that has been encrypted using the public key included in the Certificate message of operation 10.3. By way of a specific example, if the RSA algorithm is being used for key agreement and authentication, the client device <b>1010</b> generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the secure session server <b>1020</b>. As will be described below, the decrypted premaster secret is used to generate a shared secret between the client device <b>1010</b> and the secure session <b>1020</b> (called the master secret), which is then used when generating the encryption and decryption keys used to encrypt and decrypt data transmitted during the secure session. It should be understood that if the encrypted premaster secret cannot be decrypted, then the handshake will fail and the secure session will not be established.

0154The secure session server <b>1020</b> does not have the private key to decrypt the premaster secret. However, the private key is stored on the key server <b>1030</b> (as one of the private key(s) <b>1050</b>). Although <figref idref="DRAWINGS">FIG. 10</figref> illustrates the key server <b>1030</b> storing the private keys, in other embodiments the key server <b>1030</b> has access to the private keys but those private keys are stored on a different device.

0155At operation 10.6, the secure session server <b>1020</b> transmits the encrypted premaster secret to the key server <b>1030</b>. In addition to the encrypted premaster secret, the secure session server <b>1020</b> also transmits the ClientHello.random value and the ServerHello.random value to the key server <b>1030</b> in operation 10.6.

0156The key server <b>1030</b> decrypts the encrypted premaster secret using the appropriate private key for the requested domain. The key server <b>1030</b> uses the decrypted premaster secret to calculate the master secret. The client device <b>1010</b> and the key server <b>1030</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value.

0157After generating the master secret, the key server <b>1030</b> transmits the master secret to the secure session server <b>1020</b> at operation 10.7. In one embodiment, the messages of operations 10.6 and 10.7 are transmitted over a secure connection <b>1055</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or the encrypted premaster secret and the decrypted premaster secret are otherwise encrypted.

0158In one embodiment, the key server <b>1030</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>1030</b> may store or have access to the private key for example.com and example2.com, which may be owned or controlled by different entities. In such an embodiment, in conjunction with transmitting the encrypted premaster secret to the key server <b>1030</b>, the secure session server <b>1020</b> indicates the domain or zone in which the client device <b>1010</b> is requesting a connection. For example, if the client device <b>1010</b> is requesting a secure session with example.com, then the secure session server <b>1020</b> indicates to the key server <b>1030</b> that example.com is the requested domain. The client device <b>1010</b> may specify the destination domain using the Server Name Indication (SNI) extension in the Client Hello message. SNI is described in RFC 3546, June 2003. If the destination is not specified by the client device <b>1010</b> (e.g., the client device <b>1010</b> does not support SNI), then the secure session server <b>1020</b> matches the destination IP address of the client-hello message sent by the client device <b>1010</b> with the corresponding hostname (e.g., the secure session server <b>1020</b> may include a mapping of IP addresses and hostnames). The secure session server <b>1020</b> may transmit the indication of the domain or zone name to the key server <b>1030</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>1030</b> accesses the corresponding private key and decrypts the encrypted premaster secret. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>1020</b> may generate a fingerprint over the certificate included in the Certificate message of operation 10.3 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>1030</b>. The key server <b>1030</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>1020</b>, the key server <b>1030</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 10.3) to lookup the corresponding private key. As another example, the secure session server <b>1020</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 10.3 and transmit that hash value to the key server <b>1030</b>. The key server <b>1030</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>1020</b>, the key server <b>1030</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0159The master secret is used by the client device <b>1010</b> and the secure session server <b>1020</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0160At operation 10.8, the client device <b>1010</b> transmits a Change Cipher Spec message to the secure session server <b>1020</b>. The Change Cipher Spec message from the client device <b>1010</b> indicates that future messages transmitted by the client device <b>1010</b> will be encrypted. At operation 10.9, the client device <b>1010</b> transmits a Finished message to the secure session server <b>1020</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake previously sent and received.

0161At operation 10.10, the secure session server <b>1020</b> transmits a Change Cipher Spec message to the client device <b>1010</b> that indicates that future messages transmitted by the secure session server <b>1020</b> will be encrypted. At operation 10.11, the secure session server <b>1020</b> transmits a Finished message to the client device <b>1010</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received.

0162After the Finished message of operation 10.11, the handshake is complete and the secure session <b>1060</b> is considered to be established. At operation 10.12, future messages of the secure session between the client device <b>1010</b> and secure session server <b>1020</b> are encrypted over the secure session <b>1060</b>, which carry the application data of the connection.

0163As described above, the connection between the secure session server <b>1020</b> and the key server <b>1030</b> may be a secure connection for securely transmitting the decrypted premaster secret and optionally securely transmitting the encrypted premaster secret. As described above, a secure session (e.g., SSL or TLS) may be established between the secure session server <b>1020</b> and the key server <b>1030</b>. As part of establishing the secure session, the key server <b>1030</b> may request a client certificate from the secure session server <b>1020</b> and the secure session server <b>1020</b> may transmit a client Certificate message that includes its certificate to the key server <b>1030</b>. The data in the client Certificate message is used by the key server <b>1030</b> to authenticate the identity of the secure session server <b>1020</b>.

0164In some embodiments, the key server <b>1030</b> may use IP address blocking to accept connections (such as from the secure session server <b>1020</b>) from only certain IP addresses. For example, the key server <b>1030</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>1030</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>1030</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>1020</b> and the key server <b>1030</b>.

0165Although a secure session has been described between the secure session server <b>1020</b> and the key server <b>1030</b> that is initiated by the secure session server <b>1020</b>, in other embodiments the secure session can be initiated by the key server <b>1030</b>.

0166In some embodiments, the messages transmitted by the secure session server <b>1020</b> to the key server <b>1030</b> are signed with a private key that is known only to the secure session server <b>1020</b>. In such embodiments, the key server <b>1030</b> verifies the validity of the signature of a message prior to acting on that message. By way of example, the message that includes the encrypted premaster secret at operation 10.6 may be signed with a private key known only to the secure session server <b>1020</b>. The key server <b>1030</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0167A combination of the security techniques described may be used to provide security for the decrypted premaster secret. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>1020</b> and the key server <b>1030</b>.

0168In one embodiment, the secure connection <b>1055</b> between the secure session server <b>1020</b> and the key server <b>1030</b> may be a Virtual Private Network (VPN) connection, which may be desirable in a firewalled environment.

0169<figref idref="DRAWINGS">FIG. 11</figref> is a flow diagram that illustrates exemplary operations performed on a secure session server for establishing a secure session implemented with public-key cryptography between a client device and the secure session server where the secure session server does not have access to a private key for the requested domain according to another embodiment. The private key is stored remotely from the secure session server (e.g., on a key server). The embodiment described with reference to <figref idref="DRAWINGS">FIG. 11</figref> is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 2</figref> with the exception that in addition to transmitting the encrypted premaster secret to the key server, the secure session server also transmits the ClientHello.random value and the ServerHello.random value to the key server and the key server decrypts the encrypted premaster secret and generates the master secret.

0170At operation <b>1110</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name). The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.

0171In response to receiving the message in operation <b>1110</b>, the secure session server may perform a number of operations, including transmitting a digital certificate to the client device at operation <b>1115</b>. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to transmitting the digital certificate, the secure session server may perform a number of other operations including transmitting a Server Hello message to the client device which includes random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random) and may include a list of the extensions that the secure session server supports.

0172If the message in operation <b>1110</b> indicates the destination domain, the secure session server transmits the digital certificate bound to that destination domain. If the message in operation <b>1110</b> does not indicate the destination host name, the secure session server transmits the digital certificate that is associated with the destination IP address of the message in operation <b>1110</b>, which is bound to the requested domain. Flow moves from operation <b>1115</b> to operation <b>1120</b>.

0173At operation <b>1120</b>, the secure session server receives from the client device a premaster secret that has been encrypted using the public key in the digital certificate transmitted in operation <b>1115</b>. The encrypted premaster secret may be sent by the client device in a SSL or TLS Client Key Exchange message. Flow moves from operation <b>1120</b> to operation <b>1125</b>.

0174The secure session server does not have the private key that corresponds with the public key that encrypted the premaster secret. As a result, the secure session server cannot decrypt the encrypted premaster secret to obtain the premaster secret. At operation <b>1125</b>, the secure session server transmits the encrypted premaster secret, the ClientHello.random value, and the ServerHello.random value to a key server that has the private key that can decrypt the encrypted premaster secret.

0175In one embodiment, the key server is located remotely from the secure session server. Moreover, in some embodiments, the secure session server and the key server may be owned and/or operated by different entities. For example, the secure session server may not be under physical control of the owner of the requested domain while the key server is under physical control of the owner of the requested domain. In one embodiment, the encrypted premaster secret, the ClientHello.random value, and the ServerHello.random value are transmitted to the key server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted. Flow moves from operation <b>1125</b> to operation <b>1130</b>.

0176In response to receiving the encrypted premaster secret, the key server decrypts the encrypted premaster secret to obtain the premaster secret. In addition, the key server generates the master secret using the premaster secret, the ClientHello.random value, and the ServerHello.random value. <figref idref="DRAWINGS">FIG. 12</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving an encrypted premaster secret, a ClientHello.random value, and a ServerHello.random value from a secure session server according to one embodiment.

0177At operation <b>1210</b>, the key server receives an encrypted premaster secret, a ClientHello.random value, and a ServerHello.random value from the secure session server. For example, the key server receives the encrypted premaster secret, ClientHello.random value, and ServerHello.random value transmitted by the secure session server in operation <b>1125</b> of <figref idref="DRAWINGS">FIG. 11</figref>.

0178Flow then moves to operation <b>1215</b> where the key server accesses a private key that corresponds with the public key that was used to encrypt the premaster secret. The key server may receive from the secure session server an indication of the domain or zone name in which the client device is attempting to establish a secure session for. This indication may be transmitted in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). The key server uses this indication to access the private key that corresponds with the public key that encrypted the premaster secret.

0179Flow then moves to operation <b>1220</b> where the key server decrypts the encrypted premaster secret using the accessed private key. Flow then moves to operation <b>1225</b> where the key server generates a master secret using the decrypted premaster secret, the ClientHello.random value, and the ServerHello.random value. By way of example, the master secret is calculated using a pseudorandom function that takes as input at least the premaster secret, the ClientHello.random value, and the ServerHello.random value. The client device will use the same pseudorandom function over the same input to compute the same master secret.

0180Flow then moves to operation <b>1230</b> where the key server transmits the generated master secret to the secure session server. The transmission of the master secret to the secure session server may be over a secure session between the secure session server and the key server and/or may itself be encrypted in a way that can be decrypted by the secure session server. If the transmission is over a secure session between the key server and the secure session server, as part of establishing that secure session the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0181Referring back to <figref idref="DRAWINGS">FIG. 11</figref>, at operation <b>1130</b>, the secure session server receives the master secret from the key server. In one embodiment, the master secret is transmitted to the key server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted such that the secure session server is able to decrypt the message containing the master secret. Flow moves from operation <b>1130</b> to operation <b>1135</b>.

0182After receiving the master secret from the key server, the secure session server can proceed with the secure session handshake with the client device and establish the secure session. At operation <b>1135</b>, the secure session server uses the master secret to generate a set of session keys to be used in the secure session when encrypting and decrypting information. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0183Flow moves from operation <b>1135</b> to operation <b>1140</b> where the secure session server completes the handshake with the client device and establishes a secure session with the client device. For example, the client device and secure session server each may transmit a Change Cipher Spec message and a Finished message, as previously described herein. While the secure session is in operation, the client device and secure session server may exchange data securely.

0184While <figref idref="DRAWINGS">FIGS. 10, 11, and 12</figref> were described with respect to the key server transmitting the master secret to the secure session server where the secure session server generates the session keys used in the secure session, in other embodiments the key server also generates the session keys and transmits the session keys to the secure session server. <figref idref="DRAWINGS">FIG. 13</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device <b>1310</b> and a secure session server <b>1320</b> where the secure session server <b>1320</b> does not have access to the private key used during the secure session handshake according to another embodiment. The embodiment described with reference to <figref idref="DRAWINGS">FIG. 13</figref> is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 10</figref> with a difference that the key server <b>1330</b> generates and transmits the session keys to the secure session server <b>1320</b> that are to be used in the secure session between the client device <b>1310</b> and the secure session server <b>1320</b>. For example, the secure session server <b>1320</b> transmits the necessary information to generate the session keys to the key server <b>1330</b> in addition to the encrypted premaster secret.

0185The client device <b>1310</b> (including the client network application <b>1315</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>1320</b>, including the secure session module <b>1340</b> and the certificate(s) <b>1345</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>1330</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0186At operation 13.1, the client device <b>1310</b> transmits a Client Hello message to the secure session server <b>1320</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref> and transmitted to the secure session server <b>1320</b> for similar reasons. The Client Hello message includes, among other data, a ClientHello.random value.

0187In response to the Client Hello message, at operation 13.2 the secure session server <b>1320</b> transmits a Server Hello message to the client device <b>1310</b>. This Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. The Server Hello message includes, among other data, a ServerHello.random value.

0188The secure session server <b>1320</b> also transmits a Certificate message to the client device <b>1310</b> at operation 13.3 (a server Certificate). This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>. The Certificate message includes a digital certificate for the requested domain. For example, if the requested domain is example.com, the Certificate message includes a digital certificate bound to example.com. The digital certificate includes, among other things, a public key. The secure session server <b>1320</b> does not store the private key that corresponds with the public key included in the certificate.

0189At operation 13.4, the secure session server <b>1320</b> transmits a Server Hello Done message to the client device <b>1310</b> that indicates that the hello-message phase of the handshake <b>1370</b> is complete.

0190At operation 13.5, the client device <b>1310</b> transmits a Client Key Exchange message to the secure session server <b>1320</b>. The Client Key Exchange message includes a random value called a premaster secret that has been encrypted using the public key included in the Certificate message of operation 13.3. By way of a specific example, if the RSA algorithm is being used for key agreement and authentication, the client device <b>1310</b> generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the secure session server <b>1320</b>. As will be described below, the decrypted premaster secret is used to generate a master secret that is used when generating the encryption and decryption keys used to encrypt and decrypt data transmitted during the secure session. It should be understood that if the encrypted premaster secret cannot be decrypted, then the handshake will fail and the secure session will not be established.

0191The secure session server <b>1320</b> does not have the private key to decrypt the premaster secret. However, the private key is stored on the key server <b>1330</b> (as one of the private key(s) <b>1350</b>). Although <figref idref="DRAWINGS">FIG. 13</figref> illustrates the key server <b>1330</b> storing the private keys, in other embodiments the key server <b>1330</b> has access to the private keys but those private keys are stored on a different device.

0192At operation 13.6, the secure session server <b>1320</b> transmits to the key server <b>1330</b> the necessary information to generate the session keys to be used in the secure session. For example, this information may include the encrypted premaster secret (which the key server <b>1330</b> decrypts using the private key <b>1350</b> which is then used to generate the master secret), the ClientHello.random value, the ServerHello.random value, and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length) if they are not already transmitted to the key server <b>1330</b>. The key server <b>1330</b> decrypts the encrypted premaster secret using the appropriate private key for the requested domain. The key server <b>1330</b> uses the decrypted premaster secret to calculate the master secret. The client device <b>1310</b> and the key server <b>1330</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value.

0193After generating the master secret, the key server <b>1330</b> uses the master secret and the information sent in operation 13.6 to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key is generated. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0194After generating the session keys, the key server <b>1330</b> transmits the session keys to the secure session server <b>1320</b> at operation 13.7. In one embodiment, the messages of operations 13.6 and 13.7 are transmitted over a secure connection <b>1355</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or the data itself is otherwise encrypted.

0195In one embodiment, the key server <b>1330</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>1330</b> may store or have access to the private key for example.com and example2.com, which may be owned or controlled by different entities. In such an embodiment, in conjunction with transmitting the information necessary to generate the session keys to the key server <b>1330</b>, the secure session server <b>1320</b> indicates the domain or zone in which the client device <b>1310</b> is requesting a connection. For example, if the client device <b>1310</b> is requesting a secure session with example.com, then the secure session server <b>1320</b> indicates to the key server <b>1330</b> that example.com is the requested domain. The client device <b>1310</b> may specify the destination domain using the Server Name Indication (SNI) extension in the Client Hello message. SNI is described in RFC 3546, June 2003. If the destination is not specified by the client device <b>1310</b> (e.g., the client device <b>1310</b> does not support SNI), then the secure session server <b>1320</b> matches the destination IP address of the client-hello message sent by the client device <b>1310</b> with the corresponding hostname (e.g., the secure session server <b>1320</b> may include a mapping of IP addresses and hostnames). The secure session server <b>1320</b> may transmit the indication of the domain or zone name to the key server <b>1330</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>1330</b> accesses the corresponding private key. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>1320</b> may generate a fingerprint over the certificate included in the Certificate message of operation 13.3 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>1330</b>. The key server <b>1330</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>1320</b>, the key server <b>1330</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 13.3) to lookup the corresponding private key. As another example, the secure session server <b>1320</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 13.3 and transmit that hash value to the key server <b>1330</b>. The key server <b>1330</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>1320</b>, the key server <b>1330</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0196At operation 13.8, the client device <b>1310</b> transmits a Change Cipher Spec message to the secure session server <b>1320</b>. The Change Cipher Spec message from the client device <b>1310</b> indicates that future messages transmitted by the client device <b>1310</b> will be encrypted. At operation 13.9, the client device <b>1310</b> transmits a Finished message to the secure session server <b>1320</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake <b>1370</b> previously sent and received.

0197In one embodiment the secure session server <b>1320</b> uses the information in the Finished message to verify that the key exchange was successful. In one embodiment, verifying that the key exchange was successful includes using a pseudorandom function that includes as its input the master secret. In such an embodiment, the secure session server <b>1320</b> may receive the master secret from the key server <b>1330</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1320</b> calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake <b>1370</b> previously sent to the client device <b>1310</b> and received from the client device <b>1310</b> (e.g., the Client Hello message of operation 13.1, the Server Hello message of operation 13.2, the Certificate message of operation 13.3, the Server Hello Done message of operation 13.4, the Client Key Exchange message of operation 13.5, and the Change Cipher Spec message of operation 13.8). That calculated value is compared with the value received in the Finished message (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake <b>1370</b> does not continue. In order to generate the hash of the messages in the handshake <b>1370</b>, the secure session server <b>1320</b> may cache the messages that it receives from the client device <b>1310</b> and sends to the client device <b>1310</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1320</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1310</b> and transmitting each message to the client device <b>1310</b>.

0198In an alternative embodiment where the key server <b>1330</b> does not transmit the master secret to the secure session server <b>1320</b>, the secure session server <b>1320</b> transmits the value included in the Finished message received in operation 13.9 or the Finished message itself to the key server <b>1330</b> for verifying that the key exchange was successful. The secure session server <b>1320</b> may also generate the hash value and transmit it to the key server <b>1330</b> for use in the verification. In such an embodiment, the key server <b>1330</b> responds to the secure session server <b>1320</b> whether the key exchange was verified as successful. It should be understood that if the key exchange is not verified, the handshake will not continue.

0199At operation 13.10, the secure session server <b>1320</b> transmits a Change Cipher Spec message to the client device <b>1310</b> that indicates that future messages transmitted by the secure session server <b>1320</b> will be encrypted. At operation 13.11, the secure session server <b>1320</b> transmits a Finished message to the client device <b>1310</b>. The Finished message may include an encrypted hash of all of the messages in the handshake <b>1370</b> previously sent and received and is used by the client device <b>1310</b> to verify that the key exchange was successful. In one embodiment the Finished message includes a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake <b>1370</b> previously received from the client device <b>1310</b> and sent to the client device <b>1310</b> (e.g., the Client Hello message of operation 13.1, the Server Hello message of operation 13.2, the Certificate message of operation 13.3, the Server Hello Done message of operation 13.4, the Client Key Exchange message of operation 13.5, the Change Cipher Spec message of operation 13.8, the Finished message of operation 13.9, and the Change Cipher Spec message of operation 13.10). In such an embodiment, the secure session server <b>1320</b> may receive the master secret from the key server <b>1330</b>. In order to generate the hash of the messages in the handshake <b>1370</b>, the secure session server <b>1320</b> may cache the messages that it receives from the client device <b>1310</b> and sends to the client device <b>1310</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1320</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1310</b> and transmitting each message to the client device <b>1310</b>.

0200In an alternative embodiment, the secure session server <b>1320</b> transmits a request to the key server <b>1330</b> to generate the value to be included in the Finished message or to generate the entire Finished message that will be transmitted to the client device <b>1310</b>. The secure session server <b>1320</b> may also generate the hash value and transmit it to the key server <b>1330</b> for use in generating the value included in the Finished message. In such an embodiment, the key server <b>1330</b> responds to the secure session server <b>1320</b> with either the generated value to be included in the Finished message or the generated Finished message that includes the generated value.

0201After the Finished message of operation 13.11, the handshake <b>1370</b> is complete and the secure session <b>1360</b> is considered to be established. At operation 13.12, future messages of the secure session between the client device <b>1310</b> and secure session server <b>1320</b> are encrypted over the secure session <b>1360</b>, which carry the application data of the connection.

0202As described above, the connection between the secure session server <b>1320</b> and the key server <b>1330</b> may be a secure connection for securely transmitting the information necessary to generate the session keys and the generated session keys. As described above, a secure session (e.g., SSL or TLS) may be established between the secure session server <b>1320</b> and the key server <b>1330</b>. As part of establishing the secure session, the key server <b>1330</b> may request a client certificate from the secure session server <b>1320</b> and the secure session server <b>1320</b> may transmit a client Certificate message that includes its certificate to the key server <b>1330</b>. The data in the client Certificate message is used by the key server <b>1330</b> to authenticate the identity of the secure session server <b>1320</b>.

0203In some embodiments, the key server <b>1330</b> may use IP address blocking to accept connections (such as from the secure session server <b>1320</b>) from only certain IP addresses. For example, the key server <b>1330</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>1330</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>1330</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>1320</b> and the key server <b>1330</b>.

0204Although a secure session has been described between the secure session server <b>1320</b> and the key server <b>1330</b> that is initiated by the secure session server <b>1320</b>, in other embodiments the secure session can be initiated by the key server <b>1330</b>.

0205In some embodiments, the messages transmitted by the secure session server <b>1320</b> to the key server <b>1330</b> are signed with a private key that is known only to the secure session server <b>1320</b>. In such embodiments, the key server <b>1330</b> verifies the validity of the signature of a message prior to acting on that message. By way of example, the message that includes the information necessary to generate the session keys at operation 13.6 may be signed with a private key known only to the secure session server <b>1320</b>. The key server <b>1330</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0206A combination of the security techniques described may be used to provide security for the generation of the session keys. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>1320</b> and the key server <b>1330</b>.

0207In one embodiment, the secure connection <b>1355</b> between the secure session server <b>1320</b> and the key server <b>1330</b> may be a Virtual Private Network (VPN) connection, which may be desirable in a firewalled environment.

0208In some embodiments the key server <b>1330</b> may transmit the master secret it generated to the secure session server <b>1320</b>. The master secret may be used by the secure session server <b>1320</b> to support resuming sessions. Sessions may be resumed using a stateful session resumption or using a stateless session resumption. Stateful session resumption includes storing session state on the server (e.g., the master secret and the cipher suite). Stateless session resumption includes storing session state (e.g., the master secret and the cipher suite) in a ticket (encrypted with a key not known to the client) that is presented to the client and returned by the client when requesting session resumption. For example, when a connection is established by resuming a session (e.g., the client device <b>1310</b> transmits a ClientHello message with a session ID of a session that is capable of being resumed), new ClientHello.random and ServerHello.random values are generated and hashed with the master secret of the established session. If the master secret is not transmitted to the secure session server <b>1320</b>, the secure session server <b>1320</b> may request the key server <b>1330</b> to hash the new ClientHello.random and ServerHello.random values with the master secret and provide the result to the secure session server <b>1320</b>.

0209For example, the operations 13.13 through 13.21 illustrate resuming a session according to one embodiment. Prior to operation 13.13, the secure session <b>1360</b> between the client device <b>1310</b> and the secure session server <b>1320</b> has been closed. At some point later, at operation 13.13, the secure session server <b>1320</b> receives a Client Hello message from the client device <b>1310</b>. This Client Hello message differs from the Client Hello message of operation 13.1 in that it effectively includes a request to resume the session. This Client Hello message may include a session ID that was set for a previously established secure session (e.g., the secure session <b>1360</b>). The Client Hello message of operation 13.13 includes a different random value than the Client Hello message of operation 13.1 (a different ClientHello.random value).

0210Embodiments may support the use of stateful session resumption and/or stateless session resumption. In the case of stateless session resumption, encrypted session state information is transmitted to the client device <b>1310</b> in the form of a ticket that the client may present back to the secure session server <b>1320</b> when requesting resumption of a session. The ticket includes session state (e.g., the cipher suite and the master secret) and is encrypted with a key that is not known by the client device <b>1310</b> (e.g., it may be encrypted with a key that is known only to the key server <b>1330</b> and/or to the secure session server <b>1320</b>). The client device <b>1310</b> can request a session be resumed using the ticket. In some embodiments the ticket is generated by the key server <b>1330</b> whereas in other embodiments the ticket is generated by the secure session server <b>1320</b>. An exemplary format of the ticket may be defined in accordance with RFC 5077, “Transport Layer Security (TLS) Session Resumption without Server-Side State”, January 2008. If the secure session server <b>1320</b> is generating the ticket, then the key server <b>1330</b> transmits the master secret to the secure session server <b>1320</b>. If the key server <b>1330</b> is generating the ticket, the secure session server <b>1320</b> may transmit a request to the key server <b>1330</b> to generate the ticket only when the client device <b>1310</b> indicates that it supports this extension, where this request may be transmitted to the key server <b>1330</b> after the Finished message transmitted by the client device <b>1310</b> has been successfully verified. The key server <b>1330</b> receives the request to generate the ticket, generates the ticket (encrypting it with a key that is known only to the key server <b>1330</b> for example), and transmits the ticket to the secure session server <b>1320</b>. The secure session server <b>1320</b> transmits the ticket to the client device <b>1310</b> before the Change Cipher Spec message of operation 13.10 and after the Finished message of the client device <b>1310</b> has been verified. In such embodiments, the Client Hello message of operation 13.13 includes the ticket (e.g., in a SessionTicket extension as defined in RFC 5077).

0211At operation 13.14 the secure session server <b>1320</b> transmits a request to the key server <b>1330</b> to generate session keys for resuming the session. As part of this request, the secure session server <b>1320</b> transmits the ClientHello.random value included in the Client Hello message of operation 13.13, a new ServerHello.random value to the key server <b>1330</b> (this ServerHello.random value is different than the ServerHello.random value used in the secure session <b>1360</b>). If the Client Hello message of operation 13.13 includes a ticket for resuming the session that was created by the key server <b>1330</b> and encrypted with a key known only to the key server <b>1330</b>, then secure session server <b>1420</b> also transmits the ticket to the key server <b>1330</b> for resuming the session (which may be in the request of operation 13.14). The secure session server <b>1320</b> may also transmit the session identifier included in the Client Hello message of operation 13.13 (if non-empty) to the key server <b>1330</b>. In one embodiment, instead of the secure session server <b>1320</b> generating and transmitting a new ServerHello.random value to the key server <b>1330</b>, the key server <b>1330</b> generates the new ServerHello.random value.

0212Assuming that the session can be resumed (e.g., a valid ticket was included in the Client Hello message of operation 13.13 or the session identifier included in the Client Hello message of operation 13.13 matches session information in the key server <b>1330</b> and the key server <b>1330</b> is willing to re-establish the connection under the specified session state), the key server <b>1330</b> generates the session keys for the resumed session (which will be different than the session keys used for the secure session <b>1360</b>) using the existing master secret generated for the secure session <b>1360</b> and the new ClientHello.random and ServerHello.random values (along with other security parameters that have been previously negotiated). The key server <b>1330</b> may retrieve the session state (e.g., the master secret and cipher suite) from the contents of the ticket (if included in the Client Hello message of operation 13.13) for stateless session resumption or through its session cache if resuming under stateful session resumption. The session keys may include a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write IV and a server write IV may also be generated depending on the cipher used. The key server <b>1330</b> transmits the session keys to the secure session server <b>1320</b> at operation 13.15.

0213In one embodiment, the messages of operations 13.14 and 13.15 are transmitted over a secure connection <b>1355</b> (e.g., encrypted using SSL or TLS, or other mechanisms) and/or the data itself is otherwise encrypted. The secure connection used between the secure session server <b>1320</b> and the key server <b>1330</b> may be a persistent connection or it may be a new secure session (e.g., different than the secure connection <b>1355</b>).

0214At operation 13.16, the secure session server <b>1320</b> transmits a Server Hello message to the client device <b>1310</b>. This Server Hello message includes a new ServerHello.random value. At operation 13.17, the secure session server <b>1320</b> transmits a Change Cipher Spec message to the client device <b>1310</b> that indicates that future messages transmitted by the secure session server <b>1320</b> will be encrypted using the newly negotiated keys. At operation 13.18, the secure session server <b>1320</b> transmits a Finished message to the client device <b>1310</b>. The Finished message may include an encrypted hash of all of the messages in the handshake <b>1375</b> previously sent and received and is used by the client device <b>1310</b> to verify that the key exchange was successful. In one embodiment the Finished message includes a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake <b>1375</b> previously received from the client device <b>1310</b> and sent to the client device <b>1310</b> for this handshake <b>1375</b> (e.g., the Client Hello message of operation 13.13, the Server Hello message of operation 13.16, and the Change Cipher Spec message of operation 13.17).

0215At operation 13.19, the client device <b>1310</b> transmits a Change Cipher Spec message to the secure session server <b>1320</b>. The Change Cipher Spec message from the client device <b>1310</b> indicates that future messages transmitted by the client device <b>1310</b> will be encrypted using the newly negotiated keys. At operation 13.20, the client device <b>1310</b> transmits a Finished message to the secure session server <b>1320</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in this handshake <b>1375</b> previously sent and received.

0216The information in the Finished message of operation 13.20 is verified to determine whether the key exchange was successful. As described above with respect to verifying the information in the Finished message of operation 13.9, in some embodiments the secure session server <b>1320</b> verifies the Finished message and in other embodiments the secure session server <b>1320</b> transmits the value included in the Finished message or the Finished message itself to the key server <b>1330</b> for verifying whether the key exchange was successful.

0217After the Finished message of operation 13.20 has been verified, the handshake <b>1375</b> is complete and the secure session <b>1365</b> is considered to be established. At operation 13.21, future messages of the secure session between the client device <b>1310</b> and secure session server <b>1320</b> are encrypted over the secure session <b>1360</b>, which carry the application data of the connection.

0218While <figref idref="DRAWINGS">FIG. 13</figref> illustrates an exemplary order of messages being transmitted between the client device <b>1310</b>, the secure session server <b>1320</b>, and the key server <b>1330</b>, certain messages may be transmitted in a different order in some embodiments. For example, the information transmitted to the key server <b>1330</b> in operation 13.6 may be transmitted after receiving the Change Cipher Spec message of operation 13.8 or after receiving the Finished message of operation 13.9. As another example, the message in operation 13.14 may be transmitted after the Server Hello message of operation 13.16 or the Change Cipher Spec message of operation 13.17. As yet another example, the session keys transmitted in operation 13.15 may be transmitted after the Server Hello message of operation 13.16 or the Change Cipher Spec message of operation 13.17.

0219In embodiments where a ticket is used for resuming a session as previously described, the key server <b>1330</b> may also renew the ticket by transmitting a message (e.g., a NewSessionTicket message) to the secure session server <b>1320</b> which may transmit the message to the client device <b>1310</b> after the Server Hello message of operation 13.16.

0220Although <figref idref="DRAWINGS">FIG. 13</figref> illustrates the key server <b>1330</b> generating the session keys after receiving a request to resume the session, in one embodiment the secure session server <b>1320</b> generates the session keys after receiving a request to resume the session. For example, in an embodiment where the key server <b>1330</b> generates a ticket that includes the session state (e.g., the master key and the cipher suite) that is encrypted with a key that is not known or shared with the client device <b>1310</b>, the key server <b>1330</b> may transmit the key to decrypt the ticket to the secure session server <b>1320</b>. Accordingly, upon receiving a request to resume a session from the client device <b>1310</b> that includes a session resumption ticket, the secure session server <b>1320</b> may decrypt the ticket with the key received from the key server <b>1330</b>, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state. Alternatively, the key server <b>1330</b> may generate a ticket that includes the session state (e.g., the master key and the cipher suite) that is encrypted with a key that is not known or shared with the client device <b>1310</b> or the secure session server <b>1320</b>, where upon receiving a request to resume a session from the client device <b>1310</b> that includes a session resumption ticket, the secure session server <b>1320</b> may transmit the encrypted ticket to the key server <b>1330</b>, which then decrypts the ticket, and transmits the decrypted information back to the secure session server <b>1320</b>. The secure session server <b>1320</b> then uses the session state included in the decrypted information to generate the session keys. As another alternative, the key server <b>1330</b> may generate a ticket and transmit that ticket to the secure session server <b>1320</b> in unencrypted form where prior to transmitting the ticket to the client device <b>1310</b>, the secure session server <b>1320</b> encrypts the ticket using a key known only to the secure session server <b>1320</b>. Upon receiving a request to resume a session from the client device <b>1310</b> that includes a session resumption ticket, the secure session server <b>1320</b> may decrypt the ticket with appropriate key, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0221As another example, the key server <b>1330</b> may transmit the master secret to the secure session server <b>1320</b> such that secure session server <b>1320</b> may use either stateful session resumption or stateless session resumption without requiring further interaction with the key server <b>1330</b>. For example in the case of stateful session resumption, the secure session server <b>1320</b> may receive the master secret from the key server <b>1330</b> and store it in association with other session state parameters in its session cache (e.g., the cipher suite). Upon receiving a request to resume a session from a client that includes a session identifier of the session to be resumed, the secure session server <b>1320</b> checks its session cache for a matching identifier and if found and the secure session server <b>1320</b> is willing to re-establish the connection (the secure session server <b>1320</b> may deny the request to resume a session for a variety of reasons including if a lifetime of the session identifier has been reached), the secure session server <b>1320</b> will use that stored session state to generate new session keys for the resumed session. In the case of stateless session resumption, the secure session server <b>1320</b> may receive the master secret from the key server <b>1330</b> and generate and encrypt the ticket that includes the session state information (encrypted with a ticket that may be only known to the secure session server <b>1320</b>). The secure session server <b>1320</b> will provide the ticket to the client device <b>1310</b> (e.g., before the Change Cipher Spec message of operation 13.10 and after the Finished message of the client device <b>1310</b> has been verified). Upon receiving a request to resume a session from the client device <b>1310</b> that includes a session resumption ticket, the secure session server <b>1320</b> may decrypt the ticket, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0222<figref idref="DRAWINGS">FIG. 14</figref> is a flow diagram that illustrates exemplary operations performed on a secure session server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to another embodiment. The private key is stored remotely from the secure session server (e.g., on a key server). The embodiment described with reference to <figref idref="DRAWINGS">FIG. 14</figref> is similar to the embodiment described with reference to <figref idref="DRAWINGS">FIG. 2</figref> with the exception that in addition to transmitting the encrypted premaster secret to the key server, the secure session server also transmits the necessary information for the key server to generate the session keys that will be used in the secure session between the client device and the secure session server.

0223At operation <b>1410</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name). The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.

0224In response to receiving the message in operation <b>1410</b>, the secure session server may perform a number of operations, including transmitting a digital certificate to the client device at operation <b>1415</b>. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to transmitting the digital certificate, the secure session server may perform a number of other operations including transmitting a Server Hello message to the client device which includes random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random) and may include a list of the extensions that the secure session server supports.

0225If the message in operation <b>1410</b> indicates the destination domain, the secure session server transmits the digital certificate bound to that destination domain. If the message in operation <b>1410</b> does not indicate the destination host name, the secure session server transmits the digital certificate that is associated with the destination IP address of the message in operation <b>1410</b>, which is bound to the requested domain. Flow moves from operation <b>1415</b> to operation <b>1420</b>.

0226At operation <b>1420</b>, the secure session server receives from the client device a premaster secret that has been encrypted using the public key in the digital certificate transmitted in operation <b>1415</b>. The encrypted premaster secret may be sent by the client device in a SSL or TLS Client Key Exchange message. Flow moves from operation <b>1420</b> to operation <b>1425</b>.

0227The secure session server does not have the private key that corresponds with the public key that encrypted the premaster secret. As a result, the secure session server cannot decrypt the encrypted premaster secret to obtain the premaster secret. At operation <b>1425</b>, the secure session server transmits the encrypted premaster secret and the other information necessary to generate the session keys that are used to encrypt and decrypt information in the secure session between the client device and the secure session server. For example, the information transmitted to the key server may include the encrypted premaster secret (which the key server decrypts using the corresponding private key which is then used to generate the master secret), the ClientHello.random value, the ServerHello.random value, and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length) if they are not already transmitted to the key server.

0228In one embodiment, the key server is located remotely from the secure session server. Moreover, in some embodiments, the secure session server and the key server may be owned and/or operated by different entities. For example, the secure session server may not be under physical control of the owner of the requested domain while the key server is under physical control of the owner of the requested domain. In one embodiment, the encrypted premaster secret and the other information necessary to generate the session keys are transmitted to the key server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted. Flow moves from operation <b>1425</b> to operation <b>1430</b>.

0229In response to receiving the encrypted premaster secret and the other information necessary to generate the session keys, the key server decrypts the encrypted premaster secret to obtain the premaster secret using the appropriate private key, generates the master secret using the premaster secret, the ClientHello.random value, and the ServerHello.random value, and generates the session keys. <figref idref="DRAWINGS">FIG. 15</figref> is a flow diagram that illustrates exemplary operations performed by a key server in response to receiving an encrypted premaster secret and other information to generate a set of session keys for a secure session between a client device and a secure session server according to one embodiment.

0230At operation <b>1510</b>, the key server receives an encrypted premaster secret and other information necessary to generate a set of session keys used for encrypting and decrypting communication between a client device and a secure session server. For example, the information may include the ClientHello.random value, the ServerHello.random value and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length).

0231Flow then moves to operation <b>1515</b> where the key server accesses a private key that corresponds with the public key that was used to encrypt the premaster secret. The key server may receive from the secure session server an indication of the domain or zone name in which the client device is attempting to establish a secure session for. This indication may be transmitted in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). The key server uses this indication to access the private key that corresponds with the public key that encrypted the premaster secret.

0232Flow then moves to operation <b>1520</b> where the key server decrypts the encrypted premaster secret using the accessed private key. Flow then moves to operation <b>1525</b> where the key server generates a master secret using the decrypted premaster secret, the ClientHello.random value, and the ServerHello.random value. By way of example, the master secret is calculated using a pseudorandom function that takes as input at least the premaster secret, the ClientHello.random value, and the ServerHello.random value. The client device will use the same pseudorandom function over the same input to compute the same master secret.

0233Flow then moves to operation <b>1530</b> where the key server generates a set of session keys to be used in the secure session for encrypting and decrypting communication between the client device and the secure session server. By way of a specific example, the master secret and other required information (e.g., received in operation <b>1510</b>) is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0234Flow then moves to operation <b>1535</b> where the key server transmits the generated session keys to the secure session server. The transmission of the session keys to the secure session server may be over a secure session between the secure session server and the key server and/or the session keys may be encrypted in a way that they can be decrypted by the secure session server. If the transmission is over a secure session between the key server and the secure session server, as part of establishing that secure session the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0235Referring back to <figref idref="DRAWINGS">FIG. 14</figref>, at operation <b>1430</b>, the secure session server receives the session keys from the key server. In one embodiment, the session keys are transmitted to the key server over a secure connection (e.g., encrypted using SSL or TLS) and/or is otherwise encrypted such that the secure session server is able to decrypt the session keys. Flow moves from operation <b>1430</b> to operation <b>1435</b> where the secure session server completes the handshake with the client device and establishes a secure session with the client device. For example, the client device and secure session server each may transmit a Change Cipher Spec message and a Finished message, as previously described herein. While the secure session is in operation, the client device and secure session server may exchange data securely.

0236In addition to transmitting the session keys to the secure session server, the key server may also transmit the generated master secret to the secure session server. The generated master secret may be used when verifying the information included in the Finished message received from the client and when generating the Finished message to transmit to the client. In addition, the master secret may be used when resuming a session between the client device and the secure session server. For example, when a connection is established by resuming a session (e.g., the client transmits a ClientHello message with a session ID of a session that is capable of being resumed or includes a session resumption ticket), new ClientHello.random and ServerHello.random values are generated and hashed with the master secret of the established session. If the master secret is not transmitted to the secure session server, the secure session server may request the key server to hash the new ClientHello.random and ServerHello.random values with the master secret and provide the result to the secure session server to support resumption of sessions.

0237If the master secret is not transmitted to the secure session server, the secure session server may transmit the value included in the Finished message received from the client device or the entire Finished message to the key server to verify that the key exchange was successful. The secure session server may generate the hash value and transmit it to the key server for use in the verification. In such an embodiment, the key server responds to the secure session server whether the key exchange was verified as successful. It should be understood that if the key exchange is not verified, the handshake will not continue.

0238In an alternative embodiment, instead of generating the Finished message (e.g., if the secure session server does not have access to the master secret), the secure session server transmits a request to the key server to generate the value to be included in the Finished message or to generate the entire Finished message that will be transmitted to the client device. The secure session server may also generate the hash value and transmit it to the key server for use in generating the value included in the Finished message. In such an embodiment, the key server responds to the secure session server with either the generated value to be included in the Finished message or the generated Finished message that includes the generated value.

0239In another embodiment, the secure session server proxies the messages of the handshake between the client device and the key server where the key server generates and transmits to the secure session server the set of session keys to be used during the secure session between the client device and the secure session server. <figref idref="DRAWINGS">FIG. 16A</figref> illustrates exemplary messages for establishing a secure session using public-key cryptography between a client device <b>1610</b> and a secure session server <b>1620</b> where the key server <b>1630</b> generates and transmits to the secure session server <b>1620</b> the session keys used for the secure session.

0240The client device <b>1610</b> (including the client network application <b>1615</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>1620</b>, including the secure session module <b>1640</b> and the optional certificate(s) <b>1645</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>1630</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0241At operation 16.1, the client device <b>1610</b> transmits a Client Hello message to the secure session server <b>1620</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref> and transmitted to the secure session server <b>1620</b> for similar reasons. The Client Hello message includes, among other data, a ClientHello.random value. The secure session server <b>1620</b> transmits the Client Hello message to the key server <b>1630</b> at operation 16.2. This Client Hello message is the same or substantially the same as the Client Hello message of operation 16.1.

0242In one embodiment, the secure session server <b>1620</b> may terminate secure session connections for multiple domains that are owned by different entities and the respective private keys for those domains are stored on different key servers. By way of example and assuming that the domain example.com and example2.com are owned by different entities, the secure session server <b>1620</b> may terminate secure session connections for those domains and a first key server may store or have access to the private key for example.com and a second key server may store or have access to the private key for example2.com. If the secure session server <b>1620</b> is supporting multiple domains whose respective private keys are stored on different key servers, the secure session server <b>1620</b> determines which key server to transmit the Client Hello message. If the client device <b>1610</b> specifies the destination domain using the SNI extension in the Client Hello message, the secure session server <b>1620</b> uses the destination domain to determine which key server the Client Hello message should be transmitted to. If the client device <b>1610</b> does not specify the destination domain using the SNI extension, then the secure session server <b>1620</b> matches the destination IP address of the Client Hello message received form the client device <b>1610</b> with the corresponding hostname to determine which key server to determine which key server the Client Hello message should be transmitted to (e.g., the secure session server <b>1620</b> may include a mapping of IP addresses and hostnames). The secure session server <b>1620</b> may also transmit the destination hostname to the key server <b>1630</b> (e.g., if the Client Hello message does not include the SNI extension).

0243In response to receiving the Client Hello message, at operation 16.3 the key server <b>1630</b> transmits a Server Hello message to secure session server <b>1620</b>. The Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. The Server Hello message includes, among other data, a ServerHello.random value. The secure session server <b>1620</b> transmits the Server Hello message to the client device <b>1610</b> at operation 16.4.

0244The key server <b>1630</b> also transmits a Certificate message to the secure session server <b>1620</b> at operation 16.5 (a server Certificate). This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>. The Certificate message includes a digital certificate for the requested domain. For example, if the requested domain is example.com, the Certificate message includes a digital certificate bound to example.com. The digital certificate includes, among other things, a public key. The secure session server <b>1620</b> does not store the private key that corresponds with the public key included in the certificate. The secure session server <b>1620</b> may also not store the digital certificate bound to the requested domain. The secure session server <b>1620</b> transmits the Certificate message to the client device <b>1610</b> at operation <b>166</b>.

0245At operation 16.7, the key server <b>1630</b> transmits a Server Hello Done message to the secure session server <b>1620</b> that indicates that the hello-message phase of the handshake is complete. This Server Hello Done message is similar to the Server Hello Done message described in operation 1.4 of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>1620</b> transmits the Server Hello Done message to the client device <b>1610</b> at operation 16.8.

0246At operation 16.9, the client device <b>1610</b> transmits a Client Key Exchange message to the secure session server <b>1620</b>. The Client Key Exchange message includes a premaster secret that has been encrypted using the public key included in the Certificate message of operation 16.6. By way of a specific example, if the RSA algorithm is being used for key agreement and authentication, the client device <b>1610</b> generates a 48-byte value for the premaster secret and encrypts it using the public key from the server's certificate and transmits the encrypted premaster secret to the secure session server <b>1620</b>. The secure session server <b>1620</b> does not have the private key to decrypt the premaster secret. However, the private key is stored on the key server <b>1630</b> (as one of the private key(s) <b>1650</b>). Although <figref idref="DRAWINGS">FIG. 16A</figref> illustrates the key server <b>1630</b> storing the private keys, in other embodiments the key server <b>1630</b> has access to the private keys but those private keys are stored on a different device. At operation 16.10, the secure session server <b>1620</b> transmits the Client Key Exchange message to the key server <b>1630</b>.

0247The key server <b>1630</b> decrypts the encrypted premaster secret included in the Client Key Exchange message using the appropriate private key for the requested domain. Using the premaster secret, the key server <b>1630</b> calculates the master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. The client device <b>1610</b> also generates the same master secret. The master secret is used by the client device <b>1610</b> and the key server <b>1630</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the master secret is used to generate a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0248At operation 16.11, the client device <b>1610</b> transmits a Change Cipher Spec message to the secure session server <b>1620</b>. The Change Cipher Spec message from the client device <b>1610</b> indicates that future messages transmitted by the client device <b>1610</b> will be encrypted. In one embodiment, the secure session server <b>1620</b> transmits the Change Cipher Spec message to the key server <b>1630</b> at operation 16.12. In another embodiment, the secure session server <b>1620</b> does not transmit the Change Cipher Spec message to the key server <b>1630</b>.

0249At operation 16.13, the client device <b>1610</b> transmits a Finished message to the secure session server <b>1620</b>. The Finished message is used to verify that the key exchange and authentication processes were successful. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b>. For example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b>. In one embodiment, the secure session server <b>1620</b> transmits the Finished message to the key server <b>1630</b> at operation 16.14.

0250In another embodiment, the secure session server <b>1620</b> does not transmit the Finished message to the key server <b>1630</b>. If the secure session server <b>1620</b> does not transmit the Finished message to the key server <b>1630</b>, the secure session server <b>1620</b> will verify whether the key exchange was successful. In one embodiment, verifying that the key exchange was successful includes using a pseudorandom function that includes as its input the master secret. In such an embodiment, the secure session server <b>1620</b> may receive the master secret from the key server <b>1630</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1620</b> calculating a value using the same pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b> (e.g., the Client Hello message of operation 16.1, the Server Hello message of operation 16.4, the Certificate message of operation 16.6, the Server Hello Done message of operation 16.8, the Client Key Exchange message of operation 16.9, and the Change Cipher Spec message of operation 16.11). That calculated value is compared with the value received in the Finished message (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1620</b> may cache the messages that it receives from the client device <b>1610</b> and transmits to the client device <b>1610</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1620</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1610</b> and transmitting each message to the client device <b>1610</b> for generating the hash.

0251At operation 16.15, the key server <b>1630</b> transmits a Change Cipher Spec message to the secure session server <b>1620</b>. At operation 16.16, the secure session server <b>1620</b> transmits the Change Cipher Spec message to the client device <b>1610</b>.

0252At operation 16.17, the key server <b>1630</b> transmits a Finished message to the secure session server <b>1620</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received. For example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent and received.

0253At operation 16.18, the key server <b>1630</b> transmits to the secure session server <b>1620</b> the set of session keys that are used to encrypt and decrypt messages during the secure session between the client device <b>1610</b> and the secure session server <b>1620</b>. The session keys may include a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. The session keys may also include a client write IV and a server write IV depending on the cipher used.

0254The operation 16.18 (transmission of the session keys) may be performed at any time after receiving the Client Key Exchange message in operation 16.10. For example, the key server <b>1630</b> may generate the session keys after receiving the Client Key Exchange message in operation 16.10 prior to receiving the Change Cipher Spec message in operation 16.12 or the Finished message in operation 16.14, or prior to transmitting the Change Cipher Spec message in operation 16.15 or the Finished message in operation 16.17.

0255The session keys will be used by the secure session server <b>1620</b> when encrypting and decrypting information sent between the client device <b>1610</b> and the secure session server <b>1620</b>. For example, the client write key is used by the client device to encrypt data and used by the secure session server to decrypt data received from the client device, the client write MAC key is used to authenticate data written by the client device, the server write key is used by the secure session server to encrypt data and used by the client device to decrypt data received from the secure session server, and the server write MAC key is used to authenticate data written by the secure session server.

0256At operation 16.19, the secure session server <b>1620</b> transmits the Finished message to the client device <b>1610</b>. Thereafter, at operation 16.20, future messages of the secure session between the client device <b>1610</b> and secure session server <b>1620</b> are encrypted over the secure session <b>1660</b>, which carry the application data of the connection.

0257In one embodiment, the messages transmitted between the secure session server <b>1620</b> and the key server <b>1630</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). The session keys transmitted to the secure session server <b>1620</b> may be encrypted in such a way that the secure session server may decrypt them.

0258In one embodiment, the operations of 16.12, 16.14, 16.15, and 16.17 are optional. For example, the secure session server <b>1620</b> may not forward the Change Cipher Spec message to the key server <b>1630</b>. In order to perform the key exchange verification using the information included in the Finished message of operation 16.13, the secure session server <b>1620</b> may receive the master secret from the key server <b>1630</b> in addition to the session keys. The secure session server <b>1620</b> may generate and transmit a Change Cipher Spec message to the client device <b>1610</b> and generate and transmit a Finished message to the to the client device <b>1610</b>. Generating the Finished message may include calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b> (e.g., the Client Hello message of operation 16.1, the Server Hello message of operation 16.4, the Certificate message of operation 16.6, the Server Hello Done message of operation 16.8, the Client Key Exchange message of operation 16.9, the Change Cipher Spec message of operation 16.11, the Finished message of operation 16.13, and the Change Cipher Spec message of operation 16.16). For generating the hash, the secure session server <b>1620</b> may cache the messages that it receives from the client device <b>1610</b> and transmits to the client device <b>1610</b> such that it may generate the hash in the message. Alternatively the secure session server <b>1620</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1610</b> and transmitting each message to the client device <b>1610</b> for generating the hash in the Finished message.

0259In addition to receiving the session keys from the key server <b>1630</b>, the secure session server <b>1620</b> may also receive the master secret from the key server <b>1630</b>. As described above the master secret may be used when verifying information included in the Finished message received from the client device <b>1610</b> and/or when generating the Finished message to transmit to the client device <b>1610</b>.

0260In addition, the master secret may be used when resuming a session between the client device <b>1610</b> and the secure session server <b>1620</b>. Sessions may be resumed using a stateful session resumption or using a stateless session resumption. For example, when a connection is established by resuming a session (e.g., the client device <b>1610</b> transmits a ClientHello message with a session ID of a session that is capable of being resumed), new ClientHello.random and ServerHello.random values are generated and hashed with the master secret of the established session. If the master secret is not transmitted to the secure session server <b>1620</b>, the secure session server <b>1620</b> may request the key server <b>1630</b> to hash the new ClientHello.random and ServerHello.random values with the master secret and provide the result to the secure session server <b>1620</b> to support resumption of sessions.

0261<figref idref="DRAWINGS">FIG. 16B</figref> illustrates exemplary operations for resuming a session according to the embodiment of <figref idref="DRAWINGS">FIG. 16A</figref>. Although not illustrated in <figref idref="DRAWINGS">FIG. 16B</figref>, prior to the operation 16.21, the secure session <b>1660</b> between the client device <b>1610</b> and the secure session server <b>1620</b> has been closed. At some point later, at operation 16.21, the secure session server <b>1620</b> receives a Client Hello message from the client device <b>1610</b>. This Client Hello message differs from the Client Hello message of operation 16.1 in that it effectively includes a request to resume the session. This Client Hello message may include a session ID that was set for a previously established secure session (e.g., the secure session <b>1660</b>). The Client Hello message of operation 16.21 includes a different random value than the Client Hello message of operation 16.1 (a different ClientHello.random value).

0262Embodiments may support the use of stateful session resumption and/or stateless session resumption. In the case of stateless session resumption, encrypted session state information is transmitted to the client device <b>1610</b> in the form of a ticket that the client may present back to the secure session server <b>1620</b> when requesting resumption of a session. The ticket includes session state (e.g., the cipher suite and the master secret) and is encrypted with a key that is not known by the client device <b>1610</b> (e.g., it may be encrypted with a key that is known only to the key server <b>1630</b> and/or to the secure session server <b>1620</b>). The client device <b>1610</b> can request a session be resumed using the ticket. In some embodiments the ticket is generated by the key server <b>1630</b> whereas in other embodiments the ticket is generated by the secure session server <b>1620</b>. An exemplary format of the ticket may be defined in accordance with RFC 5077. If the secure session server <b>1620</b> is generating the ticket, then the key server <b>1630</b> transmits the master secret to the secure session server <b>1620</b>. If the key server <b>1630</b> is generating the ticket, the secure session server <b>1620</b> may transmit a request to the key server <b>1630</b> to generate the ticket only when the client device <b>1610</b> indicates that it supports this extension, where this request may be transmitted to the key server <b>1630</b> after the Finished message transmitted by the client device <b>1610</b> in operation 16.13 has been successfully verified. The key server <b>1630</b> receives the request to generate the ticket, generates the ticket (encrypting it with a key that is known only to the key server <b>1630</b> for example), and transmits the ticket to the secure session server <b>1620</b>. The secure session server <b>1620</b> transmits the ticket to the client device <b>1610</b> before the Change Cipher Spec message of operation 16.16 and after the Finished message of the client device <b>1610</b> has been verified. In such embodiments, the Client Hello message of operation 16.21 includes the ticket (e.g., in a SessionTicket extension as defined in RFC 5077).

0263At operation 16.22, the secure session server <b>1620</b> transmits the Client Hello message to the key server <b>1630</b>. This Client Hello message is the same or substantially the same as the Client Hello message of operation 16.21 and includes the request to resume the session.

0264Assuming that the session can be resumed (e.g., a valid ticket was included in the Client Hello message of operation 16.21 or the session identifier included in the Client Hello message of operation 16.21 matches session information in the key server <b>1630</b> and the key server <b>1630</b> is willing to re-establish the connection under the specified session state), the key server <b>1630</b> generates the session keys for the resumed session (which will be different than the session keys used for the secure session <b>1660</b>) using the existing master secret generated for the secure session <b>1660</b>, the new ClientHello.random value (included in the Client Hello message of operation 16.21), a new ServerHello.random value chosen by the key server <b>1630</b>, and other security parameters that have been previously negotiated. The key server <b>1630</b> may retrieve the session state (e.g., the master secret and cipher suite) from the contents of the ticket (if included in the Client Hello message of operation 16.21) or through its session cache if resuming under stateful session resumption. The session keys may include a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write IV and a server write IV may also be generated depending on the cipher used. The key server <b>1630</b> transmits the session keys to the secure session server <b>1620</b> at operation 16.23.

0265At operation 16.24, the key server transmits a Server Hello message to the secure session server <b>1620</b> that is destined for the client device <b>1610</b>. This Server Hello message includes the new ServerHello.random value selected by the key server <b>1630</b>. At operation 16.25, the secure session server <b>1620</b> forwards the Server Hello message to the client device <b>1610</b>.

0266At operation 16.26, the key server <b>1630</b> transmits a Change Cipher Spec message to the secure session server <b>1620</b> which is transmitted by the secure session server <b>1620</b> to the client device <b>1610</b> at operation 16.27. The Change Cipher Spec message indicates that future messages transmitted by the secure session server <b>1620</b> will be encrypted using the newly negotiated keys.

0267At operation 16.28, the key server <b>1630</b> transmits a Finished message to the secure session server <b>1620</b> which is then transmitted by the secure session server <b>1620</b> to the client device <b>1610</b> at operation 16.29. The Finished message may include an encrypted hash of all the messages in the handshake to resume the session previously sent and received by the client device <b>1610</b> to verify that the key exchange was successful. In one embodiment the Finished message includes a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously received from the client device <b>1610</b> and sent to the client device <b>1610</b> for this handshake (e.g., the Client Hello message of operation 16.21, the Server Hello message of operation 16.25, and the Change Cipher Spec message of operation 16.27).

0268At operation 16.30, the secure session server <b>1620</b> receives a Change Cipher Spec message from the client device <b>1610</b>. The Change Cipher Spec message from the client device <b>1610</b> indicates that future messages transmitted by the client device <b>1610</b> will be encrypted using the newly negotiated keys. In one embodiment, at operation 16.31, the secure session server <b>1620</b> transmits the Change Cipher Spec message to the key server <b>1630</b>. In another embodiment, the secure session server <b>1620</b> does not transmit the Change Cipher Spec message to the key server <b>1630</b>.

0269At operation 16.32, the client device <b>1610</b> transmits a Finished message to the secure session server <b>1620</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in this handshake previously sent by and received by the client device <b>1610</b>. The Finished message is used to verify that the key exchange and authentication processes were successful. For example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent by the client device <b>1610</b> and received at the client device <b>1610</b>. In one embodiment, the secure session server <b>1620</b> transmits the Finished message to the key server <b>1630</b> at operation 16.33.

0270In another embodiment, the secure session server <b>1620</b> does not transmit the Finished message to the key server <b>1630</b>. If the secure session server <b>1620</b> does not transmit the Finished message to the key server <b>1630</b>, the secure session server <b>1620</b> will verify whether the key exchange was successful. In one embodiment, verifying that the key exchange was successful includes using a pseudorandom function that includes as its input the master secret. In such an embodiment, the secure session server <b>1620</b> may receive the master secret from the key server <b>1630</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1620</b> calculating a value using the same pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake for this session that were previously sent to the client device <b>1610</b> and received from the client device <b>1610</b> (e.g., the Client Hello message of operation 16.21, the Server Hello message of operation 16.25, the Change Cipher Spec message of operation 16.27, the Finished message of operation 16.29, and the Change Cipher Spec message of operation 16.30). That calculated value is compared with the value received in the Finished message (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1620</b> may cache the messages that it receives from the client device <b>1610</b> and transmits to the client device <b>1610</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1620</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1610</b> and transmitting each message to the client device <b>1610</b> for generating the hash.

0271At operation 16.34, the key server <b>1630</b> transmits a message indicating whether the key exchange and authentication processes were verified as being successful. Assuming that the key exchange and authentication processes are verified as being successful, thereafter at operation 16.35 future messages between the client device <b>1610</b> and the secure session server <b>1620</b> are encrypted over the secure session <b>1665</b>, which carry the application data of the connection.

0272In one embodiment, the messages transmitted between the secure session server <b>1620</b> and the key server <b>1630</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). The session keys transmitted to the secure session server <b>1620</b> may be encrypted in such a way that the secure session server <b>1620</b> may decrypt them.

0273In one embodiment, the operations of 16.24, 16.26, 16.28, 16.31, 16.33, and/or 16.34 are optional. For example, in some embodiments the secure session server <b>1620</b> generates the Server Hello message instead of receiving it from the key server <b>1630</b>. In such an embodiment, the secure session server <b>1620</b> may select a ServerHello.random value and transmit that value to the key server <b>1630</b> prior to the key server <b>1630</b> generating the session keys. As another example, in some embodiments the secure session server <b>1620</b> generates the Change Cipher Spec message to transmit to the client device <b>1610</b> instead of it being received from the key server <b>1630</b>.

0274As another example, in some embodiments the secure session server <b>1620</b> generates the Finished message to transmit to the client device <b>1610</b> instead of it being received from the key server <b>1630</b>. Generating the Finished message may include calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b> (e.g., the Client Hello message of operation 16.21, the Server Hello message of operation 16.25, and the Change Cipher Spec message of operation 16.27). For generating the hash, the secure session server <b>1620</b> may cache the messages that it receives from the client device <b>1610</b> and transmits to the client device <b>1610</b> such that it may generate the hash in the message. Alternatively the secure session server <b>1620</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1610</b> and transmitting each message to the client device <b>1610</b> for generating the hash in the Finished message. In order to generate the Finished message, the secure session server <b>1620</b> receives the master secret from the key server <b>1630</b>.

0275As another example, in some embodiments the secure session server <b>1620</b> may not transmit the Change Cipher Spec received from the client device <b>1610</b> in operation 16.30 to the key server <b>1630</b> and may not transmit the Finished message received from the client device <b>1610</b> in operation 16.33 to the key server <b>1630</b>. In an embodiment where the Finished message is not transmitted to the key server <b>1630</b>, the secure session server <b>1620</b> may perform the verification if it has access to the master secret from the key server <b>1630</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1620</b> calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1610</b> and received from the client device <b>1610</b> (e.g., the Client Hello message of operation 16.21, the Server Hello message of operation 16.25, the Change Cipher Spec message of operation 16.27, the Finished message of operation 16.29, and the Change Cipher Spec message of operation 16.30). That calculated value is compared with the value received in the Finished message of operation 16.32 (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1620</b> may cache the messages that it receives from the client device <b>1610</b> and sends to the client device <b>1610</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1620</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1610</b> and transmitting each message to the client device <b>1610</b>.

0276As described above, the messages transmitted between the secure session server <b>1620</b> and the key server <b>1630</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). As part of establishing the secure session, the key server <b>1630</b> may request a client certificate from the secure session server <b>1620</b> and the secure session server <b>1620</b> may transmit a client Certificate message that includes its certificate to the key server <b>1630</b>. The data in the client Certificate message is used by the key server <b>1630</b> to authenticate the identity of the secure session server <b>1620</b>.

0277In some embodiments, the key server <b>1630</b> may use IP address blocking to accept connections (such as from the secure session server <b>1620</b>) from only certain IP addresses. For example, the key server <b>1630</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>1630</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>1630</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>1620</b> and the key server <b>1630</b>.

0278Although a secure session has been described between the secure session server <b>1620</b> and the key server <b>1630</b> that is initiated by the secure session server <b>1620</b>, in other embodiments the secure session can be initiated by the key server <b>1630</b>.

0279In some embodiments, the messages transmitted by the secure session server <b>1620</b> to the key server <b>1630</b> are signed with a private key that is known only to the secure session server <b>1620</b>. In such embodiments, the key server <b>1630</b> verifies the validity of the signature of a message prior to acting on that message. The key server <b>1630</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0280A combination of the security techniques described may be used to provide security for connection between the secure session server <b>1620</b> and the key server <b>1630</b>. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>1620</b> and the key server <b>1630</b>.

0281In one embodiment, the key server <b>1630</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>1630</b> may store or have access to the private key for example.com and example2.com, which may be owned or controlled by different entities. In such an embodiment, the secure session server <b>1620</b> indicates the domain or zone in which the client device <b>1610</b> is requesting a connection. For example, if the client device <b>1610</b> is requesting a secure session with example.com, then the secure session server <b>1620</b> indicates to the key server <b>1630</b> that example.com is the requested domain. The client device <b>1610</b> may specify the destination domain using the Server Name Indication (SNI) extension in the Client Hello message. SNI is described in RFC 3546, June 2003. If the client device <b>1610</b> includes the SNI extension in the Client Hello message of operation 16.1, then the Client Hello message of operation 16.2 also includes the SNI extension that indicates the destination domain. If the destination is not specified by the client device <b>1610</b> (e.g., the client device <b>1610</b> does not support SNI), then the secure session server <b>1620</b> matches the destination IP address of the client-hello message sent by the client device <b>1610</b> with the corresponding hostname (e.g., the secure session server <b>1620</b> may include a mapping of IP addresses and hostnames). The secure session server <b>1620</b> may transmit the indication of the domain or zone name to the key server <b>1630</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>1630</b> accesses the corresponding private key. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>1620</b> may generate a fingerprint over the certificate included in the Certificate message of operation 16.6 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>1630</b>. The key server <b>1630</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>1620</b>, the key server <b>1630</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 16.6) to lookup the corresponding private key. As another example, the secure session server <b>1620</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 16.6 and transmit that hash value to the key server <b>1630</b>. The key server <b>1630</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>1620</b>, the key server <b>1630</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0282In embodiments where a ticket is used for resuming a session as previously described, the key server <b>1630</b> may also renew the ticket by transmitting a message (e.g., a NewSessionTicket message) to the secure session server <b>1620</b> which may transmit the message to the client device <b>1610</b> after the Server Hello message of operation 16.25.

0283Although <figref idref="DRAWINGS">FIG. 16B</figref> illustrates the key server <b>1630</b> generating the session keys after receiving a request to resume the session, in one embodiment the secure session server <b>1620</b> generates the session keys after receiving a request to resume the session. For example, in an embodiment where the key server <b>1630</b> generates a ticket that includes the session state (e.g., the master key and the cipher suite) that is encrypted with a key that is not known or shared with the client device <b>1610</b>, the key server <b>1630</b> may transmit the key to decrypt the ticket to the secure session server <b>1620</b>. Accordingly, upon receiving a request to resume a session from the client device <b>1610</b> that includes a session resumption ticket, the secure session server <b>1620</b> may decrypt the ticket with the key received from the key server <b>1630</b>, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0284As another example, the key server <b>1630</b> may transmit the master secret to the secure session server <b>1620</b> such that secure session server <b>1620</b> may use either stateful session resumption or stateless session resumption without requiring further interaction with the key server <b>1630</b>. For example in the case of stateful session resumption, the secure session server <b>1620</b> may receive the master secret from the key server <b>1630</b> and store it in association with other session state parameters in its session cache (e.g., the cipher suite). Upon receiving a request to resume a session from a client that includes a session identifier of the session to be resumed, the secure session server <b>1620</b> checks its session cache for a matching identifier and if found and the secure session server <b>1620</b> is willing to re-establish the connection (the secure session server <b>1620</b> may deny the request to resume a session for a variety of reasons including if a lifetime of the session identifier has been reached), the secure session server <b>1620</b> will use that stored session state to generate new session keys for the resumed session. In the case of stateless session resumption, the secure session server <b>1620</b> may receive the master secret from the key server <b>1630</b> and generate and encrypt the ticket that includes the session state information (encrypted with a ticket that may be only known to the secure session server <b>1620</b>). The secure session server <b>1620</b> will provide the ticket to the client device <b>1310</b> (e.g., before the Change Cipher Spec message of operation 16.16 and after the Finished message of the client device <b>1610</b> has been verified). Upon receiving a request to resume a session from the client device <b>1610</b> that includes a session resumption ticket, the secure session server <b>1620</b> may decrypt the ticket, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0285<figref idref="DRAWINGS">FIG. 17</figref> is a flow diagram that illustrates exemplary operations performed by the secure session server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to another embodiment. The private key is stored remotely from the secure session server (e.g., on a key server). For example, in the embodiment described with reference to <figref idref="DRAWINGS">FIG. 17</figref>, the secure session server proxies the messages of the handshake between the client device and the key server where the key server generates and transmits to the secure session server the set of session keys to be used during the secure session between the client device and the secure session server.

0286At operation <b>1710</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device and transmits the message to a key server. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name). The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.

0287The secure session server may be terminating secure session connections for multiple domains that are owned by different entities and the respective private keys for those domains may be stored on different key servers. If the secure session server is supporting multiple domains whose respective private keys are stored on different key servers, the secure session server determines which key server it will transmit the message received from the client device. For example, if the client device specifies the destination domain using the SNI extension in the Client Hello message, the secure session server uses the destination domain to determine which key server the Client Hello message should be transmitted to. If the client device does not specify the destination domain using the SNI extension, then the secure session server matches the destination IP address of the message received from the client device with the corresponding hostname to determine which key server to determine which key server the message should be transmitted to (e.g., the secure session server may include a mapping of IP addresses and hostnames). The secure session server may also transmit the destination hostname to the key server (e.g., if the SNI extension is not used by the client device).

0288Flow then moves to operation <b>1715</b> where the secure session server receives a digital certificate from the key server and transmits the digital certificate to the client device. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. Prior to receiving the digital certificate from the key server, the secure session server may receive a Server Hello message from the key server and transmit the Server Hello message to the client device. After receiving the digital certificate from the key server, the secure session server may receive a Server Hello Done message from the key server and transmit the Server Hello Done message to the client device. Flow then moves to operation <b>1720</b>.

0289At operation <b>1720</b>, the secure session server receives from the client device a premaster secret that has been encrypted using the public key in the digital certificate transmitted in operation <b>1715</b> and transmits the encrypted premaster secret to the key server. The encrypted premaster secret may be sent by the client device in a SSL or TLS Client Key Exchange message. Flow moves from operation <b>1720</b> to operation <b>1725</b>.

0290In response to receiving the encrypted premaster secret, the key server decrypts the encrypted premaster secret to obtain the premaster secret using the appropriate private key. Using the premaster secret along with other values (e.g., the ClientHello.random value and the ServerHello.random value), the key server generates the master secret. The client device will also generate the same master secret. The key server will also generate the session keys that will be used to encrypt and decrypt information during the secure session between the client device and the secure session server. By way of a specific example, the master secret is used along with other information to generate a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write IV and a server write IV may also be generated depending on the cipher used.

0291The secure session server may also receive from the client device and transmit to the key server a message that indicates that future messages transmitted by the client device will be encrypted (e.g., a Change Cipher Spec message). In addition, the secure session server may also receive from the client device and transmit to the key server a message that has been encrypted using the session keys (e.g., a Finished message).

0292At operation <b>1725</b>, the secure session server receives a set of session keys from the key server for encrypting and decrypting communication for the secure session between the client device and the secure session server. The secure session server may also receive from the key server and transmit to the client device a message that indicates that future messages transmitted by the secure session server will be encrypted (e.g., a Change Cipher Spec message). In addition, the secure session server may also receive from the key server and transmit to the client device a message that has been encrypted using the session keys (e.g., a Finished message). The secure session server may also receive the master secret from the key server, which may be used for resuming the secure session.

0293Flow then moves to operation <b>1730</b> where future messages sent between the client device and the secure session server over the secure session will be encrypted and decrypted using the set of session keys received from the key server. For example, the client write key is used by the client device to encrypt data and used by the secure session server to decrypt data received from the client device, the client write MAC key is used to authenticate data written by the client device, the server write key is used by the secure session server to encrypt data and used by the client device to decrypt data received from the secure session server, and the server write MAC key is used to authenticate data written by the secure session server.

0294<figref idref="DRAWINGS">FIG. 18</figref> is a flow diagram that illustrates exemplary operations performed by a key server for establishing a secure session connection between a client device and a secure session server that will terminate the secure session connection according to one embodiment. At operation <b>1810</b>, the key server receives a message from a secure session server that a client is requesting a secure session with the secure session server. For example, the message may be a Client Hello message that originated from a client device. The secure session server may also transmit an indication of the destination host name in which the client devices wishes to establish a secure session. For example, the Client Hello message may include the SNI extension that specifies the destination host name. As another example, the secure session server may otherwise indicate to the key server the destination host name if the Client Hello message does not include the SNI extension. The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports. Flow moves from operation <b>1810</b> to operation <b>1815</b>.

0295At operation <b>1815</b>, the key server transmits a message to the secure session server that is destined for the client in response to the message received at operation <b>1810</b>. For example, the message may be a Server Hello message. This message may include the version of the SSL or TLS protocol supported, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the message received in operation <b>1810</b>), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may also include a list of the extensions that the server supports. Flow then moves to operation <b>1820</b>.

0296At operation <b>1820</b>, the key server transmits a digital certificate to the secure session server that is destined for the client for the requested domain. The digital certificate may be included in a Certificate message. The digital certificate includes a public key for the requested domain. Flow then moves to operation <b>1825</b> where the key server transmits a message to the secure session server that is destined for the client that indicates that the hello-message phase of the handshake is complete and the client can proceed with its phase of the key exchange. For example, this message may be a Server Hello Done message.

0297Flow then moves to operation <b>1830</b> where the key server receives from the secure session server a message that includes an encrypted premaster secret set by the client (encrypted with the public key included in the certificate sent to the client). For example, the message may be a Client Key Exchange message.

0298Flow then moves to operation <b>1835</b> where the key server accesses the corresponding private key and decrypts the encrypted premaster secret. Flow then moves to operation <b>1840</b> where the key server generates a master secret using at least the decrypted premaster secret. By way of a specific example, the key server may generate the master secret using a pseudorandom function that takes as input at least the premaster secret, the ClientHello.random value, and the ServerHello.random value. The client device will use the same pseudorandom function over the same input to compute the same master secret. Flow then moves to operation <b>1845</b>.

0299At operation <b>1845</b>, the key server generates a set of session keys to be used in the secure session between the client device and the secure session server for encrypting and decrypting communication between the client device and the secure session server. Generating the session keys includes at least the use of the master secret and may include other security parameters that have been negotiated between the client and the key server. For example, the other security parameters may include the ClientHello.random value, the ServerHello.random value, and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length). The session keys may include a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used. Flow moves from operation <b>1845</b> to operation <b>1850</b>.

0300The key server may also receive from the secure session server a message that indicates that future messages transmitted by the client will be encrypted (e.g., a Change Cipher Spec message). The key server may also receive from the secure session server a message that originates from the client that is encrypted using the generated session keys and is used to verify that the key exchange and authentication processes were successful (e.g., a Finished message).

0301At operation <b>1850</b>, the key server transmits the set of session keys to the secure session server for use in the secure session between the client and the secure session server. The key server may also transmit to the secure session server that is destined for the client a message that indicates that future messages transmitted by the server will be encrypted (e.g., a Change Cipher Spec message) and/or a message that is encrypted using the generated session keys and is used by the client to verify that the key exchange and authentication processes were successful (e.g., a Finished message).

0302In addition to transmitting the session keys to the secure session server, the key server may also transmit the generated master secret to the secure session server. The generated master secret may be used when verifying the information included in the Finished message received from the client and when generating the Finished message to transmit to the client. In addition, the master secret may be used when resuming a session between the client device and the secure session server. For example, when a connection is established by resuming a session (e.g., the client transmits a ClientHello message with a session ID of a session that is capable of being resumed), new ClientHello.random and ServerHello.random values are generated and hashed with the master secret of the established session. If the master secret is not transmitted to the secure session server, the secure session server may request the key server to hash the new ClientHello.random and ServerHello.random values with the master secret and provide the result to the secure session server to support resumption of sessions.

0303If the master secret is not transmitted to the secure session server, the secure session server may transmit the value included in the Finished message received from the client device or the entire Finished message to the key server to verify that the key exchange was successful. The secure session server may generate the hash value and transmit it to the key server for use in the verification. In such an embodiment, the key server responds to the secure session server whether the key exchange was verified as successful. It should be understood that if the key exchange is not verified, the handshake will not continue.

0304In an alternative embodiment, instead of generating the Finished message (e.g., if the secure session server does not have access to the master secret), the secure session server transmits a request to the key server to generate the value to be included in the Finished message or to generate the entire Finished message that will be transmitted to the client device. The secure session server may also generate the hash value and transmit it to the key server for use in generating the value included in the Finished message. In such an embodiment, the key server responds to the secure session server with either the generated value to be included in the Finished message or the generated Finished message that includes the generated value.

0305As described above, the messages transmitted between the secure session server and the key server may be over a secure session. As part of establishing the secure session between the key server and the secure session server, the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0306<figref idref="DRAWINGS">FIG. 19A</figref> illustrates another embodiment for establishing a secure session between a client device and a secure session server where the secure session server does not have access to the private key used during the secure session handshake. Similar to the embodiment described in <figref idref="DRAWINGS">FIG. 7</figref>, the embodiment described in <figref idref="DRAWINGS">FIG. 19A</figref> describes the messages where the cipher suite chosen requires the use of a Server Key Exchange message (e.g., a Diffie-Hellman cipher suite is used such as DHE_RSA, DHE_DSS, ECDHE_RSA, or ECDHE_ECDSA). The client device <b>1910</b> (including the client network application <b>1915</b>) is similar to the client device <b>110</b> of <figref idref="DRAWINGS">FIG. 1</figref>. The secure session server <b>1920</b>, including the secure session module <b>1940</b> and the optional certificate(s) <b>1945</b>, are similar to the secure session server <b>120</b> (including the secure session module <b>140</b> and the certificate(s) <b>145</b>), but perform different operations as will be described below. The key server <b>1930</b> is similar to the key server <b>130</b> of <figref idref="DRAWINGS">FIG. 1</figref>, but performs different operations as will be described below.

0307At operation 19.1, the client device <b>1910</b> transmits a Client Hello message to the secure session server <b>1920</b>. This Client Hello message is similar to the Client Hello message described in operation 1.1 of <figref idref="DRAWINGS">FIG. 1</figref>. At operation 19.2, the secure session server <b>1920</b> transmits the Client Hello message to the key server <b>1930</b>.

0308In response to the Client Hello message, at operation 19.3 the key server <b>1930</b> transmits a Server Hello message to the secure session server <b>1920</b>. This Server Hello message is similar to the Server Hello message described in operation 1.2 of <figref idref="DRAWINGS">FIG. 1</figref>. At operation 19.4, the secure session server <b>1920</b> transmits the Server Hello message to the client device <b>1910</b>.

0309The key server <b>1930</b> also transmits a Certificate message to the secure session server <b>1920</b> at operation 19.5. This Certificate message is similar to the Certificate message described in operation 1.3 of <figref idref="DRAWINGS">FIG. 1</figref>. At operation 19.6, the secure session server <b>1920</b> transmits the Certificate message to the client device <b>1910</b>.

0310With reference to the embodiment illustrated in <figref idref="DRAWINGS">FIG. 19A</figref>, the cipher suite that is used has a key exchange in which the certificate message transmitted in operation 19.6 does not include enough data to allow the client device <b>1910</b> to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA). Because of this, a message is transmitted to the client device <b>1910</b> that conveys cryptographic information to allow the client device <b>1910</b> to generate the premaster secret. By way of a specific example where the key exchange mechanism is Diffie-Hellman such as DHE_DSS or DHE_RSA, the cryptographic information includes a set of cryptographic parameters that may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value of the server). As another specific example where the key exchange mechanism is ECDHE such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). The message that conveys the cryptographic information is referred to as a Server Key Exchange message. The cryptographic information of the Server Key Exchange message may need to be signed with the private key <b>1950</b> corresponding to the public key that the server transmitted in the Certificate message transmitted in operation 19.6 (e.g., if the key exchange mechanism is DHE_RSA, DHE_DSS, ECDHE_ECDSA, or ECDHE_RSA). For example, private key <b>1950</b> may be used to sign the set of cryptographic parameters, the ClientHello.random value, and the ServerHello.random value. As similarly described with respect to the embodiment discussed in <figref idref="DRAWINGS">FIG. 1</figref>, the secure session server <b>1920</b> does not have local access to this private key <b>1950</b>. As a result, the secure session server <b>1920</b> cannot sign the Server Key Exchange message with this private key <b>1950</b>.

0311At operation 19.7, the key server <b>1930</b> transmits the Server Key Exchange message to the secure session server <b>1920</b>. Since the key server <b>1930</b> has access to the private key <b>1950</b>, the key server <b>1930</b> generates the cryptographic parameters and signs them using the private key <b>1950</b>. In this embodiment, the private key <b>1950</b> is typically an RSA key if the key exchange mechanism is DHE_RSA or ECDHE_RSA, and is typically a Digital Signature Algorithm (DSA) key if the key exchange mechanism is DHE_DSS or an ECDSA key if the key exchange mechanism is ECDHE_ECDSA. Thus the Server Key Exchange message includes the signed cryptographic parameters. At operation 19.8, the secure session server <b>1920</b> transmits the Server Key Exchange message to the client device <b>1910</b>.

0312At operation 19.9, the key server <b>1930</b> transmits a Server Hello Done message to the secure session server <b>1920</b> that the secure session server <b>1920</b> transmits to the client device <b>1910</b> at operation 19.10. The Server Hello done message indicates that the hello-message phase of the handshake is complete.

0313At operation 19.11, the secure session server <b>1920</b> receives a Client Key Exchange message from the client device <b>1910</b>. The Client Key Exchange message transmitted in operation 19.11 does not include the encrypted premaster secret. Rather, this Client Key Exchange message includes information necessary to generate the same premaster secret as the client generated (e.g., it includes the client's Diffie-Hellman public value). At operation 19.12, the secure session server <b>1920</b> transmits the Client Key Exchange message to the key server <b>1930</b>.

0314The key server <b>1930</b> generates the premaster secret using the client's Diffie-Hellman public value (received in the Client Key Exchange message) and its Diffie-Hellman private value. The key server <b>1930</b> uses the premaster secret to calculate the master secret. The client device <b>1910</b> and the key server <b>1930</b> use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value.

0315The master secret is used by the client device <b>1910</b> and the key server <b>1930</b> to generate session keys that are used to encrypt and decrypt information during the secure session. By way of example, generating the session keys includes at least the use of the master secret and may include other security parameters that have been negotiated between the client and the key server including the ClientHello.random value, the ServerHello.random value, and an indication of the negotiated cipher suite (e.g., the information may specify the negotiated cipher suite that defines the cipher specification (the key server may look up the parameters of the cipher specification) or may specify parameters of the negotiated cipher suite for generating the session keys including information identifying the pseudorandom function (PRF) algorithm, encrypted key length, fixed IV length, and MAC key length. By way of a specific example, the master secret is used to generate a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0316At operation 19.13, the key server <b>1930</b> transmits the set of session keys to the secure session server <b>1920</b> which will be used by the secure session server <b>1920</b> to encrypt and decrypt messages during the secure session between the client device <b>1910</b> and the secure session server <b>1920</b>.

0317At operation 19.14, the secure session server <b>1920</b> receives a Change Cipher Spec message from the client device <b>1910</b> which indicates that future messages transmitted by the client device <b>1910</b> will be encrypted using the set of session keys. The secure session server <b>1920</b> transmits the Change Cipher Spec message to the key server <b>1930</b> at operation 19.15.

0318At operation 19.16, the secure session server <b>1920</b> receives a Finished message from the client device <b>1910</b> that is encrypted using the generated session keys and includes an encrypted hash of all of the messages in the handshake previously sent and received (previously sent and received to the client device <b>1910</b>). The Finished message is used to verify that the key exchange and authentication processes were successful. By way of example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the message in the handshake previously sent by and to the client device <b>1910</b>. The secure session server <b>1920</b> transmits the Finished message to the key server <b>1930</b> at operation 19.17. The key server <b>1930</b> will verify whether key exchange process was successful with techniques as previously described herein.

0319At operation 19.18, the secure session server <b>1920</b> receives a Change Cipher Spec message from the key server <b>1930</b> and transmits the Change Cipher Spec message to the client device <b>1910</b> at operation 19.19. The Change Cipher Spec indicates to the client device <b>1910</b> that future messages transmitted by the secure session server <b>1920</b> will be encrypted using the generated session keys.

0320At operation 19.20, the secure session server <b>1920</b> receives a Finished message from the key server <b>1930</b>. The Finished message may include an encrypted hash of all of the messages in the handshake previously sent and received between the client device <b>1910</b> and the secure session server <b>1920</b>. For example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent and received. The secure session server <b>1920</b> transmits the Finished message to the client device <b>1910</b> at operation 19.21.

0321Thereafter, at operation 19.22, future messages of the secure session between the client device <b>1910</b> and secure session server <b>1920</b> are encrypted over the secure session <b>1960</b>, which carry the application data of the connection.

0322In one embodiment, the messages transmitted between the secure session server <b>1910</b> and the key server <b>1920</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). The session keys transmitted to the secure session server <b>1910</b> in operation 19.13 may be encrypted in such a way that the secure session server may decrypt them.

0323In one embodiment, the operations of 19.15, 19.17, 19.18, and/or 19.20 optional. For example, the secure session server <b>1920</b> may not forward the Change Cipher Spec message to the key server <b>1930</b>. In one embodiment, instead of transmitting the Change Cipher Spec of operation 19.15 and the Finished message of operation 19.17 and instead of receiving the Change Cipher Spec of operation 19.18 and the Finished message of operation 19.20, the secure session server <b>1920</b> performs the key exchange verification of the value in the Finished message 19.16 and generates and transmits the Change Cipher Spec and Finish message to the client device <b>1910</b>.

0324In order to perform the key exchange verification using the information included in the Finished message of operation 19.16, the secure session server <b>1920</b> may receive the master secret from the key server <b>1930</b> in addition to the session keys. In one embodiment, verifying that the key exchange was successful includes using a pseudorandom function that includes as its input the master secret. For example, verifying that the key exchange was successful may include the secure session server <b>1920</b> calculating a value using the same pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1910</b> and received from the client device <b>1910</b> (e.g., the Client Hello message of operation 19.1, the Server Hello message of operation 19.4, the Certificate message of operation 19.6, the Server Key Exchange message of operation 19.8, the Server Hello Done message of operation 19.10, the Client Key Exchange message of operation 19.11, and the Change Cipher Spec message of operation 19.14). That calculated value is compared with the value received in the Finished message (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1920</b> may cache the messages that it receives from the client device <b>1910</b> and transmits to the client device <b>1910</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1920</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1910</b> and transmitting each message to the client device <b>1910</b> for generating the hash.

0325The secure session server <b>1920</b> may generate and transmit a Change Cipher Spec message to the client device <b>1910</b> and generate and transmit a Finished message to the to the client device <b>1910</b>. If generating the Finished message, the secure session server <b>1920</b> may cache the messages that it receives from the client device <b>1910</b> and transmits to the client device <b>1910</b> such that it may generate the encrypted hash in the message. Alternatively the secure session server <b>1920</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1910</b> and transmitting each message to the client device <b>1910</b> to generate the hash in the Finished message. Generating the Finished message may include calculating a value using a pseudorandom function that takes as input the master secret (which is received from the key server <b>1930</b>), a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1910</b> and received from the client device <b>1910</b> (e.g., the Client Hello message of operation 19.1, the Server Hello message of operation 19.4, the Certificate message of operation 19.6, the Server Key Exchange message of operation 19.8, the Server Hello Done message of operation 19.10, the Client Key Exchange message of operation 19.11, the Change Cipher Spec message of operation 19.14, the Finished message of operation 19.16, and the Change Cipher Spec message of operation 19.19).

0326In addition to receiving the session keys from the key server <b>1930</b>, the secure session server <b>1920</b> may also receive the generated master secret from the key server <b>1930</b>. The generated master secret may be used when verifying the information included in the Finished message received from the client device <b>1910</b> and when generating the Finished message to transmit to the client device <b>1910</b> as previously described herein. In addition, the master secret may be used when resuming a session between the client device <b>1910</b> and the secure session server <b>1920</b>. For example, when a connection is established by resuming a session (e.g., the client transmits a ClientHello message with a session ID of a session that is capable of being resumed), new ClientHello.random and ServerHello.random values are generated and hashed with the master secret of the established session. If the master secret is not transmitted to the secure session server <b>1920</b>, the secure session server <b>1920</b> may request the key server <b>1930</b> to hash the new ClientHello.random and ServerHello.random values with the master secret and provide the result to the secure session server <b>1920</b> to support resumption of sessions.

0327<figref idref="DRAWINGS">FIG. 19B</figref> illustrates exemplary operations for resuming a session according to the embodiment of <figref idref="DRAWINGS">FIG. 19A</figref>. Although not illustrated in <figref idref="DRAWINGS">FIG. 19B</figref>, prior to the operation 19.23, the secure session <b>1960</b> between the client device <b>1910</b> and the secure session server <b>1920</b> has been closed. At some point later, at operation 19.23, the secure session server <b>1920</b> receives a Client Hello message from the client device <b>1910</b>. This Client Hello message differs from the Client Hello message of operation 19.1 in that it effectively includes a request to resume the session. This Client Hello message may include a session ID that was set for a previously established secure session (e.g., the secure session <b>1960</b>). The Client Hello message of operation 19.23 includes a different random value than the Client Hello message of operation 19.1 (a different ClientHello.random value).

0328Embodiments may support the use of stateful session resumption and/or stateless session resumption. In the case of stateless session resumption, encrypted session state information is transmitted to the client device <b>1910</b> in the form of a ticket that the client may present back to the secure session server <b>1920</b> when requesting resumption of a session. The ticket includes session state (e.g., the cipher suite and the master secret) and is encrypted with a key that is not known by the client device <b>1910</b> (e.g., it may be encrypted with a key that is known only to the key server <b>1930</b> and/or to the secure session server <b>1920</b>). The client device <b>1910</b> can request a session be resumed using the ticket. In some embodiments the ticket is generated by the key server <b>1930</b> whereas in other embodiments the ticket is generated by the secure session server <b>1920</b>. An exemplary format of the ticket may be defined in accordance with RFC 5077. If the secure session server <b>1920</b> is generating the ticket, then the key server <b>1930</b> transmits the master secret to the secure session server <b>1920</b>. If the key server <b>1930</b> is generating the ticket, the secure session server <b>1920</b> may transmit a request to the key server <b>1930</b> to generate the ticket only when the client device <b>1910</b> indicates that it supports this extension, where this request may be transmitted to the key server <b>1930</b> after the Finished message transmitted by the client device <b>1910</b> has been successfully verified. The key server <b>1930</b> receives the request to generate the ticket, generates the ticket (encrypting it with a key that is known only to the key server <b>1930</b> for example), and transmits the ticket to the secure session server <b>1920</b>. The secure session server <b>1920</b> transmits the ticket to the client device <b>1910</b> before the Change Cipher Spec message of operation 19.19 and after the Finished message of the client device <b>1910</b> has been verified. In such embodiments, the Client Hello message of operation 19.23 includes the ticket (e.g., in a SessionTicket extension as defined in RFC 5077).

0329At operation 19.24, the secure session server <b>1920</b> transmits the Client Hello message to the key server <b>1930</b>. This Client Hello message is the same or substantially the same as the Client Hello message of operation 19.23 and includes the request to resume the session.

0330Assuming that the session can be resumed (e.g., a valid ticket was included in the Client Hello message of operation 19.23 or the session identifier included in the Client Hello message of operation 19.23 matches session information in the key server <b>1930</b> and the key server <b>1930</b> is willing to re-establish the connection under the specified session state), the key server <b>1930</b> generates the session keys for the resumed session (which will be different than the session keys used for the secure session <b>1960</b>) using the existing master secret generated for the secure session <b>1960</b>, the new ClientHello.random value (included in the Client Hello message of operation 19.23), a new ServerHello.random value chosen by the key server <b>1930</b>, and other security parameters that have been previously negotiated. The key server <b>1930</b> may retrieve the session state (e.g., the master secret and cipher suite) from the contents of the ticket (if included in the Client Hello message of operation 19.23) or through its session cache if resuming under stateful session resumption. The session keys may include a client write MAC key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write IV and a server write IV may also be generated depending on the cipher used. The key server <b>1930</b> transmits the session keys to the secure session server <b>1920</b> at operation 19.25.

0331At operation 19.26, the key server transmits a Server Hello message to the secure session server <b>1920</b> that is destined for the client device <b>1910</b>. This Server Hello message includes the new ServerHello.random value selected by the key server <b>1930</b>. At operation 19.27, the secure session server <b>1920</b> forwards the Server Hello message to the client device <b>1910</b>.

0332At operation 19.28, the key server <b>1930</b> transmits a Change Cipher Spec message to the secure session server <b>1920</b> which is transmitted by the secure session server <b>1920</b> to the client device <b>1910</b> at operation 19.29. The Change Cipher Spec message indicates that future messages transmitted by the secure session server <b>1920</b> will be encrypted using the newly negotiated keys.

0333At operation 19.30, the key server <b>1930</b> transmits a Finished message to the secure session server <b>1920</b> which is then transmitted by the secure session server <b>1920</b> to the client device <b>1910</b> at operation 19.31. The Finished message may include an encrypted hash of all the messages in the handshake to resume the session previously sent and received by the client device <b>1910</b> to verify that the key exchange was successful. In one embodiment the Finished message includes a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously received from the client device <b>1910</b> and sent to the client device <b>1910</b> for this handshake (e.g., the Client Hello message of operation 19.23, the Server Hello message of operation 19.27, and the Change Cipher Spec message of operation 19.29).

0334At operation 19.32, the secure session server <b>1920</b> receives a Change Cipher Spec message from the client device <b>1910</b>. The Change Cipher Spec message from the client device <b>1910</b> indicates that future messages transmitted by the client device <b>1910</b> will be encrypted using the newly negotiated keys. In one embodiment, at operation 19.33, the secure session server <b>1920</b> transmits the Change Cipher Spec message to the key server <b>1930</b>. In another embodiment, the secure session server <b>1920</b> does not transmit the Change Cipher Spec message to the key server <b>1930</b>.

0335At operation 19.34, the client device <b>1910</b> transmits a Finished message to the secure session server <b>1920</b>. The Finished message is encrypted using the generated session keys. By way of example, the Finished message includes an encrypted hash of all of the messages in this handshake previously sent by and received by the client device <b>1910</b>. The Finished message is used to verify that the key exchange and authentication processes were successful. For example, the message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent by the client device <b>1910</b> and received at the client device <b>1910</b>. In one embodiment, the secure session server <b>1920</b> transmits the Finished message to the key server <b>1930</b> at operation 19.35.

0336In another embodiment, the secure session server <b>1920</b> does not transmit the Finished message to the key server <b>1930</b>. If the secure session server <b>1920</b> does not transmit the Finished message to the key server <b>1930</b>, the secure session server <b>1920</b> will verify whether the key exchange was successful. In one embodiment, verifying that the key exchange was successful includes using a pseudorandom function that includes as its input the master secret. In such an embodiment, the secure session server <b>1920</b> may receive the master secret from the key server <b>1930</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1920</b> calculating a value using the same pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake for this session that were previously sent to the client device <b>1910</b> and received from the client device <b>1910</b> (e.g., the Client Hello message of operation 19.23, the Server Hello message of operation 19.27, the Change Cipher Spec message of operation 19.29, the Finished message of operation 19.31, and the Change Cipher Spec message of operation 19.32). That calculated value is compared with the value received in the Finished message (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1920</b> may cache the messages that it receives from the client device <b>1910</b> and transmits to the client device <b>1910</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1920</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1910</b> and transmitting each message to the client device <b>1910</b> for generating the hash.

0337At operation 19.36, the key server <b>1930</b> transmits a message indicating whether the key exchange and authentication processes were verified as being successful. Assuming that the key exchange and authentication processes are verified as being successful, thereafter at operation 19.37 future messages between the client device <b>1910</b> and the secure session server <b>1920</b> are encrypted over the secure session <b>1965</b>, which carry the application data of the connection.

0338In one embodiment, the messages transmitted between the secure session server <b>1920</b> and the key server <b>1930</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). The session keys transmitted to the secure session server <b>1920</b> may be encrypted in such a way that the secure session server <b>1920</b> may decrypt them.

0339In one embodiment, the operations of 19.26, 19.28, 19.30, 19.33, 19.35, and/or 19.36 are optional. For example, in some embodiments the secure session server <b>1920</b> generates the Server Hello message instead of receiving it from the key server <b>1930</b>. In such an embodiment, the secure session server <b>1920</b> may select a ServerHello.random value and transmit that value to the key server <b>1930</b> prior to the key server <b>1930</b> generating the session keys. As another example, in some embodiments the secure session server <b>1920</b> generates the Change Cipher Spec message to transmit to the client device <b>1910</b> instead of it being received from the key server <b>1930</b>.

0340As another example, in some embodiments the secure session server <b>1920</b> generates the Finished message to transmit to the client device <b>1910</b> instead of it being received from the key server <b>1930</b>. Generating the Finished message may include calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1910</b> and received from the client device <b>1910</b> (e.g., the Client Hello message of operation 19.23, the Server Hello message of operation 19.27, and the Change Cipher Spec message of operation 19.29). For generating the hash, the secure session server <b>1920</b> may cache the messages that it receives from the client device <b>1910</b> and transmits to the client device <b>1910</b> such that it may generate the hash in the message. Alternatively the secure session server <b>1920</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1910</b> and transmitting each message to the client device <b>1910</b> for generating the hash in the Finished message. In order to generate the Finished message, the secure session server <b>1920</b> receives the master secret from the key server <b>1930</b>.

0341As another example, in some embodiments the secure session server <b>1920</b> may not transmit the Change Cipher Spec received from the client device <b>1910</b> in operation 19.32 to the key server <b>1930</b> and may not transmit the Finished message received from the client device <b>1910</b> in operation 19.35 to the key server <b>1930</b>. In an embodiment where the Finished message is not transmitted to the key server <b>1930</b>, the secure session server <b>1920</b> may perform the verification if it has access to the master secret from the key server <b>1930</b>. For example, verifying that the key exchange was successful may include the secure session server <b>1920</b> calculating a value using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously sent to the client device <b>1910</b> and received from the client device <b>1910</b> (e.g., the Client Hello message of operation 19.23, the Server Hello message of operation 19.27, the Change Cipher Spec message of operation 19.29, the Finished message of operation 19.31, and the Change Cipher Spec message of operation 19.32). That calculated value is compared with the value received in the Finished message of operation 19.34 (the values should be the same if the key exchange was successful). It should be understood that if the verification fails, the handshake does not continue. In order to generate the hash of the messages in the handshake, the secure session server <b>1920</b> may cache the messages that it receives from the client device <b>1910</b> and sends to the client device <b>1910</b> such that it may generate the hash for the comparison. Alternatively the secure session server <b>1920</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1910</b> and transmitting each message to the client device <b>1910</b>.

0342As described above, the messages transmitted between the secure session server <b>1920</b> and the key server <b>1930</b> may be transmitted over a secure connection (e.g., encrypted using SSL or TLS). As part of establishing the secure session, the key server <b>1930</b> may request a client certificate from the secure session server <b>1920</b> and the secure session server <b>1920</b> may transmit a client Certificate message that includes its certificate to the key server <b>1930</b>. The data in the client Certificate message is used by the key server <b>1930</b> to authenticate the identity of the secure session server <b>1920</b>.

0343In some embodiments, the key server <b>1930</b> may use IP address blocking to accept connections (such as from the secure session server <b>1920</b>) from only certain IP addresses. For example, the key server <b>1930</b> may have a whitelist of IP address(es) and/or IP address range(s) that are allowed to connect to the key server <b>1930</b> or have a blacklist of IP address(es) and/or IP address range(s) that are not allowed to connect to the key server <b>1930</b>. IP address blocking may also be used at one or more intermediary network devices between the secure session server <b>1920</b> and the key server <b>1930</b>.

0344Although a secure session has been described between the secure session server <b>1920</b> and the key server <b>1930</b> that is initiated by the secure session server <b>1920</b>, in other embodiments the secure session can be initiated by the key server <b>1930</b>.

0345In some embodiments, the messages transmitted by the secure session server <b>1920</b> to the key server <b>1930</b> are signed with a private key that is known only to the secure session server <b>1920</b>. In such embodiments, the key server <b>1930</b> verifies the validity of the signature of a message prior to acting on that message. The key server <b>1930</b> verifies whether the signature is valid using the corresponding public key and will only continue with the operations if the signature is valid.

0346A combination of the security techniques described may be used to provide security for the connection between the secure session server <b>1920</b> and the key server <b>1930</b>. For example, a combination of requiring a client Certificate, IP address blocking, and signing the messages transmitted by the secure session server with a private key known only to the secure session server may be used to provide security for the connection between the secure session server <b>1920</b> and the key server <b>1930</b>.

0347In one embodiment, the key server <b>1930</b> stores or has access to private keys for multiple domains and/or zones, which may be owned or controlled by different entities. For example, the key server <b>1930</b> may store or have access to the private key for example.com and example2.com, which may be owned or controlled by different entities. In such an embodiment, the secure session server <b>1920</b> indicates the domain or zone in which the client device <b>1910</b> is requesting a connection. For example, if the client device <b>1910</b> is requesting a secure session with example.com, then the secure session server <b>1920</b> indicates to the key server <b>1930</b> that example.com is the requested domain. The client device <b>1910</b> may specify the destination domain using the SNI extension in the Client Hello message. If the destination is not specified by the client device <b>1910</b> (e.g., the client device <b>1910</b> does not support SNI), then the secure session server <b>1920</b> matches the destination IP address of the client-hello message sent by the client device <b>1910</b> with the corresponding hostname (e.g., the secure session server <b>1920</b> may include a mapping of IP addresses and hostnames). The secure session server <b>1920</b> may transmit the indication of the domain or zone name to the key server <b>1930</b> in a number of different ways including in a header, a custom binary structure, or a serialization format (e.g., protobuf, JavaScript Object Notation (JSON), etc.). After receiving the indication of the domain or zone name in which the client is attempting to connect, the key server <b>1330</b> accesses the corresponding private key. In another embodiment, a certificate fingerprint or a hash of the modulus (for RSA) may be used to identify the corresponding private key. For example, the secure session server <b>1920</b> may generate a fingerprint over the certificate included in the Certificate message of operation 19.6 (e.g., a hash may be generated over the certificate) and transmit that fingerprint value to the key server <b>1930</b>. The key server <b>1930</b> uses the same fingerprint algorithm to generate a fingerprint over its digital certificates and matches each to the corresponding private key. Upon receiving the fingerprint value from the secure session server <b>1920</b>, the key server <b>1930</b> matches that fingerprint value with one of the fingerprint values it generated over the public certificate (the same public certificate included in the Certificate message of operation 19.6) to lookup the corresponding private key. As another example, the secure session server <b>1920</b> may hash the modulus of the public key included in the certificate of the Certificate message of operation 19.6 and transmit that hash value to the key server <b>1930</b>. The key server <b>1930</b> uses the same hash algorithm to generate a hash value over the modulus over its stored public keys and matches each to the corresponding private key. Upon receiving the hash value from the secure session server <b>1920</b>, the key server <b>1930</b> matches that hash value with one of the hash values it generated to lookup the corresponding private key.

0348In embodiments where a ticket is used for resuming a session as previously described, the key server <b>1930</b> may also renew the ticket by transmitting a message (e.g., a NewSessionTicket message) to the secure session server <b>1920</b> which may transmit the message to the client device <b>1910</b> after the Server Hello message of operation 19.27.

0349Although <figref idref="DRAWINGS">FIG. 19</figref> illustrates the key server <b>1930</b> generating the session keys after receiving a request to resume the session, in one embodiment the secure session server <b>1920</b> generates the session keys after receiving a request to resume the session. For example, in an embodiment where the key server <b>1930</b> generates a ticket that includes the session state (e.g., the master key and the cipher suite) that is encrypted with a key that is not known or shared with the client device <b>1910</b>, the key server <b>1930</b> may transmit the key to decrypt the ticket to the secure session server <b>1920</b>. Accordingly, upon receiving a request to resume a session from the client device <b>1910</b> that includes a session resumption ticket, the secure session server <b>1920</b> may decrypt the ticket with the key received from the key server <b>1930</b>, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0350As another example, the key server <b>1930</b> may transmit the master secret to the secure session server <b>1920</b> such that secure session server <b>1920</b> may use either stateful session resumption or stateless session resumption without requiring further interaction with the key server <b>1930</b>. For example in the case of stateful session resumption, the secure session server <b>1920</b> may receive the master secret from the key server <b>1930</b> and store it in association with other session state parameters in its session cache (e.g., the cipher suite). Upon receiving a request to resume a session from a client that includes a session identifier of the session to be resumed, the secure session server <b>1920</b> checks its session cache for a matching identifier and if found and the secure session server <b>1920</b> is willing to re-establish the connection (the secure session server <b>1920</b> may deny the request to resume a session for a variety of reasons including if a lifetime of the session identifier has been reached), the secure session server <b>1920</b> will use that stored session state to generate new session keys for the resumed session. In the case of stateless session resumption, the secure session server <b>1920</b> may receive the master secret from the key server <b>1930</b> and generate and encrypt the ticket that includes the session state information (encrypted with a ticket that may be only known to the secure session server <b>1920</b>). The secure session server <b>1920</b> will provide the ticket to the client device <b>1910</b> (e.g., before the Change Cipher Spec message of operation 19.19 and after the Finished message of the client device <b>1910</b> has been verified). Upon receiving a request to resume a session from the client device <b>1910</b> that includes a session resumption ticket, the secure session server <b>1920</b> may decrypt the ticket, retrieve the session state from the contents of the ticket, and generate the session keys using the retrieved session state.

0351<figref idref="DRAWINGS">FIG. 20</figref> is a flow diagram that illustrates exemplary operations performed by a secure session server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to another embodiment. The private key is stored remotely from the secure session server (e.g., on a key server). For example, in the embodiment described with reference to <figref idref="DRAWINGS">FIG. 20</figref>, the secure session server proxies the messages of the handshake between the client device and the key server where the key server generates and transmits to the secure session server the set of session keys to be used during the secure session between the client device and the secure session server.

0352At operation <b>2010</b>, the secure session server receives a message from the client device that initiates a procedure to establish a secure session with the client device and transmits the message to a key server. For example, the secure session server may receive a Client Hello message from the client device (e.g., an SSL or TLS Client Hello message). Depending on the protocol and capabilities of the client device, the message may indicate the destination host name in which the client device wishes to establish a secure session (e.g., the Client Hello message may include the Server Name Indication (SNI) extension and specify the destination host name). The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports.

0353The secure session server may be terminating secure session connections for multiple domains that are owned by different entities and the respective private keys for those domains may be stored on different key servers. If the secure session server is supporting multiple domains whose respective private keys are stored on different key servers, the secure session server determines which key server it will transmit the message received from the client device. For example, if the client device specifies the destination domain using the SNI extension in the Client Hello message, the secure session server uses the destination domain to determine which key server the Client Hello message should be transmitted to. If the client device does not specify the destination domain using the SNI extension, then the secure session server matches the destination IP address of the message received from the client device with the corresponding hostname to determine which key server to determine which key server the message should be transmitted to (e.g., the secure session server may include a mapping of IP addresses and hostnames). The secure session server may also transmit the destination hostname to the key server (e.g., if the SNI extension is not used by the client device).

0354Flow then moves to operation <b>2015</b> where the secure session server receives a message from the key server in response to the message transmitted in operation <b>2010</b> and transmits the message to the client device. For example, this message may be a Server Hello message. This message may include the version of the SSL or TLS protocol supported, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the message received in operation <b>2010</b>), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may also include a list of the extensions that the server supports. Flow then moves to operation <b>2020</b>.

0355At operation <b>2020</b>, the secure session server receives a digital certificate from the key server and transmits the digital certificate to the client device. The digital certificate includes a public key for the requested domain. It should be understood that the private key that corresponds to the public key is not stored on the secure session server (e.g., it is stored remotely on a key server). The digital certificate may be transmitted in an SSL or TLS Certificate message. In the embodiment of <figref idref="DRAWINGS">FIG. 20</figref>, the key server has selected a cipher suite that has a key exchange in which the certificate message transmitted by the secure session server does not include enough data to allow the client device to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE, ECDSA, or ECDHE_RSA).

0356Flow moves from operation <b>2020</b> to operation <b>2025</b> where the secure session server receives a message from the key server that includes a signed set of cryptographic parameters used for generating a premaster secret and the secure session server transmits the message to the client device. In one embodiment this message is a Server Key Exchange message. By way of example if the key exchange mechanism is DHE_DSS or DHE_RSA, the cryptographic parameters may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the key server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value selected by the key server). As another specific example where the key exchange mechanism is Ephemeral Elliptic Curve Diffie-Hellman (ECDHE) such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). The cryptographic parameters are signed using a private key on the key server. The message may also include one or more random values (e.g., the ClientHello.random and the ServerHello.random values) that may also be part of the signed data. Flow then moves to operation <b>2030</b>.

0357At operation <b>2030</b>, the secure session server receives from the key server a message that indicates that the hello-message phase of the handshake is complete and the secure session server transmits this message to the client device. For example this message may be a Server Hello Done message. Flow then moves to operation <b>2035</b>.

0358At operation <b>2035</b>, the secure session server receives from the client device a message with information necessary to generate a premaster secret (e.g., it includes the client's Diffie-Hellman public value) and transmits the message to the key server. For example this information may be included in a Client Key Exchange message. Using this information, the key server generates a premaster secret. For example, the key server generates the premaster secret using the client's Diffie-Hellman public value and its Diffie-Hellman private value. Using the premaster secret, the key server calculates the master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. After calculating the master secret, the key server generates session keys that will be used to encrypt and decrypt information during the secure session between the client device and the secure session server. By way of a specific example, the master secret is used when generating a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used.

0359Flow then moves to operation <b>2040</b> where the secure session server receives from the key server the set of session keys that will be used to encrypt and decrypt information during the secure session between the client device and the secure session server. The set of session keys may be encrypted prior to transmission to the secure session server.

0360Although not illustrated in <figref idref="DRAWINGS">FIG. 20</figref>, in some embodiments the secure session server may also receive from the client device and transmit to the key server a message that indicates that future messages transmitted by the client device will be encrypted (e.g., a Change Cipher Spec message). In addition, the secure session server may also receive from the client device and transmit to the key server a message that has been encrypted using the session keys (e.g., a Finished message).

0361Although not illustrated in <figref idref="DRAWINGS">FIG. 20</figref>, in some embodiments the secure session server may also receive from the key server and transmit to the client device a message that indicates that future messages transmitted by the secure session server will be encrypted (e.g., a Change Cipher Spec message). In addition, the secure session server may also receive from the key server and transmit to the client device a message that has been encrypted using the session keys (e.g., a Finished message).

0362The secure session server may also receive the master secret from the key server, which may be used for resuming the secure session among other actions.

0363Flow then moves to operation <b>2045</b> where future messages sent between the client device and the secure session server over the secure session will be encrypted and decrypted using the set of session keys received from the key server. For example, the client write key is used by the client device to encrypt data and used by the secure session server to decrypt data received from the client device, the client write MAC key is used to authenticate data written by the client device, the server write key is used by the secure session server to encrypt data and used by the client device to decrypt data received from the secure session server, and the server write MAC key is used to authenticate data written by the secure session server.

0364The messages transmitted between the secure session server and the key server described in <figref idref="DRAWINGS">FIG. 20</figref> can be transmitted over a secure connection and/or can otherwise be encrypted.

0365Although not illustrated in <figref idref="DRAWINGS">FIG. 20</figref>, in some embodiments the secure session server may also receive from the client device a message that indicates that future messages transmitted by the client device will be encrypted (e.g., a Change Cipher Spec message) and a first message that has been encrypted using the session keys (e.g., a Finished message). This first encrypted message may be used by the secure session server to verify that the key exchange and authentication processes were successful. This message may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a client finished label), and a hash of all of the messages in the handshake previously received from and sent to the client device. Instead of transmitting these messages to the key server, in one embodiment the secure session server performs the key exchange verification using the value in the first encrypted message using the negotiated session keys (the Finished message). For example, verifying that the key exchange was successful may include the secure session server calculating a value using the same pseudorandom function that takes as input the master secret, the finished label (e.g., the client finished label), and the hash of all of the messages in the handshake previously received from and sent to the client device; and comparing that value with the value received in the Finished message (the values should be the same if the key exchange was successful). In such an embodiment, the key server transmits the master secret to the secure session server which uses the master secret in the verification. In order to generate the hash of the messages in the handshake for use in the verification, the secure session server may cache the messages that it receives from the client device and sends to the client device such that it may generate the hash for the comparison. Alternatively the secure session server <b>1320</b> may use incremental hashing and update the hash value upon receiving each message from the client device <b>1310</b> and transmitting each message to the client device <b>1310</b>.

0366The secure session server may also generate and transmit to the client a message that indicates that future messages transmitted by the secure session server will be encrypted (e.g., a Change Cipher Spec message) and generate and transmit to the client a first message that has been encrypted using the session keys (e.g., a Finished message). This first message (the Finished message) may be used by the client device to verify that the key exchange and authentication processes were successful and may include a value calculated using a pseudorandom function that takes as input the master secret, a finished label (e.g., a server finished label), and a hash of all of the messages in the handshake previously received from the client device and sent to the client device. If generating the Finished message, the secure session server may cache the messages that it receives from the client device and transmits to the client device such that it may generate the encrypted hash in the message. Alternatively the secure session server may use incremental hashing and update the hash value upon receiving each message from the client device and transmitting each message to the client device for generating the hash in the Finished message.

0367<figref idref="DRAWINGS">FIG. 21</figref> is a flow diagram that illustrates exemplary operations performed on a key server for establishing a secure session implemented with public-key cryptography between a client device and a secure session server where the secure session server does not have access to a private key for the requested domain according to another embodiment. At operation <b>2110</b>, the key server receives a message from a secure session server that a client is requesting a secure session with the secure session server. For example, the message may be a Client Hello message that originated from a client device. The secure session server may also transmit an indication of the destination host name in which the client devices wishes to establish a secure session. For example, the Client Hello message may include the SNI extension that specifies the destination host name. As another example, the secure session server may otherwise indicate to the key server the destination host name if the Client Hello message does not include the SNI extension. The message may also include random data used for cryptographic purposes (sometimes referred to as ClientHello.random), and may indicate whether and what type of extensions (defined by the protocol) the client supports. Flow moves from operation <b>2110</b> to operation <b>2115</b>.

0368At operation <b>2115</b>, the key server transmits a message to the secure session server that is destined for the client in response to the message received at operation <b>2110</b>. For example, the message may be a Server Hello message. This message may include the version of the SSL or TLS protocol supported, a session identifier that will be used to identify the session, the selected cipher suite (selected from the list of cipher suites included in the message received in operation <b>2110</b>), random data used for cryptographic purposes that is different than the random data included in the ClientHello message (sometimes referred to as ServerHello.random), and may also include a list of the extensions that the server supports. Flow then moves to operation <b>2120</b>.

0369At operation <b>2120</b>, the key server transmits a digital certificate to the secure session server that is destined for the client for the requested domain. The digital certificate may be included in a Certificate message. The digital certificate includes a public key for the requested domain. Flow moves from operation <b>2120</b> to operation <b>2125</b>.

0370In the example of <figref idref="DRAWINGS">FIG. 21</figref>, the key server has selected a cipher suite that has a key exchange in which the certificate message transmitted by the key server does not include enough data to allow the client device to generate a premaster secret. For example, the selected cipher suite may use Diffie-Hellman as the key exchange mechanism (e.g., DHE_RSA, DHE_DSS, ECDHE, ECDSA, or ECDHE_RSA).

0371At operation <b>2125</b>, the key server transmits a message to the secure session server that is destined for the client, the message having signed cryptographic parameters for the client to generate a premaster secret. In one embodiment this message is a Server Key Exchange message. By way of example if the key exchange mechanism is DHE_DSS or DHE_RSA, the cryptographic parameters may include the following: the prime modulus used for the Diffie-Hellman operation (p), the generator used for the Diffie-Hellman operation (g), and a Diffie-Hellman public value of the key server (g{circumflex over ( )}X mod p, where X is the Diffie-Hellman private value selected by the key server). As another specific example where the key exchange mechanism is ECDHE such as ECDHE_ECDSA or ECDHE_RSA, the cryptographic parameters include the Ephemeral ECDH public key and a specification of the corresponding curve (the corresponding elliptic curve domain parameters) (e.g., as defined in RFC 4492). The cryptographic parameters are signed using a private key on the key server. The message may also include one or more random values (e.g., the ClientHello.random and the ServerHello.random values) that may also be part of the signed data. Flow then moves to operation <b>2130</b>.

0372At operation <b>2130</b> the key server transmits a message to the secure session server that is destined for the client that indicates that the hello-message phase of the handshake is complete and the client can proceed with its phase of the key exchange. For example, this message may be a Server Hello Done message.

0373Flow then moves to operation <b>2135</b> where the key server receives a message from the secure session server with information for the key server to generate the same premaster. For example, the message may include the client's Diffie-Hellman public value. In one embodiment, this message is a Client Key Exchange message. Flow moves from operation <b>2135</b> to operation <b>2140</b>.

0374At operation <b>2140</b>, the key server generates premaster secret, the master secret, and the session keys that will be used for encrypting and decrypting communication for the secure session between the client and the secure session server. The key server generates the premaster secret using the client's Diffie-Hellman public value (received in the message of operation <b>2135</b>) and its Diffie-Hellman private value. The key server uses the premaster secret to calculate the master secret. The client requesting the secure session and the key server use the same algorithm and data to calculate the same master secret. By way of example, the master secret is calculated using a pseudorandom function that takes as input the premaster secret, the ClientHello.random value, and the ServerHello.random value. The master secret is used by the key server when generating the session keys that are used to encrypt and decrypt information during the secure session. By way of a specific example, the session keys may include a client write Message Authentication Code (MAC) key, a server write MAC key, a client write encryption key, and a server write encryption key. A client write Initialization Vector (IV) and a server write IV may also be generated depending on the cipher used. Flow moves from operation <b>2140</b> to operation <b>2145</b>.

0375At operation <b>2145</b>, the key server transmits the set of session keys to the secure session server for use in the secure session between the client device and the secure session server.

0376Although not illustrated in <figref idref="DRAWINGS">FIG. 21</figref>, in some embodiments the key server may receive from the secure session a message that indicates that future messages transmitted by the client device will be encrypted (e.g., a Change Cipher Spec message). The key server may also receive from the secure session server a first message that has been encrypted using the session keys (e.g., a Finished message). In such an embodiment where the key server receives a Finished message, the key server may verify that the key exchange and authentication processes were successful. The key server may also transmit to the secure session server a message that is destined for the client that indicates that future messages transmitted will be encrypted (e.g., a Change Cipher Spec message). The key server may also transmit to the secure session server a first message that is destined for the client and that has been encrypted using the session keys (e.g., a Finished message).

0377Although not illustrated in <figref idref="DRAWINGS">FIG. 21</figref>, in some embodiments the key server transmits the master secret it generated to the secure session server. The secure session server may use the master secret when responding to a request to resume the secure session using techniques as previously described herein. The secure session server may use the master secret when verifying that the key exchange was successful (e.g., verifying the value included in a Finished message received from the client device) or when generating the Finished message to transmit to the client.

0378The messages transmitted between the secure session server and the key server described in <figref idref="DRAWINGS">FIG. 21</figref> can be transmitted over a secure connection between the secure session server and the key server and/or can otherwise be encrypted. If a secure connection is used, as part of establishing that secure connection the key server may request a client certificate from the secure session server in order to authenticate the identity of the secure session server. In some embodiments, the key server may use IP address based blocking to verify that the key server is communicating with a legitimate secure session server (e.g., by verifying that the secure session server is communicating with an IP address having a value that is expected by the key server). In some embodiments, the connection between the key server and the secure session server is a VPN connection. In some embodiments, the messages transmitted by the secure session server to the key server are signed with a private key that is known only to the secure session server. In such embodiments, the key server verifies the validity of the signature of a message prior to acting on that message. In some embodiments, any combination of these security techniques may be used.

0379Unlike traditional secure session implementations where the secure session server has local access to the private key during the handshake, in embodiments of the invention the private key is not locally accessible to the secure session server. This provides increased security during the secure session handshake. For example, although the secure session server may deliver web content on behalf of a website, the secure session server may not be at the physical premises of the website owner and/or be controlled by the website owner. This may cause the website owner to not trust the security of the secure session server and/or the operators of the secure session server. However, because the private key is stored remotely (not on the secure session server) and is instead stored on a key server in embodiments of the invention, the website owner does not lose control of the private key while still allowing for a secure session server that it does not control to provide secure session capability.

0380While embodiments described herein can be used for securing web traffic, the embodiments described herein can also be used to secure any network traffic that relies on key-based cryptography for security.

0381In one embodiment, the secure session server and the key server are owned by different entities. For example, the secure session server may be a proxy server in a cloud-based proxy service that provides one or more services for one or more domain owners. By way of example, the cloud-based proxy service may provide services including protecting against Internet-based threats (e.g., proactively stopping botnets, cleaning viruses, trojans, and worms, etc.), providing performance services for customers (e.g., acting as a node in a content delivery network (CDN) and dynamically caching customer's files closer to visitors, page acceleration, content optimization services, etc.), image loading optimization (e.g., deferred image loading and/or auto-resizing), and/or other services. The key server may be owned or operated by a domain owner that is a customer of the cloud-based proxy service. By way of a specific example, the domain owner of example.com may be a customer of the cloud-based proxy service. The key server may be operated or under control of the domain owner, while the secure session server receives and transmits network traffic over a secure session between client devices and the secure session server for example.com, where the secure session was established using embodiments described herein where the private key is stored remotely from the secure session server. As a specific example, the key server may be an origin server of the website owner.

0382By way of a specific example, after establishing the secure session between a client device and the secure session server, the secure session server may receive an encrypted request for a resource (the resource may be hosted on the secure session server, the key server, or on a different server). The secure session server decrypts the encrypted request to determine the resource the client device is requesting. The secure session server then retrieves the requested resource. The resource may be retrieved locally by the secure session server (e.g., if the resource is locally available) or may be requested from an origin server that hosts the resource. In one embodiment, the secure session server may be a node in a CDN. In one embodiment, the secure session server and the key server are operated with different levels of security. For example, the key server may be operating in a high-security zone and the secure session zone may be operating in a lower-security zone.

0383In one embodiment, embodiments described herein may be used in a CDN where there may be one or more trusted nodes that store the private keys and perform the operations of the key server described herein and one or more untrusted nodes that perform the operations of the secure session server described herein. The untrusted and trusted nodes may be separated across a Wide Area Network. In some embodiments the untrusted nodes request the trusted nodes to sign the secure sessions and the secure sessions stay active for a configurable amount of time on the untrusted node without having to query the trusted nodes.

0384Embodiments described herein have described the secure session server and key server communicating over a connection (which may be a secure connection). In some embodiments this connection is a persistent connection (also referred to as a keep-alive connection) while in other embodiments this connection is established on demand each time a secure session is established.

0385In some embodiments, there may be multiple key servers that have the same private key(s) for which a secure session server may access. In such an embodiment, the traffic between the secure session server(s) and the key servers may be load balanced to distribute the load among the key servers. A secure session server may take a round-robin approach when selecting a particular one of the key servers. Alternatively, when selecting a particular one of the key servers, a secure session server may select the key server that has the fastest response, the shortest distance, the least load, or a combination thereof.

0386Embodiments have described a key server remote from the server that is terminating the secure session (the secure session server) storing private key(s) and using those private key(s) when establishing and/or resuming a secure session between a client device and the secure session server. In some embodiments, the key server may offload the private key operation (whether the private key operation is decrypting an encrypted premaster secret or signing cryptographic parameters as previously described herein) to a trusted platform module (TPM) or a hardware security module (HSM). The TPM or HSM could be part of the same physical device of the key server or may be connected to the key server through a network.

0387Splitting the Private Key

0388Embodiments have been described herein where the private key is stored on a server that is remote from the termination point of the secure connection. In some embodiments these private keys are stored in hardware security module(s) or trusted platform module(s). In other embodiments a private key is split into multiple parts that are stored in different entities (each of which may or may not also be stored in a hardware security module or trusted platform module). By way of a specific example, a private key may be split into at least two parts where at least one part is stored at the secure session server and at least one part is stored at a remote key server. By way of another example, a private key may be split into at least two parts where at least one part is stored at a first key server and another part is stored at a second key server.

0389In an embodiment where the private key is split into multiple parts where at least a first part is stored at a secure session server and a second part is stored at a key server, when a private key operation is needed in the secure session handshake, the secure session server transmits the part of the key that it is storing to the key server and the key server combines the parts to reconstruct the private key and uses the private key accordingly. The private key is split such that it is infeasible to derive the private key from a single part. By way of example, the private key may be split using Shamir's Secret Sharing or through other suitable ways of splitting the key. The whole private key may be removed from the key server after splitting the key into multiple parts. Prior to removing the key, the key server may generate an identifier of the private key and associate it with the private key part. For example, the identifier may be hash value generated as a result of a hash function over the private key. Other identifiers could also be used. Splitting the private key and not storing the whole private key in a single entity helps protect against a situation where either the secure session server or the key server is compromised since only a part of the private key cannot be used.

0390For example, with respect to <figref idref="DRAWINGS">FIG. 1</figref>, instead of the key server <b>130</b> storing the entire private key <b>150</b>, the private key <b>150</b> may be split into multiple parts where a first part is stored at the secure session server <b>120</b> and a second part is stored at the key server <b>130</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 1</figref> with the dashed box of the private key part <b>150</b>A and the private key part <b>150</b>B. The private key part <b>150</b>B can be transmitted by the key server <b>130</b> to the secure session server <b>120</b> or otherwise installed at the secure session server <b>120</b>. In addition, the private key part <b>150</b>B may be associated with an identifier (e.g., a hash of the private key <b>150</b>) that can be transmitted by the key server <b>130</b> or otherwise installed at the secure session server <b>120</b>. At operation 1.6, or in another message, the secure session server <b>120</b> transmits the private key part <b>150</b>B to the key server <b>130</b>. The key server <b>130</b> receives the private key part <b>150</b>B and reconstructs the private key <b>150</b> using the private key part <b>150</b>A and the private key part <b>150</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 1</figref>. In addition to transmitting the private key part <b>150</b>B, the secure session server <b>120</b> may also transmit an identifier that is associated with the private key part <b>150</b>B (e.g., a hash of the private key <b>150</b>). The key server <b>130</b> may use this identifier when accessing the private key part <b>150</b>A.

0391A split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIG. 4</figref>. For example, instead of the key server <b>430</b> storing the entire private key <b>450</b>, the private key <b>450</b> may be split into multiple parts where a first part is stored at the secure session server <b>420</b> and a second part is stored at the key server <b>430</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 4</figref> with the dashed box of the private key part <b>450</b>A and the private key part <b>450</b>B. The private key part <b>450</b>B can be transmitted by the key server <b>430</b> to the secure session server <b>420</b> or otherwise installed at the secure session server <b>420</b>. In addition, the private key part <b>450</b>B may be associated with an identifier (e.g., a hash of the private key <b>450</b>) that can be transmitted by the key server <b>430</b> or otherwise installed at the secure session server <b>420</b>. At operation 4.4, or in another message, the secure session server <b>420</b> transmits the private key part <b>450</b>B to the key server <b>430</b>. The key server <b>430</b> receives the private key part <b>450</b>B and reconstructs the private key <b>450</b> using the private key part <b>450</b>A and the private key part <b>450</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 4</figref>. In addition to transmitting the private key part <b>450</b>B, the secure session server <b>420</b> may also transmit an identifier that is associated with the private key part <b>450</b>B (e.g., a hash of the private key <b>450</b>). The key server <b>430</b> may use this identifier when accessing the private key part <b>450</b>A.

0392In a similar way as described with respect to <figref idref="DRAWINGS">FIG. 4</figref>, a split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIG. 7</figref>. For example, instead of the key server <b>730</b> storing the entire private key <b>750</b>, the private key <b>750</b> may be split into multiple parts where a first part is stored at the secure session server <b>720</b> and a second part is stored at the key server <b>730</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 7</figref> with the dashed box of the private key part <b>750</b>A and the private key part <b>750</b>B. The private key part <b>750</b>B can be transmitted by the key server <b>730</b> to the secure session server <b>720</b> or otherwise installed at the secure session server <b>720</b>. In addition, the private key part <b>750</b>B may be associated with an identifier (e.g., a hash of the private key <b>750</b>) that can be transmitted by the key server <b>730</b> or otherwise installed at the secure session server <b>720</b>. At operation 7.4, or in another message, the secure session server <b>720</b> transmits the private key part <b>750</b>B to the key server <b>730</b>. The key server <b>730</b> receives the private key part <b>750</b>B and reconstructs the private key <b>750</b> using the private key part <b>750</b>A and the private key part <b>750</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 7</figref>. In addition to transmitting the private key part <b>750</b>B, the secure session server <b>720</b> may also transmit an identifier that is associated with the private key part <b>750</b>B (e.g., a hash of the private key <b>750</b>). The key server <b>730</b> may use this identifier when accessing the private key part <b>750</b>A.

0393A split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIG. 10</figref>. For example, instead of the key server <b>1030</b> storing the entire private key <b>1050</b>, the private key <b>1050</b> may be split into multiple parts where a first part is stored at the secure session server <b>1020</b> and a second part is stored at the key server <b>1030</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 10</figref> with the dashed box of the private key part <b>1050</b>A and the private key part <b>1050</b>B. The private key part <b>1050</b>B can be transmitted by the key server <b>1030</b> to the secure session server <b>1020</b> or otherwise installed at the secure session server <b>1020</b>. In addition, the private key part <b>1050</b>B may be associated with an identifier (e.g., a hash of the private key <b>1050</b>) that can be transmitted by the key server <b>1030</b> or otherwise installed at the secure session server <b>1020</b>. At operation 10.6, or in another message, the secure session server <b>1020</b> transmits the private key part <b>1050</b>B to the key server <b>1030</b>. The key server <b>1030</b> receives the private key part <b>1050</b>B and reconstructs the private key <b>1050</b> using the private key part <b>1050</b>A and the private key part <b>1050</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 10</figref>. In addition to transmitting the private key part <b>1050</b>B, the secure session server <b>1020</b> may also transmit an identifier that is associated with the private key part <b>1050</b>B (e.g., a hash of the private key <b>1050</b>). The key server <b>1030</b> may use this identifier when accessing the private key part <b>1050</b>A.

0394A split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIG. 13</figref>. For example, instead of the key server <b>1330</b> storing the entire private key <b>1350</b>, the private key <b>1350</b> may be split into multiple parts where a first part is stored at the secure session server <b>1320</b> and a second part is stored at the key server <b>1330</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 13</figref> with the dashed box of the private key part <b>1350</b>A and the private key part <b>1350</b>B. The private key part <b>1350</b>B can be transmitted by the key server <b>1330</b> to the secure session server <b>1320</b> or otherwise installed at the secure session server <b>1320</b>. In addition, the private key part <b>1350</b>B may be associated with an identifier (e.g., a hash of the private key <b>1350</b>) that can be transmitted by the key server <b>1330</b> or otherwise installed at the secure session server <b>1320</b>. At operation 13.6, or in another message, the secure session server <b>1320</b> transmits the private key part <b>1350</b>B to the key server <b>1330</b>. The key server <b>1330</b> receives the private key part <b>1350</b>B and reconstructs the private key <b>1350</b> using the private key part <b>1350</b>A and the private key part <b>1350</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 13</figref>. In addition to transmitting the private key part <b>1350</b>B, the secure session server <b>1320</b> may also transmit an identifier that is associated with the private key part <b>1350</b>B (e.g., a hash of the private key <b>1350</b>). The key server <b>1330</b> may use this identifier when accessing the private key part <b>1350</b>A.

0395A split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIGS. 16A-B</figref>. For example, instead of the key server <b>1630</b> storing the entire private key <b>1650</b>, the private key <b>1650</b> may be split into multiple parts where a first part is stored at the secure session server <b>1620</b> and a second part is stored at the key server <b>1630</b>. This is illustrated in <figref idref="DRAWINGS">FIGS. 16A-B</figref> with the dashed box of the private key part <b>1650</b>A and the private key part <b>1650</b>B. The private key part <b>1650</b>B can be transmitted by the key server <b>1630</b> to the secure session server <b>1620</b> or otherwise installed at the secure session server <b>1620</b>. In addition, the private key part <b>1650</b>B may be associated with an identifier (e.g., a hash of the private key <b>1650</b>) that can be transmitted by the key server <b>1630</b> or otherwise installed at the secure session server <b>1620</b>. At operation 16.10, or in another message, the secure session server <b>1620</b> transmits the private key part <b>1650</b>B to the key server <b>1630</b>. The key server <b>1630</b> receives the private key part <b>1650</b>B and reconstructs the private key <b>1650</b> using the private key part <b>1650</b>A and the private key part <b>1650</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 16A</figref>. As an example with respect to <figref idref="DRAWINGS">FIG. 16B</figref>, at operation 16.22 or in another message prior to the key server <b>1630</b> generating the session keys, the secure session server <b>1620</b> transmits the private key part <b>1650</b>B to the key server <b>1630</b>. The key server <b>1630</b> receives the private key part <b>1650</b>B and reconstructs the private key <b>1650</b> using the private key part <b>1650</b>A and the private key part <b>1650</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 16B</figref>. In addition to transmitting the private key part <b>1650</b>B, the secure session server <b>1620</b> may also transmit an identifier that is associated with the private key part <b>1650</b>B (e.g., a hash of the private key <b>1650</b>). The key server <b>1630</b> may use this identifier when accessing the private key part <b>1650</b>A. The key server <b>1630</b> may discard the private key part <b>1650</b>B and the reconstructed private key shortly after using the reconstructed private key. For example, shortly after decrypting the encrypted premaster secret, the key server <b>1630</b> may remove the private key part <b>1650</b>B and the reconstructed private key from memory. Thus, the key server <b>1630</b> does not permanently store the private key part <b>1650</b>B or the reconstructed private key.

0396A split key approach may also be used with respect to the embodiment described in <figref idref="DRAWINGS">FIGS. 19A-B</figref>. For example, instead of the key server <b>1930</b> storing the entire private key <b>1950</b>, the private key <b>1950</b> may be split into multiple parts where a first part is stored at the secure session server <b>1920</b> and a second part is stored at the key server <b>1930</b>. This is illustrated in <figref idref="DRAWINGS">FIG. 19</figref> with the dashed box of the private key part <b>1950</b>A and the private key part <b>1950</b>B. The private key part <b>1950</b>B can be transmitted by the key server <b>1930</b> to the secure session server <b>1920</b> or otherwise installed at the secure session server <b>1920</b>. In addition, the private key part <b>1950</b>B may be associated with an identifier (e.g., a hash of the private key <b>1950</b>) that can be transmitted by the key server <b>1930</b> or otherwise installed at the secure session server <b>1920</b>. With respect to <figref idref="DRAWINGS">FIG. 19A</figref>, prior to operation 19.7, the secure session server <b>1920</b> transmits the private key part <b>1950</b>B to the key server <b>1930</b>. The key server <b>1930</b> receives the private key part <b>1950</b>B and reconstructs the private key <b>1950</b> using the private key part <b>1950</b>A and the private key part <b>1950</b>B and the operations proceed as described with respect to <figref idref="DRAWINGS">FIG. 19A</figref>.

0397Embodiments have been described herein that describe a key server that is remote from the server that is terminating the secure session (the secure session server) storing private key(s) and using those private key(s) when establishing and/or resuming a secure session between a client device and the secure session server. In some embodiments the secure session server may request the private key from the key server when a private key operation is needed and store the private key in memory (typically volatile memory) for a limited amount of time (e.g., only until the private key operation is complete). In other words, the secure session server does not permanently store the private key but instead requests it on demand from the key server and it only resides in memory of the secure session server for a limited amount of time.

0398As illustrated in <figref idref="DRAWINGS">FIG. 22</figref>, the computing device <b>2200</b>, which is a form of a data processing system, includes the bus(es) <b>2250</b> which is coupled with the processing system <b>2220</b>, power supply <b>2225</b>, memory <b>2230</b>, and the nonvolatile memory <b>2240</b> (e.g., a hard drive, flash memory, Phase-Change Memory (PCM), etc.). The bus(es) <b>2250</b> may be connected to each other through various bridges, controllers, and/or adapters as is well known in the art. The processing system <b>2220</b> may retrieve instruction(s) from the memory <b>2230</b> and/or the nonvolatile memory <b>2240</b>, and execute the instructions to perform operations described herein. The bus <b>2250</b> interconnects the above components together and also interconnects those components to the display controller &amp; display device <b>2270</b>, Input/Output devices <b>2280</b> (e.g., NIC (Network Interface Card), a cursor control (e.g., mouse, touchscreen, touchpad, etc.), a keyboard, etc.), and the wireless transceiver(s) <b>2290</b> (e.g., Bluetooth, WiFi, Infrared, etc.). One or more of the components of the computing device <b>2200</b> may be optional (e.g., the display controller and display device <b>2270</b>, I/O devices <b>2280</b>, the wireless transceiver(s) <b>2290</b>, etc.). In one embodiment, the client devices <b>110</b>, <b>410</b>, <b>710</b>, <b>1010</b>, <b>1310</b>, <b>1610</b>, and <b>1910</b>, the secure session servers <b>120</b>, <b>420</b>, <b>720</b>, <b>1020</b>, <b>1320</b>, <b>1620</b>, and <b>1920</b>, and/or the key servers <b>130</b>, <b>430</b>, <b>730</b>, <b>1030</b>, <b>1330</b>, <b>1630</b>, and/or <b>1930</b> can take the form of the computing device <b>2200</b>.

0399The techniques shown in the figures can be implemented using code and data stored and executed on one or more electronic devices (e.g., a client device, a proxy server, a key server). Such electronic devices store and communicate (internally and/or with other electronic devices over a network) code and data using computer-readable media, such as non-transitory computer-readable storage media (e.g., magnetic disks; optical disks; random access memory; read only memory; flash memory devices; phase-change memory) and transitory computer-readable communication media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals, digital signals). In addition, such electronic devices typically include a set of one or more processors coupled to one or more other components, such as one or more storage devices (non-transitory machine-readable storage media), user input/output devices (e.g., a keyboard, a touchscreen, and/or a display), and network connections. The coupling of the set of processors and other components is typically through one or more busses and bridges (also termed as bus controllers). Thus, the storage device of a given electronic device typically stores code and/or data for execution on the set of one or more processors of that electronic device. Of course, one or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.

0400While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).

0401While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.