SYSTEMS AND METHODS FOR IMPLEMENTING A MUTATING TRANSPORT

LAYER SECURITY PROTOCOL

BACKGROUND OF THE INVENTION [0001] Computer networks, such as the Internet, allow software applications on separate computers to communicate with one another. For example, a browser that is running on one computer may communicate over the Internet with server software that is running on a different computer for the purpose of downloading and viewing a web page. One problem with many existing computer networks and communication protocols is that they provide no security mechanisms to prevent an eavesdropper from monitoring or altering data that is transmitted between two or more computers. For example, the standard TCP/IP protocol that is used for most Internet communications cannot prevent a third party from monitoring the web pages that a user is viewing or information that is transmitted from a browser to a web server. In order to communicate securely over a public computer network such as the Internet, additional secure protocols must be utilized.

[0002] One such protocol is the Transport Layer Security ("TLS") Protocol. The TLS Protocol is a cryptographic protocol designed to provide security and data integrity to computer applications that communicate with one another over a computer network. This protocol allows computers to authenticate each other's identities, encrypt transmitted data so that it cannot be read by third parties, and authenticate transmitted data to ensure that it has not been altered by a third party. The TLS Protocol version 1.1 is described in RFC 4346 available at http://tools.ietf.org/html/rfc4346.

[0003] As described in RFC 4346, the TLS Protocol currently uses certain known cryptography methods such as RSA and Diffie-Hellman for key-exchange. While these methods are secure, they are vulnerable to brute force attacks of the type described in U.S. Patent Publication 2006/195402 (the '"402 Publication"), the contents of which are incorporated by reference as if fully set forth herein. In addition, the TLS Protocol may

utilize certificates to authenticate the server and optionally the client. This presents additional vulnerabilities to a party that is able to perpetrate a man in the middle attack by using a substitute certificate to pose as a server and engage in secure communications with a client. The '402 Publication presents Mutating Identifier and Black Content Protocols that greatly increase the costs associated with intercepting an encrypted message and decrypting it using a brute force attack.

SUMMARY OF THE INVENTION

[0004] In light of the security vulnerabilities of the TLS Protocol, it would be useful to have a version of the TLS Protocol with an improved security mechanism. One embodiment of the invention, provides a Mutating TLS Protocol that utilizes mutating IDs and, in some instances, a Black Content Protocol. The Mutating TLS Protocol includes a TLS Record Protocol, a TLS Handshake Protocol, an Application Protocol, and an Alert Protocol. In one embodiment, a system configured to use the Mutating TLS Protocol includes a client, a server, and a key server. In order for the Mutating TLS Protocol to use mutating ID and Black Content Protocols, the key server generates a first mutating ID that is distributed to the client and a second mutating ID that is distributed to the server. The client and the server have credentials which are known only by the key server. The client and server agree on the identity of a key server to use for the Mutating TLS session and exchange identifiers for the selected key server. This last step is accomplished using a modified TLS Handshake Protocol.

[0005] The modified TLS Handshake Protocol includes a ClientHello message and a ServerHello message in which the client and the server confirm that the current TLS session will use the Mutating Identifier, and, in some instances, Black Content Protocols, hi addition, the modified TLS Handshake Protocol includes a modified ServerKeyExchange message that contains 1) the identity of the key server for the Mutating TLS session, and 2)

the server's identifier for the selected key server. After sending the ServerKeyExchange message, the server sends a ServerHelloDone Message.

[0006] The client then sends a modified ClientKeyExchange message that 1) confirms the identity of the key server for the current Mutating TLS session and 2) provides the server with the client's unique identifier for the selected key server. The client then sends a ChangeCipherSpec message which tells the server that all further messages that it sends will use the Mutating Identifier and, in some instances, Black Content Protocols. The final message that the client sends as part of the modified TLS Handshake Protocol is a Finished message.

[0007] The server completes the modified TLS Handshake Protocol by sending its own ChangeCipherSpec message and Finished message. The client and the server use the Mutating Identifier and, in some instances, Black Content Protocols to obtain one or more keys that will be used to encrypt and decrypt their transmissions.

[0008] The Application Protocol is enabled such that an application running on the client, such as an Internet browser, can send data to the server. The TLS Record Protocol on both the client and the server use a selected encryption algorithm as well as the Mutating Identifier and, in some instances, Black Content Protocols to transmit and receive data. [0009] In one embodiment, the invention is a computer-based method of communicating between a first device and a second device. The method includes obtaining a first mutating identifier for the first device from a key server; obtaining a second mutating identifier for the second device from the key server; and establishing a cryptographic method to be used for communication between the first device and the second device comprising transmitting a first hello message from the first device to the second device and transmitting a second hello message from the second device to the first device. The method further includes transmitting a first key exchange message from the second device to the first device, the first key

exchange message including a first identifier and an address for the key server and a public identifier for the second device; transmitting a second key exchange message from the first device to the second device, the second key exchange message including the first identifier and the address for the key server and a public identifier for the first device; providing a session key to the first device and the second device from the key server; and transmitting an information payload between the first device and the second device by encrypting the payload using the cryptographic method and session key.

[0010] In another embodiment, the invention is a first device configured to use a mutating transport layer security protocol to communicate with a key server and a second device. The first device includes a processor having a first mutating identifier associated therewith. The processor is configured to transmit a first hello message to the second device, receive a second hello message from the second device, establishing a cryptographic method, and receive a first identifier and an address for a key server, and a public identifier for the second device, from the second device. The processor is also configured to transmit a key exchange message including the first identifier and address for the key server, and a public identifier for the first device, transmit a first change cipher message to the second device, and obtain a session key from the key server. The processor is also configured to transmit an information payload to the second device by fragmenting the information payload into blocks and encrypting the blocks using the cryptographic method and session key, and receive an information payload from the second device by receiving encrypted blocks of a fragmentized and encrypted information payload, decrypting the encrypted blocks using a session key, and using the unencrypted blocks to obtain the original message.

