Search Images Maps Play YouTube News Gmail Drive More »
Sign in
Screen reader users: click this link for accessible mode. Accessible mode has the same essential features but works better with your reader.

Patents

  1. Advanced Patent Search
Publication numberUS20050149732 A1
Publication typeApplication
Application numberUS 10/806,772
Publication dateJul 7, 2005
Filing dateMar 23, 2004
Priority dateJan 7, 2004
Also published asCN1761256A, US7546357, US7930374, US8145735, US20050149204, US20090254639, US20110196946
Publication number10806772, 806772, US 2005/0149732 A1, US 2005/149732 A1, US 20050149732 A1, US 20050149732A1, US 2005149732 A1, US 2005149732A1, US-A1-20050149732, US-A1-2005149732, US2005/0149732A1, US2005/149732A1, US20050149732 A1, US20050149732A1, US2005149732 A1, US2005149732A1
InventorsTrevor Freeman, Scott Manchester, Paul Mayfield, Brian Swander
Original AssigneeMicrosoft Corporation
Export CitationBiBTeX, EndNote, RefMan
External Links: USPTO, USPTO Assignment, Espacenet
Use of static Diffie-Hellman key with IPSec for authentication
US 20050149732 A1
Abstract
Embodiments of the invention authenticate devices and establish secure connections between devices using static Diffie-Hellman key pairs. A first device obtains in a trusted manner a static DH public key of a second device prior to negotiation. The second device negotiates a secure connection to the first device using a shared secret created from the static DH public key, which serves as both a claim on the second device's identity and an encryption key. The static DH public key can be used to establish subsequent secure, authenticated communications sessions.
Images(7)
Previous page
Next page
Claims(23)
1. A method for establishing a secure communications channel and authenticating a party, for use by an initiator in an Internet Security Protocol (IPSec) negotiation, comprising:
initiating an Internet Key Exchange (IKE) negotiation with a responder;
transmitting, to the responder, a public Diffie-Hellman (DH) key of the initiator;
receiving, from the responder, a public DH key of the responder;
transmitting, to the responder, a payload encrypted with a shared secret created from the public DH key of the responder and the private DH key corresponding to the public DH key of the initiator transmitted to the responder;
receiving, from the responder, a payload encrypted with the shared secret; and
decrypting the payload;
wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator.
2. The method of claim 1 wherein the public DH key of the responder is previously known to the initiator and is a claim on the identity of the responder.
3. The method of claim 2 wherein the responder has previously obtained the public DH key of the initiator from a portable media device.
4. The method of claim 1 wherein the public DH key of the initiator is previously known to the responder and is a claim on the identity of the initiator.
5. The method of claim 4 wherein the initiator has previously obtained the public DH key of the responder from a portable media device.
6. The method of claim 1 wherein the secure communications channel is a channel in a virtual private network (VPN).
7. The method of claim 6 wherein the VPN comprises a client and a server, and a public DH key of the VPN client is transmitted as a hint to the identity of the client.
8. A method for establishing a secure communications channel and authenticating a party, for use by a responder in an Internet Security Protocol (IPSec) negotiation, comprising:
receiving an Internet Key Exchange (IKE) negotiation request from an initiator;
transmitting, to the initiator, a public Diffie-Hellman (DH) key of the responder;
receiving, from the initiator, a public DH key of the initiator;
transmitting, to the initiator, a payload encrypted with a shared secret created from the public DH key of the initiator and the private DH key corresponding to the public DH key of the responder transmitted to the initiator;
receiving, from the initiator, a payload encrypted with the shared secret; and
decrypting the payload;
wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator.
9. The method of claim 8 wherein the public DH key of the responder is previously known to the initiator and is a claim on the identity of the responder.
10. The method of claim 9 wherein the responder has previously obtained the public DH key of the initiator from a portable media device.
11. The method of claim 8 wherein the public DH key of the initiator is previously known to the responder and is a claim on the identity of the initiator.
12. The method of claim 11 wherein the initiator has previously obtained the public DH key of the responder from a portable media device.
13. The method of claim 8 wherein the secure communications channel is a channel in a virtual private network (VPN).
14. The method of claim 13 wherein VPN comprises a client and a server, and a public DH key of the VPN client is received as a hint to the identity of the client.
15. A method of establishing, between an initiator and a responder, a secure communications channel following the Internet Security Protocol (IPSec), comprising using the Internet Key Exchange (IKE) protocol, wherein a static Diffie-Hellman (DH) key-pair is used by at least one of the initiator or the responder to establish confidentiality and authentication.
16. The method of claim 15 wherein the private DH key of the DH key-pair is used to create a claim of identity for the initiator or the responder.
17. The method of claim 15 wherein the secure communications channel is a channel in a virtual private network.
18. A system for establishing a secure communications channel between networked devices comprising:
a first networked device generating a Diffie-Hellman (DH) key pair;
a portable media device storing the DH key pair generated by the first networked device;
a second networked device reading the DH key pair from the portable media device; and
the second networked device using the DH key pair to ensure confidentiality and authenticity in securing a communications channel with another networked device, following the Internet Key Exchange (IKE) and Internet Security (IPSec) protocols.
19. The system of claim 18 wherein the secure communications channel is a channel in a virtual private network.
20. A computer-readable medium including computer-executable instructions facilitating establishing a secure communications channel and authenticating a party, for execution by an initiator in an Internet Security Protocol (IPSec) negotiation, said computer-executable instructions executing the steps of:
initiating an Internet Key Exchange (IKE) negotiation with a responder;
transmitting, to the responder, a public Diffie-Hellman (DH) key of the initiator;
receiving, from the responder, a public DH key of the responder;
transmitting, to the responder, a payload encrypted with a shared secret created from the public DH key of the responder and the private DH key corresponding to the public DH key of the initiator transmitted to the responder;
receiving, from the responder, a payload encrypted with the shared secret; and
decrypting the payload;
wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator.
21. The computer-readable medium of claim 20 wherein the public DH key of the responder is previously known to the initiator and is as a claim on the identity of the responder.
22. The computer-readable medium of claim 20 wherein the public DH key of the initiator is previously known to the responder and is a claim on the identity of the initiator.
23. The computer-readable medium of claim 20 wherein the secure communications channel is a channel in a virtual private network.
Description
    CROSS-REFERENCE TO RELATED APPLICATION
  • [0001]
    The present application claims the benefit of Abraham et al., U.S. Provisional Patent Application No. 60/534,795 entitled, “Configuring Network Settings Using Portable Media”, filed on Jan. 7, 2004, which is hereby incorporated by reference in its entirety.
  • FIELD OF THE INVENTION
  • [0002]
    This invention generally relates to the area of computer systems. More particularly, the present invention concerns methods for facilitating the use of a security protocol to protect network communications, and even more particularly to methods for negotiating security parameters and authenticating users interconnected to a network.
  • BACKGROUND OF THE INVENTION
  • [0003]
    Computer networks provide an efficient way to exchange information between two or more computers. Various types of computer networks are utilized including private networks, e.g., local area networks (LANs), and public networks, e.g., the Internet. Often, the information exchanged between computers is of a sensitive or confidential nature. For example, to purchase goods or services via the network, a user is required to enter payment information such as a credit card number. Similarly, users routinely transmit sensitive and confidential business information over networks.
  • [0004]
    Information is exchanged over networks according to a protocol, such as the Internet Protocol (IP). IP was designed to allow for an open exchange of information; however, standard IP was not designed to protect information from unauthorized access. Accordingly, standard IP does not prevent an unauthorized user from receiving, viewing, and even modifying information transmitted over a network. Standard IP lacks other features such as authentication of users and network devices.
  • [0005]
    To address the lack of security provided by standard IP, the Internet Engineering Task Force (IETF) has developed a set of protocols, referred to as the Internet Protocol Security (IPSec) suite. IPSec provides protocols that conform to standard IP, but that include security features lacking in standard IP. Specific examples of IPSec protocols include an authentication header (AH) protocol and encapsulating security protocol (ESP). The ESP protocol, documented mainly in IETF Request for Comments (RFC) 2406, is an authenticating and encrypting protocol that uses cryptographic mechanisms to provide integrity, source authentication, and confidentiality of data. The AH protocol, documented mainly in IETF RFC 2402, is an authentication protocol that uses a hash signature in the packet header to validate the integrity of the packet data and authenticity of the sender. RFCs 2406 and 2402 are hereby incorporated by reference in their entirety for all that they teach without exclusion of any parts thereof.
  • [0006]
    Prior to using the ESP, AH or similar protocols, a first computer and a second computer in communication over the network must negotiate a set of security parameters. The first computer begins the negotiation and is usually referred to as an initiator. The second computer is referred to as a responder because it is responding to a request from the initiator. The negotiated security parameters are stored in the initiator and the responder as one or more data structures referred to as a security association (SA). Parameters stored in the SA identify a security protocol (e.g. ESP or AH), a cryptographic algorithm used to secure communication (e.g. DES, 3DES), keys used with the cryptographic algorithm, a lifetime during which the keys are valid and the like.
  • [0007]
    One method of negotiating security parameters is by using a separate negotiation protocol. An example of a negotiation protocol is the internet key management and exchange protocol (IKE), also provided as part of IPSec and documented in IETF RFC 2409, hereby incorporated by reference in its entirety for all that it teaches without exclusion of any parts thereof. IKE is generally used to negotiate and provide authenticated cryptographic keys to be used in establishing a security association (SA) in a protected manner. As practiced today, IKE typically requires multiple messages and keys between an initiator and a responder. A first set of ephemeral Diffie-Hellman (DH) keys are exchanged to establish a confidential channel. Ephemeral keys are used a limited number of times or for a limited period of time before being discarded. A second set of information is then exchanged over the confidential channel to authenticate the parties and establish a symmetric cryptographic key. The ephemeral DH keys exchanged in existing methods are not used directly for authentication. The authentication in existing IKE implementations is mutual, in that each party authenticates the identity of the other.
  • [0008]
    The IPSec protocol is also sometimes used in Virtual Private Networks (VPNs). A VPN is a private, secured network that runs over a public, unsecured network (typically the Internet). A user connecting to a VPN typically uses a password that is used to gain access to the VPN. In some existing systems, the password is also used to compute a symmetric cryptographic key for encrypting subsequent communications between the user and the VPN. In other existing VPN systems, a group of users share a pre-determined symmetric key and password to allow authentication in IKE.
  • BRIEF SUMMARY OF THE INVENTION
  • [0009]
    Embodiments of the invention authenticate devices and establish secure connections between devices using static Diffie-Hellman key pairs. A first device obtains in a trusted manner a static DH public key of a second device prior to negotiation. The second device negotiates a secure connection to the first device using the static DH public key, which serves as both a claim on the second device's identity and an encryption key. Because the DH key is static, rather than ephemeral, the static DH public key can be used to establish subsequent secure, authenticated communications sessions. Furthermore, using the public DH directly for authentication allows one-way authentication, where only one party authenticates the identity of the other.
  • [0010]
    In one embodiment of the invention, a method is provided for establishing a secure communications channel and authenticating a party, for use by an initiator in an Internet Security Protocol (IPSec) negotiation, comprising initiating an Internet Key Exchange (IKE) negotiation with a responder, transmitting to the responder a public Diffie-Hellman (DH) key of the initiator, receiving from the responder a public DH key of the responder, transmitting to the responder a payload encrypted with a shared secret created from the public DH key of the responder and the private DH key corresponding to the public DH key of the initiator transmitted to the responder, receiving from the responder a payload encrypted with the shared secret, and decrypting the payload, wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator. In a further embodiment, the secure communications channel is a channel in a virtual private network.
  • [0011]
    In another embodiment, a method is provided for establishing a secure communications channel and authenticating a party, for use by a responder in an Internet Security Protocol (IPSec) negotiation, comprising receiving an Internet Key Exchange (IKE) negotiation request from an initiator, transmitting to the initiator a public Diffie-Hellman (DH) key of the responder, receiving from the initiator a public DH key of the initiator, transmitting to the initiator a payload encrypted with a shared secret created from the public DH key of the initiator and the private DH key corresponding to the public DH key of the responder transmitted to the initiator, receiving from the initiator a payload encrypted with the shared secret; and decrypting the payload, wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator. In a further embodiment, the secure communications channel is a channel in a virtual private network.
  • [0012]
    In another embodiment, a method is provided for establishing, between an initiator and a responder, a secure communications channel following the Internet Security Protocol (IPSec), comprising using the Internet Key Exchange (IKE) protocol, wherein a static Diffie-Hellman key-pair is used by at least one of the initiator or the responder to establish confidentiality and authentication. In one embodiment, the private DH key of the DH key-pair is used to create a claim of identity for the initiator or the responder. In a further embodiment, the secure communications channel is a channel in a virtual private network.
  • [0013]
    In still another embodiment, a system is provided for establishing a secure communications channel between networked devices comprising a first networked device generating a Diffie-Hellman (DH) key pair, a portable media device storing the DH key pair generated by the first networked device, a second networked device reading the DH key pair from the portable media device, and the second networked device using the DH key pair to ensure confidentiality and authenticity in securing a communications channel with another networked device, following the Internet Key Exchange (IKE) and Internet Security (IPSec) protocols. In a further embodiment, the secure communications channel is a channel in a virtual private network.
  • [0014]
    In yet another embodiment, a computer-readable medium including computer-executable instructions is provided for facilitating establishing a secure communications channel and authenticating a party, for execution by an initiator in an Internet Security Protocol (IPSec) negotiation, said computer-executable instructions executing the steps of initiating an Internet Key Exchange (IKE) negotiation with a responder, transmitting to the responder a public Diffie-Hellman (DH) key of the initiator, receiving from the responder a public DH key of the responder, transmitting to the responder a payload encrypted with a shared secret created from the public DH key of the responder and the private DH key corresponding to the public DH key of the initiator transmitted to the responder, receiving from the responder a payload encrypted with the shared secret, and decrypting the payload, wherein the public DH key of the responder is a claim on the identity of the responder and the shared secret is used to authenticate the identity of the responder, or the public DH key of the initiator is a claim on the identity of the initiator and the shared secret is used to authenticate the identity of the initiator. In a further embodiment, the secure communications channel is a channel in a virtual private network.
  • BRIEF DESCRIPTION OF THE DRAWINGS
  • [0015]
    While the appended claims set forth the features of the present invention with particularity, the invention and its advantages are best understood from the following detailed description taken in conjunction with the accompanying drawings, of which:
  • [0016]
    FIG. 1 is a simplified schematic illustrating an exemplary architecture of a network device for carrying out a method in accordance with an embodiment of the present invention;
  • [0017]
    FIG. 2 is an exemplary network environment including multiple network devices coupled to a network, as used in accordance with embodiments of the invention;
  • [0018]
    FIG. 3 is a simplified diagram of a packet payload format used to exchange payload data, as used in accordance with embodiments of the invention;
  • [0019]
    FIG. 4 is a diagram illustrating a method of two devices each using a single trusted DH key pair to authenticate the other device and establish a confidential channel, in accordance with an embodiment of the invention;
  • [0020]
    FIG. 5 is a flow diagram illustrating a method used by an initiator to authenticate and establish a secure communications channel with a responder using a single DH key pair, in accordance with an embodiment of the invention; and
  • [0021]
    FIG. 6 is a flow diagram illustrating a method used by a responder to authenticate and establish a secure communications channel with an initiator using a single DH key pair, in accordance with an embodiment of the invention.
  • DETAILED DESCRIPTION OF THE INVENTION
  • [0022]
    The methods and systems supporting the use of a static Diffie-Hellman key pair to authenticate devices during an IPSec protocol will now be described with respect to a number of embodiments; however, the methods and systems of the invention are not limited to the illustrated embodiments. Moreover, the skilled artisan will readily appreciate that the methods and systems described herein are merely exemplary and that variations can be made without departing from the spirit and scope of the invention.
  • [0023]
    The invention will be more completely understood through the following detailed description, which should be read in conjunction with the attached drawings. In this description, like numbers refer to similar elements within various embodiments of the present invention. The invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as procedures, being executed by a personal computer. Generally, procedures include program modules, routines, functions, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices. The term computer system may be used to refer to a system of computers such as may be found in a distributed computing environment.
  • [0024]
    FIG. 1 illustrates an example of a suitable computing system environment 100 on which the invention may be implemented. The computing system environment 100 is only one example of a suitable computing environment and is not intended to suggest any limitation as to the scope of use or functionality of the invention. Neither should the computing environment 100 be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment 100. Although one embodiment of the invention does include each component illustrated in the exemplary operating environment 100, another more typical embodiment of the invention excludes non-essential components, for example, input/output devices other than those required for network communications.
  • [0025]
    With reference to FIG. 1, an exemplary system for implementing the invention includes a general purpose computing device in the form of a computer 110. Components of the computer 110 may include, but are not limited to, a processing unit 120, a system memory 130, and a system bus 121 that couples various system components including the system memory to the processing unit 120. The system bus 121 may be any of several types of bus structures including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of bus architectures. By way of example, and not limitation, such architectures include Industry Standard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus also known as Mezzanine bus.
  • [0026]
    The computer 110 typically includes a variety of computer readable media. Computer readable media can be any available media that can be accessed by the computer 110 and includes both volatile and nonvolatile media, and removable and non-removable media. By way of example, and not limitation, computer readable media may comprise computer storage media and communication media. Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium which can be used to store the desired information and which can be accessed by the computer 110. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media. Combinations of the any of the above are also included within the scope of computer readable media.
  • [0027]
    The system memory 130 includes computer storage media in the form of volatile and/or nonvolatile memory such as read only memory (ROM) 131 and random access memory (RAM) 132. A basic input/output system 133 (BIOS), containing the basic routines that help to transfer information between elements within computer 110, such as during start-up, is typically stored in ROM 131. RAM 132 typically contains data and/or program modules that are immediately accessible to and/or presently being operated on by processing unit 120. By way of example, and not limitation, FIG. 1 illustrates operating system 134, application programs 135, other program modules 136 and program data 137.
  • [0028]
    The computer 110 may also include other removable/non-removable, volatile/nonvolatile computer storage media. By way of example only, FIG. 1 illustrates a hard disk drive 141 that reads from or writes to non-removable, nonvolatile magnetic media, a magnetic disk drive 151 that reads from or writes to a removable, nonvolatile magnetic disk 152, and an optical disk drive 155 that reads from or writes to a removable, nonvolatile optical disk 156 such as a CD ROM or other optical media. Other removable/non-removable, volatile/nonvolatile computer storage media that can be used in the exemplary operating environment include, but are not limited to, magnetic tape cassettes, flash memory cards, digital versatile disks, digital video tape, solid state RAM, solid state ROM, SmartCards, SecureDigital cards, SmartMedia cards, CompactFlash cards and the like. The hard disk drive 141 is typically connected to the system bus 121 through a non-removable memory interface such as interface 140, and magnetic disk drive 151 and optical disk drive 155 are typically connected to the system bus 121 by a removable memory interface, such as interface 150.
  • [0029]
    The drives and their associated computer storage media, discussed above and illustrated in FIG. 1, provide storage of computer readable instructions, data structures, program modules and other data for the computer 110. In FIG. 1, for example, hard disk drive 141 is illustrated as storing operating system 144, application programs 145, other program modules 146 and program data 147. Note that these components can either be the same as or different from operating system 134, application programs 135, other program modules 136, and program data 137. Operating system 144, application programs 145, other program modules 146, and program data 147 are given different numbers hereto illustrate that, at a minimum, they are different copies. A user may enter commands and information into the computer 110 through input devices such as a tablet, or electronic digitizer, 164, a microphone 163, a keyboard 162 and pointing device 161, commonly referred to as a mouse, trackball or touch pad. Other input devices (not shown) may include a joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 120 through a user input interface 160 that is coupled to the system bus, but may be connected by other interface and bus structures, such as a parallel port, game port or a universal serial bus (USB). A monitor 191 or other type of display device is also connected to the system bus 121 via an interface, such as a video interface 190. The monitor 191 may also be integrated with a touch-screen panel or the like. Note that the monitor and/or touch screen panel can be physically coupled to a housing in which the computing device 110 is incorporated, such as in a tablet-type personal computer. In addition, computers such as the computing device 110 may also include other peripheral output devices such as speakers 197 and printer 196, which may be connected through an output peripheral interface 194 or the like.
  • [0030]
    The computer 110 is operable in a networked environment using logical connections to one or more remote computers, such as a remote computer 180. The remote computer 180 may be a personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the computer 110, although only a memory storage device 181 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 171 and a wide area network (WAN) 173, but may also include other networks. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet. For example, in the present invention, the computer 110 may comprise the source machine from which data is being migrated, and the remote computer 180 may comprise the destination machine. Note however that source and destination machines need not be connected by a network or any other means, but instead, data may be migrated via any media capable of being written by the source platform and read by the destination platform or platforms.
  • [0031]
    When used in a LAN networking environment, the computer 110 is connected to the LAN 171 through a network interface or adapter 170. Alternatively, the computer 110 contains a wireless LAN network interface operating on, for example, the 802.11b protocol, allowing the computer 110 to connect to the LAN 171 without a physical connection. When used in a WAN networking environment, the computer 110 typically includes a modem 172 or other means for establishing communications over the WAN 173, such as the Internet. The modem 172, which may be internal or external, may be connected to the system bus 121 via the user input interface 160 or other appropriate mechanism. Alternatively, the computer 110 contains a wireless WAN network interface operating over, for example, the General Packet Radio Service (GPRS), allowing the computer 110 to connect to the WAN 173 without a physical connection. In a networked environment, program modules depicted relative to the computer 110, or portions thereof, may be stored in the remote memory storage device. By way of example, and not limitation, FIG. 1 illustrates remote application programs 185 as residing on memory device 181. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used. Additionally, variations of the computer 110 may be incorporated into other exemplary systems for implementing the invention, such as cellular phones, personal digital assistants, and the like.
  • [0032]
    FIG. 2 illustrates an exemplary network environment wherein the present invention is employed. Embodiments of the invention are directed to a method for authenticating and establishing a secure communications channel between devices through one or more networks using a static DH key pair. Embodiments are implemented as extensions to existing protocols, such as the Internet key exchange and management protocol (IKE). Alternatively, embodiments are implemented as separate proprietary protocols.
  • [0033]
    The environment includes a plurality of network devices 202, 204, 206 communicatively coupled to a network 208. The network 208 is any suitable type such as a local area network (LAN), wide area networks (WAN), intranet, the Internet, or any combination thereof. For the purpose of illustrating the invention, only a limited number of network devices are shown. However, it will be understood that many network devices may, in fact, be coupled to the network. Moreover, although the network devices are illustrated as coupled directly to the network 208, the network devices are alternatively coupled to the network 208 through a combination of servers, routers, proxies, gateways, network address translation devices, or the like.
  • [0034]
    The network device 202 communicates, i.e., exchanges information, with the network device 204 by sending packets of data according to a protocol such as the Internet Protocol (IP). The network device 202, referred to herein as the initiator, begins the exchange of information by sending a request to the network device 204, referred to herein as the responder. The network device 206 is a malicious user that attempts to gain unauthorized access to the information exchanged between the initiator 202 and the responder 204. The malicious user 206 also attempts to mount attacks on one or more of the initiator 202 and the responder 204 through, for example, a denial of service attack.
  • [0035]
    The initiator 202 includes a security policy 216 stored in security policy database. The security policy 216 is used by the initiator 202 to determine whether data transmitted to, or received from, another network device, such as the responder 204, needs to conform to a security protocol such as the Encapsulating Security Protocol (ESP) or Authentication Header (AH). The responder 204 includes its own security policy 220 stored in a security policy database that is used by the responder 204 to determine whether data transmitted to, or received from, another device, such as the initiator 202, needs to conform to a security protocol.
  • [0036]
    Security protocols such as AH and ESP protect the contents of data in an IP packet from the attacker 206. Before the security protocol is used to exchange data, the initiator 202 and the responder 204 must negotiate security parameters. The negotiated security parameters include an identification of the security protocol to be used (e.g. AH or ESP), an encryption algorithm that will be used to secure the data (e.g. DES or 3DES), keys used with the encryption algorithm to protect the data, life time that the keys will be valid and the like. The negotiated security parameters are stored in one or more data structures called a Security Association (SA).
  • [0037]
    Embodiments of the invention provide a method to exchange keys to authenticate identity and establish a confidential channel. The method is executed via a main mode 210 or an aggressive mode 212 by negotiation module 218 executing in the initiator 202 and negotiation module 222 executing in the responder 204. Each mode includes one or more pair of exchanges between the initiator 202 and the responder 204. Each exchange includes a first message sent from the initiator 202 to the responder 204 and a second message sent from the responder 204 to the initiator 202.
  • [0038]
    A main mode 210 or aggressive mode 212 is used to perform machine authentication, negotiate security parameters, and to provide a secure channel for subsequent communication under the IPSec protocol. Unlike existing systems, embodiments of the invention allow both one-way and mutual authentication. One-way machine authentication is used to prove the identity of one of, but not both, the initiator 202 and the responder 204. Mutual machine authentication is used to prove the identity of both the initiator 202 and the responder 204.
  • [0039]
    Keys are derived and refreshed with IPSec protocols such as ESP and AH. Typically, the keys used with AH and ESP to encrypt and decrypt data have a limited lifetime defined by the SA, referred to as life time of the key. Thus, it is necessary for the initiator 202 and responder 204 to periodically refresh keys used as part of the security protocol.
  • [0040]
    FIG. 3 illustrates an example of a packet 228, referred to herein as a message, used to exchange data between the initiator 202 and the responder 204. The packet or message 228 includes a header portion 230 and one or more payloads 232. The format illustrated in FIG. 3 generally conforms to the IKE protocol. It will be understood that the format described is by way of example, and not limitation, as any suitable format can be used to exchange data between the initiator 202 and the responder 204.
  • [0041]
    The header 230 includes an Initiator Cookie (I-Cookie) 236 and a Responder Cookie (R-Cookie) 238. The I-Cookie is a non-zero value assigned by the initiator 202 and the R-Cookie is a non-zero value assigned by the responder 204. It will be understood that the header is shown in simplified form and may include fields for additional data such as version data, flags, and a message length.
  • [0042]
    Each of the one or more payloads 232 includes a payload length field and a corresponding payload data field. The payload length field stores the size, e.g. in bytes, of the corresponding payload data. The payload data field stores data that varies depending on a payload type. The payload types included in the message depend upon the mode (e.g. main mode 210 or aggressive mode 212), state of the negotiation process, and security options employed by the initiator 202 and the responder 204. The different payload types and corresponding payload data are described in Table 1, below.
    TABLE 1
    Payload Type Payload Data
    HDR An ISAKMP header.
    HDR* An encrypted ISAKMP header.
    security association (SA) The security association includes either proposed or
    agreed upon security parameters.
    key exchange data (KE) Data for a key exchange according to known methods
    such as a Diffie-Hellman key exchange or elliptical curve.
    Main mode nonce (N) Pseudo random number sent for signing during a main mode
    exchange.
    Kerberos authentication Kerberos authentication data also referred to as
    data (SSPI) GSSAPI.
    Authentication data A calculated value that incorporates a secret key.
    (AUTH)
    Certificate (CERT) Includes data that establishes a user's credentials to
    another user such as a name, serial number, expiration
    date, and public key.
    Certificate Request Request for a network device to provide a certificate.
    (CERTreq)
    Identity payload (Id) Data that identifies a network device, such as an IP
    address, domain (DNS) name, or fully-qualified
    domain name (FQDN).
    Traffic selector (TS) Identifies transmitted or received messages subject to
    a security policy.
    Vendor Id (V-Id) Generic data field that includes data to be transmitted
    from a first network device to a second network
    device.
    Notify Generic data field that includes data to be transmitted
    from a first network device to a second network
    device.
  • [0043]
    The payload types described in Table I are identified herein with the subscript “i” to represent values associated with the initiator 202 and with the subscript “r” to represent values associated with the responder 204 where appropriate. For example, Ni identifies a main mode nonce generated by the initiator 202 and Nr identifies a main mode nonce generated by the responder 204.
  • [0044]
    Returning to FIG. 3, the message 228 may include a plurality of payloads and each payload has different payload data. The payload data is in the form of one of the payload types previously described herein. As shown, a first payload has a payload length 240 and corresponding first payload data 242; a second payload has a payload length 244 and corresponding second payload data 246; and a last payload has a last payload length 248 and corresponding last payload data 249.
  • [0045]
    The payloads are shown in simplified form and it will be understood that each payload may include additional information, such as data that identifies the payload types included therein.
  • [0046]
    FIG. 4 illustrates a method for conducting an authentication and security negotiation between the initiator 202 and the responder 204 according to an embodiment of the invention. As previously described, the negotiation is executed by the negotiation module 218 of the initiator 202 and the negotiation module 222 of the responder 204 in accordance with the respective security policies 216 and 220.
  • [0047]
    The method is performed in a main mode 210 or an aggressive mode 212. The main mode 210 and the aggressive mode 212 are completed through a plurality of messages exchanged between the initiator 202 and the responder 204. Messages 250, 252 and 256 are messages sent from the initiator 202 to the responder 204. Messages 251, 254 and 258 are messages sent from the responder 204 to the initiator 202.
  • [0048]
    As a precursor to performing the method, the initiator and responder obtain each other's public (but not private) Diffie-Hellman (DH) keys in a trusted manner, allowing for subsequent mutual authentication. Alternatively, only one party obtains public DH keys of the other party in a trusted manner, allowing for subsequent one-way authentication. Trust in a set of DH keys can come from another mechanism, such as an Out of Band configuration. Alternatively, trust in a set of DH keys can come via an exchange through a trusted hardware device, such as a portable media device. In this embodiment, a set of DH keys are generated by a first device and stored onto a portable media device such as a USB flash drive, Secure Digital card, SmartCard, or the like. When the portable media device is attached to a second device, the second device trusts that the DH keys originated from the first device. Trust in individual DH keys can come, for example, via local policy. Alternatively, devices may employ transitive trust, where a third party endorses trust in a public DH key. Each public DH key is generated along with a corresponding private DH key.
  • [0049]
    A typical use of DH keys includes the initiator 202 exchanging public DH keys with the responder 204. The initiator 202 creates a “shared secret” from the responder's 204 public key and its own private key. The responder 204 creates the shared secret using the initiator's 202 public key and its own private key. The mathematical properties of the Diffie-Hellman algorithm guarantee that the shared secret is identical for the initiator 202 and the responder 204. Although the shared secret is useful in establishing a secure connection, it is often computationally inefficient for continued use during a communications session. The initiator 202 therefore typically creates a symmetric key for use in a more efficient cryptographic protocol such as Triple-DES, encrypts the symmetric key using the shared secret, and sends the encrypted symmetric key to the responder 204. The responder 204 decrypts the symmetric key, which is then used for efficient encrypting and decrypting during the communications session.
  • [0050]
    The method used in the embodiment begins when the initiator 202 sends message 250 to the responder 204. The message 250 is an initiation request for a key exchange negotiation following the IKE protocol. The message 250 contains an ISAKMP header and a proposed SA negotiation payload. ISAKMP is a security association management protocol, and provides a framework for SA management. The responder 204 receives the request 250 and responds with an acknowledgement message 251 containing an ISAKMP header and an agreed-upon SA negotiation payload. The agreed-upon SA includes security parameters, selected from the proposed security parameters, to which the responder 204 agrees. If the responder does not agree to a set of the parameters in the proposed SA, the negotiation fails.
  • [0051]
    The initiator 202 sends message 252 to the responder 204. The message 252 has a plurality of payload types including an ISAKMP header, a nonce (Ni), and a key exchange payload (KE). The KE comprises a public DH key for the initiator 202. Because the responder 204 has previously obtained the initiator's 202 public DH key in a trusted manner, the KE acts as a claim for the initiator's 202 identity. The initiator 202 creates a shared secret from its private key and the responder's 204 public key.
  • [0052]
    The responder 204 receives the message 252 and in return sends the message 254 back to the initiator 202. The message 254 has a plurality of payload types including a ISAKMP header, a responder nonce (Nr) and key exchange data (KE). The KE comprises a public DH key for the responder 204. Because the initiator 202 has previously obtained the responder's 204 public DH key in a trusted manner, the KE acts as a claim for the responder's 204 identity. The responder 204 creates the shared secret from its private key and the initiator's public key. This shared secret is, by mathematics, identical to the shared secret produced by the initiator 202.
  • [0053]
    The initiator 202 receives the message 254 and, in return, sends the message 256 to the responder 204. The message 256 has a header (HDR*) and a plurality of payload types including an identification payload (IDii) and a hash payload (HASH_I). The HDR* header indicates the payload is encrypted using the shared secret.
  • [0054]
    The responder 204 receives the message 256 and decrypts the encrypted payload using the shared secret. Because only a holder of the private DH key can encrypt a message that is decrypted with the corresponding public DH key, and the responder 204 trusts that the public DH key previously sent belongs to the initiator 202, the responder 204 is convinced that it is in communication with the identity of initiator 202. The responder 204 replies with a message 258 to the initiator 202. The message 258 has a header (HDR*) and a plurality of payload types including an identification payload (IDir) and a hash payload (HASH_R). The HDR* header indicates the payload is encrypted using the shared secret.
  • [0055]
    The initiator 202 receives the message 258 and decrypts the encrypted payload using the shared secret. The initiator is thereby convinced of the identity of the responder 204.
  • [0056]
    In an alternative embodiment of the described method, one-way authentication is provided. In this embodiment, one device learns the public DH key of the second device in a trusted manner as described above, prior to beginning the method. The second device does not, however, know the public DH key of the first device. For the following example, the initiator 202 has learned the public DH key of the responder 204 in a trusted manner. The method proceeds as above, with the initiator 202 sending an initiation request message 250 to the responder 202. The responder 202 responds with a message 251.
  • [0057]
    The initiator then sends message 252 as above. However, because the responder 204 does not know the public DH key of the initiator 202, the KE payload in message 252 does not serve as an identity claim on the initiator 202. The initiator 202 thus remains anonymous to the responder 204.
  • [0058]
    The responder 204 responds to message 252 by sending message 254. The KE payload in message 254 contains the public DH key for the responder 204. Because the initiator 202 has previous knowledge of this public DH key, the key serves as an identity claim on the responder 204.
  • [0059]
    The initiator 202 receives the message 254 and, in return, sends the message 256 to the responder 204. The message 256 includes an HDR*, which indicates the payload is encrypted using the shared secret created from the responder's 204 public DH key and the initiator's private DH key.
  • [0060]
    The responder 204 receives the message 256 and decrypts the encrypted payload using the shared secret created from its private key and the initiator's 202 public key. Because the responder 204 does not know the identity of the owner of the DH keys used for this encryption, the responder is not convinced of the initiator's 202 identity. The responder 204 replies with a message 258 to the initiator 202. The message 258 includes an HDR* header indicating that the payload is encrypted using the shared secret.
  • [0061]
    The initiator 202 receives the message 258 and decrypts the encrypted payload using the shared secret. The initiator 202 is thereby convinced of the identity of the responder 204.
  • [0062]
    In an alternative example, the responder 204 has learned the public DH key of the initiator 202 in a trusted manner prior to beginning the method, and the method proceeds similarly as described above, with the responder 204 being convinced of the identity of the initiator 202.
  • [0063]
    An embodiment of the invention performs a variation of the method in an aggressive mode. In the aggressive mode, three exchanges take place. First, the initiator 202 passes to the responder 204 a message containing a ISAKMP header, a proposed SA negotiation payload, a KE comprising a public key for the initiator 202, a nonce (Ni), and an identification payload IDii. Second, the responder 204 replies with a ISAKMP header, an accepted SA negotiation payload, a KE comprising a public key for the responder 204, a nonce (Nr), and identification payload IDir, and a hash payload (HASH_R). The initiator 202 and responder 204 create a shared secret using the exchanged public keys and their own private keys. If either of the exchanged public keys had been previously obtained in a trusted manner, it serves as a claim to the owner's identity. The third exchange is when the initiator 202 replies with a header (HDR*) and a hash payload (HASH_I), encrypted using the shared secret.
  • [0064]
    Turning attention to FIG. 5, a method is described for use by an initiator to authenticate and establish a secure communications channel with a responder using a static DH key pair, in accordance with an embodiment of the invention. The method begins by initiating an IKE negotiation at step 502. The initiation preferably comprises sending a ISAKMP header and proposed SA negotiation payload. In response to the negotiation request, the initiator receives a reply at step 504. The initiator checks that the SA negotiation was successful at step 506. If the negotiation was not successful and a security association was not agreed upon, then the initiator starts another negotiation initiation at step 502. Alternatively, the negotiation process terminates. Otherwise, the initiator continues by sending a key exchange (KE) payload at step 508. The KE payload comprises the initiator's public DH key. In one embodiment, the responder has previously obtained the initiator's public DH key in a trusted manner. In such an embodiment, the KE sent at step 508 acts as a claim to the initiator's identity.
  • [0065]
    The initiator receives a reply at step 509. The reply contains a public DH key for the responder. In one embodiment, the initiator has previously obtained the responder's public DH key in a trusted manner. In such an embodiment, the KE sent at step 509 acts as a claim to the responder's identity.
  • [0066]
    The initiator sends an encrypted payload at step 510. The payload is encrypted using a shared secret created from the initiator's 202 private key and the public key received at step 509.
  • [0067]
    The initiator receives a message at step 512 comprising an encrypted payload, which the initiator decrypts using the shared secret. The initiator decides whether or not to trust the identity of the responder at step 514 by noting if the public key received at step 509 corresponds to a previously known, trusted identity. If so, the initiator trusts the responder's identity at step 516. Otherwise, the initiator does not trust the identity of the responder at step 518.
  • [0068]
    Turning attention to FIG. 6, a method is described for use by a responder to authenticate and establish a secure communications channel with an initiator using a static DH key pair, in accordance with an embodiment of the invention. The method begins by receiving an IKE negotiation at step 602. The initiation preferably comprises receiving a ISAKMP header and proposed SA negotiation payload. In response to the negotiation request, the responder sends a reply at step 604 preferably comprising a ISAKMP header and an accepted SA negotiation payload.
  • [0069]
    The responder receives a key exchange (KE) payload at step 608. The payload contains a public DH key for the initiator. In one embodiment, the responder has previously obtained the initiator's public DH key in a trusted manner. In such an embodiment, the KE sent at step 608 acts as a claim to the initiator's identity.
  • [0070]
    The responder continues by sending a key exchange (KE) payload at step 609. The KE payload comprises the responder's public DH key. In one embodiment, the initiator has previously obtained the responder's public DH key in a trusted manner. In such an embodiment, the KE sent at step 609 acts as a claim to the responder's identity.
  • [0071]
    The responder receives a message at step 610 comprising an encrypted payload, which the responder decrypts using a shared secret created from the responder's 204 private key and the public DH key received at step 608.
  • [0072]
    The responder sends an encrypted payload at step 612. The payload is encrypted using the shared secret.
  • [0073]
    The responder decides whether or not to trust the identity of the initiator at step 614 by noting if the public key received at step 610 corresponds to a previously known, trusted identity. If so, the responder trusts the initiator's identity at step 616. Otherwise, the responder does not trust the identity of the initiator at step 618.
  • [0074]
    The above-described methods are further applicable in a Virtual Private Network setting. Using a static DH key in the manner described above, a device connects and is authenticated to a VPN via the IKE protocol. This is used to establish a secure channel that follows the IPSec protocol. Typically, in existing VPNs, the client and server use a shared key derived from a hash of the client's user-password. Because the identity of the client is encrypted, existing VPN servers are limited by a conundrum: they need to know the identity of the client in order to use the correct shared key for decryption.
  • [0075]
    In accordance with an embodiment of the invention, a VPN server (responder) first obtains the public DH key of a client (initiator) in a trusted manner, prior to beginning a negotiation. To begin a negotiation, a client sends his public DH key to the server. The public DH key acts as a hint to the user's identity. Using this hint, the server finds the corresponding shared key for the user, and performs pre-shared key authentication with the client using the shared key.
  • [0076]
    In view of the many possible embodiments to which the principles of the present invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. For example, those of skill in the art will recognize that the illustrated embodiments can be modified in arrangement and detail without departing from the spirit of the invention. Although the invention is described in terms of software modules or components, those skilled in the art will recognize that such may be equivalently replaced by hardware components. Devices embodying the invention can include, for example, computers, personal digital assistants (PDAs), portable media devices (USB flash drives, Smartcards, etc.), and the like. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
