WO2009018510A1

WO2009018510A1 - Systems and methods for implementing a mutating internet protocol security

Info

Publication number: WO2009018510A1
Application number: PCT/US2008/071892
Authority: WO
Inventors: Richard Malina; Stuart Stubblebine
Original assignee: Imagineer Software, Inc.
Priority date: 2007-08-02
Filing date: 2008-08-01
Publication date: 2009-02-05

Abstract

A method and system for enabling secure communications between devices on a computer network. The system includes a first device, a second device, and a key server. Mutating Internet Protocol Security ('Mutating IPSec') is presented which allows two devices to communicate with one another using a Mutating Identifier Protocol, a Black Content Protocol, or both. The Mutating IPSec includes a modified Internet Key Exchange ('IKE'). The key server generates mutating identifiers and distributes them to the first device and the second device.

Description

SYSTEMS AND METHODS FOR IMPLEMENTING A MUTATING INTERNET

PROTOCOL SECURITY

BACKGROUND OF THE INVENTION

[0001] Often, information that is transmitted across a public computer network contains confidential information. For example, individuals who make online purchases may need to provide their personal financial data (e.g., their credit card number or bank information) as part of the purchase. In addition, employees may wish to establish a secure and confidential electronic communication pathway with trusted devices that are owned or controlled by their employer for the purposes of sending and receiving confidential documents. Due to the nature of public computer networks, there is no way to ensure that only the intended recipient will be able to access such sensitive information without providing addition security mechanisms. Therefore, it is useful to have a means for protecting confidential information when it is transmitted over a public network.

[0002] One such mechanism is Internet Protocol Security ("IPSec") which is a set of protocols developed by the Internet Engineering Task Force ("IETF") to support the secure exchange of information at the Network Layer of the Open Systems Interconnection Basic Reference Model (the "OSI Model"), which corresponds to the IP Layer of the TCP/IP Reference Model. IPSec has been used widely to implement Virtual Private Networks ("VPNs"). A VPN uses a public network's communication links to connect with one or more of its endpoints in a manner that approximates communication over a private network. VPNs typically use a combination of data encryption and source validation to ensure that only authorized parties can access their information. IPSec provides means for both data encryption and source validation to information that is transmitted over the Internet.

[0003] IPSec provides these services through the use of two protocols: the Authentication Header ("AH") protocol, which provides for message authentication, and Encapsulating Security Payload ("ESP") protocol, which provides for message authentication and data encryption. In addition, IPSec provides for two modes of operation: Transport Mode in which only the data portion of an IP datagram is encrypted, and Tunnel Mode which encrypts both the header and the payload of an IP datagram. The receiver of IP datagrams which have been encrypted using IPSec's protocols, decrypts the datagram's encrypted payload upon receipt. Internet Protocol Security is described in detail by RFC 4301, available at http://tools.ietf.org/html/rfc4301. [0004] The protocols that are used by IPSec require the communicating devices to agree upon a set of cryptographic algorithms and keys to use for data encryption and message authentication. These cryptographic algorithms may be established through the use of a key management protocol such as an Internet Key Exchange ("IKE"). IKE provides for mutual authentication and establishes IPSec Security Associations ("SA") between two parties. The IPSec SA includes information that the parties may use to communicate during an IPSec session, including traffic selector information, cryptographic algorithms, and cryptographic keys. Internet Key Exchange version two is described in detail by RPC 4306, available at http://tools.ietf.org/html/rfc4301.

[0005] One vulnerability of IKE is that it is susceptible to man in the middle attacks. Specifically, IKE allows for parties to authenticate themselves using a pre-shared secret and uses Diffie-Hellman for key exchange. A malicious third party may be able to intercept Internet communications between two parties and listen to or modify them. The risk of such an attack is decreased by the availability of authentication methods that use digital certificates and digital signatures in IKE. However, a malicious user could still carry out a man in the middle attack by obtaining a fake certificate. U.S. Patent Publication 2006/0195402 (the '"402 Publication"), the contents of which are incorporated by reference as if fully set forth herein, presents Mutating Identifier and Black Content Protocols that greatly increase the costs associated with intercepting and decrypting these communications.

SUMMARY OF THE INVENTION

[0006] In light of the vulnerabilities that are present in IPSec and IKE, it is useful to have an implementation with an improved security mechanism. Embodiments of the invention provide what is referred to as Mutating IPSec, which utilizes Mutating Identifiers and, in some circumstances, a Black Content Protocol. Mutating Identifiers and Black Content Protocol are both described in the '402 Publication. One embodiment is a system that includes a first device, a second device, and a key server. The first device and the second device may communicate using IPSec. Embodiments of the invention implement a modified Internet key exchange which provides a mechanism for the first device and the second device to establish shared cryptographic keys through the key server.

[0007] Mutating IPSec provides for data encryption and message authentication by modifying IP datagrams as they are processed at the Network Layer. The ESP Protocol encrypts the modified IP datagram payloads. The cryptographic algorithms and keys that are used for data encryption and message authentication are determined by a security association that is established by the first device and the second device. The first device and the second device establish the security association through an Internet Key Exchange ("IKE"). IKE includes a series of requests (which are sent by the first device) and responses (which are sent by the second device). Each pair of requests and responses is termed an exchange. IKE includes four types of exchanges: 1) the IKE_SA_INIT exchange, which creates a special security association that identifies the cryptographic algorithms and keys that will be used for the remaining IKE exchanges, 2) the IKE-AUTH which provides for identification and mutual authentication of the first device and second device and creates a first security association, 3) the CREATE_CHILD_SA exchange which creates additional security associations and refreshes the keys of existing security associations, and 4) INFORMATIONAL exchanges which the first device and second device may use to exchange notifications and alerts during the IKE.