[0011] In yet another embodiment, the invention is a computer-based method for implementing a mutating transport layer security (MTLS) protocol using mutating identifiers. The method includes fragmentizing and encrypting an information payload on a first device

and decrypting and reassembling an information payload on a second device using a TLS Record Protocol. The method also includes establishing a cryptographic method and exchanging cryptographic material between the first device and a second device, using a mutating identifier protocol and optionally a black content protocol, using a TLS Handshake Protocol. The method also includes permitting a software application running on the first device to communicate with a software application running on the second device using at least one protocol suitable for electronic communications using an Application Protocol. The method also includes using an Alert Protocol to signal the first device and the second device when an error has occurred during the TLS Record Protocol, TLS Handshake Protocol, or Application Protocol.

[0012] In still another embodiment, the invention is a system for communicating information. The system includes a key server configured to generate a first mutating ID and a second mutating ID; a first device having a first-device credential; and a second device having a second-device credential. The first device is configured to send a message to a second device regarding a cryptographic method, send a message to the second device regarding the identity of the key server, and send a change cipher message. The second device is configured to send a message to the first device regarding at least one cryptographic method, send a message to the first device regarding the identity of the key server, send a hello done message to the first device; and send a change cipher message. [0013] hi another embodiment, the invention is a computer-based method of establishing secure and confidential communications between a first device and a second device. The method includes transmitting a first random value and a first cryptographic key from an authenticator device to the first device; transmitting a second random value and a second cryptographic key from the authenticator device to the second device; transmitting information suitable for identifying the authenticator device from the second device to the

first device; and transmitting information suitable to confirm the identity of the authenticator device from the first device to the second device.

[0014] In still another embodiment, the invention is a client terminal configured to use a mutating transport layer security protocol to communicate with a key server and a content server. The terminal includes a processor and a storage medium having a first mutating identifier associated therewith, the storage medium being operably coupled to the processor. The storage medium includes program instructions executable by the processor for transmitting a first hello message to the content server; receiving a second hello message from the content server, thereby establishing a cryptographic method; receiving a first identifier and an address for a key server, and a public identifier for the content server, from the content server; transmitting to the content server a key exchange message including the first identifier and address for the key server, and a public identifier for the client terminal; transmitting a first change cipher message to the content server; obtaining a session key from the key server; transmitting a first information payload to the content server by fragmenting the first information payload into blocks and encrypting the blocks using the cryptographic method and session key; and receiving a second information payload from the content server by receiving encrypted blocks of a fragmentized and encrypted second information payload, decrypting the encrypted blocks using the session key, and using the unencrypted blocks to obtain the second information payload.

[0015] In yet another embodiment, the invention is a content server configured to use a mutating transport layer security protocol to communicate with a client terminal and a key server. The content server includes a processor and a storage medium having a first mutating identifier associated therewith, the storage medium being operably coupled to the processor. The storage medium includes program instructions executable by the processor for receiving a first hello message from the client terminal; transmitting a second hello message to the

client terminal, thereby establishing a cryptographic method; transmitting a first identifier and an address for a key server, and a public identifier for the content server, to the client terminal; receiving from the client terminal a key exchange message including the first identifier and address for the key server, and a public identifier for the client terminal; receiving a first change cipher message from the client terminal; obtaining a session key from the key server; receiving a first information payload from the client terminal by receiving encrypted blocks of a fragmentized and encrypted first information payload, decrypting the encrypted blocks using the session key, and using the unencrypted blocks to obtain the first information payload; and transmitting a second information payload to the client terminal by fragmenting the second information payload into blocks and encrypting the blocks using the cryptographic method and session key.

BRIEF DESCRIPTION OF THE DRAWINGS

[0016] FIG. 1 is a schematic representation of a system that is configured to use the Mutating Identifier and Black Content Protocols.

[0017] FIG.2 is a schematic representation of a system that is configured to use the (prior art) TLS Protocol.

[0018] FIG. 3 is an illustrative representation of the (prior art) TLS Protocol. [0019] FIG. 4 is a schematic representation of the (prior art) TLS Handshake Protocol. [0020] FIG. 5 is an illustrative view of a (prior art) ServerKeyExchange message. [0021] FIG. 6 is an illustrative view of a (prior art) ClientKeyExchange message. [0022] FIG. 7 is a schematic representation of a system that is configured to use the Mutating TLS Protocol.

[0023] FIG. 8 is a schematic representation of a modified TLS Handshake Protocol. [0024] FIG. 9 is an illustrative view of a modified ServerKeyExchange message.

[0025] FIG. 10 is an illustrative view of a modified ClientKeyExchange message.

DETAILED DESCRIPTION

[0026] Before any embodiments of the invention are explained in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments and of being practiced or of being carried out in various ways. Also, it is to be understood that the phraseology and terminology used herein is for the purpose of description and should not be regarded as limiting. For example, some terms in the specification are capitalized to conform to naming convention often used in the applicable art, but no special meaning is intended simply due to the use of capital letters, unless the text clearly indicates otherwise.