Patent Citations
Cited PatentFiling datePublication dateApplicantTitle
US5930362 *Oct 9, 1996Jul 27, 1999At&T Wireless Services IncGeneration of encryption key
US5933504 *May 17, 1996Aug 3, 1999Certicom Corp.Strengthened public key protocol
US6052720 *May 14, 1998Apr 18, 2000Sun Microsystems, Inc.Generic schema for storing configuration information on a server computer
US6078667 *Oct 10, 1996Jun 20, 2000Certicom Corp.Generating unique and unpredictable values
US6148354 *Apr 5, 1999Nov 14, 2000M-Systems Flash Disk Pioneers Ltd.Architecture for a universal serial bus-based PC flash disk
US6178507 *Feb 2, 1998Jan 23, 2001Certicom Corp.Data card verification system
US6195433 *May 8, 1998Feb 27, 2001Certicom Corp.Private key validity and validation
US6449642 *Sep 15, 1998Sep 10, 2002Microsoft CorporationMethod and system for integrating a client computer into a computer network
US6526264 *Oct 29, 2001Feb 25, 2003Cognio, Inc.Wideband multi-protocol wireless radio transceiver system
US6563928 *Apr 1, 1999May 13, 2003Certicom Corp.Strengthened public key protocol
US6654841 *Jul 16, 2001Nov 25, 2003Power Quotient International Company, Inc.USB interface flash memory card reader with a built-in flash memory
US6687492 *Jun 19, 2002Feb 3, 2004Cognio, Inc.System and method for antenna diversity using joint maximal ratio combining
US6693651 *Feb 7, 2001Feb 17, 2004International Business Machines CorporationCustomer self service iconic interface for resource search results display and selection
US6700450 *Nov 13, 2002Mar 2, 2004Cognio, Inc.Voltage-controlled oscillator with an automatic amplitude control circuit
US6714605 *Sep 18, 2002Mar 30, 2004Cognio, Inc.System and method for real-time spectrum analysis in a communication device
US6728517 *Oct 11, 2002Apr 27, 2004Cognio, Inc.Multiple-input multiple-output radio transceiver
US6785520 *Jun 19, 2002Aug 31, 2004Cognio, Inc.System and method for antenna diversity using equal power joint maximal ratio combining
US6850735 *Sep 18, 2002Feb 1, 2005Cognio, Inc.System and method for signal classiciation of signals in a frequency band
US6907532 *Mar 2, 2001Jun 14, 2005Telefonaktiebolaget Lm Ericsson (Publ)Communication node, communication network and method of recovering from a temporary failure of a node
US7058180 *Jul 29, 2002Jun 6, 2006Swisscom Mobile AgSingle sign-on process
US7130425 *Jul 6, 2005Oct 31, 2006Ati International SrlMethod and apparatus for providing a bus-encrypted copy protection key to an unsecured bus
US7181012 *Sep 7, 2001Feb 20, 2007Telefonaktiebolaget Lm Ericsson (Publ)Secured map messages for telecommunications networks
US7181542 *Mar 22, 2001Feb 20, 2007Corente, Inc.Method and system for managing and configuring virtual private networks
US7181620 *Nov 9, 2001Feb 20, 2007Cisco Technology, Inc.Method and apparatus providing secure initialization of network devices using a cryptographic key distribution approach
US7188365 *Apr 4, 2002Mar 6, 2007At&T Corp.Method and system for securely scanning network traffic
US7269730 *Apr 18, 2002Sep 11, 2007Nokia CorporationMethod and apparatus for providing peer authentication for an internet key exchange
US20010014153 *Apr 24, 2001Aug 16, 2001Johnson Donald B.Key validation scheme
US20020090085 *Dec 26, 2001Jul 11, 2002Vanstone Scott A.Method of public key generation
US20020152380 *Apr 12, 2001Oct 17, 2002Microsoft CorporationMethods and systems for unilateral authentication of messages
US20020152384 *Nov 13, 2001Oct 17, 2002Microsoft CorporationMethods and systems for unilateral authentication of messages
US20030101247 *Nov 7, 2001May 29, 2003Microsoft CorporationMethod and system for configuring a computer for real-time communication
US20030225971 *May 28, 2003Dec 4, 2003Yuji OishiUSB storage device and program
US20040002943 *Jun 28, 2002Jan 1, 2004Merrill John Wickens LambSystems and methods for application delivery and configuration management of mobile devices
US20040010429 *Jul 12, 2002Jan 15, 2004Microsoft CorporationDeployment of configuration information
US20040024875 *Jul 30, 2002Feb 5, 2004Microsoft CorporationSchema-based services for identity-based access to device data
US20040038592 *Aug 21, 2002Feb 26, 2004Fu-I YangUSB flash drive
Referenced by
Citing PatentFiling datePublication dateApplicantTitle
US7574603Nov 14, 2003Aug 11, 2009Microsoft CorporationMethod of negotiating security parameters and authenticating users interconnected to a network
US7675867Mar 9, 2010Owl Computing Technologies, Inc.One-way data transfer system with built-in data verification mechanism
US7774837Aug 10, 2010Cipheroptics, Inc.Securing network traffic by distributing policies in a hierarchy over secure tunnels
US7818571Feb 9, 2007Oct 19, 2010Microsoft CorporationSecuring wireless communications between devices
US7822982 *Oct 26, 2010Hewlett-Packard Development Company, L.P.Method and apparatus for automatic and secure distribution of a symmetric key security credential in a utility computing environment
US7864762Feb 14, 2007Jan 4, 2011Cipheroptics, Inc.Ethernet encryption over resilient virtual private LAN services
US7895648 *Feb 22, 2011Cisco Technology, Inc.Reliably continuing a secure connection when the address of a machine at one end of the connection changes
US7941843 *Jan 11, 2005May 10, 2011Panasonic CorporationMobile wireless communication system, mobile wireless terminal apparatus, virtual private network relay apparatus and connection authentication server
US8046820Oct 25, 2011Certes Networks, Inc.Transporting keys between security protocols
US8082574Dec 20, 2011Certes Networks, Inc.Enforcing security groups in network of data processors
US8104082Jan 24, 2012Certes Networks, Inc.Virtual security interface
US8126896 *Nov 3, 2008Feb 28, 2012Canon Kabushiki KaishaInformation processing apparatus, control method therefor, and storage medium
US8145735Mar 27, 2012Microsoft CorporationConfiguring network settings using portable storage media
US8275989Jul 9, 2009Sep 25, 2012Microsoft CorporationMethod of negotiating security parameters and authenticating users interconnected to a network
US8281038Jul 15, 2009Oct 2, 2012Fujitsu LimitedThin client terminal, operation program and method thereof, and thin client system
US8284943Oct 9, 2012Certes Networks, Inc.IP encryption over resilient BGP/MPLS IP VPN
US8327437Dec 4, 2012Certes Networks, Inc.Securing network traffic by distributing policies in a hierarchy over secure tunnels
US8379638Feb 19, 2013Certes Networks, Inc.Security encapsulation of ethernet frames
US8607301Sep 27, 2006Dec 10, 2013Certes Networks, Inc.Deploying group VPNS and security groups over an end-to-end enterprise network
US8612452Jan 24, 2012Dec 17, 2013Canon Kabushiki KaishaInformation processing apparatus, control method therefor, and storage medium
US8732453Jul 14, 2011May 20, 2014Owl Computing Technologies, Inc.Secure acknowledgment device for one-way data transfer system
US8793780Apr 11, 2011Jul 29, 2014Blackberry LimitedMitigation of application-level distributed denial-of-service attacks
US20050108531 *Nov 14, 2003May 19, 2005Microsoft CorporationMethod of negotiating security parameters and authenticating users interconnected to a network
US20050251589 *May 4, 2004Nov 10, 2005Jung-Chung WangMethod of authenticating universal serail bus on-the-go device
US20060285693 *Jun 16, 2005Dec 21, 2006Amit RaikarMethod and apparatus for automatic and secure distribution of a symmetric key security credential in a utility computing environment
US20070130069 *Mar 3, 2006Jun 7, 2007Microsoft CorporationEncapsulating Address Components
US20070214502 *Jan 30, 2007Sep 13, 2007Mcalister Donald KTechnique for processing data packets in a communication network
US20080016550 *May 25, 2007Jan 17, 2008Mcalister Donald KSecuring network traffic by distributing policies in a hierarchy over secure tunnels
US20080040775 *Jul 23, 2007Feb 14, 2008Hoff Brandon LEnforcing security groups in network of data processors
US20080072033 *Sep 19, 2006Mar 20, 2008Mcalister DonaldRe-encrypting policy enforcement point
US20080072281 *Sep 11, 2007Mar 20, 2008Willis Ronald BEnterprise data protection management for providing secure communication in a network
US20080075073 *Sep 25, 2006Mar 27, 2008Swartz Troy ASecurity encapsulation of ethernet frames
US20080075088 *Jan 22, 2007Mar 27, 2008Cipheroptics, Inc.IP encryption over resilient BGP/MPLS IP VPN
US20080104692 *Sep 29, 2006May 1, 2008Mcalister DonaldVirtual security interface
US20080104693 *Sep 29, 2006May 1, 2008Mcalister DonaldTransporting keys between security protocols
US20080127327 *Sep 27, 2006May 29, 2008Serge-Paul CarrascoDeploying group VPNS and security groups over an end-to-end enterprise network
US20080162922 *Dec 27, 2006Jul 3, 2008Swartz Troy AFragmenting security encapsulated ethernet frames
US20080192739 *Feb 14, 2007Aug 14, 2008Serge-Paul CarrascoEthernet encryption over resilient virtual private LAN services
US20080195863 *Feb 9, 2007Aug 14, 2008Microsoft CorporationSecuring wireless communications between devices
US20080222693 *Aug 1, 2007Sep 11, 2008Cipheroptics, Inc.Multiple security groups with common keys on distributed networks
US20080232382 *Jan 11, 2005Sep 25, 2008Matsushita Electric Industrial Co., Ltd.Mobile Wireless Communication System, Mobile Wireless Terminal Apparatus, Virtual Private Network Relay Apparatus and Connection Authentication Server
US20090034738 *Jul 31, 2007Feb 5, 2009Charles Rodney StarrettMethod and apparatus for securing layer 2 networks
US20090089593 *Sep 26, 2008Apr 2, 2009Sony CorporationRecording system, information processing apparatus, storage apparatus, recording method, and program
US20090119318 *Nov 3, 2008May 7, 2009Canon Kabushiki KaishaInformation processing apparatus, control method therefor, and storage medium
US20090240942 *Mar 20, 2008Sep 24, 2009Canon Kabushiki KaishaLong term key establishment for embedded devices
US20090276524 *Nov 5, 2009Fujitsu LimitedThin client terminal, operation program and method thereof, and thin client system
US20090276828 *Nov 5, 2009Microsoft CorporationMethod of negotiating security parameters and authenticating users interconnected to a network
US20110013776 *Jan 20, 2011Cipheroptics, Inc.Securing Network Traffic by Distributing Policies in a Hierarchy Over Secure Tunnels
US20110196946 *Aug 11, 2011Microsoft CorporationConfiguring network settings using portable storage media
US20120023325 *Aug 25, 2010Jan 26, 2012Gemtek Technology Co., Ltd.Virtual private network system and network device thereof
US20150095649 *Sep 30, 2013Apr 2, 2015Unisys CorporationCommunity of interest-based secured communications over ipsec
US20150113277 *Oct 31, 2013Apr 23, 2015Aruba Networks, Inc.Provisioning Devices For Secure Wireless Local Area Networks
WO2007124671A1 *Apr 17, 2007Nov 8, 2007Huawei Technologies Co., Ltd.A method, device and system of negotiating the encrypting algorithm between the user equipment and the network
WO2009026771A1 *Sep 5, 2007Mar 5, 2009Guan, HaiyingThe method for negotiating the key, encrypting and decrypting the information, signing and authenticating the information
WO2015065189A1 *Oct 31, 2014May 7, 2015Ubiqu B.V.Method for setting up, via an intermediate entity, a secure session between a first and a second entity, and corresponding entities and computer program products
Classifications
U.S. Classification713/171
International ClassificationH04L29/06, H04L29/08, H04L12/28, H04L12/24, G05B15/00, H04L9/00, H04L12/56
Cooperative ClassificationH04W12/04, H04L67/02, H04L67/303, H04L69/329, H04L63/20, H04W48/16, H04W12/02, H04L63/0853, H04W12/06, H04L63/0442, H04L63/062, H04L63/164, H04L63/0272, H04L41/0806, H04W76/02, H04L41/0879, H04L29/06, H04L63/061, H04L63/0435, H04L41/0843, H04W28/18, H04W48/08
European ClassificationH04L41/08A4A, H04L63/06A, H04L29/06, H04L63/04B1, H04W12/02, H04W28/18, H04L63/16C, H04L63/04B2, H04L63/06B, H04L29/08N29T, H04W12/06, H04L29/08N1, H04L41/08A1
Legal Events
DateCodeEventDescription
Aug 25, 2004ASAssignment
Owner name: MICROSOFT CORPORATION, WASHINGTON
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:FREEMAN, TREVOR W.;MANCHESTER, SCOTT;MAYFIELD, PAUL G.;AND OTHERS;REEL/FRAME:015030/0678;SIGNING DATES FROM 20040804 TO 20040812
Jul 28, 2014ASAssignment
Owner name: ROVI CORPORATION, CALIFORNIA
Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:033429/0314
Effective date: 20140708
Dec 2, 2014ASAssignment
Owner name: ROVI TECHNOLOGIES CORPORATION, CALIFORNIA
Free format text: CORRECTIVE ASSIGNMENT TO CORRECT THE ASSIGNEE NAME TO READ ROVI TECHNOLOGIES CORPORATION PREVIOUSLYRECORDED ON REEL 033429 FRAME 0314. ASSIGNOR(S) HEREBY CONFIRMS THE CORRECTION TO READ ROVI TECHNOLOGIES CORPORATION;ASSIGNOR:MICROSOFT CORPORATION;REEL/FRAME:034503/0252
Effective date: 20141027