[0008] As part of the IKE exchanges, the first device and the second device exchange key exchange information with one another. As specified in RFC 4306, this key exchange information includes the Diffie-Hellman value of the first device or second device. Mutating IPSec modifies this message so that, in place of the Diffie-Hellman public values, the key exchange information contains the information necessary for the first device and the second device to obtain cryptographic keys from the key server. This decreases the possibility of a man in the middle attack, because a malicious third-party device will not be able to authenticate itself to the key server in order to obtain an authorized cryptographic key.

[0009] In one embodiment, the invention is a computer-based method of establishing secure communication between a first device and a second device. The method includes obtaining a first mutating identifier for the first device from a key server and obtaining a second mutating identifier for the second device from the key server. The method also includes transmitting a first message, including a first mutating key identifier, from the first device to the second device as part of the initial exchange of an Internet key exchange and transmitting a second message, including a second mutating key identifier, from the second device to the first device, establishing a first cryptographic method as part of the initial exchange of the Internet key exchange. The method also includes providing a first session key to the first device and the second device from the key server; transmitting a third message, including self- authentication information for the first device, from the first device to the second device as part of the Internet key exchange; transmitting a fourth message, including self-authentication information for the second device, from the second device to the first device, establishing a second cryptographic method as part of the Internet key exchange; providing a second session key to the first device and the second device from the key server; and transmitting at least one datagram between the first device and the second device by encrypting the payload using the second cryptographic method and session key.

[0010] In another embodiment the invention is a first device configured to communicate with a key server and a second device. The first device includes a processor having a mutating identifier associated therewith, the mutating identifier provided by the key server. The processor is configured to transmit a first message, including a first mutating key identifier, to the second device; receive a second message, including a second mutating key identifier, from the second device to establish a first cryptographic method; and receive a first set of cryptographic keys from the key server, the first set of cryptographic keys including at least one cryptographic key. The processor is also configured to transmit a third message, including self-authentication information, to the second device; receive a fourth message, including self-authentication information, from the second device establishing a second cryptographic method; and receive a second set of cryptographic keys from the key server, including at least one cryptographic key.

[0011] In yet another embodiment, the invention is a second device configured to communicate with a key server and a first device. The second device includes a processor having a mutating identifier associated therewith, the mutating identifier provided by the key server. The processor is configured to receive a first message, including a first mutating key identifier, from the first device; transmit a second message, including a second mutating key identifier, to the first device to establish a first cryptographic method; receive a first set of cryptographic keys from the key server, including at least one cryptographic key; receive a third message, including self-authentication information, from the first device; transmit a fourth message, including self-authentication information, to the first device establishing a second cryptographic method; and receive a second set of cryptographic keys from the key server, including at least one cryptographic key. BRIEF DESCRIPTION OF THE DRAWINGS

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

[0013] FIG. 2A is a schematic representation of a system that is configured to use Internet Security Protocol.

[0014] FIG. 2B is a schematic representation of an alternative system that is configured to use Internet Security Protocol.

[0015] FIG. 2C is a schematic representation of another alternative system that is configured to use Internet Security Protocol.

[0016] FIG. 3 is a schematic representation of an IP datagram (version 4). [0017] FIG. 4 is a schematic representation of an ESP Payload.

[0018] FIG. 5 is a schematic representation of an IP datagram that is modified using the ESP protocol.

[0019] FIG. 6 is a schematic representation of the initial exchanges of an Internet key exchange.

[0020] FIG. 7 is a schematic representation of a CREATE_CHILD_SA exchange.

[0021] FIG. 8A is a schematic representation of a system that is configured to use Mutating IPSec.

[0022] FIG. 8B is a schematic representation of an alternative system that is configured to use Mutating IPSec.

[0023] FIG. 8C is a schematic representation of an alternative system that is configured to use Mutating IPSec.

[0024] FIG. 9 is a schematic representation of a key exchange information payload. DETAILED DESCRIPTION

[0025] 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 conventions 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.

[0026] 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, hi 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. 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. [0027] 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 Internet Protocol Security. The first two sections (e.g., Mutating Identifier Protocol and Black Content Protocol) are intended to summarize encryption techniques that are described in the '402 Publication. The third section (e.g., Mutating Internet Protocol Security) provides a detailed description of embodiments of the invention.

MUTATING IDENTIFIER PROTOCOL

[0028] 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 is 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. In 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 specific embodiments). 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.

[0029] 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. In 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. [0030] 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 (A) 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

[0031] 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_cred and B_credy respectively) that are known only to Trent and to the respective holder of the credential.

[0032] 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., B_tJ) with her secret key K_A and append her number to the result. Alice transmits the result to Bob.