[0027] It should also be understood that some embodiments are implemented using various computer devices, such as personal or home computers, servers, and other devices that have processors or that are capable of executing programs or sets of instructions, including special purpose devices such as set top boxes (e.g., digital cable or satellite decoders). In general, some embodiments may be implemented using existing hardware or hardware that could be readily created by those of ordinary skill in the art. Thus, the architecture of exemplary devices will not be explained in detail, except to note that the devices will generally have a processor, memory or other computer-readable storage medium including for example optical, electronic, magnetic, or other types of storage media, and input and output devices or interfaces. The input devices, which can include a keyboard, mouse, touch screen, or the like can be used by a user to input commands and data into a system. The output devices, which can include a CRT or LCD monitor or the like, can be used to inform the user of the result of the methods that are run on the systems disclosed herein. In

some cases, the devices may also have operating systems and application programs that are managed by the operating systems. In some embodiments, the hardware devices or software executed by the hardware devices also provides some ability, depending on the role of the device in the particular embodiment of the invention implemented, to compress or decompress data or to encode data or decode encrypted data, hi some instances, a decompression capability may be provided using available codecs, such as hardware- implemented Moving Picture Experts Group ("MPEG") codecs. A decryption capability may be provided using a decryption hardware or software module capable of decrypting data that is encrypted using a particular encryption algorithm.

[0028] Before discussing any embodiments of the invention, the reader should be familiar with certain encryption protocols and techniques described in the '402 Publication. To that end, this Detailed Description is arranged in three sections: 1) Mutating Identifier Protocol, 2) Black Content Protocol, and 3) Mutating Transport Layer Security. The first two subsections (i.e., Mutating Identifier Protocol and Black Content Protocol) are intended to summarize encryption techniques that are described in the '402 Publication, and are not intended to introduce any new subject matter. The third section (e.g., Mutating Transport Layer Security) provides a detailed description of embodiments of the invention. MUTATING IDENTIFIER PROTOCOL

[0029] FIG. 1 depicts a system 20, that is suitable for using the Mutating Identifier Protocol as disclosed in the '402 Publication. The system 20 includes a first device 22, a second device 24, and an authenticator device 28. It will be assumed that the first device 22 has data that it wants to transmit to the second device 24. The first device 22, the second device 24, and the authenticator device are connected by two-way links 30, 32, and 38 which can include all or part of one or more of computer networks such as the Internet, hi addition, in some embodiments the system 20 may include a random number generator 39 which is a

specialized device designed to produce numbers that are truly random (i.e., numbers that are as random as is possible with the particular technology used to implement the invention of the '402 Publication). In some embodiments, the authenticator device 28 uses the random number generator 39 to generate numbers used by a protocol implemented or followed by the system 20.

[0030] The system 20, can use mutating identifiers ("mutating IDs") to facilitate the transfer of information from the first device 22 to the second device 24. A mutating ID is an identifier that has at least two portions: 1) an identifying number and 2) a secret key. Both portions of the mutating ID are random values. Mutating IDs are generated and tracked by the authenticator device 28. Therefore, before the first device 22 and the second device 24 can communicate they must first obtain at least one mutating ID from the authenticator device 28. hi addition, each mutating ID can only be used one time, and when the first device 22 or the second device 24 has used its supply of mutating IDs, it must obtain additional mutating IDs from the authenticator device 28 before it can continue to communicate.

[0031] In one embodiment of the invention disclosed in the '402 Publication, mutating IDs are used to exchange a session key between the first device 22 and the second device 24. An example of this embodiment is described below. As with many descriptions of communication protocols, names are assigned to the various devices (or computer systems associated with those devices) used in the protocol. In one embodiment, Alice ( _^ 4) and Bob (B) represent the first device 22 and the second device 24, respectively, and Trent (T) represents the authenticator 28, a trusted arbiter of communication. The following table, Table 1, is a list of other symbols used in this document to explain multiple embodiments of the proposed protocol.

Table 1

[0032] Assume that Trent has assigned Alice a mutating ID that includes a random number N _A and a secret key K _A for some symmetric cipher and Bob a mutating ID that includes a number N _B and a secret key K _B for some symmetric cipher. In addition, Alice and Bob each have credentials (e.g., A _cre d and B _cre d, respectively) that are known only to Trent and to the respective holder of the credential.

[0033] Alice can request a session key (e.g., K _AB ) from Trent by encrypting her credentials and a publicly known identifier for Bob (e.g., _9,y) with her secret key K _A and append her number to the result. Alice transmits the result to Bob. A → B: NAE(K _A , A _cred B _id )

[0034] Bob concatenates his credentials B _cred and a publicly known identifier of Alice (e.g., Aid) with the message from Alice and encrypts the result with his secret key K _B . Bob appends his number K _B to the result of the encryption and sends the resulting message to Trent.

B → T: N _B E(K _B , B _cred A^ NAE(KA, A _cred B _id ))

[0035] Trent identifies that the message has come from Bob because Trent knows that the number TVg is associated with Bob. Trent decrypts the message using K _B and verifies Bob's credentials B _cred . Trent also decrypts and verifies the part of the message constructed by

AIi ce. If Bob's credentials B _cre( j match his number N _B and his identifier Bi _d provided by Alice and Alice's credentials A _cred match her number N _A and her identifier Ai _d provided by Bob, Trent verifies the request. After verifying the request, Trent generates a message for Alice and a message for Bob. The message for Alice includes a new number N _A ', a new secret key K _A ', Alice's credentials A _cred , and a session key K _AB - Trent encrypts the message for Alice with Alice's current secret key K _A - The message for Bob includes a new number N _B ', a new secret key K _B ', Bob's credentials B _cred , and a session key K _AB - Trent encrypts the message for Bob with Bob's current secret key K _B - Trent sends the messages to Alice and Bob.

