WO2011139440A2 - Fonctionnalité de cryptage à couplage lâche pour systèmes d'exploitation - Google Patents

Fonctionnalité de cryptage à couplage lâche pour systèmes d'exploitation Download PDF

Info

Publication number
WO2011139440A2
WO2011139440A2 PCT/US2011/030742 US2011030742W WO2011139440A2 WO 2011139440 A2 WO2011139440 A2 WO 2011139440A2 US 2011030742 W US2011030742 W US 2011030742W WO 2011139440 A2 WO2011139440 A2 WO 2011139440A2
Authority
WO
WIPO (PCT)
Prior art keywords
computing device
data packet
encryption
encryption information
operating system
Prior art date
Application number
PCT/US2011/030742
Other languages
English (en)
Other versions
WO2011139440A3 (fr
Inventor
Shaun Jaikarran Bharrat
Damascene M. Joachimpillai
Aby Kuriakose
Vivian Lu
Xiang Yu
Original Assignee
Sonus Networks, Inc.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US12/770,476 external-priority patent/US20110271097A1/en
Priority claimed from US12/770,473 external-priority patent/US20110271096A1/en
Application filed by Sonus Networks, Inc. filed Critical Sonus Networks, Inc.
Publication of WO2011139440A2 publication Critical patent/WO2011139440A2/fr
Publication of WO2011139440A3 publication Critical patent/WO2011139440A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/16—Implementing security features at a particular protocol layer
    • H04L63/164—Implementing security features at a particular protocol layer at the network layer
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281—Proxies
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/06—Network architectures or network communication protocols for network security for supporting key management in a packet data network

Definitions

  • the invention relates generally to computer-based methods and apparatuses, including computer program products, for loosely-coupled encryption functionality for operating systems.
  • IPsec Internet Protocol Security
  • IETF Internet Engineering Task Force
  • RRCs Requests for Comments
  • IPsec can authenticate and encrypt each IP packet of a data stream transmitted from a host IP node to a remote IP node.
  • IPsec can authenticate and encrypt each IP packet of a data stream transmitted from a host IP node to a remote IP node.
  • IPsec can authenticate and encrypt each IP packet of a data stream transmitted from a host IP node to a remote IP node.
  • IPsec Internet Engineering Task Force
  • On the software side most off-the-shelf operating systems provide support for the negotiation of IPsec associations and/or the encryption/decryption of the data stream on those associations.
  • On the hardware side there are boards and processors that can perform the encrypt/decrypt at enormous throughput.
  • an operating system (OS) coupled with any of several encrypt/decrypt accelerator boards can serve as a high-performance IPsec solution
  • the Linux OS provides a rich implementation of IPsec through the XFRM framework that includes a Security-Association-Database (SAD), a Security-Policy-Database (SPD), and serveral encryption algorithms.
  • SAD contains security associations (SAs), which are sets of security information that describe a particular kind of secure connection between one device and another.
  • SAs security associations
  • the SPD stores security policies, which are rules programmed into the IPsec implementation that describe how to process different data packets received by the device. For example, security policies are used to decide if a particular data packet needs to be processed by IPsec or not, and if so, the security policies provide general guidelines for how the IPsec processing is done.
  • the Linux IPsec implementation also includes a scatter/gather type application programmer interface (API) for interfacing with either user-provided software encryption/decryption modules or external hardware for encryption/decryption assist.
  • API application programmer interface
  • the set of communications protocols used for the Internet and other similar networks can be generalized into the IP protocol suite layers, which include: the Application Layer (e.g., HTTP), the Transport Layer (e.g., TCP, UDP), the Internet Layer (e.g., IP), the Link Layer (e.g, Ethernet), and the Physical Layer (e.g., IEEE 802.3u).
  • the XFRM framework logically sits as a layer of functionality between the Internet Layer and the Link Layer drivers.
  • the XFRM framework provides automatic checking of input and output data packets against the SPD and the SAD, callouts through a kernel/user interface to a key management application to request negotiation of SA information, support for several user-space key management applications (e.g., including Pluto, Isakmpd, and Racoon from the OpenSwan, OpenBSD, and Kame projects, respectively), APIs to user-definable encryption software or hardware (e.g., an encryption module), and implementations of numerous encryption protocols (e.g., Triple Data Encryption Standard (3DES), Advanced Encryption Standard (AES), Blowfish, Twofish, and others).
  • 3DES Triple Data Encryption Standard
  • AES Advanced Encryption Standard
  • Blowfish Twofish
  • the flow between the operating system and the encryption module can be thought off as a sidebar when the packet is flowing down the IP protocol layers (on output) or up the IP protocol layers (on input).
  • the operating system determines the SA (e.g., locates the SA in the SAD or negotiates a SA for a first packet for a connection), and the relevant keying information is determined, the operating system transmits the packet (e.g., as a list of memory buffers) and the keying information to the encryption module (e.g., an encrypt API routine).
  • the encryption module completes encryption, the operating system collects the encrypted packet (as a list of memory buffers) and continues the output processing (e.g., processing the encrypted packet through the remaining IP layers).
  • the XFRM framework supports both a transport mode and a tunnel mode for IPsec.
  • transport mode the original IP source and destination addresses are unchanged by the transform, and just the IP contents are encrypted.
  • tunnel mode the original packet, including the IP header, is encapsulated in another IP packet with its own IP header. After the encapsulation by the XFRM layer, the packet goes through the Internet Layer again (e.g., the router layer).
  • the central processing unit (CPU) that is hosting the operating system kernel can get bogged down since the encryption/decryption is very computing intensive. It is often desirable in such systems to have an offloaded encryption module to perform the encryption/decryption.
  • these encryption/decryption functions are typically only available on specialized network processor hardware which are not in the kernel's packet processing path. Therefore, using such network processor hardware often requires modifying the kernel (e.g., to insert an asynchronous processing method or find other alternate methods to use these network processors).
  • a tightly-coupled design is, for example, a design where the external encryption hardware (e.g., a network processor) is a co-processor to the main processor, such that the main processor can easily transmit a packet to the external encryption hardware and then subsequently receive the processed (e.g., encrypted/decrypted) packet back to continue processing the packet.
  • the external encryption hardware e.g., a network processor
  • the main processor can easily transmit a packet to the external encryption hardware and then subsequently receive the processed (e.g., encrypted/decrypted) packet back to continue processing the packet.
  • IP contents and/or IP header of the packet are encrypted by the encryption module (in either a synchronous or asynchonous manner).
  • the operating system then performs additional Link Layer processing to the encrypted packet and only then does the OS forward the encrypted packet (from the kernel driver) to the network.
  • BITW bump- in-the-wire
  • the BITW method can be a useful approach when, for example, the network stack cannot be modified or when the hardware capable of the encrypt/decrypt is not directly coupled to the main processor but rather is located at a second processor that is in the path between the main processor and the network (i.e., loosely- coupled).
  • IPsec for example, the second computing device can perform all the encryption processing including the SAD/SPD lookup, the encrypt, and then the link processing.
  • offloading all encryption functionality e.g., IPsec
  • an encryption module can be executed by a second computing device (e.g., encryption hardware) that is loosely-coupled to the operating system (e.g., is merely in the "path" between the first computing device and the network).
  • a second computing device e.g., encryption hardware
  • the path that crosses the boundary between the first computing device and the second computing device is often inefficient and/or unidirectional. Therefore, the operating system cannot use the loosely-coupled encryption module to perform the encryption since once the packet leaves the operating system, the data packet cannot be efficiently returned to the operating system.
  • the operating system can be configured to process the data packet through the IP layers to completion, and then "hand off the packet to a second computing device which then directly performs both the encryption and link processing, and sends the packet onto the network.
  • this does not utilize the rich functionality of the operating system's built in encryption features. It is desirable to directly use the encryption functionality of the operating system on the first computing device to perform everything but the encryption or decryption, and for the second computing device to perform the encryption, decryption and link-layer processing (with a single handoff of packets from the first computing device to the second computing device).
  • the invention features an encryption apparatus including a first computing device in communication with a second computing device.
  • the first computing device includes an operating system configured to process a data packet through one or more internet protocol stack layers to generate a processed data packet to be transmitted to a remote computer.
  • the operating system is configured to determine encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the operating system is configured to execute a bypass encryption routine to generate an unencrypted data packet based on the processed data packet.
  • the bypass encryption routine does not encrypt the processed data packet.
  • the operating system is configured to transmit the unencrypted data packet to the second computing device.
  • the first computing device includes a negotiation module in communication with the operating system and the second computing device configured to transmit a message including data indicative of the encryption information to the second computing device.
  • the operating system is unaware of a security nature of the transmission.
  • the second computing device includes an encryption module configured to encrypt the unencrypted data packet based on the message transmitted from the first computing device to generate an encrypted data packet.
  • the invention features a computerized encryption method including processing, by a first computing device, a data packet through one or more internet protocol stack layers to generate a processed data packet to be transmitted to a remote computer.
  • the method includes determining, by the first computing device, encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the method includes transmitting, by the first computing device, a message including data indicative of the encryption information to a second computing device.
  • An operating system being executed by the first computing device is unaware of a security nature of the transmission.
  • the method includes executing, by the first computing device, a bypass encryption routine to generate a unencrypted data packet. The bypass encryption routine does not encrypt the processed data packet.
  • the method includes transmitting, by the first computing device, the unencrypted data packet to the second computing device.
  • the method includes encrypting, by the second computing device, the unencrypted data packet based on the message transmitted from the first computing device to generate an encrypted data packet.
  • the invention features a computerized decryption method executed by a decryption apparatus including a first computing device and a second computing device.
  • the method includes receiving, by the second computing device, an encrypted data packet from a remote computer to the first computing device.
  • the method includes determining, by the second computing device, encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the method includes decrypting, by the second computing device, the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the method includes transmitting, by the second computing device, the unencrypted data packet to the first computing device.
  • the method includes executing, by the first computing device, a bypass decryption routine to generate a processed data packet.
  • the bypass decryption routine does not modify the unencrypted data packet.
  • the method includes processing, by the first computing device, the processed data packet through one or more internet protocol stack layers to generate a data packet.
  • the invention features a decryption apparatus including a first computing device in communication with a second computing device.
  • the second computing device is configured to receive an encrypted data packet from a remote computer to a first computing device.
  • the second computing device is configured to determine encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the second computing device is configured to decrypt the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the second computing device is configured to transmit the unencrypted data packet to the first computing device.
  • the first computing device includes an operating system configured to execute a bypass decryption routine to generate a processed data packet.
  • the bypass decryption routine does not modify the unencrypted data packet.
  • the first computing device is configured to process the processed data packet through one or more internet protocol stack layers to generate a data packet.
  • the invention features an encryption apparatus.
  • the encryption apparatus includes a first computing device in communication with a second computing device.
  • the first computing device includes an operating system configured to processes a data packet through one or more internet protocol stack layers to generate a processed data packet to be transmitted to a remote computer.
  • the operating system is configured to determine modified encryption information that does not include a desired security policy for the data packet.
  • the modified encryption information includes one or more null parameters, and the modified encryption information is based on encryption information that includes the desired security policy.
  • the encryption information includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the operating system is configured to execute a null-encryption routine to generate an unencrypted data packet based on the processed data packet and the modified encryption information.
  • the null-encryption routine does not encrypt the processed data packet.
  • the operating system is configured to transmit the unencrypted data packet to the second computing device.
  • the first computing device includes a negotiation module in communication with the operating system and the second computing device configured to transmit a message including data indicative of the encryption information to the second computing device.
  • the operating system is unaware of a security nature of the transmission.
  • the second computing device includes an encryption module configured to encrypt the unencrypted data packet based on the message transmitted from the negotiation module to generate an encrypted data packet.
  • the invention features a computerized encryption method.
  • the method includes processing, by a first computing device, a data packet through one or more internet protocol stack layers to generate a processed data packet to be transmitted to a remote computer.
  • the method includes determining, by the first computing device, modified encryption information that does not include a desired security policy for the data packet.
  • the modified encryption information includes one or more null parameters, and the modified encryption information is based on encryption information that includes the desired security policy.
  • the encryption information includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the method includes transmitting, by the first computing device, a message including data indicative of the encryption information to a second computing device.
  • the method includes executing, by the first computing device, a null- encryption routine to generate an unencrypted data packet based on the processed data packet and the modified encryption information.
  • the null-encryption routine does not encrypt the processed data packet.
  • the method includes transmitting, by the first computing device, the unencrypted data packet to the second computing device.
  • the method includes encrypting, by the second computing device, the unencrypted data packet based on the message transmitted from the first computing device to generate an encrypted data packet.
  • the invention features a computerized decryption method executed by a decryption apparatus including a first computing device and a second computing device.
  • the method includes receiving, by the second computing device, an encrypted data packet transmitted from a remote computer to the first computing device.
  • the method includes determining, by the second computing device, encryption information that includes a desired security policy for the encrypted data packet.
  • the encryption information includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the method includes decrypting, by the second computing device, the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the method includes transmitting, by the second computing device, the unencrypted data packet to the first computing device.
  • the method includes determining, by the first computing device, modified encryption information that does not include the desired security policy.
  • the modified encryption information includes one or more null parameters.
  • the method includes executing, by the first computing device, a null-encryption routine.
  • the null-encryption routine does not modify the unencrypted data packet.
  • the method includes processing, by the first computing device, the unencrypted data packet through one or more internet protocol stack layers to generate a data packet.
  • the invention features a decryption apparatus including a first computing device in communication with a second computing device.
  • the second computing device is configured to receive an encrypted data packet transmitted from a remote computer to a first computing device.
  • the second computing device is configured to determine encryption information that includes a desired security policy for the encrypted data packet.
  • the encryption information includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device and the remote computer.
  • the second computing device is configured to decrypt the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the second computing device is configured to transmit the unencrypted data packet to the first computing device.
  • the first computing device includes an operating system configured to determine modified encryption information that does not include the desired security policy.
  • the modified encryption information includes one or more null parameters.
  • the first computing device is configured to execute a null-encryption routine.
  • the null-encryption routine does not modify the unencrypted data packet.
  • the second computing device is configured to process the unencrypted data packet through one or more internet protocol stack layers to generate a data packet.
  • any of the aspects above, or any apparatus, device or system or method, process or technique described herein, can include one or more of the following features.
  • the second computing device is further configured to transmit the encrypted data packet to the remote computer.
  • the negotiation module can be configured to generate the encryption information, transmit the encryption information to the operating system through a socket, and transmit the message including data indicative of the encryption information to the second computing device.
  • the negotiation module can include an unmodified key management application and a snoop application configured to monitor the socket to generate the message, or a modified key management application.
  • a database is in communication with the first computing device, and determining the encryption information includes retrieving the encryption information from the database.
  • the first computing device can include a bypass encryption module in communication with the operating system configured to receive the processed data packet from the operating system, execute the bypass encryption routine to generate the unencrypted data packet, and transmit the unencrypted data packet to the operating system.
  • the encryption module can be configured to add one or more padding bytes to the processed data packet to generate the unencrypted data packet.
  • the first computing device is a main processor and the second computing device is a network processor.
  • the operating system can be Linux and the operating system can include an IPsec implementation.
  • the bypass encryption routine includes a user-specified bypass encryption routine that is separate from the operating system and does not require modification of the operating system to install the bypass encryption routine.
  • the operating system processes the unencrypted data packet as if the unencrypted data packet were an encrypted data packet.
  • the second computing device can transmit the encrypted data packet to the remote computer.
  • determining the encryption information includes determining whether a security association between the first computing device and the remote computer is stored in a database. If a security association for the first computing device and the remote computer is not stored in the database, a security association can be determined for the first computing device and the remote computer.
  • a key management application can be modified to transmit the message including data indicative of the encryption information to the second computing device.
  • a request for encryption information is transmitted between the first computing device and the remote computer to an unmodified key management application using a socket, and data indicative of the encryption information for the first computing device and the remote computer using the socket is received from the unmodified key management application.
  • a snoop application can monitor the socket to determine the message including data indicative of the encryption information.
  • Executing the bypass encryption routine can include adding one or more padding bytes to the processed data packet to generate the unencrypted data packet.
  • the unencrypted data packet includes original plaintext from the data packet.
  • Executing the bypass encryption routine can include transmitting, by an operating system, the processed data packet to the bypass encryption routine through an application programming interface.
  • the bypass encryption routine is registered with the operating system.
  • the operating system receives the unencrypted data packet from the bypass encryption routine.
  • the operating system processes the unencrypted data packet as if the unencrypted data packet were an encrypted data packet.
  • the operating system is configured to transmit a request for the encryption information to a modified key management application, and receive the modified encryption information from the modified key management application.
  • the negotiation module can include the modified key management application.
  • the modified key management application is configured to receive the request from the operating system, calculate the encryption information, transmit the modified encryption information to the operating system, and transmit the encryption information to the second computing device.
  • the modified key management application can be configured to receive the encryption information from the key management application, calculate the modified encryption information, transmit the modified encryption information to the key management application, and transmit the encryption information to the second computing device.
  • the request for the encryption information can include a request for an advanced encryption standard policy, and the encryption information includes an advanced encryption standard policy.
  • the second computing device is configured to transmit the encrypted data packet to the remote computer.
  • the first computing device can be a main processor and the second computing device is a network processor.
  • the operating system can be Linux and the operating system can include an IPSec implementation.
  • a request to calculate the encryption information is received, the encryption information is calculated in response to the request, and the modified encryption information is calculated based on the encryption information including calculating the one or more null parameters, including a null encryption parameter and a null authentication parameter.
  • Calculating the encryption information can include calculating a security association between the first computing device and the remote computer.
  • the security association includes a security parameter index and one or more encryption parameter.
  • the security association is stored in a database.
  • the second computing device transmits the encrypted data packet to the remote computer.
  • the encryption information is stored in a database in communication with the second computing device.
  • Encrypting the unencrypted data packet based on the encryption information includes identifying the security association based on a supplied context identifier, a packet header for the unencrypted data packet, or both.
  • the unencrypted data packet can include original plaintext from the data packet.
  • Determining the modified encryption information can include retrieving the modified encryption information from a database in communication with the first computing device.
  • the operating system is configured to receive data indicative of a fragmentation configuration parameter calculated based on the encryption information. The operating system can fragment the unencrypted data packet based on the fragmentation configuration parameter.
  • Encryption e.g., IPsec encryption/decryption
  • a generally-available operating system with a loosely-coupled network processor (e.g., a processor configured to perform the actual encryption/decryption).
  • An operating system can be loosely-coupled to the network processor without requiring any changes to the operating system.
  • the operating system can be faked to not encrypt a processed data packet (e.g., an unmodified operating system can be configured to execute a bypass encryption routine that does not encrypt the processed data packet, yet the operating system processes the packet returned from the bypass encryption routine as if it were encrypted).
  • the rich and powerful framework for the negotiation and use of IPsec security associations built into many OS 's can be utilized while still offloading the encrypt/decrypt operations to a loosely-coupled offboard security processor.
  • the normal requirement for the security processor to return an encrypted packet to the operating system for continued processing can be eliminated (e.g., the main processor transmits the data message to the network processor, and the network processor encrypts the data packet and transmits the encrypted data packet to the remote computer without transmitting the encrypted data packet back to the main processor for any further processing).
  • FIG. 1 illustrates an architectural diagram of a switch for loosely-coupled encryption functionality for an operating system.
  • FIG. 2 illustrates an architectural diagram of an operating system being faked to not encrypt a processed data packet according to a first embodiment.
  • FIG. 3 illustrates an architectural diagram of a switch that includes loosely-coupled encryption functionality for an operating system according to a first embodiment using an unmodified key management application and a snoop application.
  • FIG. 4 illustrates an architectural diagram of a switch that includes loosely-coupled encryption functionality for an operating system according to a first embodiment using a modified key management application.
  • FIG. 5 is a method for encrypting a data packet using loosely-coupled encryption functionality according to a first embodiment.
  • FIG. 6A is a detailed method for determining encryption information using loosely- coupled encryption functionality according to a first embodiment.
  • FIG. 6B is a detailed method for presenting an encryption facade using loosely- coupled encryption functionality according to a first embodiment.
  • FIG. 7 is a method for decrypting a data packet using loosely-coupled encryption functionality according to a first embodiment.
  • FIG. 8 illustrates an architectural diagram of an operating system being faked to not encrypt a processed data packet according to a second embodiment.
  • FIG. 9 illustrates an architectural diagram of a switch that incorporates loosely- coupled encryption functionality for an operating system according to a second embodiment using a modified key management application.
  • FIG. 10 is a method for encrypting a data packet using loosely-coupled encryption functionality according to a second embodiment.
  • FIG. 11 is a method for calculating modified encryption information using loosely- coupled encryption functionality according to a second embodiment.
  • FIG. 12 is a method for decrypting a data packet using loosely-coupled encryption functionality according to a second embodiment.
  • an operating system is faked into not encrypting/decrypting a data packet while still performing the remaining encryption/decryption processing functionality to the data packet.
  • the actual encryption/decryption is performed by a loosely- coupled computing device (e.g., network processor).
  • a loosely- coupled computing device e.g., network processor.
  • an encryption/decryption protocol or suite
  • an operating system that supports a driver API for a user-specified encrypt/decrypt or an operating system that supports null -encryption.
  • the term encryption used herein can be used to refer to both encryption and decryption, and does not refer to just encryption (e.g., an encryption module can both encrypt and decrypt data).
  • FIG. 1 illustrates an architectural diagram of a switch 100 for loosely-coupled encryption functionality for an operating system.
  • the switch 100 includes a first computing device 102 in communication with a second computing device 104.
  • the first computing device 102 includes an operating system 106, which is in communication with an encryption module 108, a negotiation module 110, and a database 112.
  • the second computing device 104 includes an encryption module 114.
  • the encryption module 114 is in communication with a database 116.
  • the second computing device 104 is in communication with one or more remote computers 118 via a network 120.
  • the first computing device can be a main processor (e.g., running the operating system 106, such as Linux) and the second computing device can be a network processor (e.g., running proprietary code).
  • the first computing device 102 and the second computing device 104 can be two separate processor systems connected by an internal bus within the switch 100.
  • the operating system 106 can be any software program that provides an interface between the hardware of the first computing device 102 and other software. Examples of operating systems include Mac OS X, the Microsoft Windows family of operating systems, Linux, Unix-like operating systems, etc. In one embodiment, the operating system 106 is a Linux 2.6 OS with an IPsec implementation (framework).
  • the operating system 106 includes an interface (e.g., an API interface) to the encryption module 108.
  • the encryption module 108 can be a user-supplied encryption/decryption module.
  • the encryption module 108 can be, for example, a bypass encryption module (e.g., as described in FIGS. 2-4) or a null encryption module (e.g., as described in FIGS. 6-7).
  • the interface can be a scatter/gather interface allowing the operating system 106 (the kernel) to request the encryption module 108 to encrypt/decrypt a discontiguous set of memory buffers (or pages).
  • the negotiation module 110 is a key management application configured to negotiate encryption information (e.g,. security association (SA) information) between the switch 100 and the remote computer 118.
  • the negotiation module 110 also conveys encryption information to the operating system 106 and the second computing device 104.
  • the negotiation module 110 can include, for example, an unmodified key management application and a snoop application (e.g., as described in FIG. 3), a modified key management application (e.g., as described in FIG. 4 or FIG. 9).
  • the databases 112 and 116 are configured to store data, including encryption information, for data streams transmitted between the switch 100 and the remote computer 118 (e.g., the SAD, SPD, etc.). While only one remote computer 1 18 is shown for simplification purposes, the switch 100 can be in communication with any number of remote computers.
  • the switch 100 can be an interconnect switch.
  • the switch 100 can handle IP-to-IP interconnect for IP -voice peering and access, providing security, control, and Service Level Agreement (SLA) services.
  • SLA Service Level Agreement
  • the switch 100 can be, for example, the NBS® Network Border Switch available from Sonus Networks, Inc.
  • FIG. 2 illustrates an architectural diagram 200 of the operating system 106 from FIG. 1 being faked to not encrypt a processed data packet according to a first embodiment.
  • the operating system 106 is in communication with the negotiation module 110 and the bypass encryption module 202.
  • the operating system 106 sends an encryption information request 204 (e.g., key negotiation request) to the negotiation module 110.
  • the negotiation module sends encryption information 206 (e.g., SA info) to the operating system 106.
  • the operating system 106 using the encryption information 206, sends the processed data packet 208 (e.g., via a scatter/gather API) to the bypass encryption module 202.
  • the bypass encryption module 202 executes a bypass encryption routine to generate an unencrypted data packet 210.
  • the bypass encryption module 202 transmits the unencrypted data packet 210 to the operating system 106.
  • the operating system 106 is faked into processing the unencrypted data packet 210 as if the unencrypted data packet 210 were an encrypted data packet.
  • the bypass encryption module 202 is registered as an encryption module with the operating system 106.
  • the operating system 106 allows user-supplied implementations of encryption modules. Each such software encryption module provides interface functions for various cryptographic operations (such as encrypt, decrypt, etc), and it registers itself for particular cryptographic protocols (such as 3DES, AES, etc). With such a registration in place, when the operating system 106 needs the specific cryptographic operation, the operating system 106 invokes the supplied encryption module (e.g., bypass encryption module) to perform the operation.
  • the supplied encryption module e.g., bypass encryption module
  • the bypass encryption module 202 executes a user-specified bypass encryption routine.
  • the bypass encrypt routine is, for example, separate from the operating system 106 and does not require modification of the operating system 106 to install.
  • the bypass encryption module 202 is configured to interface with the operating system 106 as if it were a true encryption module. For example, the bypass encryption module 202 advertises to the operating system 106 capabilities for encryption of all the relevant cryptographic algorithms. However, the bypass encryption module 202 does not actually implement an encryption algorithm (i.e., it doesn't encrypt or decrypt, and therefore presents a facade to the operating system 106 by telling the operating system 106 that it is actually performing AES encryption).
  • the bypass encryption module 202 does not encrypt the IP data or IP headers of the processed data packet 208, and the resulting packet is the plaintext of the data packet. While the data in the unencrypted data packet 210 is plaintext, the bypass encryption module 202 can be configured to perform some processing to the processed data packet 208 (e.g., which can distinguish the bypass encryption module 202 from purely a null encryption routine). For example, the bypass encryption module 202 can be configured to add one or more padding bytes to the processed data packet 208 to generate the unencrypted data packet 210 (e.g., AES requires 256 bytes, so even if the bypass encryption module does not encrypt the data, padding bytes can be added to achieve the requisite 256 bytes).
  • AES requires 256 bytes, so even if the bypass encryption module does not encrypt the data, padding bytes can be added to achieve the requisite 256 bytes).
  • the operating system 106 processes the unencrypted data packet 210 (e.g., via the XFRM layer) using all of the built-in encryption functionality (e.g., IPsec), but without actually encrypting/decrypting the data.
  • the encrypt/decrypt can later be performed by encryption hardware or software (e.g., via the second computing device 104) both without transmitting the encrypted data packet back to the first computing device 102 and without bypassing the built-in security functionality (e.g., all the non-encryption/decryption related functionality, such as SA negotiation, SAD functionality, SPD functionality, etc.) of the operating system 106.
  • the built-in security functionality e.g., all the non-encryption/decryption related functionality, such as SA negotiation, SAD functionality, SPD functionality, etc.
  • the negotiation module 110 e.g., a key management application
  • a standard OS flow e.g., a Linux IPsec flow
  • the operating system 106 processes the data packet as if the encrypt/decrypt is being handled by the invoked bypass encryption module 202 (e.g., from the XFRM layer).
  • This unchanged view from the operating system 106 and negotiation module 110 can allow the switch to perform the actual encryption/decryption by a loosely- coupled computing device (e.g., the second computing device 104 of FIG. 3) without requiring any changes to operating system kernel 106 core or the negotiation module 110.
  • FIG. 3 illustrates an architectural diagram of a switch 300 that includes loosely- coupled encryption functionality for the operating system 106 according to a first embodiment, using an unmodified key management application 302 (e.g., Racoon2 or any other key management application) and a snoop application 304.
  • the switch 300 includes the first computing device 102 in communication with the second computing device 104.
  • the first computing device 102 includes the operating system 106, which is in communication with the negotiation module 306 through sockets 308 and 310.
  • the operating system 106 receives packets (e.g., for transmission to remote computers) from one or more user-space applications (not shown) through socket 308 (e.g., an INET or INET6 socket).
  • Socket 310 is, for example, a kernel interface or user interface (e.g., PF KEY socket) from the kernel space of the operating system 106 to the user space of the first computing device 102.
  • the negotiation module 306 (e.g., the negotiation module 110 of FIG. 1) includes the unmodified key management application 302 and a snoop application 304.
  • the unmodified key management application 302 exchanges key-negotiation messages with the receiving remote computers through the socket 308.
  • the unmodified key management application 302 is configured to send encryption information (e.g., SA update messaging) to the operating system 106 through socket 310.
  • the snoop application 304 is configured to listen to socket 310 to glean information communicated between the unmodified key management application 302 and the operating system 106 via socket 310.
  • the snoop application 304 can be registered in promiscuous mode to listen to socket 310.
  • the snoop application 304 is configured to transmit a message 326 (e.g., SA info) to the encryption module 114 of the second computing device 104 based on the data gleaned from socket 310.
  • a message 326 e.g., SA info
  • the operating system 106 includes IP processing module 312, which is in communication with the socket 308 and the routing module 314.
  • the IP processing module 312 and the routing module 314 comprise, for example, the Internet Layer of the IP protocol stack.
  • the routing module 314 is in communication with the OS encryption framework 316 (e.g., the XFRM framework of the Linux OS or any other encryption framework).
  • the OS encryption framework 316 is in communication with the unmodified key management application 302 of the negotiation module 306 via socket 310.
  • the OS encryption framework 316 can send key negotiation requests to the registered unmodified key management application 302 (e.g., ACQUIRE and other PF KEY messaging) and receive SA information from the unmodified key management application 302 via socket 310.
  • the OS encryption framework 316 is also in communication with the bypass encryption module 202 of FIG. 2 and the link driver module 320.
  • the link driver module 320 is, for example, the Link Layer of the IP protocol stack.
  • the second computing device 104 includes an encryption module 114 which is in communication with a link driver module 324.
  • the link driver module 324 is in communication with one or more remote computers (not shown, e.g., via the internet).
  • the encryption module 114 of the second computing device 104 is configured to receive the message 326 from the snoop application 304.
  • the bypass encryption module 202 does not produce an encrypted data packet, but instead returns the unencrypted data packet 210 to the operating system 106.
  • the encryption module 114 is configured to perform encryption of the unencrypted data packet 210.
  • the link driver module 320 transmits the unencrypted data packet 210 to the encryption module 114.
  • the encryption module 114 using the encryption information gleaned from message 326, encrypts the unencrypted data packet. Therefore, the overall switch 300 produces an encrypted data packet (and therefore an encrypted data stream).
  • FIG. 4 illustrates an architectural diagram of a switch 400 that incorporates loosely- coupled encryption functionality for an operating system according to a first embodiment using a modified key management application 402.
  • the switch 400 includes the first computing device 102 in communication with the second computing device 104.
  • the first computing device 102 includes the operating system 106 which is in communication with the negotiation module 404 through sockets 308 and 310.
  • the operating system 106 includes IP processing module 312, which is in communication with the socket 308 and the routing module 314.
  • the routing module 314 is in communication with the OS encryption framework 316.
  • the OS encryption framework 316 is in communication with the modified key management application 402 of the negotiation module 404 via socket 310.
  • the OS encryption framework 316 is also in communication with the bypass encryption module 202 and the link driver module 320.
  • the second computing device 104 includes encryption module 114 which is in communication with a link driver module 324.
  • the negotiation module 404 does not include a snoop application (e.g., like the negotiation module 306 of FIG. 3). Instead, the negotiation module 404 includes a modified key management application 402 that is modified to transmit the message 326 to the encryption module 114 of the second computing device 104.
  • the key management application 402 is still configured to perform the key management functionality (e.g., the modified key management application 402 is a modified Racoon2 implementation).
  • the snoop application functionality can be configured into the modified key management application 402 to, for example, avoid registering a snoop application in promiscuous mode (e.g., which requires being a root process on the first computing device 102).
  • FIG. 5 is a method 500 (a computerized method) for encrypting a data packet using loosely-coupled encryption functionality according to a first embodiment.
  • the operating system 106 processes a data packet through one or more internet protocol stack layers (e.g., via the IP processing module 312 and the routing module 314) to generate a processed data packet to be transmitted to a remote computer (e.g., the remote computer 118 of FIG. 1).
  • the operating system 306 determines encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device 102 and the remote computer.
  • the negotiation module e.g., the snoop application 304 in negotiation module 306 of FIG.
  • the operating system 106 executes a bypass encryption routine (via bypass encryption module 202) to generate a unencrypted data packet.
  • the bypass encryption routine does not encrypt the processed data packet.
  • the link driver module 320 transmits the unencrypted data packet to the second computing device 104.
  • the encryption module 114 encrypts the unencrypted data packet based on the message 326 transmitted from the first computing device 102 to generate an encrypted data packet.
  • the encryption module 114 transmits the encrypted data packet to the link driver module 324, which transmits the encrypted data packet to the remote computer.
  • the operating system 106 can determine whether encryption information (an SA) between the first computing device 102 and the remote computer is stored in a database of the first computing device 102 (e.g., database 112 of FIG. 1). For example, if a SA was previously negotiated (e.g., via the key management application in the negotiation module), then the operating system 106 can have a SA stored in the database, and the operating system 106 can retrieve the encryption information from the database. However, if encryption information is not stored in the database (e.g., if the data packet is the first packet of the transmission), the operating system 106 determines encryption information for the first computing device 102 and the remote computer.
  • an SA an SA
  • the operating system 106 determines encryption information for the first computing device 102 and the remote computer.
  • the operating system 106 being executed by the first computing device 102 is unaware of a security nature of the transmission of message 326 to the second computing device 104.
  • the message 326 is transmitted from the negotiation module (e.g., a user-space application) to the second computing device 104 via a hardware device (e.g., a network processor card).
  • the operating system 106 may process the message 326 for transmission through the hardware device, the operating system 106 may not be aware of the security nature (e.g., that the message 326 includes encryption information) of the message 326.
  • the OS encryption framework 316 did not initiate the transmission of message 326 to the second computing device 104 (e.g., the OS encryption framework 316 is unaware of the transmission of message 326 by the negotiation module).
  • FIG. 6A is a detailed method 600 for determining encryption information using loosely-coupled encryption functionality according to a first embodiment.
  • the OS encryption framework 316 transmits a request for encryption information between the first computing device 102 and the remote computer to a key management application (e.g., either the unmodified key management application 302 or the modified key management application 402) using the socket 110.
  • the OS encryption framework 316 receives, from the key management application, data indicative of the encryption information for the first computing device 102 and the remote computer using the socket 110.
  • the negotiation module e.g., via the snoop application 304 monitoring the socket 310 or the modified key management application 402 creates the message 326 comprising data indicative of the encryption information.
  • the negotiation module transmits the message 326 to the second computing device 104.
  • the snoop application 304 transmits the message 326.
  • the key management application is modified to transmit the message 326.
  • the message 326 comprises all information needed to perform encryption/decryption.
  • the message 326 includes the peer address, encryption key, an encryption cipher, encryption key length, and all other information required to perform encryption/decryption.
  • the negotiation module also transmits the encryption information to the operating system 106 through socket 310.
  • FIG. 6B is a detailed method 650 for presenting an encryption facade using loosely-coupled encryption functionality according to a first embodiment.
  • the OS encryption framework 316 transmits the processed data packet to the bypass encryption routine 202 (executing the bypass encryption routine) through an API (e.g., a function-call API).
  • the bypass encryption module 202 is registered as an encryption module with the operating system 106.
  • the OS encryption framework 316 receives the unencrypted data packet from the bypass encryption module 202.
  • the operating system 106 processes the unencrypted data packet as if the unencrypted data packet were an encrypted data packet.
  • the OS encryption framework 316 completes processing the unencrypted data packet and transmits it to the link driver module 320 for transmission (e.g., to the second computing device 104).
  • the encryption module 114 encrypts the unencrypted data packet to generate the unencrypted data packet (e.g., as 3DES, AES, etc.).
  • An example of the encryption method 500 is provided below, which is intended to be illustrative of the concepts described herein and not limiting in any manner. Many of the details provided in the example are particular to the embodiments being described therein, but one should appreciate that the concepts apply in other configurations and environments. In particular, the concepts described herein apply to any operating system which allows for user- supplied software encryption modules.
  • a modified key management application, a snoop application, or some other means can glean the SA information (the encryption information) generated from the key management application and convey the SA information to the second computing device 104.
  • the operating system 106 is a Linux 2.6 kernel (the OS encryption framework 316 is the XFRM framework), and the first computing device 102 is a standard main processor system.
  • the second computing device 104 is a network processor system including an encryption module 114 configured to encrypt/decrypt a packet using the AES cipher.
  • the key management application e.g., the unmodified key management application 302 in FIG. 3 or the modified key management application 402 in FIG.
  • IKE IPsec Key Exchange
  • RFC 2309 IKE defined by RFC 2309 or IKEv2 defined by RFC 4306
  • socket 310 interface e.g., a PF KEY socket as defined by RFC 2367.
  • Racoon2 available from the TheRacoon2Project.
  • the bypass encryption module 202 provides an AES cipher facade (since the encryption module 114 is using the AES cipher).
  • the bypass encryption module 202 can be configured roughly analogous both in operation and form to the AES implementation typically found in the "kernel/crypto/" directory of the Linux 2.6 distribution.
  • the bypass encryption module 202 is a loadable kernel module (LKM).
  • LKM loadable kernel module
  • the bypass encryption module 202 registers with the operating system 106 as an encryption algorithm with an appropriately completed crypt alg structure in the LKM init routine.
  • the bypass encryption module 202 provides an encrypt and decrypt routine, along with all the necessary crytographic parameters (e.g., such as keysize, etc.).
  • the bypass encryption module 202 indicates that it is the highest preference for the AES algorithm (i.e.
  • the bypass encryption module 202 deregisters the algorithm in the LKM cleanup routine. Also, while the bypass encryption module 202 indicates that it handles the encrypt/decrypt for AES, the bypass encryption module 202 does not actually encrypt the data packet contents. Specifically, the encrypt and decrypt routines need not transform the input packet in any way. A plaintext packet given to the encrypt routine can come out in plaintext (with any additional processing, such as adding padding bytes, being performed), and an encrypted packet given to decrypt routine returns the same decrypted packet.
  • the snoop application 304 is configured to open a PF KEY socket (socket 310) in promiscuous mode.
  • the snoop application 304 runs as a root process, and therefore sees any PF KEY interactions over socket 310 between the operating system 106 and the unmodified Racoon2 key management application 302.
  • the snoop application 304 sees the SADB ACQUIRE, SADB GETSPI, SADP UPDATE, and the other PF KEY messaging between the operating system kernel 106 and Racoon2 key management application 302.
  • the snoop application 304 has an interface (e.g., through an operating system kernel 106 driver) to the second computing device 104, the network interface system (NIS). This interface allows the snoop application 304 to notify the second computing device 104 (e.g., the encryption module 114) of important encryption information, such as SA information including the IPsec Security Parameter Index (SPI) and the cryptographic parameters associated with that SPI.
  • SA information including
  • the link driver module 320 comprises a link level driver for the second computing device 104.
  • the link driver module 320 can be, for example, a normal Linux link level driver which transfer packets between the Linux operating system kernel 106 and the second computing device 104 (the NIS).
  • the specific type of driver model used can depend on the hardware specifics.
  • the link driver module 320 can be configured as a driver for any high-speed network interface card.
  • the second computing device 104 provides both physical layer connectivity to the network (e.g., network 120) and hardware capable of encrypting a packet before sending it, or decrypting a packet after receiving it.
  • encryption hardware include commercial boards containing network-processors with on-board encryption/decryption algorithms (the encryption module 114) and coupled with Ethernet interfaces (the link driver module 324).
  • the encryption module 114 runs code which can encrypt or decrypt the packets based on the cryptographic parameters associated with specific SPIs.
  • Many implementations of encryption hardware/algorithms are capable of tremendous rates of encrypt and decrypt, often at full-wire speeds for all network ports on the card. IPsec protection starts with the definition of security policy rules. An interface to the SPD allows a user to enter SPD rules.
  • the interface can be, for example, a command-line interface provided by Linux, or a user application which invokes the relevant APIs for adding rules.
  • an application initiates a connection which matches the rule (e.g., an IP application transmits a first packet for a connection to IP 10.160.20.63 at port 5060 through the operating system 106 via socket 308).
  • the processing in this example for the initial packet is next described.
  • the Linux operating system kernel 106 performs its normal Transport Layer and Internet Layer processing (e.g, via IP processing module 312, routing module 314, and other modules not shown) to generate the processed data packet.
  • This processing includes, for example, transport layer header addition, IP header addition, and IP routing.
  • the packet is given to the XFRM encryption framework 316.
  • the XFRM encryption framework 316 checks the packet parameters against the SPD (e.g., located in database 112 of FIG. 1). Since there is a matching rule, the XFRM encryption framework 316 attempts to find a matching SA entry in the SAD (e.g., also located in the database 112 of FIG. 1). No such entry is found in the SAD since this is the initial packet. The XFRM encryption framework 316 then queues the packet and sends an SADB ACQUIRE message on the PF KEY socket 310 to the registered Racoon2 unmodified key management application 302.
  • the SADB ACQUIRE message includes all the necessary cryptographic parameters including protocol (AES), IP addressing, port, protocol, etc.
  • the Racoon2 unmodified key management application 302 receives the SADB ACQUIRE message.
  • the Racoon2 unmodified key management application 302 sends an SADB GETSPI request to the operating system kernel 106 through socket 308.
  • the operating system kernel 106 allocates a SPI and sends the response through the PF KEY socket 310.
  • the Racoon2 unmodified key management application 302 negotiates the encryption information - the SA parameters - with the IKE peer (of the receiving remote computer at IP 10.160.20.63). This is, for example, a normal IKE negotiation as defined in IETF 2409. Any key-negotiation application can be used as it's the outcome (the SA) the is useful to the switch, not the method or processes of negotiating the SA.
  • the Racoon2 unmodified key management application 302 pushes the SA encryption information into the operating system kernel 106 through the PF KEY socket 310 with an SADB UPDATE message.
  • the operating system kernel 106 creates the SA entry in the SAD (via the XFRM encryption framework 316).
  • the snoop application 304 sees the SADB ACQUIRE message, the SADB GETSPI request, and the response from the operating system kernel 106 (but need not act on these messages).
  • the snoop application 304 also sees the SADB UPDATE message and the SA contents.
  • the snoop application 304 sends the SA information to the second computing device 104 via message 326 (e.g., using the relevant driver API).
  • the encryption module 114 creates an SA entry in a local SAD (e.g., in the database 116).
  • the XFRM encryption framework 316 dequeues the packets waiting on the SA.
  • the operating system kernel 106 locates the highest precedence encryption module for the AES protocol (which is the bypass encryption module 202, the pseudo-AES module), and invokes the bypass encryption module 202's encrypt algorithm with the keying information and the packet.
  • the bypass encryption module 202 performs any necessary processing to the packet (such as padding, etc.) but does not alter the plaintext packet contents.
  • the module returns success to the kernel indicating that it has "encrypted" the packet, generating the unencrypted data packet.
  • the XFRM encryption framework 316 passes the unencrypted data packet to the link driver module 320.
  • the link driver module 320 performs typical link layer activities (such as adding the link layer header) and transmits the unencrypted data packet to the second computing device 104 (the NIS).
  • the encryption module 114 extracts the SPI, target address, and security protocol from the unencrypted data packet and checks for a matching SA entry in the local SAD. This check can find the SA previously added by the snoop application 304 (e.g., via step 506).
  • the encryption module 114 encrypts the packet in place using the keying information from the SA to generate the truly encrypted data packet.
  • the encryption module 1 14 then passes the encrypted data packet to the link driver module 324.
  • the link driver module 324 performs any additional link processing (such as computing the CRC32 on the final encrypted data packet contents) and then forwards the encrypted data packet onto the network.
  • the embodiment described above used the snoop application 304 to generate the message 326, which usually requires a root process to install it in promiscuous mode.
  • the key management application 402 itself can be modified to (in addition to negotiating the SAs) push the SA information into the encryption module 114.
  • the modified key management application 402 does not require a root process listening on a PF KEY socket.
  • the Linux operating system kernel 106 performs its normal transport layer and IP layer processing to generate the processed data packet.
  • the processed data packet is transmitted to the XFRM encryption framework 316.
  • the XFRM encryption framework 316 checks the packet parameters against the SPD. Since there is a matching rule, the XFRM attempts to find a matching SA entry. No such entry is found since this is the initial packet.
  • the XFRM encryption framework 316 queues the packet and sends an SADB ACQUIRE message on the PF KEY socket 310 to the registered modified key management application 402.
  • the modified key management application 402 receives the SADB ACQUIRE message, and then sends an SADB GETSPI request to the operating system kernel 106.
  • the operating system kernel 106 allocates a SPI and sends the response through the PF KEY socket 310.
  • the modified key management application 402 negotiates the SA parameters with the IKE peer of the remote computer.
  • the modified key management application 402 pushes the SA information into the operating system kernel 106 through the PF KEY socket 310 with an SADB UPDATE message.
  • the operating system kernel 106 creates the SA entry in the SAD.
  • the modified key management application 402 also pushes the SA information to the second computing device 104 through the relevant driver API.
  • the encryption module 114 creates an SA entry in a local SAD.
  • the operating system kernel 106 XFRM encryption framework 316 dequeues the packets waiting on the SA.
  • the operating system kernel 106 locates the highest precedence encryption module for the AES protocol, the bypass encryption module 202.
  • the operating system kernel 106 invokes the bypass encryption module 202 's encrypt algorithm with the keying information and the packet.
  • the bypass encryption module 202 performs any necessary fixups to the processed data packet (but does not alter the plaintext packet contents) to produce the unencrypted data packet.
  • the bypass encryption module 202 returns success to the operating system kernel 106 indicating that it has "encrypted" the packet.
  • the XFRM encryption framework 316 transmits the unencrypted data packet to the link driver module 320, which performs typical link layer activities (such as adding the link layer header) and transfers the packet to the second computing device 104.
  • the encryption module 114 extracts the SPI from the packet and checks for a matching SA entry in the local SAD. This check can find the SA previously added by the modified key management application 402. The encryption module 114 encrypts the packet in place using the keying information from the SA to generate the encrypted data packet.
  • the encryption module 114 transmits the encrypted data packet to the link driver module 324.
  • the link driver module 324 performs any additional link processing (such as computing the CRC32 on the final packet contents) and then forwards the encrypted data packet onto the network.
  • step 504 the sequence of steps associated with the negotiation and installation of the SA are unnecessary. For example, if a matching SA was already installed, the SAD lookup can find the SA and the remaining processing can immediately proceed (e.g., step 504 is completed and the method 500 proceeds to step 506). As another example, the subsequent packet can be queued while the SA was already requested, but not yet installed, and the packet can be queued until the SA is installed.
  • FIG. 7 is a method 700 for decrypting a data packet using loosely-coupled encryption functionality according to a first embodiment.
  • the second computing device 104 receives (via link driver module 324) an encrypted data packet transmitted from a remote computer to the first computing device 102.
  • the encryption module 114 determines encryption information including one or more parameters for encrypting and decrypting data packets transmitted between the first computing device 102 and the remote computer.
  • the encryption module 114 decrypts the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the encryption module 114 transmits the unencrypted data packet to the first computing device 102.
  • the first computing device 102 executes a bypass encryption routine (e.g., being executed by the bypass encryption module 202) to generate a processed data packet.
  • the bypass encryption routine does not modify the unencrypted data packet.
  • the operating system processes the processed data packet through one or more internet protocol stack layers to generate a data packet (e.g., through the routing module 314 and the IP processing module 312, and eventually to the user-space application via socket 308.
  • some encryption frameworks dictate that the sender of a packet is responsible for creating the encryption information if it does not already exist (e.g., initiating an SA negotiation if a matching SA does not exist). Consequently, on the receiving side (the switch), there is first a negotiation to create the encryption information (via the negotiation module) before the first packet is transmitted by the remote computer.
  • the transmission process by the remote computer begins with creating the encryption information.
  • the remote computer can initiate the key negotiation between the remote key management application (the key management application in the negotiation module of the first computing device 102) and the local key management application on the remote computer.
  • the key management application pushes the SA information into the operating system 106.
  • the negotiation module also transmits a message 326 to the second computing device 104 indicative of the encryption information.
  • the snoop application 304 sees the SA information transmitted by the unmodified key management application 302 to the OS encryption framework 316 and transmits the encryption information via message 326 to the encryption module 114.
  • the encryption module 114 uses the encryption information (e.g., SA information stored in the database 116 of FIG. 1) to decrypt the packet and forward to the link driver module 320 in the operating system 106.
  • the encryption module 114 is configured to not remove encryption header information.
  • the encryption module 114 can be configured to not remove the encapsulating security payload (ESP, which provides origin authenticity, integrity, and confidentiality) header and/or IPsec authentication headers (AH, which protects the data packet header, unlike ESP).
  • ESP encapsulating security payload
  • AH IPsec authentication headers
  • IPsec tunnel mode the encryption module 114 can be configured to not remove the outer IP header.
  • the XFRM layer also determines the relevant SA information in the SAD and invokes the registered decrypt module. The decrypt module does a simulated (fake) decrypt and then the XFRM continues with rest of the local packet processing.
  • the encryption information (SAs) is negotiated by the sending remote computer.
  • the method 700 starts with the peer initiating a SA negotiation.
  • the Racoon2 unmodified key management application 302 receives the SA negotiation request from the remote computer.
  • the Racoon2 unmodified key management application 302 transmits an SADB GETSPI request to the operating system kernel 106 to request a SPI.
  • the operating system kernel 106 allocates a SPI and sends the response to Racoon2 unmodified key management application 302.
  • the Racoon2 unmodified key management application 302 completes the SA negotiation.
  • the Racoon2 unmodified key management application 302 pushes the SA information into the operating system kernel 106 with an SADB UPDATE message.
  • the operating system kernel 106 installs the SA into the SAD.
  • the snoop application 304 sees the GETSPI request and response (but does not need to act on it).
  • the snoop application 304 also sees the SADB UPDATE with the SA information.
  • the snoop application 304 sends the SA information to the second computing device 104 through message 326.
  • the encryption module 114 on the second computing device 104 creates an SA entry in a local SAD.
  • the remote computer sends an encrypted packet to the switch.
  • the link driver module 324 executes the necessary link layer processing and sends the encrypted data packet to the encryption module 114.
  • the encryption module 114 looks up the SA using the SPI from the encrypted data packet.
  • the keying information from the SA is used to decrypt the packet in place to generate the unencrypted data packet.
  • the IPsec ESP and/or AH headers are not removed or modified, nor is the outer IP header removed for tunnel mode IPsec connections.
  • the unencrypted data packet is delivered to the link driver module 320 in the Linux operating system kernel 106.
  • the link driver does any necessary additional processing (e.g., remove the link layer header).
  • the link driver module 320 transmits the unencrypted data packet to the XFRM encryption framework 316.
  • the XFRM encryption framework 316 looks up the SA from the SPI in the unencrypted data packet.
  • the operating system kernel 106 finds the encryption module for the SA, the bypass encryption module 202.
  • the SA keying information and the pseudo- encrypted packet are passed into the bypass encryption module 202 decrypt routine.
  • the bypass encryption module 202 performs any ancillary decryption activities (e.g., padding removal).
  • the operating system kernel 106 performs all normal additional IP processing (e.g., local routing, transport layer processing, delivery into a socket, etc.).
  • the switch e.g., the first computing device 102 and the second computing device
  • the second computing device 104 can be configured to reject packets sent by a remote computer that are created with an invalid SPI.
  • the remote computer sends an encrypted data packet with an ESP and/or AH IPsec header containing an invalid SPI.
  • the link driver module 324 performs the necessary link layer processing and sends the encrypted data packet to the encryption module 114.
  • the SPI in the encrypted data packet is invalid so the encryption module 114 does not find an SA in the SAD (e.g., the SPI expired, etc.).
  • the encryption module 114 transmits the encrypted data packet to the link driver module 320 in the Linux operating system kernel 106 without change.
  • the link driver module 320 does any necessary additional processing (e.g., removing the link layer header).
  • the encrypted data packet is transmitted to the XFRM encryption framework 320.
  • the encrypted data packet has an invalid SPI so the XFRM encryption framework does not find an SA in the SAD.
  • the XFRM encryption framework 316 drops the packet due to the invalid SPI.
  • the switch can be configured to reject a packet when the remote computer sends a plaintext packet when it should have negotiated an SA and sent encrypted and/or authenticated packets.
  • the remote computer sends a plaintext packet (no IPsec ESP or AH header) without establishing an SA.
  • the link driver module 324 does the necessary link layer processing and sends the packet to the encryption module 114.
  • there is no IPsec header so the encryption module 114 can perform plaintext handling (e.g., basic IP packet validation) but does not decrypt the packet.
  • the encryption module 114 transmits the packet to the link driver module 320 in the Linux operating system kernel 106.
  • the link driver module 320 does any necessary additional processing, and transmits the packet to the XFRM encryption framework 316.
  • the packet has no IPsec header so the XFRM encryption framework does not try to find an SA.
  • the XFRM encryption framework 316 matches the packet against the SPD for a matching rule. A matching rule that requiresAES encryption is found. Since AES is required, but the packet has no IPsec header, the XFRM encryption framework 316 discards the packet.
  • FIG. 8 illustrates an architectural diagram 800 of an operating system 106 in the first computing device 102 of FIG. 1 being faked to not encrypt a processed data packet according to a second embodiment.
  • the operating system 106 is in communication with the negotiation module 110 and a null encryption module 802.
  • the operating system 106 sends an encryption information request 804 (e.g., key negotiation request) to the negotiation module 110.
  • the negotiation module sends modified encryption information 806 to the operating system 106.
  • the operating system 106 using the modified encryption information 206, sends the processed data packet 808 (e.g., via a scatter/gather API) to the null encryption module 802.
  • the null encryption module 802 executes a null encryption routine to generate an unencrypted data packet 810.
  • the bypass encryption module 802 transmits the unencrypted data packet 810 to the operating system 106.
  • the operating system 106 is faked into calling the null encryption module 802 upon receipt of the modified encryption information 806.
  • the operating system 106 asks for a particular type of encryption information (e.g., AES), the negotiation module 110 negotiates AES encryption information, but the negotiation module 110 returns the modified encryption information 806 that includes instructions for the operating system 106 to call the null encryption module 802.
  • the null encryption module can be a commonly supported null encryption routine built into many operating systems that performs no processing of the processed data packet 808.
  • the modified encryption information 806 includes instructions that cause the operating system to perform null encryption so the operating system 106 never invokes an encryption module.
  • the operating system 106 requests a key negotiation from the negotiation module 110 as it can with any other negotiation module.
  • this unchanged view from the operating system 106 allows the operating system 106 to receive the modified encryption information 806 from the negotiation module 110 without requiring any changes to operating system kernel 106 core.
  • FIG. 9 illustrates an architectural diagram of a switch 900 that incorporates loosely- coupled encryption functionality for an operating system according to a second embodiment using a modified key management application 902.
  • the switch 900 includes the first computing device 102 in communication with the second computing device 104.
  • the first computing device 102 includes the operating system 106 which is in communication with the negotiation module 906 through sockets 308 and 310.
  • the operating system 106 includes IP processing module 312, which is in communication with the socket 308 and the routing module 314.
  • the routing module 314 is in communication with the OS encryption framework 316.
  • the OS encryption framework 316 is in communication with the modified key management application 902 of the negotiation module 906 via socket 310.
  • the OS encryption framework 316 is also in communication with the null encryption module 908 and the link driver module 320.
  • the second computing device 104 includes encryption module 114 which is in communication with the link driver module 324.
  • the modified key management application 902 transmits the message 326 to the encryption module 114.
  • the modified key management application 902 performs the encryption information (e.g., security key) negotiation and establishes the security association between the first computing device 102 and a remote computer.
  • the modified key management application 902 can also maintain the lifetime of the negotiated encryption information and perform renegotiation when appropriate.
  • the modified key management application 902 can re-negotiate encryption information when traffic that uses a specific encryption information (e.g., SA) has reached a certain number of bytes to prevent pattern matching.
  • a configuration system is in communication with the modified key management application 902.
  • the configuration system can be a user interface which provides functionality to configure the negotiation module 906.
  • FIG. 10 is a method 1000 for encrypting a data packet using loosely-coupled encryption functionality according to a second embodiment.
  • the operating system 106 processes a data packet through one or more internet protocol stack layers (e.g., via the IP processing module 312 and the routing module 314) to generate a processed data packet to be transmitted to a remote computer.
  • the OS encryption framework 316 determines modified encryption information that does not comprise a desired security policy for the data packet.
  • the modified key management application 902 transmits the message 326 comprising data indicative of the encryption information to the encryption module 114 of the second computing device 104.
  • the operating system 106 being executed by the first computing device 102 is unaware of a security nature the transmission.
  • the OS encryption framework 316 executes a null-encryption routine (e.g., via the null encryption module 908) to generate an unencrypted data packet based on the processed data packet and the modified encryption information.
  • the null-encryption routine does not encrypt the processed data packet (e.g., the unencrypted data packet comprises plaintext).
  • the bypass encryption module e.g., 202 of FIGS. 3-4
  • the null-encryption routine is configured to not process the data packet at all (e.g., perform no processing of the data packet).
  • the link driver module 320 transmits the unencrypted data packet to the second computing device 104.
  • the encryption module 114 encrypts the unencrypted data packet based on the message 326 transmitted from the first computing device 102 to generate an encrypted data packet.
  • the OS encryption framework can determine the modified encryption information by retrieving the modified information from a database in communication with the first computing device (e.g., database 112 of FIG. 1). For the first data packet, for example, the negotiation module 906 may not yet have calculated the encryption information and/or modified encryption information.
  • the OS encryption framework 316 can transmit a request for the encryption information to the modified key management application 902, and receive the modified encryption information from the modified key management application 902. FIG. 11 describes this process in more detail.
  • the message 326 comprises data indicative of the actual encryption information.
  • the message can include the decryption ID mapping, the encryption ID mapping, information indicative of the actual encryption parameters, and/or information indicative of the actual integrity parameters.
  • the encryption module 114 receives the message 326, all data packets transmitted between the first computing device 102 and the remote computer can be encrypted/decrypted according to the encryption information (e.g., according to a negotiated SA).
  • Other parameters, such as the lifetime of the encryption information, etc. can be maintained by the operating system 106 (e.g., via the OS encryption framework).
  • the unencrypted data packet includes data indicative of the modified encryption information.
  • the encryption module uses the data indicative of the modified encryption information in the unencrypted data packet to encrypt the packet.
  • the OS encryption framework 316 e.g., the XFRM framework
  • ESP Encapsulating Security Payload
  • the encryption module 314 uses the decryption ID and/or encryption ID to calculate the encrypted data packet.
  • the encryption module 314 can replace the ESP header created by the OS encryption framework 316 with an ESP header that includes the proper ESP information (e.g., the actual SPIs, actual encryption information, and actual integrity information).
  • FIG. 11 is a method 1100 for calculating modified encryption information using loosely-coupled encryption functionality according to a second embodiment.
  • the negotiation module 906 e.g., the modified key management application 902 receives a request to calculate the encryption information (e.g., from the OS encryption framework 316).
  • the negotiation module 906 calculates the encryption information in response to the request received in step 1102.
  • the negotiation module 906 calculates the modified encryption information based on the encryption information.
  • the negotiation module 906 transmits the modified encryption information to the requesting device (e.g., the OS encryption framework 316).
  • the modified key management application 902 determines/negotiates encryption information, which includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device 102 and the remote computer (e.g., a Security Parameter Index (SPI) for the first computing device 102, a SPI for the remote computer, actual encryption information, actual integrity information).
  • the encryption information comprises the desired security policy for data packets transmitted between the first computing device 102 and the remote computer.
  • the encryption information can include a security association between the first computing device 102 and the remote computer.
  • the security association comprises a security parameter index (SPI) and one or more encryption parameters and/or integrity parameters.
  • the request for encryption information can include a request for any non-null encryption policy.
  • the request for the encryption information (received in step 1102) comprises a request for an advanced encryption standard (AES) encryption policy, and the encryption information comprises an AES policy.
  • AES advanced encryption standard
  • the modified key management application 902 calculates encryption context identifier(s) for the second computing device 104 (e.g., for the encryption module 114).
  • the encryption context identifiers include a decryption ID mapping and an encryption ID mapping for the encryption module 114 (e.g., which map a decryption ID of the encryption module 114 to the SPI for the first computing device 102 and an encryption ID of the second computing device 104 to the SPI for the remote computer, respectively).
  • the modified key management application 902 determines the modified encryption information based on encryption information.
  • the modified encryption information includes the decryption ID, the encryption ID, null encryption parameters (which specify no encryption to the payload) and null authentication parameters (which specify no authentication/integrity) to the OS encryption framework 316.
  • the modified encryption information instructs the OS encryption framework 316 to execute a null encryption routine on the processed data packet, while the message 326 provides the encryption module 114 with the encryption parameters necessary to encrypt/decrypt packets transmitted between the first computing device 102 and the remote computer.
  • the negotiation module 906 may include a resource manager (not shown) in communication with the modified key management application 902 configured to perform some of the functionality described above with respect to the modified key management application 902.
  • the operating system can include one or more configuration parameters (e.g., that can be configured at the Application Level).
  • the operating system can receive data indicative of the one or more configuration parameters separately from the modified encryption information (e.g., the data can be calculated based on the encryption information).
  • the operating system can receive data indicative of a fragmentation configuration parameter.
  • the fragmentation configuration parameter can include data indicative of a maximum size for data packets (e.g., the maximum segment size (MSS), which is the largest amount of data, specified in bytes, that the operating system can handle in a single, unfragmented piece).
  • MSS maximum segment size
  • the maximum size for the operating system 106 can be determined based on the maximum size used by the second computing device 104 (e.g., used by the encryption module 114). For example, assume the encryption module 114 is configured to perform AES encryption, which adds a 40 byte header to the encrypted data packet. Further assume that the second computing device 104 is configured with a maximum size of 1500 bytes (e.g., based on a maximum transmission unit (MTU), the maximum size of a data packet that can be transmitted to the network 120).
  • MTU maximum transmission unit
  • the operating system 106 can be configured with a maximum size of 1460 bytes for a data packet (e.g., the maximum size of a data packet that is transmitted from the operating system 106).
  • the operating system 106 fragments the unencrypted data packet into a first fragmented unencrypted data packet and a second fragmented unencrypted data packet, both of which include less than 1460 bytes.
  • the negotiation module 906 can transmit the modified encryption information to the OS encryption framework 316.
  • the OS encryption framework 316 can locally store the modified encryption information.
  • the modified key management application 902 can be configured to transmit the encryption information to the second computing device 104.
  • FIG. 12 is a method 1200 for decrypting a data packet using loosely-coupled encryption functionality according to a second embodiment.
  • the second computing device 104 receives (e.g., via the link driver module 324) an encrypted data packet transmitted from a remote computer to the first computing device 102.
  • the encryption module 114 determines encryption information (e.g., by identifying the encryption information in database 116 of FIG. 1) that comprises a desired security policy for the encrypted data packet.
  • the encryption information includes one or more parameters for encrypting and decrypting data packets transmitted between the first computing device 102 and the remote computer (e.g., encryption parameters and/or integrity parameters).
  • the encryption module 114 decrypts the encrypted data packet based on the encryption information to generate an unencrypted data packet.
  • the encryption module 114 transmits the unencrypted data packet to the first computing device 104 (e.g., via the link driver module 320).
  • the OS encryption framework 316 determines modified encryption information that does not comprise the desired security policy.
  • the modified encryption information includes, for example, one or more null parameters (e.g., null encryption parameters and null integrity parameters).
  • the OS encryption framework 316 executes a null-encryption routine (e.g., via the null encryption module 908).
  • the null-encryption routine does not modify the unencrypted data packet.
  • the operating system 106 processes the unencrypted data packet through one or more internet protocol stack layers (e.g., via routing module 314 and IP processing module) to generate a data packet.
  • the encryption module 114 can reconstruct a packet header for the unencrypted data packet.
  • the encrypted data packet can comprise an ESP header comprising SPIs, actual encryption information, and actual integrity information.
  • the operating system 106 upon receipt of this ESP header, need not receive instructions to invoke a null-decryption routine.
  • the encryption module 114 can create a new ESP header that includes a decryption ID for the encryption module, null encryption parameters, and/or null integrity parameters.
  • the operating system 106 receives the unencrypted data packet and, based on the reconstructed packet header, invokes a null-decryption routine (and therefore does not perform any decryption processing on the unencrypted data packet) but still executes other encryption framework processing for the unencrypted data packet.
  • the above-described systems and methods can be implemented in digital electronic circuitry, in computer hardware, firmware, and/or software.
  • the implementation can be as a computer program product (i.e., a computer program tangibly embodied in an information carrier).
  • the implementation can, for example, be in a machine-readable storage device, for execution by, or to control the operation of, data processing apparatus.
  • the implementation can, for example, be a programmable processor, a computer, and/or multiple computers.
  • a computer program can be written in any form of programming language, including compiled and/or interpreted languages, and the computer program can be deployed in any form, including as a stand-alone program or as a subroutine, element, and/or other unit suitable for use in a computing environment.
  • a computer program can be deployed to be executed on one computer or on multiple computers at one site.
  • Method steps can be performed by one or more programmable processors executing a computer program to perform functions of the invention by operating on input data and generating output. Method steps can also be performed by and an apparatus can be implemented as special purpose logic circuitry.
  • the circuitry can, for example, be a FPGA (field programmable gate array) and/or an ASIC (application-specific integrated circuit). Modules, subroutines, and software agents can refer to portions of the computer program, the processor, the special circuitry, software, and/or hardware that implements that functionality.
  • processors suitable for the execution of a computer program include, by way of example, both general and special purpose microprocessors, and any one or more processors of any kind of digital computer.
  • a processor receives instructions and data from a read-only memory or a random access memory or both.
  • the essential elements of a computer are a processor for executing instructions and one or more memory devices for storing instructions and data.
  • a computer can include, can be operatively coupled to receive data from and/or transfer data to one or more mass storage devices for storing data (e.g., magnetic, magneto-optical disks, or optical disks).
  • Data transmission and instructions can also occur over a communications network.
  • Information carriers suitable for embodying computer program instructions and data include all forms of non-volatile memory, including by way of example semiconductor memory devices.
  • the information carriers can, for example, be EPROM, EEPROM, flash memory devices, magnetic disks, internal hard disks, removable disks, magneto -optical disks, CD- ROM, and/or DVD-ROM disks.
  • the processor and the memory can be supplemented by, and/or incorporated in special purpose logic circuitry.
  • the above described techniques can be implemented on a computer having a display device.
  • the display device can, for example, be a cathode ray tube (CRT) and/or a liquid crystal display (LCD) monitor.
  • CTR cathode ray tube
  • LCD liquid crystal display
  • the interaction with a user can, for example, be a display of information to the user and a keyboard and a pointing device (e.g., a mouse or a trackball) by which the user can provide input to the computer (e.g., interact with a user interface element).
  • Other kinds of devices can be used to provide for interaction with a user.
  • Other devices can, for example, be feedback provided to the user in any form of sensory feedback (e.g., visual feedback, auditory feedback, or tactile feedback).
  • Input from the user can, for example, be received in any form, including acoustic, speech, and/or tactile input.
  • the above described techniques can be implemented in a distributed computing system that includes a back-end component.
  • the back-end component can, for example, be a data server, a middleware component, and/or an application server.
  • the above described techniques can be implemented in a distributing computing system that includes a front-end component.
  • the front-end component can, for example, be a client computer having a graphical user interface, a Web browser through which a user can interact with an example implementation, and/or other graphical user interfaces for a transmitting device.
  • the components of the system can be interconnected by any form or medium of digital data communication (e.g., a communication network). Examples of communication networks include a local area network (LAN), a wide area network (WAN), the Internet, wired networks, and/or wireless networks.
  • LAN local area network
  • WAN wide area network
  • the Internet wired networks, and/or wireless networks.
  • the system can include clients and servers.
  • a client and a server are generally remote from each other and typically interact through a communication network.
  • the relationship of client and server arises by virtue of computer programs running on the respective computers and having a client-server relationship to each other.
  • Packet-based networks can include, for example, the Internet, a carrier internet protocol (IP) network (e.g., local area network (LAN), wide area network (WAN), campus area network (CAN), metropolitan area network (MAN), home area network (HAN)), a private IP network, an IP private branch exchange (IPBX), a wireless network (e.g., radio access network (RAN), 802.11 network, 802.16 network, general packet radio service (GPRS) network, HiperLAN), and/or other packet-based networks.
  • IP carrier internet protocol
  • LAN local area network
  • WAN wide area network
  • CAN campus area network
  • MAN metropolitan area network
  • HAN home area network
  • IP network IP private branch exchange
  • wireless network e.g., radio access network (RAN), 802.11 network, 802.16 network, general packet radio service (GPRS) network, HiperLAN
  • GPRS general packet radio service
  • HiperLAN HiperLAN
  • Circuit-based networks can include, for example, the public switched telephone network (PSTN), a private branch exchange (PBX), a wireless network (e.g., RAN, bluetooth, code-division multiple access (CDMA) network, time division multiple access (TDMA) network, global system for mobile communications (GSM) network), and/or other circuit-based networks.
  • PSTN public switched telephone network
  • PBX private branch exchange
  • CDMA code-division multiple access
  • TDMA time division multiple access
  • GSM global system for mobile communications
  • the transmitting device can include, for example, a computer, a computer with a browser device, a telephone, an IP phone, a mobile device (e.g., cellular phone, personal digital assistant (PDA) device, laptop computer, electronic mail device), and/or other communication devices.
  • the browser device includes, for example, a computer (e.g., desktop computer, laptop computer) with a world wide web browser (e.g., Microsoft® Internet Explorer® available from Microsoft Corporation, Mozilla® Firefox available from Mozilla Corporation).
  • the mobile computing device includes, for example, a personal digital assistant (PDA).
  • Comprise, include, and/or plural forms of each are open ended and include the listed parts and can include additional parts that are not listed. And/or is open ended and includes one or more of the listed parts and combinations of the listed parts.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention porte sur des procédés et des appareils à base d'ordinateur, comprenant des produits programmes d'ordinateur, pour une fonctionnalité de cryptage à couplage lâche pour des systèmes d'exploitation. Un paquet de données est traité par une ou plusieurs couches de pile de protocole Internet afin de générer un paquet de données traité. Des informations de cryptage qui comprennent des paramètres de cryptage et de décryptage de paquets de données transmis entre le premier dispositif informatique et l'ordinateur distant sont déterminées. Un message comprenant des données indicatives des informations de cryptage est envoyé à un second dispositif informatique, dans lequel un système d'exploitation exécuté n'est pas conscient d'une nature de sécurité de la transmission. Un programme de court-circuitage de cryptage est exécuté pour générer un paquet de données non crypté, le programme de court-circuitage de cryptage ne cryptant pas le paquet de données traité. Le paquet de données non crypté est envoyé au second dispositif informatique. Le paquet de données non crypté est crypté sur la base du message envoyé par le premier dispositif informatique afin de générer un paquet de données crypté.
PCT/US2011/030742 2010-04-29 2011-03-31 Fonctionnalité de cryptage à couplage lâche pour systèmes d'exploitation WO2011139440A2 (fr)

Applications Claiming Priority (4)

Application Number Priority Date Filing Date Title
US12/770,476 US20110271097A1 (en) 2010-04-29 2010-04-29 Loosely-Coupled Encryption Functionality for Operating Systems
US12/770,476 2010-04-29
US12/770,473 US20110271096A1 (en) 2010-04-29 2010-04-29 Loosely-Coupled Encryption Functionality for Operating Systems
US12/770,473 2010-04-29

Publications (2)

Publication Number Publication Date
WO2011139440A2 true WO2011139440A2 (fr) 2011-11-10
WO2011139440A3 WO2011139440A3 (fr) 2012-01-05

Family

ID=44904296

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2011/030742 WO2011139440A2 (fr) 2010-04-29 2011-03-31 Fonctionnalité de cryptage à couplage lâche pour systèmes d'exploitation

Country Status (1)

Country Link
WO (1) WO2011139440A2 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112543197A (zh) * 2020-12-04 2021-03-23 中船重工（武汉）凌久电子有限责任公司 一种xfrm框架下对ipsec实现硬件加解密的方法

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20050273850A1 (en) * 2004-06-07 2005-12-08 Check Point Software Technologies, Inc. Security System with Methodology Providing Verified Secured Individual End Points
US20080137848A1 (en) * 2003-07-07 2008-06-12 Cryptography Research, Inc. Reprogrammable security for controlling piracy and enabling interactive content
US20100071055A1 (en) * 2004-03-02 2010-03-18 Advanced Micro Devices, Inc. Two Parallel Engines for High Speed Transmit IPSEC Processing

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20080137848A1 (en) * 2003-07-07 2008-06-12 Cryptography Research, Inc. Reprogrammable security for controlling piracy and enabling interactive content
US20100071055A1 (en) * 2004-03-02 2010-03-18 Advanced Micro Devices, Inc. Two Parallel Engines for High Speed Transmit IPSEC Processing
US20050273850A1 (en) * 2004-06-07 2005-12-08 Check Point Software Technologies, Inc. Security System with Methodology Providing Verified Secured Individual End Points

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112543197A (zh) * 2020-12-04 2021-03-23 中船重工（武汉）凌久电子有限责任公司 一种xfrm框架下对ipsec实现硬件加解密的方法
CN112543197B (zh) * 2020-12-04 2022-09-06 中船重工（武汉）凌久电子有限责任公司 一种xfrm框架下对ipsec实现硬件加解密的方法

Also Published As

Publication number Publication date
WO2011139440A3 (fr) 2012-01-05

Similar Documents

Publication Publication Date Title
US20110271096A1 (en) Loosely-Coupled Encryption Functionality for Operating Systems
US10958627B2 (en) Offloading communication security operations to a network interface controller
JP2023116573A (ja) クライアント－クラウドまたはリモートサーバーの安全なデータまたはファイル・オブジェクト暗号化ゲートウェイ
CN109150688B (zh) IPSec VPN数据传输方法及装置
US9667601B2 (en) Proxy SSL handoff via mid-stream renegotiation
US7913261B2 (en) Application-specific information-processing method, system, and apparatus
EP2561663B1 (fr) Serveur et procédé permettant d'offrir un accès sècurisé à des service
US20110113236A1 (en) Methods, systems, and computer readable media for offloading internet protocol security (ipsec) processing using an ipsec proxy mechanism
JP5746446B2 (ja) ネットワーク付属のステートレス・セキュリティ・オフロード・デバイスを用いるネットワーク・ノード
EP3613195A1 (fr) Stockage sur le nuage utilisant une passerelle de chiffrement avec identification d'autorité de certificat
US11245674B2 (en) Secure communication protocol processing
US20050160269A1 (en) Common security key generation apparatus
US20110271097A1 (en) Loosely-Coupled Encryption Functionality for Operating Systems
US9467471B2 (en) Encrypted communication apparatus and control method therefor
US6920556B2 (en) Methods, systems and computer program products for multi-packet message authentication for secured SSL-based communication sessions
WO2011139440A2 (fr) Fonctionnalité de cryptage à couplage lâche pour systèmes d'exploitation
CN117254976B (zh) 基于VPP的国标IPsec VPN实现方法、装置、系统及电子设备
Agrawal et al. Performance analysis of offloading ipsec processing to hardware based accelerators
Morrison et al. IPSec: Protocol challenges and performance analysis and enhancements
Rosen et al. IPsec
JP2002077150A (ja) 暗号通信時の暗号化パケットの作成方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 11777759

Country of ref document: EP

Kind code of ref document: A2

NENP Non-entry into the national phase in:

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 11777759

Country of ref document: EP

Kind code of ref document: A2