A → B: N_AE(K_A, A_credB_id) [0033] Bob concatenates his credentials B_cred and a publicly known identifier of Alice (e.g., Ai_d) 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: NBE(KB, B_credA_idN_AE(K_A, A_credB_id))

[0034] Trent identifies that the message has come from Bob because Trent knows that the number N_B 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 Alice. If Bob's credentials B_cred match his number N_B and his identifier B^ provided by Alice and Alice's credentials A_cred match her number N_A and her identifier A_id 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 KB. Trent sends the messages to Alice and Bob.

T→ A: E(K_A, N_A 'K_A 'A_credK_AB)

T → B: E(K_B, W K_B ' B_credK_AB)

[0035] 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 K_AB, his new number N_B ', and her new secret key K_B '■

BLACKCONTENT PROTOCOL

[0036] 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.

[0037] 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 located. 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.

[0038] 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.

[0039] 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_AE(K_A, A_cred B_id) [0040] 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^ ' and K_A 0-

[0041] 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.

[0042] 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.

[0043] 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"). 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 an 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 noted 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 Kc) and one or more keys (e.g., one or more mutating IDs) can be used to encrypt the discoverable data (e.g., BiJ). Since the same keys are never used to encrypt undiscoverable data and discoverable data, the possibility of an eavesdropper determining undiscoverable date is reduced.

[0044] 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.

[0045] Using the authenticator device 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 in the Mutating Internet Security Protocol described below.

MUTATING INTERNET PROTOCOL SECURITY

[0046] Before embodiments of the present invention are described, the reader should understand the basic modes and protocols of IPSec (as disclosed in RFC 4301 and RFC 4306). To that end, the following is a brief description of IPSec, intended to provide background only. For a more detailed description of IPSec please see the RFCs.

[0047] As previously discussed, IPSec provides for secure communications between two devices over a public computer network such as the Internet. FIG. 2A is a schematic representation of a system 40 which is configured to use IPSec. The system 40 includes a first device 42 and a second device 44 which communicate with one another over a protected communication pathway 46. The first device 42 and the second device 44 may each be personal or home computers, servers, or other devices that have processors or that are capable of communicating with one another. In addition, the first device 42 and/or the second device 44 may be configured as a secure gateway, which is a device that serves as an entry point to a separate computer network and routes network traffic to end points on that separate network. FIG. 2B is a schematic representation of a system that is configured to use IPSec where the second device 44a is a secure gateway that serves as an entry point to a separate electronic network. The second device 44a receives data that is intended for one or more of the endpoints on its internal network, and routes them accordingly. FIG. 2C is a schematic representation of a system that is configured to use IPsec where the first device 42b and the second device 44b are both secure gateways. In the examples of IPSec provided below, the first device 42 will be described as the sending device and the second device 44 will be described as the receiving device. It should be understood, however, that both the first device 42 and the second device 44 are capable of sending and receiving data.

[0048] IPSec operates at the Network Layer of the OSI Model which corresponds to the IP Layer of the TCP/IP Model. The Network Layer provides a means for transmitting IP datagrams from a sender device (e.g., the first device 42) to a destination device (e.g., the second device 44). An IP datagram is a variable length, formatted block of data that that can be transmitted over a computer network. FIG. 3 depicts an IP datagram 60. The depicted datagram is an IP version 4 datagram. However, IPSec can be implemented to work with other types of datagrams, including IP version 6. The IP datagram 60 includes an IP Header 62 and a payload 64. The IP Header 62 marks the beginning of the IP datagram and includes defined fields including the IP version number 65 (ver) , the length 66 (Men) of the IP Header (in bytes), a type of service field 67 (tos) which indicates how the IP datagram 60 should be used (i.e., delay, optimum bandwidth, optimum reliability, etc.), the length 68 (pkt len) of the IP datagram 60 (in bytes), an ID field 73 (ID) which identifies related IP datagrams 60, a flags field 70 (figs) which includes information about fragmenting the IP datagram 60, a fragment offset field 71 (frag offset) which is used to reassemble fragmented IP datagrams 60, a time to live field 72 (TTL) which controls the amount of time that an IP datagram 60 is allowed to live on the network, a protocol field 73 (proto) which identifies the network protocol (i.e., TCP, UDP, etc.) for the payload, a header checksum field 74 (hdr checksum) which holds a checksum of the IP Header 62 that is used for error detection, the network address 75 (src IP Address) for the first device 42, the network address (dst IP Address) 76 for the second device 44, and an optional IP Options 77 (IP Options) field that contains application specific information. The payload 64 contains the data that is being transmitted in the IP datagram 60. IPSec modifies IP datagrams to provide for source authentication and data confidentiality.

[0049] IPSec includes two separate protocols: 1) Authentication Header ("AH") which provides for source authentication but does not provide for data confidentiality, and 2) Encapsulating Security Payload ("ESP") which provides for both source identification and data confidentiality. Typically, these protocols are used separately from one another. AH will not be discussed in detail here because it does not support data confidentiality.