T→ A: E(K _A , N _A ' KA ' A _cred K _AB )

T→ B: E(K ₈ , N _B ' K _B ' B _cre dK _AB )

[0036] Alice receives her message and decrypts it using her current secret key K _A and retrieves the session key K _AB , her new number N _A ', and her new secret key K _A '. Bob also receives his message and decrypts it using his current secret key K _B and retrieves the session key KAB, his new number N _B ', and her new secret key K _B '.

BLACKCONTENT PROTOCOL

[0037] Embodiments of the invention may also implement the Black Content Protocol disclosed in the '402 Publication. The secret keys of mutating IDs (e.g., K _A and K _B ) need to remain secret in order to protect the security of transmitted data encrypted with the secret keys. For example, if Trent provides Alice with a new mutating ID encrypted with Alice's current secret key (e.g., K _A ), an eavesdropper who has determined Alice's current secret key can obtain Alice's new mutating ID. The eavesdropper can then use the new mutating ID to send false data and/or to obtain the plaintext of future data exchanged between Alice and Trent.

[0038] Eavesdroppers can determine (or attempt to determine) a key used to encrypt particular data by performing an attack. For example, an eavesdropper can perform a brute force attack. A brute force attack includes decrypting ciphertext with every possible key until a key is found that produces coherent or recognizable data (e.g., human readable data). If the eavesdropper obtains or knows the plaintext (or a portion or pattern thereof) corresponding to obtained ciphertext, the eavesdropper can more easily determine whether a correct candidate key has been found. For example, if the eavesdropper obtains ciphertext and knows that the

ciphertext includes an individual's name followed by a 4-digit personal identification number ("PIN"), the eavesdropper can apply candidate keys until a candidate key produces the plaintext including the individual's name. The eavesdropper can then assume, with some certainty, that the remaining information included in the generated plaintext corresponds to the PIN.

[0039] However, if the eavesdropper has no knowledge of the plaintext or a pattern of the plaintext (i.e., has no content hint), the eavesdropper's ability to determine whether a correct candidate key has been found is greatly reduced and, perhaps, eliminated. For example, if plaintext includes a random number encrypted with a particular key, no matter how many keys the eavesdropper attempts in a brute force attack, the eavesdropper will have no way to determine whether candidate plaintext is the true plaintext corresponding to the ciphertext. Decrypting an encrypted random number with any candidate key will produce a random number that is equally likely to be the original random number as every other random number produced by every other candidate key.

[0040] Referring to the session key example described above involving Alice, Bob, and Trent, if any portion of an encrypted message is recognizable, known, becomes known, or includes any content hints, an eavesdropper could possibly perform a plaintext or partial- plaintext attack on the encrypted message and uncover a secret key of Alice or Bob used to encrypt the message. For example, assume that Alice sends the following message to Bob that is intercepted by an eavesdropper.

A → B: N _λ E(K _λ , A _cred B _id )

[0041] The eavesdropper can perform a brute force attack on the intercepted message because Bob's identifier Bi _d and the format of the above message are known or public. Thus, the eavesdropper can obtain Alice's secret key K _A and her credentials A _cred . Furthermore, once the eavesdropper obtains Alice's current secret key K _A , the eavesdropper can use Alice's current secret key K _A to obtain all data encrypted with Alice's current secret key K _A , such as her next mutating ID (e.g., N _A ' and K _A ^* )■

[0042] An eavesdropper can use other knowledge about an encrypted message or the communication protocol used to generate an encrypted message to perform brute force attacks. For example, an eavesdropper can use the mutating ID number (e.g., N _A ), which is

passed in the clear, to perform a brute force attack. An eavesdropper could also use knowledge of the algorithm used to generate the mutating ID numbers to perform a brute force attack.

[0043] As pointed out above, keys used to encrypt undiscoverable or "black" data (i.e., data that is random or has no content hints) cannot be easily determined or discovered using a brute force attack, since an eavesdropper will be unable to determine when a correct candidate key is found. Keys used to encrypt discoverable or "white" data (i.e., data that is known, may be later disclosed, is recognizable, or has a known or easily guessed format), however, can (theoretically) be determined using a brute force attack. When the discoverable data and the undiscoverable data are encrypted together or with the same encryption key (e.g., a recognizable name and a corresponding possibly random PIN encrypted with the same key), a key determined through a brute force attack using the discoverable data is also the key used to encrypt the undiscoverable data and, therefore, the undiscoverable data can be discovered.

[0044] To increase the security of the undiscoverable or secret data, separate keys can be used to encrypt the different types of data (hereinafter referred to as the "Black Content Protocol"). Data included in the black data class can be encrypted with one or more keys that are used only to encrypt black data (hereinafter referred to in this example as "black data keys"). Optionally, data included in the white data class can be encrypted with one ore more keys that are only used to encrypt white data (hereinafter referred to in this example as "white data keys"). It should be understood that the black data keys cannot be determined from (or are unrelated to) the white data keys. In other words, the black and white data keys are chosen (e.g., randomly) so as to avoid creating a predetermined relationship to one another, which differs, for example, from the way in which public and private key pairs are created in public key infrastructure systems. Such private and public keys have a predetermined relationship to one another, often a complex mathematical inverse. It should also be that the data does not need to be separated and placed in contiguous blocks of data according to the data class that the portions of data belong to. For example, one or more keys (e.g., one or more mutating IDs) can be used to encrypt the undiscoverable data (e.g., the secret keys K _A , K _B , and ^c) and one or more keys (e.g., one or more mutating IDs) can be used to encrypt the discoverable data (e.g., Bu). Since the same keys are never used to encrypt undiscoverable

data and discoverable data, the possibility of an eavesdropper determining undiscoverable data is reduced.

[0045] As more fully described in the '402 Publication, the Black Content Protocol can be used by the system 20, as shown in FIG. 1, to exchange requests and responses between entities (e.g., the first device 22 and the second device 24) and an authenticator (such as the authenticator device 28). Implementations of the protocol can be used by an entity to request a periodic mutation of a mutating ID, to request an encryption key, and to request a decryption key. Further, an entity (such as the first device 22) can communicate with another entity (such as the second device 24) using the responses from the authenticator device 28. For example, the first device 22 can request an encryption key from the authenticator device 28, use the encryption key to encrypt a message for the second device 24, and send the encrypted message to the second device 24. The second device 24 receives the encrypted message and can request a decryption key from the authenticator device 28, receive a decryption key from the authenticator device 28, and use the decryption key to decrypt the encrypted message.

[0046] Using the authenticator device 28 as the key distributor allows the entities to communicate with each other without having to establish a separate encryption or session key between entities. This request and response format can be used to establish the Mutating Transport Layer Security described below.

MUTATING TRANSPORT LAYER SECURITY

[0047] FIG. 2 is an exemplary depiction of a system 40 which is capable of using the TLS Protocol. The system 40 includes at least one TLS enabled client 42 and a TLS enabled server 44. As depicted in FIG. 2, the client 42 and the server 44 are connected to each other via a two-way link 46. The two-way link 46 can include all or part of one or more computer networks such as the Internet. The client 42 may be configured to run software, such as an Internet browser, which is capable of transmitting or receiving data to or from the server 44. In addition, the client 42 and the server 44 are TLS enabled so that they can implement the TLS Protocol, as described below, to provide secure transmission of data between the two machines.

[0048] FIG. 3 depicts the TLS Protocol as it is disclosed in RFC 4346. As shown in FIG. 3, the TLS Protocol is a layered protocol which consists of a TLS Record Protocol 60, at least

four client protocols 63, a Handshake Protocol 62, a Change Cipher Spec Protocol 64, an Application Protocol 66, and an Alert Protocol 68. The TLS Record Protocol 60 sits between a transport protocol (e.g., the Transmission Control Protocol ("TCP") 70) and the client protocols 63 and is used to encapsulate and transmit data for the client protocols. [0049] On the sender's side, the TLS Record Protocol 60 takes a message that is to be transmitted by a higher level protocol and fragments it into manageable blocks. These blocks are then optionally compressed, using a compression algorithm agreed upon by the sender and the receiver, encrypted, and used to create a message authentication code ("MAC") which is used by the receiver to verify that the message has not been tampered with during transmission. The sender transmits each encrypted block, along with its corresponding MAC, to the receiver.

[0050] On the receiver side, each encrypted block and its corresponding MAC are received by the TLS Record Protocol 60. Each block is decrypted, authenticated using the MAC, and decompressed (if necessary). The TLS Record Protocol 60 then reassembles the blocks and passes them to a higher level protocol.

[0051] In order for a TLS enabled client 42 to communicate with a TLS enabled server 44, the client 42 and the server 44 must first negotiate the cryptographic and compression methods that will be used by the TLS Record Protocol 60. This negotiation is accomplished by the TLS Handshake Protocol 62. The TLS Handshake Protocol 62 allows a TLS enabled client 42 and a TLS enabled server 44 to agree on the security parameters that will be used by the TLS Record Protocol 60, authenticate themselves, instantiate negotiated security parameters, and report error conditions to each other. This protocol is responsible for negotiating the parameters for a TLS session, which consist of the following information: 1) a session identifier, 2) optional peer certificates which can be used to verify the identity of the server or client, 3) a compression method which is the algorithm that the TLS Record Protocol uses to compress or decompress any transmitted data, 4) a set of encryption algorithms (e.g., DES) which will be used by the TLS Record Protocol to encrypt and decrypt the data, 5) a MAC algorithm (e.g., MD5 or SHA) which will be used by the TLS Record Protocol to calculate a MAC for any data that is transmitted, and 6) a master secret which is a 48 byte secret number shared by the client and the server.

[0052] FIG. 4 is a depiction of the TLS Handshake Protocol 62. This protocol consists of handshake messages that must be sent in a specific order. On the client 42 side there is a ClientHello message 70, an optional Certificate 72, a ClientKeyExchange message 74, an

optional Certificate Verify message 76, a ChangeCipherSpec message 78, and a Finished message 80. On the server 44 side, there is a ServerHello message 82, an optional Certificate 84, a ServerKeyExchange message 86, an optional CertificateRequest message 88, a ServerHelloDone message 90, a ChangeCipherSpec message 92, and a Finished message 94. Generally, the failure to send these messages in the proper order results in an error. [0053] As depicted in FIG. 4, the first handshake message is the ClientHello message 70. The ClientHello message 70 is sent by the client 42 when it attempts to connect to the server 44 or at any time that the client 42 wants to renegotiate a connection with the server 44. The ClientHello Message 70 includes a list of ciphersuites, listed in order of the preference of the client 42. A ciphersuite is a combination of cryptographic algorithms (or more broadly, cryptographic methods) which are supported by the client 42. Each ciphersuite includes a key-exchange algorithm (or more broadly, a protocol for exchanging cryptographic keys), a bulk encryption algorithm (or more broadly, an encryption method), and a MAC algorithm (or, more broadly, a MAC method). Version 1.1 of the TLS Protocol supports the RSA and Diffie-Hellman Protocols for key-exchange; RC4, RC2, DES, 3DES, DES40, IDEA, and AES for bulk encryption; and MD5 and SHA for MAC authentication. The ciphersuites are represented by predefined values which correspond to a specific combination of cryptographic elements. For example, the value {0x00, 0x004} indicates that the client 42 supports RSA for key-exchange, RC4 for bulk encryption, and SHA for MAC authorization. The ClientHello message 70 also includes a list of compression algorithms supported by the client 42, listed in order of the client's 42 preference, and the highest version of the TLS Protocol supported by the client 42.