[0050] The ESP protocol encrypts the payload 64, and adds a header and a trailer to the encrypted payload (this modified payload is referred to herein as an "ESP payload"). FIG. 4 is a representation of an ESP payload 80. The ESP Payload 80 includes an ESP Header 82, an encrypted payload 84, ESP Trailer 86, and Message Authentication Data 88. The ESP Header 82 includes a Security Parameters Index field 90, which is used by the destination device (e.g., the second device 44) to determine which IPSec Security Association ("SA") is associated with the modified IP datagram. As described below, an IPSec SA determines which cryptographic algorithms and keys are used to encrypt data and computes a cryptographic hash of a payload that is being sent to the target device. In addition, the ESP Header 82 includes a monotonically increasing number 91 (or Sequence Number) which the target device uses to detect repeat messages. The ESP Trailer includes three fields: 1) a padding field 92 (padding), which lengthens the encrypted data 84 so that it is the correct length for block oriented encryption algorithms, 2) a padding length variable 93 (pad len) which identifies the length of the padding field, and 3) and a next header field 94 (next hdr), which gives the protocol type (IP, TCP, UDP, etc.) of the encrypted payload 84. The Message Authentication Data 88 is a cryptographic hash of the ESP Payload 84. FIG. 5 is a schematic depiction of an IP datagram that has been processed using the ESP protocol.

[0051] IPSec supports two transmission modes: 1) Transport Mode, and 2) Tunnel Mode. ESP Transport Mode may be used for communications between two network endpoints. During ESP Transport Mode, the first device 42 modifies IP datagram 60 by applying either the AH protocol or the ESP protocol to the payload 64 of the original IP datagram. The modified IP datagram 60 retains its original IP Header 62, however, the protocol field 73 of the IP Header is modified to indicate that the IP datagram 60 was processed using ESP (NeXt=ESP). The ESP Payload 84 is the original payload 64, modified using the ESP protocol as described above.

[0052] Tunnel Mode is most often used to create VPNs which provides for secure communications between two or more devices over a public network. During Tunnel Mode, the first device 42 modifies the IP datagram 60 by applying the AH protocol or the ESP protocol to the entire IP datagram 60, rather than just the payload 64. Therefore, when the ESP protocol is used, the entire IP datagram 60 is encrypted and inserted into the ESP Payload 82 (as the encrypted payload 82). The first device 42 then creates a new IP Header 62 and combines it with the AH or ESP processed datagram (which contains the original IP datagram as its payload). Referring to FIG. 2B, Tunnel Mode is used for VPN's because it allows the first device 42 to communicate with an internal node on a network that is protected by a secure gateway (the second device 44a) by 1) creating an IP datagram that is addressed to the internal node (e.g., that has the network address of the internal node listed as its destination address); 2) encapsulating the IP datagram using either the AH or ESP protocols, and 3) inserting the encapsulated payload as the payload of a new IP datagram which has an IP Header that lists the network address of the secure gateway 44a as its destination address. The first device 42 transmits the new IP datagram to the secure gateway 44a. The secure gateway 44b receives the new IP datagram and uses the appropriate cryptographic methods to extract the payload. The secure gateway determines that the payload for the modified IP datagram contains the original IP datagram that is addressed to a node on the protected network and transmits the original IP datagram to the appropriate node.

[0053] The first device 42 and the second device use SAs to determine which cryptographic algorithms and keys to use for a given IP datagram 60. An SA contains specific information regarding each active IPSec session, including the encryption algorithm, the encryption key, the authentication algorithm, and the authentication key. The first device 42 and the second device 44 each maintain a Security Associations Database ("SADB") which stores all of the SA's for the device. The SADB holds at least the following information for each SA: a. The encryption algorithm b. The encryption secret key; c. The authentication algorithm d. The authentication seed; e. Routing Restrictions; and f. IP Filtering Policy.

[0054] The first device 42 and the second device 44 establish the SAs through the use of Internet Key Exchange ("IKE"). IKE is a key management protocol that negotiates and provides the cryptographic material for the establishment of an SA. IKE transmissions include pairs of messages (requests and responses) called exchanges. There are four types of exchanges, IKE_SA_INIT 102, IKE_AUTH 108, CREATE_CHILD_SA 114, and INFORMATIONAL exchanges. FIG. 6 is a schematic representation of the initial exchanges in an IKE. The IKE takes place between the first device 42, the initiator, and the second device 44, the responder.

[0055] An IKE begins with an IKE_S AJNIT 102. The IKE_S AJNIT 102 negotiates and provides the information necessary to create an IKE_S A which is a unique security association used only to provide encryption and authentication for subsequent IKE exchanges. The IKE_SA_INIT exchange 102 includes a first request 104, transmitted by the first device 42 to the second device 44, and a first response 106, transmitted by the second device 44 to the first device 42. The first request 104includes the following: 1) an IKE header 104a (HDR), 2) security association information 104b (SAi), 3) key exchange information 104c (KEi), and 3) a nonce 104d (Ni). The IKE header 104a (HDR) includes security parameter indexes, version numbers, and flags of various sorts. The IKE header 104a is the first part of each subsequent IKE message. The security association information 104b (SAi) includes a list of cryptographic algorithms which are supported by the first device 42. The key exchange information 104c (KEi) contains Diffie-Hellman values that the second device 44 uses to compute cryptographic keys for the IKE_S A. The nonce 104d (Ni) is a random value which is used as an input for the cryptographic functions which compute the keys for the IKE_SA. Subsequent messages also include nonces which are also used as inputs for the cryptographic functions that generate the keys used by the SAs.