[0054] After transmitting the ClientHello message 70, the client 42 waits for the server 44 to respond. The server 44 responds by transmitting a ServerHello message 82 if the server 44 supports any of the cryptographic and compression algorithms listed in the ClientHello message 70, or with an error alert if it does not. The ServerHello message 82 includes the version of the TLS Protocol that the client 42 and server 44 will use and a session identifier for the current session. In addition, the ServerHello message 82 contains the ciphersuite (i.e., the key-exchange, bulk encryption, and MAC algorithms) and the compression algorithm selected by the server 44 from the lists provided by the client 42 in the ClientHello message 70.

[0055] After sending the ServerHello message 82, the server 44 sends additional handshake messages to the client 42, some of which are optional. First, if the selected

ciphersuite requires a key-exchange algorithm that is not anonymous (i.e., such as RSA) the server 44 sends a Certificate 84 to the client 42. This Certificate 84 is an X.509v3 certificate which is appropriate to the selected key-exchange method. The Certificate 84 is issued to a server from a trusted certificate authority and will contain information that can be used to authenticate the identity of the server 44 and information concerning the server's 44 public key. Upon receipt of this certificate, the client 42 may contact the trusted certificate authority and verify the identity of the server 44 by verifying that the Certificate 84 it received from the server 44 is the same as a certificate which was issued to the server 44 by the certificate authority.

[0056] In addition, the server 40 may send a ServerKeyExchange message 86 to the client 42. This message is sent only if the server 44 did not send a Certificate 84 to the client 42, or if the server's 44 public key is too large to fit on the Certificate 84. The ServerKeyExchange message 86 includes the cryptographic information necessary for the client 42 to encrypt and send a premaster secret to the server 44. The premaster secret is used by the client 42 and the server 44 to compute a master secret which is used for generating encryption keys and MAC secrets. This message may consist of an RSA public key with which to encrypt the premaster secret or a Diffie-Hellman public key with which the client 42 can complete a key exchange (the result of which will be the premaster secret). FIG. 5 illustrates the format of the ServerKeyExchange message.

[0057] In addition, if appropriate to the selected ciphersuite, a non-anonymous server 44 sends a CertificateRequest message 88 to the client 42. This message signals the client 42, that it should send a certificate to the server 44, if it has one. Finally, the server 44 sends a ServerHelloDone message 90. This message indicates that the server 44 has sent all of the messages necessary to support the key-exchange and the client 42 may proceed. [0058] Upon receipt of the ServerHelloDone message, the client 42 may authenticate the identity of the server 44 using the server's Certificate 84 (if one was sent) and determine that the other parameters that it received from the server 44 are acceptable. If the server 44 sent the client 42 a CertificateRequest message 88, the client 42 responds by transmitting its Certificate 72 to the server 44. This Certificate 72 is also a V.509v3 certificate that is appropriate for the key-exchange algorithm of the suggested ciphersuite and maybe verified in the manner described above.

[0059] The client 42 sends a ClientKeyExchange message 74 to the server 44. The ClientKeyExchange message 74 communicates the premaster secret to the server 44: either

by transmitting the encrypted premaster secret (encrypted using the server's RSA public key) or by the transmission of Diffie-Hellman parameters which allow both the client 42 and the server 44 to compute the premaster secret. FIG. 6 illustrates the format of the ClientKeyExchange message 74.

[0060] The client 42 sends a CertificateVerify message 76 if explicit certificate verification is required by the selected ciphersuite. This message is only sent if the client's Certificate 72 has signing capability (i.e., any certificate other than one containing fixed Diffie-Hellman parameters).

[0061] Next, the client 42 sends a ChangeCipherSpec message 78. This is actually an instantiation of the Change Cipher Spec Protocol 64 mentioned above, and tells the server 44 that everything the client 42 sends after this message will be encrypted using the methods specified in the selected ciphersuite.

[0062] Finally, the client 42 sends a Finished message 80 to the server 44, verifying that the key-exchange and authentication process was successful. Upon receiving the client's Finished message 80, the server 44 sends a ChangeCipherSpec message 92 to the client 42, informing the client 42 that everything the server 44 sends after this message will be encrypted using the cryptographic methods specified in the selected ciphersuite. The server 44 then sends its Finished message 94.

[0063] At this point, the TLS Handshake Protocol 62 is complete, and the Application Protocol 66 is enabled. Any application running on the client 42, such as an Internet browser, can now transmit secure data (or more broadly, an information payload) to the TLS enabled server 10. As discussed above, the client 42 will use the TLS Record Protocol 60 to fragmentize, encrypt, and optionally compress any data that is transmitted by the browser to the TLS enabled server 44 using the cryptographic and compression algorithms established by the TLS Handshake protocol 62. Likewise, any data sent from an application, such as server software, running on the TLS enabled server 44 will be fragmentized, compressed, and encrypted, using the cryptographic and compression methods negotiated during the TLS Handshake Protocol 62, by the TLS Record Protocol 60 before it is sent to the TLS encrypted client.

[0064] Embodiments of the invention provide a Mutating TLS Protocol which modifies the TLS Protocol described above so that both the Mutating Identifier and Black Content Protocols may be used. FIG. 7 depicts an exemplary system 100 that is configured to use the Mutating TLS Protocol. The system 100 includes three participants: the client 42, which

corresponds to the first device 22 (as shown in FIG. 1) described in the '402 Publication, the server 44, which corresponds to the second device 24 (as shown in FIG. 1) described in the '402 Publication, and a key server 110, which corresponds to the authenticator device 28 (as shown in FIG. 1) described in the '402 Publication. The client 42, server 44, and key server 110 are connected to each other via two-way links 120, 122, and 124. The links 120, 122, and 124 can include all or part of one or more of computer networks such as the Internet. [0065] The Mutating TLS Protocol includes each of the TLS Protocols (e.g., the TLS Record Protocol 60, TLS Handshake Protocol 62, ChangeCipherSpec Protocol 64, Application Protocol 66, and Alert Protocol 68). However, these protocols are modified to support the Mutating Identifier and Black Content Protocol.

[0066] Before a Mutating TLS session can be established between a client 42 and a server 44, each device should have at least one mutating ID stored on their respective memory modules. These mutating IDs are generated by the key server 110 and transmitted to the client 42 and the server 44 by some secure means. The contents of these mutating IDs will be described below. In addition, the client 42 and the server 44 may each have a credential that is known only to each of them and to the key server 44.

[0067] FIG. 8 is a depiction of the modified TLS Protocol 128. On the client 42 side, the protocol includes a ClientHello message 130, modified ClientKeyExchange message 132, ChangeCipherSpec Message 134 and Finished message 136. On the server 44 side, the protocol includes a ServerHello message 138, modified ServerKeyExchange message 140, ServerHelloDone message 142, ChangeCipherSpec message 144, and Finished message 146. The modified TLS Handshake Protocol 128 does not require that the client 42 and server 44 exchange certificates. Therefore, none of the certificate related messages are transmitted. The lack of any certificates in the Mutating TLS Protocol decreases the likelihood of a man in the middle attack. A man in the middle attack can occur during the TLS Protocol when a device (an "imposter device") obtains a certificate allowing it to assume the identity of another device (the "target device") such as a secure web server. The imposter device is then able to communicate with other client devices as though it were the target device, and communicate with the target device as though the imposter device were a client. This allows the imposter device to intercept communications between the target and the client devices and possibly alter them, without alerting either the client device or the target device. In the Mutating TLS Protocol, each of the parties is authenticated by the key server 110 using information that is known only to them and to the key server 110. Further, the information

which the key server 110 uses to verify the identities of the client 42 and the server 44 consists of random values which can be encrypted using the Black Content Protocol, decreasing the likelihood that those values can be discovered by an eavesdropper who wishes to perpetrate a man in the middle attack.

[0068] The modified TLS Handshake Protocol 128 begins when the client 42 transmits the ClientHello message 130 to the server 44. As with the TLS Protocol described above, the ClientHello message 130 for the Mutating TLS Protocol includes a list of ciphersuites which identifies the possible cryptographic methods (i.e., protocols for exchanging cryptographic keys, encryption methods, and MAC methods) that may be used for the Mutating TLS session. This list of ciphersuites includes at least one entry that provides the option to use the Mutating Identifier Protocol alone or in combination with the Black Content Protocol as the key exchange algorithm (or protocol for exchanging cryptographic keys) for this Mutating TLS session.

[0069] The server 44 responds to the ClientHello message 130 by transmitting the ServerHello message 138 to the client 42, which indicates that the key exchange algorithm for this Mutating TLS session will be the Mutating Identifier Protocol and, in some instances, the Black Content Protocol, hi addition the ServerHello Message 138 also indicates which encryption and MAC methods the client 42 and the server 44 will use. [0070] Next, the server 44 transmits the modified S erverKey Exchange message 140 to the client 42. The modified ServerKeyExchange message 140 includes at least two variables which are necessary for the client 42 and the server 44 to use the key server 110 for the Mutating TLS session. The first variable is referred to as the KEYSER VER DEF and may include a unique identifier and the Uniform Resource Locator ("URL") (or more broadly and generically, an address) for the key server 110 that will be used for this session. The second variable is referred to as the KEY_ID and contains the server's 44 publicly known identifier (Si _d ) for the selected key server 110. FIG. 9 is a representation of the format for the modified ServerKeyExchange message 140 which adds the ability to choose mutating IDs as the key exchange protocol for the Mutating TLS session and includes the addition of two new variables KEYSERVER_DEF and KEYJD.

[0071] The server 44 then transmits a ServerHelloDone message 142, indicating to the client 42 that the server 44 is done with its part of the handshake. The client 42 responds to the ServerHelloDone message 142 by transmitting a modified ClientKeyExchange message 132 to the server 44. This modified ClientKeyExchange message 132 includes the same

KEYSER VER-DEF variable that was transmitted during the modified ServerKeyExchange message 140 to verify that the client 42 will use they key server 110 selected by the server 44. In addition, the modified ClientKeyExchange message 132 contains a KEY_ID variable which is the client's 42 publicly known identifier (Q _d ) for the selected key server 110. FIG. 10 is a representation of the format for the modified ClientKeyExchange message 132 which includes the addition of two new variables KEYSER VER DEF and KEYJD. [0072] The client 42 then sends a ChangeCipherSpec message 134 which indicates to the server 44 that all future transmissions will use the Mutating Identifier Protocol and, in some instances, the Black Content Protocol. The server 44 responds with its own ChangeCipherSpec message 144 and Finished message 146, which completes the modified TLS Handshake Protocol 128.

[0073] Mutating TLS provides a mechanism for the client 42 and the server 44 to implement a protocol for exchanging cryptographic keys, using the Mutating Identifier Protocol and perhaps the Black Content Protocol, to obtain cryptographic keys which are used to encrypt data (or more broadly, an information payload) that is transmitted between the client 42 and the server 44 using the selected encryption methods. For example, after completing the modified TLS Handshake Protocol the client 42 and the server 44 may obtain a session key (K _c8 ) from the key server 110 that will be used by the modified TLS Record Protocol to encrypt the communications between the applications on those two devices, hi this example, the mutating IDs that are on the client 42 and the server 44 will include at least two pieces of information: 1) random identification number (N), and 2) an encryption key (K). The session key (K _cS ) can be established for communication between the client 42 and the server 44 using the methods described above in the section entitled Mutating Identifier Protocol. The client 42 requests a session key from the key server 110 by first encrypting the client's credential (C _cred ) and the server's 44 publicly known value (Si _d ) for the key server 110 using the encryption algorithm (E) which is supported by the selected key server 110 and the encryption key from the client's mutating ID (K _c ). The client 42 concatenates the random number (N ₀ ) from its mutating ID to the encrypted data and transmits this request for a session key to the server 44.