[0056] Upon receiving the first request 104, the second device 44 prepares and transmits the first response 106. The first response 106 includes the following: 1) an IKE header 106a (HDR), 2) security association information 106b (SAr), 3) key exchange information 106c (KEr), 4) a nonce 106d (Nr), and 5) an optional request for a digital certificate from the first device 106e ([CERTREQ]). The security association information 106b (SAr) identifies the cryptographic algorithms for the IKE_SA, selected from the list transmitted during the first request 104. The key exchange information 106c (KEr) contains Diffie-Hellman values that the first device 42 uses to compute cryptographic keys for the IKE_SA. Finally, the first response may include an optional request for the first device's digital certificate 106e ([CERTREQ]) for authentication purposes as described below. After the first device 42 receives the first response 106, both the first device 42 and the second device 44 have the cryptographic materials necessary to create the IKE S A. Portions of all future IKE exchanges between these two devices are encrypted using the cryptographic keys and algorithms identified by the IKE_SA as established during the IKE SA INIT exchange 102.

[0057] The IKE_SA_INIT exchange 102 is followed by the IKE AUTH exchange 108. The IKE AUTH exchange 108 provides for mutual authentication of the first device 42 and second device 44, and for the negotiation of the cryptographic keys and algorithms that will be used for the first child SA which may be used by the first device 42 for IPSec communications. The IKE_AUTH exchange 108 includes a second request 110 and a second response 112. The second request 110 includes an unencrypted IKE header 110a (HDR), and the following information which is encrypted using the cryptographic keys and algorithms established for the IKE_SA: 1) an identifier 110b (IDi) for the first device 42, 2) an optional digital certificate 110c ([CERT]) for the first device 42, 3) an optional request for the digital certificate HOd ([CERTREQ]) for the second device 44, 4) an optional identifier request HOe ([IDr]), 5) additional security association information 11Of (SAi2), 6) an authentication value for the first device 11Og (AUTH), and 7) traffic selector information 11Oh, 11Oi(TSi and TSr).

[0058] The identifier 110b (IDi) asserts the identity of the first device 42 by providing information such as the network address and perhaps a Uniform Resource Locator ("URL") of the first device 42. The optional identifier request HOe ([IDr]) allows the first device 42 to indicate which identity of the second device's 44 it desires to communicate with. The authentication value HOg (AUTH) provides the means for the first device 42 to authenticate its identity using either digital signatures (which generally require the use of digital certificates) or a pre-shared secret (e.g., a cryptographic hash of information received during previous exchanges). The additional security association information 11Of (SAi2) includes a list of cryptographic algorithms supported by the first device 42 which may be used for the first SA. The traffic selector information 11Oh, 11Oi (TSi and TSr) allow the first device 42 to identify what type of IP datagrams should be processed using IPSec. Finally, the second request 110 may contain the first device's certificate 110c ([CERT]) and an optional request for second device's 44 certificate HOd ([CERTREQ]) if the authentication value HOg (AUTH) uses digital signatures.

[0059] Upon receiving the second request 110, the second device 44 transmits the second response 112. The second response 112 includes an unencrypted IKE header 112a (HDR) and the following information, which is encrypted using the cryptographic keys and algorithms established for the IKE_SA: 1) an identifier 112b (IDr) for the second device 44, 2) an optional digital certificate 112c ([CERT]) for the second device 44, 3) an authentication value 112d (AUTH) for the second device 44, 4) additional security association information 112e (SAr2), and 5) traffic selector information 112f, 112g (TSi and TRr). The additional security information 112e (SAr2) identifies the cryptographic algorithms and keys for the SA, from the list provided in the second request 110. The remaining fields of the second response 112, contain the same information for the second device 42 as the corresponding fields in the second response 110. Upon the completion of the second response 112, an SA is established between the first device and the second device. This SA identifies which cryptographic algorithms, cryptographic keys, and IP datagrams are used for IPSec communication between these two devices.

[0060] In addition, the first device 42 and the second device 44 may create additional SA's or refresh the cryptographic keys for an existing SA using the CREATE CHILD S A exchange 114. FIG. 7 is a schematic depiction of a CREATE CHILD SA exchange 114 that includes a third request 116 and a third response 118. The third request 116 includes an unencrypted IKE header 116a (HDR), and the following information, which is encrypted using the cryptographic keys and algorithms established for the IKE SA: 1) an optional SA identifier 116b ([N]); 2) security association information 116c (SA), 3) a nonce 116d (Ni), 4) optional key exchange information 116e (KEi), and 5) traffic selector information 116f, 116g(TSi and TSr). The optional SA identifier 116b ([N]) is only included if the CREATE_CHILD_SA exchange is refreshing the cryptographic keys of an existing SA. This SA identifier 116b ([N]) contains a value which identifies the existing SA. The security association information 116c (SA) includes a list of cryptographic algorithms that are supported by the first device 42. The optional key exchange information 116e (KEi) contains a Diffie-Hellman public value for the first device and is sent only if it is necessary to establish a new set of cryptographic keys between the first device 42 and second device 44. The traffic selector information 116f, 116g ([TSi] and [TSr]) allows the first device 42 to identify what type of P datagrams should be processed using IPSec for the new or rekeyed SA.