C → S: N _C E(K _C , CcredSid)

[0074] The server 44 concatenates its credentials (S _cred ) and the client's public identifier for the selected key server 110 (Cid) to the message that it received from the client 42. The server 44 encrypts that data with the encryption key from its mutating ID (Ks) and the encryption algorithm (E) that is supported by the selected key server 110. The server 44 also concatenates the random number (N ₅ ) from its mutating ID to the encrypted data and transmits the request for a session key to the key server 110.

S → KS:N _s (E(K _s ,S _cred C _id N _c E(K _c ,C _cred S _id ))

[0075] The key server 110 identifies that the message it received came from the server 44 because it knows that the number N _s is identified with the server 44. The key server 110 decrypts the message using the encryption algorithm (E) and the encryption key K _s and verifies the server's 44 credentials S _cred - The key server 110 then decrypts the part of the message encrypted by the client 42 using the encryption algorithm (E) and the encryption key K ₀ . If the server's 44 credentials S _cred match the identifying number N _s and the identifier Sjd provided by the client 42 and the client's credentials C _cred match the identifying number N _c and the identifier Q _d provided by the server 44, then the key server 110 verifies the request and generates a message for the client 42 and the server 44. The message for the client 42 includes a new mutating ID which has a new identifying number N _c ' and a new encryption key K ₀ ', the client's credentials C _cred , and the session key K _cS . The key server encrypts the message for the client 42 using the client's current secret key K ₀ .

KS → C: E(K _c N _c 'K _c 'C _cred K _cs )

The message for the server 44 includes a new mutating ID which has a new identifying number N _s ' and a new encryption key K _s ', the server's credentials S _cred , and the session key K ₀₈ . The key server 110 encrypts the message using the server's current secret key K _s and sends it to the server 44.

KS → S: E(K _S ,N _S 'K ₅ 'S _cred K _cs )

[0076] Upon completing this key exchange, the client 42 and server 44 can communicate securely using Mutating TLS. The Application Protocol is enabled, which allows software

applications on the client 42 and the server 44 to communicate using one or more well-known communication protocols (i.e., HTTP, TELNET, FTP, SMTP). Data (or an information payload) that is to be transmitted by the Application Protocol is fragmentized into manageable blocks and encrypted by the modified TLS Record Protocol using the encryption algorithms (or more broadly, encryption methods) selected by the client 42 and the server 44 during the modified TLS Handshake 128 and the session key K _c8 .

[0077] In a separate embodiment, the client 42 and the server 44 may choose to use the Black Content Protocol to obtain a session key from the server. In this embodiment, the mutating IDs on the client and server contain two encryption keys: 1) an encryption key that can be used to encrypt white data (K _w ) and 2) an encryption key that can be used to encrypt black data (K _b ). Alternatively, the client 42 and the server 44 can each have two mutating IDs one which contains the encryption key for the white data (K _w ) and the other that includes the encryption key for the black data (K _b ). In this embodiment, the client 42, server 44, and the key server 110 each send the same messages described above. However, the white data key (K _w ) is used to encrypt the discoverable data (e.g., Q _d and Si _d ) and the black data key is used to encrypt the undiscoverable data (e.g., C _cre d, S _cre d, N _c ).

[0078] In still another embodiment, the key server 110 assigns the client 42 and the server 44 each a large mutating ID consisting of a public identifier, a key for encrypting white data, and a separate key for encrypting black data. As described in the '402 Publication, these elements may be used to exchange requests and responses between the client 42 and the server 44. For example, the client 42 can use the information in these identifiers to request an encryption key from the key server 110. The client 42 can then use that encryption key to encrypt and transmit data to the server 44. The server 44 uses the information in its large mutating ID to request a decryption key for the data from the key server 110. The server 44 uses the decryption key to decrypt the encrypted data that it received from the client 42. The client 42 and the server 44 may carry out this process each time they communicate with one another. This requires the TLS Record Protocol to be further modified so that, on the sender's side, an encryption key is requested before the data is encrypted and transmitted to the receiver and, on the receiver side, the decryption key is requested from the key server 110 before decrypting the encrypted data. [0079] Various features and embodiments of the invention are set forth in the following claims.