[0061] Upon receiving the third request 116, the second device 44 prepares and transmits a third response 118. This third response 118 contains an unencrypted IKE header 118a (HDR) and the following information, which is encrypted using the cryptographic keys and algorithms established for the IKE SA: 1) security association information 118b (SA), 2) a nonce 118c (Nr), 3) optional key exchange information 118d ([KEi]), and 4) optional traffic selector information 118f, 118g ([TSi] and [TSr]). The security association information 118b (SA) specifies the encryption algorithm that will be used for the new or rekeyed SA, from the list provided in the third request 116. The optional key exchange information 118d ([KEi]) contains a Diffie-Hellman public value for the second device and is sent only if it is necessary to establish a new set of cryptographic keys between the first device 42 and second device 44. Finally, the optional traffic selector information 118f, 118g ([TSi] and [TSr]) allow the second device 44 to identify what type of IP datagrams should be processed using IPSec for the new or rekeyed SA.

[0062] IKE, as described above and in RFC 4306, has some potential weaknesses. One important weakness is that IKE uses Diffie-Hellman for its key exchange algorithm, and a Diffie-Hellman key exchange is vulnerable to a man in the middle attack. As an example of this attack, a malicious third-party device may intercept the key exchange information 104c (KEi) that is transmitted from the first device 42 to the second device 44 during the first request 104 of the IKE_SA_INIT exchange 102. The third-party device modifies the first request 104 so that the key exchange information 104c (KEi) contains the third-party device's public Diffie-Hellman value and transmits the modified first request to the second device 44. The second device 44 prepares and transmits the first response 106. The third-party device intercepts the first response and uses the key exchange information 106c (KEr) to obtain the second device's 44 public Diffie-Hellman value. The third-party device modifies the first response 106 so that the key exchange information 106c (KEr) contains the third party device's public Diffie-Hellman value and transmits the modified first response 106 to the first device 42. In this manner, the third party device establishes a unique IKE_SA with both the first device 42 and the second device 44. The third party device sits between the first device 42 and the second device 44, listens to and possibly modifies their communications. This enables the third-party device to establish additional SA' s with the first device 42 and second device 44 and participate in IPSec communications with both devices.

[0063] IKE addresses this potential man in the middle attack by providing a means for the first device 42 and the second device 44 to authenticate themselves (in the (AUTH) field 11Og, 112d) during the IKE AUTH exchange 108. Theoretically, this authentication prevents the third-party device that has negotiated an IKE_SA with both the first device 42 and the second device 44 to go undetected, because it is not able to provide the appropriate authentication values. However, IKE allows the first device 42 and the second device 44 to authenticate themselves using a pre-shared secret, e.g., simply a cryptographic hash of a block of data using a shared cryptographic key. As described above, the third-party device that executes a successful man in the middle attack establishes shared cryptographic keys with the first device 42 and the second device 44. The third-party device may be able to create an appropriate pre-shared secret using those shared keys.

[0064] IKE also provides for the use of digital certificates and digital signatures for authentication purposes. This reduces the chance that the third-party device can pose as the first device 42 or second device 44. However, it may still be possible for the third-party device to obtain a fake digital certificate and provide an appropriate authentication.

[0065] Embodiments of the invention provide for the creation of Security Associations (both IKE SAs and SAs) that permit the use of Mutating Identifiers and perhaps the Black Content Protocol for key exchange and data encryption during an IPSec session (hereinafter referred to as Mutating IPSec). As described in the '402 patent, the use of Mutating Identifiers and Black Content Protocol decreases the potential of a man in the middle attack because the malicious third-party device cannot access the confidential information in the mutating identifiers stored on the first device 42 and second device 44 to obtain the appropriate cryptographic keys. FIG. 8 A depicts an exemplary system 140 that is configured to use Mutating IPSec. The system 140 includes three participants: the first device 42, the second device 44, and a key server 142, which corresponds to the authenticator device 28 (as shown in FIG. 1) described in the '402 Publication. The first device 42, second device 44, and key server 142 are connected to each other via two-way links 144, 146, and 148. The links 144, 146, and 128 can include all or part of one or more of computer networks such as the Internet.

[0066] Alternative embodiments may also include systems where either the first device 42 and second device 44, or both the first device 42 and second device 44, are secure gateways that serve as an entry point to separate electronic networks. Such embodiments will generally use the ESP protocol and Tunnel Mode for IPSec communications. For example, FIG. 8B depicts an alternative embodiment which shows a system 140A that includes a second device 44a which is a secure gateway that communicates with the first device 42 (which can be a personal computer, server, or other device that is capable of serving as a network endpoint). hi addition, FIG. 8C is an alternative embodiment which shows a system 140B in which both the first device 42b and the second device 44b are secure gateways.

[0067] Before a Mutating IPSec session is established between the first device 42 and the second device 44, each device should have at least one mutating ID stored on its memory modules. These mutating IDs are generated by the key server 110 and delivered to the first device 42 and the second device 44 by some secure means. The contents of these mutating IDs are described below. In addition, the first device 42 and the second device 44 may each have a credential that is known only to each of them and to the key server 44.

[0068] Mutating IPSec creates IKE_SAs and SAs that provide for the use of Mutating Identifiers and perhaps Black Content Protocol by modifying the key exchange information messages (KEi and KEr) that are sent during the IKE. These key exchange information messages (KEi and KEr) are modified so that they provide information to the first device 42 and the second device 44 which allow them to use Mutating Identifiers and perhaps the Black Content Protocol to communicate.

[0069] FIG. 9 is a schematic representation of a standard key exchange information message 150 as it is described in RFC 4306. The key exchange information message 150 includes: 1) a next payload field 151 which indicates that this is a key exchange information message, 2 ) a critical bit 152 (C) which tells the recipient what to do if it does not understand this message, 3) a reserved field 153 which is reserved for future use, 4) a payload length field 154 which indicates the length (in bytes) of the key exchange message 150, 5) a key exchange group number field 155, which identifies the Diffie-Hellman group in which the key exchange data was computed, 6) a second reserved field 156 which is reserved for future use, and 7) a key exchange data field 157 which contains the sender's Diffie-Hellman public value. The receiver of this key exchange information message 150 can use the Diffie- Hellman group number and the Diffie-Hellman public value, to compute cryptographic keys that are used to for IKE and IP Sec communications with the sender.

[0070] Embodiments of the present invention modify the key exchange message 150 so that the key exchange data field 157 contains a mutating key identifier (which is the sender's public identifier for the key server 142) for the sender and an optional key server definition (to be sent when more than one key server may be used by the sender), and the key exchange group number 155 contains a value (e.g.., -1 or 65537 as shown) which indicates that Mutating Identifiers and perhaps Black Content Protocol will be used for communication associated with this SA.

[0071] This modification to the IKE provides a mechanism for the first device 42 and the second device 44 to implement a protocol for exchanging cryptographic keys, using the Mutating Identifier Protocol and perhaps the Black Content Protocol, which may be used by these devices to encrypt IKE exchanges or an IP datagram payload. For example, the IKEJSA that is created as a result of the IKE_SA_INIT exchange, provides the first device 42 and the second device 44 with each other's mutating key identifier (i.e., their publicly known value for the key server 142) and an identifier for the appropriate key server 142, as this information was exchanged as part of the key exchange information messages 104c, 106d (KEi and KEr). Thereafter, the first device 42 and the second device 44 obtain a session key (K_Session) from the key server 142 in order to proceed with the IKE.

[0072] The session key (K_sessi_on) can be established using the methods described above in the section entitled Mutating Identifier Protocol. The first device 42 requests a session key from the key server 142 by first encrypting its credential for the key server 142 (First_cred) and the second device's 44 mutating key identifier (Secondi_d) using the encryption algorithm (E) which is supported by the selected key server 142 and the encryption key from the first device's 42 mutating ID (K_f1Rt). The first device 42 concatenates the random number (Nf_iπ5t) from its mutating ID to the encrypted data and transmits this request for a session key to the second device 44.

F — * S: Nfi_rstE(Kfi_rshFirst_credSecondi_d)

[0073] The second device 44 concatenates its credentials (Second_cm/) and the first device's 42 public identifier (Firsts) to the message that it received from the first device 42. The second device 44 encrypts that data with the encryption key from its mutating ID (K_second) and the encryption algorithm (E) that is supported by the selected key server 142. The second device 44 also concatenates the random number (N_second) from its mutating ID to the encrypted data and transmits the request for a session key to the key server 142.

S → KS:N_secondE(K_seCond, Second_credFirstidNfi_rstE(Kfi_rstFirst_credSecondid))

[0074] The key server 142 (KS) identifies that the message it received came from the second device 44 because it knows that the number S_econd is identified with the second device 44. The key server 142 decrypts the message using the encryption algorithm (E) and the encryption key K._second and verifies the second device's 44 credentials Second_ed. The key server 142 then decrypts the part of the message encrypted by the first device 42 using the encryption algorithm (E) and the encryption key Ky^. If the second device's 44 credentials Second_cred match the identifying number N_second and the identifier Second provided by the first device 42 and the first device's credentials First_cred match the identifying number Nf_list and the identifier Firstj_d provided by the second device 44, then the key server 142 verifies the request and generates a message for the first device 42 and the second device 44. The message for the first device 42 includes a new mutating ID which has a new identifying number Nf_irst' and a new encryption key Kfir_st', the client's credentials Firstc_red, and the session key Kse_ssi_on- The key server encrypts the message for the client 42 using the client's current secret key Kf_iret.

KS — > C: E(Kfl_rst Nfirst 'Kfirst FirSt_credK_Session)

The message for the second device 44 includes a new mutating ID which has a new identifying number N_seCond' and a new encryption key K_seCond', the server's credentials Second_cred, and the session key K_sessi_on- The key server 110 encrypts the message using the server's current secret key K_seCond and sends it to the second device 44.

KS → S: E(K_seCond,N_second K._second 'SeCOnd_CredK._Sessioti)

[0075] In a separate embodiment, the first device 42 and the second device 44 may choose to use the Black Content Protocol to obtain a session key from the key server 142. hi this embodiment, the mutating IDs on the first device 42 and the second device 44 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 first device 42 and the second device 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 first device 42, second device 44, and the key server 142 each send the same messages described above. However, the white data key (K_w) is used to encrypt the discoverable data (e.g., Firstj_d and Secondjd) and the black data key is used to encrypt the undiscoverable data (e.g., Firstc_red, Second_cred, Nfiist,N_second).

[0076] In still another embodiment, the key server 142 assigns each of the first device 42 and the second device 44 a large mutating ID having 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 first device 42 and the second device 44. For example, the first device 42 can use the information in these identifiers to request an encryption key from the key server 110. The first device 42 can then use that encryption key to encrypt and transmit data to the second device 44. The second device 44 uses the information in its large mutating ID to request a decryption key for the data from the key server 110. The second device 44 uses the decryption key to decrypt the encrypted data that it received from the first device 42. The first device 42 and the second device 44 may carry out this process each time they communicate with one another.

[0077] This requires that IPSec 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. [0078] In addition, upon the completion of the IKE, the first device 42 and the second device 44 have established an SA that will be used for future IPSec communications between them. However, before engaging in any IPSec communication (which will require the encryption of an IPdatagram payload) the first device 42 and the second device 44 may need to establish a session key for IPSec communication. This session key may be established using the same methods described above.

[0079] Various features and embodiments of the invention are set forth in the following claims.

Claims

CLAIMSWhat is claimed is:

1. A computer-based method of establishing secure communication between a first device and a second device, the method comprising: 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; transmitting a first message, including a first mutating key identifier, from the first device to the second device as part of the initial exchange of an Internet key exchange; transmitting a second message, including a second mutating key identifier, from the second device to the first device, establishing a first cryptographic method as part of the initial exchange of the Internet key exchange; providing a first session key to the first device and the second device from the key server; transmitting a third message, including self-authentication information for the first device, from the first device to the second device as part of the Internet key exchange; transmitting a fourth message, including self-authentication information for the second device, from the second device to the first device, establishing a second cryptographic method as part of the Internet key exchange; providing a second session key to the first device and the second device from the key server; and transmitting at least one datagram between the first device and the second device by encrypting the payload using the second cryptographic method and session key.

2. A computer-based method as claimed in claim 1, wherein the first message also includes the identity of the key server and the second message includes a confirmation of the identity of the key server.

3. A computer-based method as claimed in claim 1 , wherein the first message further includes a list of cryptographic methods supported by the first device and the second message selects one of the cryptographic methods from the list.

4. A computer-based method as claimed in claim 1, wherein the third message further includes a list of cryptographic methods supported by the first device and the fourth message selects one of the cryptographic methods from the list.

5. A computer-based method as claimed in claim 1, wherein the first cryptographic method and first session key are used to encrypt portions of the third message and the fourth message.

6. A first device configured to communicate with a key server and a second device, the first device comprising: a processor having a mutating identifier associated therewith, the mutating identifier provided by the key server, the processor configured to transmit a first message, including a first mutating key identifier, to the second device; receive a second message, including a second mutating key identifier, from the second device to establish a first cryptographic method; receive a first set of cryptographic keys from the key server, the first set of cryptographic keys including at least one cryptographic key; transmit a third message, including self-authentication information, to the second device; receive a fourth message, including self-authentication information, from the second device establishing a second cryptographic method; and receive a second set of cryptographic keys from the key server, including at least one cryptographic key.

7. A first device as claimed in claim 6, wherein the first cryptographic method and first set of cryptographic keys are used to encrypt portions of the third message and fourth message.

8. A first device as claimed in claim 6, wherein the second cryptographic method and second set of keys is used to encrypt and decrypt the payloads of datagrams that are transmitted between the first device and the second device.

9. A first device as claimed in claim 6, wherein the first message includes the identity of the key server and the second message confirms the identity of the key server.

10. A first device as claimed in claim 6, wherein the first message includes a list of cryptographic methods and the second message selects a cryptographic method from that list.

11. A first device as claimed in claim 6, wherein at least one of the first device and the second device is a secure gateway.

12. A second device configured to communicate with a key server and a first device, the second device comprising: a processor having a mutating identifier associated therewith, the mutating identifier provided by the key server, the processor configured to receive a first message, including a first mutating key identifier, from the first device; transmit a second message, including a second mutating key identifier, to the first device to establish a first cryptographic method; receive a first set of cryptographic keys from the key server, including at least one cryptographic key; receive a third message, including self-authentication information, from the first device; transmit a fourth message, including self-authentication information, to the first device establishing a second cryptographic method; and receive a second set of cryptographic keys from the key server, including at least one cryptographic key.

13. A second device as claimed in claim 12, wherein the first cryptographic method and first set of cryptographic keys are used to encrypt portions of the third message and fourth message.

14. A second device as claimed in claim 12, wherein the second cryptographic method and second set of keys is used to encrypt and decrypt the payloads of datagrams that are transmitted between the first device and the second device.

15. A second device as claimed in claim 12, wherein the first message includes the identity of the key server and the second message confirms the identity of the key server.

16. A second device as claimed in claim 12, wherein the third message includes a list of cryptographic methods and the fourth message selects a cryptographic method from that list.

17. A second device as claimed in claim 12, wherein at least one of the first device and the second device is a secure gateway.