HK1050969A - Protection of communications - Google Patents

Description

Communication protection

Background

The present invention relates to information protection for communication over a transmission medium, such as a network.

With the increasing use of networks or other transmission media for communication, security is becoming an increasing concern. Various security protocols are used to protect data entering or leaving devices coupled to a transmission medium such as a network (e.g., local area network, wide area network, internet). The security protocol includes cryptographic algorithms (including encryption, decryption, and authentication) to maintain confidentiality of transmitted information and authentication of the information source.

Cryptographic operations typically involve data intensive arithmetic operations that take up a considerable amount of processing by the system. To reduce the load on the system's main processor when performing cryptographic operations, some systems include a coprocessor to perform some data intensive processing. In a conventional coprocessor architecture, the host processor (under application control) loads into system memory the data to be processed (encrypted, scrambled, etc.) which is accessed by the coprocessor via the system bus. After processing, the coprocessor copies the processed data back to memory for access by the main processor, which then sends the data to a transmission medium (e.g., a network, telephone line, etc.). This process is inefficient because the data is copied over the bus to the system memory twice before being transferred over the transmission medium. Similarly, at the receiving end, the data is also copied in and out of the coprocessor twice before decryption and validation.

Running cryptographic operations in a conventional coprocessor architecture uses up valuable shared system resources, including the host processor, bus, and system memory, to make it unusable by other devices in the system. This may reduce the performance of the overall system. Accordingly, there is a need for techniques and apparatus to reduce the use of system resources in performing security protocol related operations when communicating information over a transmission medium.

SUMMARY

In general, according to one embodiment, a method for use in a device coupled to a communication channel includes determining a security service to be performed with a data block and processing the data block in accordance with the security service in a controller adapted to control communication with the communication channel.

Other features and embodiments will be apparent from the following description and from the claims.

Brief Description of Drawings

Fig. 1A is a block diagram of an embodiment of a system including a network and a device coupled to the network.

Fig. 1B is a block diagram of a network controller in a device of the system of fig. 1A according to one embodiment.

Fig. 2 is a block diagram of a device in the system of fig. 1A, according to an embodiment of the present invention.

Fig. 3 is a more detailed block diagram of the network controller of fig. 1B.

Fig. 4A-4C are diagrams of packets according to one security protocol used by the device of fig. 2.

Fig. 5 is a flow diagram of a security procedure according to an embodiment performed by the network controller of fig. 3.

Fig. 6 illustrates a flow tuple (flow tuple) stored in a storage device of the network controller of fig. 3.

Fig. 7 is a flowchart illustrating a receive parser of the network controller of fig. 5 parsing packet data.

Fig. 8 and 9A-9B are flow diagrams of different layers of security routines in the device of fig. 2.

FIG. 10 is a flow diagram of a process for determining security traffic associated with a data block executed by the security routine of FIG. 8.

Detailed Description

In the following description, numerous details are set forth to provide an understanding of the present invention. However, it will be understood by those skilled in the art that the present invention may be practiced without these details and that numerous variations and modifications from the described embodiments are possible.

Referring to fig. 1, an embodiment of the system includes a first device 50 and a second device 51 coupled to a transmission medium, which may be a wired or wireless transmission medium (or a combination of both). In the description that follows, the transmission medium is referred to as a network 47, which includes one or more types of transmission media, whether wired or wireless, such as telephone lines, cable lines, Local Area Networks (LANs), Wide Area Networks (WANs), the Internet, radio frequency links, cellular links, or other transmission media. Each of the devices 50 and 51 comprises a computer, handheld computing device, set-top box, application, gaming system, or other controller-based system, where the controller may be a microprocessor, microcontroller, programmable device such as an Application Specific Integrated Circuit (ASIC), Programmable Gate Array (PGA), or the like.

There may be different types of communication over the network 47 between the devices 50 and 51, as well as other devices. The communication includes: e.g., the sending of an email; browsing the Internet; file access and copying; searching a database; online sales and financial transactions, etc.

To provide secure communications between devices or systems on network 47, a security protocol according to some embodiments may be implemented in devices coupled to network 47. In certain embodiments, by implementing Internet Protocol Security (IPSEC) in devices coupled to network 47, as discussed in draft (RFC)2401 entitled "Security Architecture for the internet protocol" at month 11 of 1998, Security services may be provided to ensure secure communications between authorized parties, as described further below.

In the present description, reference is made to various drafts (RFCs) available on some internet websites. One such site is { http: html }/www.ietf.org/rfc.

As shown in fig. 1A, each of devices 50 and 51 (as well as other devices coupled to network 47) may include many layers and components capable of communicating over network 47. For example, in device 50, a network controller 52 (which may be an integrated network controller chip or a board or card containing several chips or some other hardware component) is coupled between network 47 and system bus 72. In an example embodiment, the system bus 72 may be a Peripheral Component Interconnect (PCI) bus as described in PCI local bus specification, production edition, revision 2.1, published by month 6 of 1995. A more complete diagram and description of the device 50 and the network controller 52 is provided in connection with fig. 2 and 3, respectively, below.

In accordance with certain embodiments, cryptographic processing (including encryption, decryption, and/or cryptographic signatures) as part of a network security protocol is performed by the network controller 52, which may be implemented as a hardware component, possibly along with associated firmware or "on-the-fly" or "in-transit" microcode, in order to improve system performance. Other types of controllers for controlling communications with a communication channel or transmission medium may also be used in further embodiments. Such a controller may comprise a pure hardware implementation or a combination of hardware and firmware or software.

With further reference to fig. 1B, the network controller 52 includes cryptographic engines (126 at the transmitting end and 102 at the receiving end) for performing encryption, decryption and authentication operations on data blocks to be transmitted or that have been received. An advantage of separating the cryptographic engines 102 and 126 on the receive and transmit channels is that the cryptographic processing of the transmit data and the receive data can be done simultaneously. In an alternative embodiment, a single engine may be used for sending and receiving data.

As used in this description, one or more data blocks refer to data in a different format in a device. For example, the data blocks from the transport and network layer 406 may comprise IP datagrams or packets (if the network layer is an IP layer). If the IPSEC protocol (e.g., AH or ESP) is used, the data block is converted into an IPSEC packet after IPSEC processing. The IP datagrams or packets and the IPSEC packets are reformatted after flowing through each of the different layers of the device 50. The security protocol may be applied to one or more IP datagrams or packets and IPSEC packets. Other types of data blocks may be defined if other security protocols are implemented. IPSEC can use one of two protocols to provide traffic security — an Authentication Header (AH) and an Encapsulating Security Payload (ESP). These protocols may be applied alone or in combination with one another to provide a desired set of security services. The AH protocol is described in RFC2402 entitled "IP Authentication Header" at month 11 of 1998, and the ESP protocol is described in RFC 2406 entitled "IP Encapsulating Security Payload (ESP)" at month 11 of 1998.

To reduce the complexity of the network controller 52, the generation of security control information associated with the security protocol is performed by one or more software routines (e.g., 410 and 411) in the device 50. In one embodiment, the security control information includes information identifying the encryption and authentication algorithms, key location, data location and length to be encrypted or signed, signature location, and other information used by the network controller 52 for cryptographic processing (including encryption, decryption, and/or authentication).

There are some examples (described below) in which multiple cryptographic operations are performed on a block of data by the network controller 52. To handle this situation, a loopback feature in the network controller 52 sends the data block processed by the crypto-engine 126 back to the device 50 for further processing by one or more software routines 410 and 411. After further processing by the software routines 410 and 411, the data block is sent back to the network controller 52 for further cryptographic processing.

Another feature of some embodiments is that the cryptographic engine 126 or 102 (or both) in the network controller 52 may be used by application processes other than those required to perform secure communications over the network 47. These application processes are referred to as secondary usage processes. For example, the secondary usage process performs communication to an external device through another interface (distinct from the network controller 52) of the device 50. The secondary usage process includes any process that does not perform or is incapable of performing cryptographic processing in transmission. Examples of secondary usage procedures include encrypted file systems, secure e-mails, secure Remote Procedure Calls (RPCs), and so forth. The cryptographic engine of the network controller 52 is used to perform such secondary usage cryptographic operations, rather than using a separate coprocessor or main processor 54.

The device 50 includes a policy management routine 413 that tracks security traffic available in the device 50. Policy management routine 413 maintains a database (e.g., 520A described below) that identifies security traffic to be performed with different data flows between different devices on network 47. For example, security services for devices coupled by a local area network are different from security services for devices coupled over an unsecured channel such as the internet. The device 50 also includes a key exchange component 415 for managing the generation and transmission of keys for use in encryption and authentication. The components 413 and 415 may be defined according to the Internet Security Association and Key Management Protocol (ISAKMP) described in draft (RFC)2408 of month 11, 1998.

Still referring to FIG. 1A, in device 50, system bus 72 is coupled to other devices in the system, including main processor 54, which may be coupled to system bus 72 by one or more bridge layers 59. By way of example, the processor 54 includes a microprocessor, microcontroller, ASIC, PGA, or the like. Data packets, frames, or blocks sent between network 47 and various applications (e.g., 402 and 404) pass through several layers of device 50. By way of example, application processes 402 and 404 include an email application, a web browser, a file manager, or other application program capable of accessing storage locations on network 47.

In the transmit and receive channels, data is routed between application processes 402, 404 and network 47 through network controller 52, network device driver 408, transport and network layer 406, and Operating System (OS) 400. The network and transport layer 406 may be a transmission control protocol/internet protocol (TCP/IP) stack to perform data routing and flow control as well as validation and ordering of data in the device 50. Thus, in one embodiment, the network layer may be the Internet Protocol (IP) layer as described in draft (RFC)791 entitled "Internet Protocol (Internet Protocol)" at 9 months 1981, which defines the Protocol for the transmission of blocks of data called datagrams from a source identified by source and destination IP addresses to a destination. Above the network layer is a transport layer, which may be, for example, a Transmission Control Protocol (TCP) or User Datagram Protocol (UDP) layer. TCP is described in draft (RFC)793 entitled "Transmission Control Protocol" at 9 months 1981. UDP is described in RFC 768 entitled "User Datagram Protocol" at 8 months 1980.

According to some embodiments, to implement the security protocol of the network 47 in the network controller 52, the security routine 410 in the network device driver 408 and the security routine 411 in the transport and network layer 406 format the data blocks according to the security protocol and add security information to be sent to the network controller 52 along with the associated data blocks. In this description, routine 410 is referred to as a driver security routine 410 and routine 411 is referred to as an IP security routine 411. In further embodiments, the tasks performed by security routines 410 and 411 may be performed by one routine or more than two routines.

Depending on the type of OS 400 used, the IP security routine 411 may be an integral part of the network and transport layer 406 (as shown in fig. 1) or a separate routine. For example, for Windows^NT version 5 operating system, IP security routine 411, may be part of layer 406. However, for Windows^NT version 4 or Windows^98 operating system, IP security routine 411 may be a separate routine.

Based on the security control information generated by the security routines 410 and 411, if any, the network controller 52 performs cryptographic processing (including encryption and/or authentication) of the data block before it is sent to the network 47. If the security control information indicates that cryptographic processing is not necessary, the network controller 52 sends the data block to the network 47 without sending the data block through the cryptographic engine 126 in the network controller 52.

At the receiving end, when the network controller 52 receives a data block, the network controller 52 determines from the security control portion that received the data block whether a cryptographic process is required, and if so, which key or keys to use to perform decryption and authentication.

According to some embodiments, the security protocols implemented in device 50 and some other devices coupled to network 47 include the IPSEC protocol. IPSEC provides secure services by enabling the device 50 to select the required security protocol, determine the algorithm to use for the service, and put in place any cryptographic keys that provide the desired service usage. Although the description herein refers to IPSEC security protocols such as the AH and ESP protocols, the invention is not limited in this respect. In further embodiments, other types of security protocols may be implemented. Also, in other embodiments, other types of transport and network layers besides the TCP and IP layers may be used.

In one embodiment, IP security routine 411 performs IPSEC processing on IP packets to be sent to network 47 or received from network 47. IPSEC processing includes converting IP packets into IPSEC packets or vice versa. According to some embodiments, the IPSEC packet may be an ESP packet or an AH packet. Security control information is contained in the IPSEC packet. Referring to fig. 4A-4C, after IPSEC processing, an IP datagram including an IP header 500 and an IP payload field 502 (fig. 4A) is sent to an ESP packet as shown in fig. 4B and 4C. The ESP packets shown in fig. 4B and 4C (ESP packets representing transmission mode and tunnel mode, respectively) include the following fields: ESP header 504, ESP trailer 506, and ESP verification field 508. In transport mode (fig. 4B), the ESP security protocol is applied to IP payload 502. But in tunnel mode, the ESP security protocol also applies to IP header 500-so a new IP header 510 is generated for tunnel mode (fig. 4C) ESP packets, which identifies, for example, a security gateway address. Tunnel mode ESP is typically used for communications over network 47 when passing through two security gateways. In an AH packet (not shown), the AH header may be added before the IP payload (transport mode) or before the IP header and IP payload (tunnel mode), but the trailer information is not added.

The header and trailer fields 504 and 506 of the ESP include the following: a Security Parameter Index (SPI) that identifies, in combination with certain other information, security traffic that is performed on the datagram; a sequence number that monotonically adds up and is included in the datagram as a defense against an attack in response; information such as cryptosync information; padding for encryption, such as for use as a block cipher; and other information. The authentication domain 508 is used to authenticate traffic.

ESP header 504 also includes IPSEC control information identifying the cryptographic algorithm applied by network controller 52, key location, data location and length to be encrypted and/or signed, and other information used for encryption and/or authentication. ESP header 504, among other things, includes an indication of whether the datagram will be sent over network 47 after being cryptographically processed or routed back to system bus 72 in a loopback mode. The ESP header includes a protocol type field that points to TCP, UDP, etc., in which case the datagram is sent over network 47. Alternatively, if the protocol type field points to ESP or AH, loopback is performed.

The AH header includes similar information for providing authentication services. However, AH does not provide encryption. In some embodiments, the AH and ESP protocols may be implemented in combination to provide secure traffic.

Encryption, decryption, and authentication algorithms are determined based on a Security Association (SA) of IP datagrams. The SA indicates the type of security traffic associated with the IP datagram. A detailed description of SA is provided in RFC 2401 referenced above. The security associations of different IP datagrams are stored in one or more security association data blocks (SADs) 520A and 520B, which may be stored in a storage medium such as main memory 56 or a hard disk drive. The security association may be managed by a policy management routine 413.

In the illustrated embodiment, SAD 520A is accessible by IP security routine 411 and SAD 520B is accessible by drive security routine 410. SAD 520B includes a subset of SAD 520A for faster access by driver security routine 410. In an alternative embodiment, to process packets received by network controller 52 over network 47, network controller 52 includes SAD520C, which is a subset of the information stored in SAD 520A or 520B.

For inbound processing of a received packet (either an IPSEC packet or an unencrypted IP datagram) from network 47, the SA of the packet is determined by network controller 52 from the following information in the received packet: a destination IP address; the IPSEC protocol (AH or ESP); and SPI values. The information listed from the received IPSEC datagram is compared to information stored in an entry 140 (referred to as a flow burst) in a storage device or memory (which may be static random access memory or SRAM, for example) of the network controller 52 to determine whether a match has occurred. A combination of these information may be used to program the SAD520C stored in the storage device 100. The SAD520C stored in the network controller 52 may be updated based on a Least Recently Used (LRU) replacement policy, a first-in-first-out (FIFO) policy, or other policy.

Thus, based on the SA (if any) of the received packet, the appropriate keys and other cryptographic information may be retrieved from a storage unit (e.g., in storage device 104 or elsewhere) to perform the decryption and authentication processes. While SAD520C is stored in the network controller of the illustrated embodiment, it is desirable that the security association information and stream tuples are stored on an external storage device coupled to the network controller.

For outbound processing of IP datagrams to be sent over network 47, IP security routine 411 determines the SA associated with the outbound IP datagram based on the particular field of the IP datagram. These fields indicate the source and destination devices and addresses from which the type of secure traffic for communicating between the source and destination devices can be determined. For example, the device is coupled to a local area network, in which case a first set of security services may be performed. If the device is coupled to a security gateway (e.g., a device that couples the LAN to an unsecured link such as the internet), a second set of security services are performed (providing enhanced security). The IP datagram is converted into an IPSEC packet including security control information based on the associated SA. The IPSEC packet is sent down by IP security routine 411 to driver security routine 410 of network device driver 408, which repacks the IPSEC packet for forwarding to network controller 52.

Referring to fig. 8, the security operations performed by the IP security routine 411 are illustrated. If an IP packet to be sent is detected (at 650), the IP security routine 411 determines (at 652) whether the IP packet is subject to a security protocol based on its SA. May be determined based on information in the SAD 520A and, if not, from information in a Security Policy Database (SPD)522 stored in a storage device, such as the system memory 56.

The SPD 522 indicates whether the datagram is provided with IPSEC protection or whether IPSEC protection is bypassed. If IPSEC protection is to be implemented for the datagram, a selected entry in SPD 522 maps with an SA that identifies the security traffic to be performed on the datagram, including whether the AH or ESP protocol is used, cryptographic algorithms for encryption/decryption and authentication, and so on. The identified security traffic is encoded by the IP security routine 411 into security control information (e.g., located in an ESP or AH header) for transmission to the network controller 52 for cryptographic processing.

Information in the IP datagram, referred to as a selector, may be used in entries programmed into SPD 522. These selectors include the following information: a destination IP address; a source IP address; transport layer protocols (such as TCP or UDP); and source and destination ports (e.g., TCP or UDP ports); and other information. The selector associated with the datagram is then used to perform a query of SPD 522 to retrieve information in the entries of SPD 522. In turn, the SPD entry information is used to determine the SA of the IP datagram, which is then loaded into the corresponding entry of SAD 520A.

Although there are references to SPD and SAD to identify the security traffic performed on the data block, the invention is not limited in this respect. Other techniques for determining security traffic may be used in further embodiments.

If the IP security routine 411 determines (at 652) that IPSEC protection is not to be used, the IP datagram is forwarded (at 655) to the network device driver 408 for transmission by the network controller 52 as a regular IP datagram over the network 47. However, if IPSEC protection is used, the IP datagrams are reformatted into IPSEC packets as shown in FIGS. 4A-4C as an example.

Next, the IP security routine 411 determines (at 656) whether the cryptographic operation is to be offloaded from the network device driver 408 and the network controller 52. According to some embodiments, offloading refers to the IP security routine 411 forwarding the cryptographic operation to a lower layer (e.g., the network controller 52) rather than the IP security routine 411 performing the cryptographic operation itself, which would take valuable time from the main processor 54. Offloading security traffic is not performed if, for example, network controller 52 does not support cryptographic operations, if the cryptographic operations are not costly to perform on processor 54, or if the offloading is more costly than performing cryptographic operations on CPU 54.

If an offload is required, an offload command (including security control information) is prepared (at 658) by the IP security routine 411 at the head of the IPSEC packet to indicate the type of algorithm used for encryption and/or authentication, the key location, the location and length of the data to be encrypted and/or signed, and other relevant information. If no offload is required, the IP security routine 411 performs the desired cryptographic operation (at 660) and includes a no-op command in the IPSEC packet sent to the driver security routine 410 of the network device driver 408 (to indicate that the cryptographic operation is necessary).

Referring to FIG. 9A, a transmit portion of a network device driver security routine 410 is illustrated. If the transmit data is received (at 700) from the IP security routine 411, the driver security routine 410 determines (at 702) whether the IPSEC packet is a secondary usage packet (i.e., a packet originating from a secondary usage process, such as 405). If so, the IPSEC packet is marked (at 710) as a loopback mode so that the packet can be returned to the secondary usage process (e.g., process 405 in FIG. 1A) after being cryptographically processed by the network controller 52. The packet is processed (at 706, described below) and sent to the network controller 52.

If the IPSEC packet is not a secondary use packet, the driver security routine 410 determines (at 704) whether the packet includes an offload command. If so, the driver security routine 410 determines (at 708) whether the packet includes multiple commands (e.g., executing multiple security protocols on the packet). If so, the IPSEC packet is marked (at 710) as loopback mode.

Next, the commands in the IPSEC packet are converted (at 706) into a format (including device-specific operations) that is understandable by the network controller for processing by the network controller 52. The IPSEC packet sent by the drive security routine 410 to the network controller 52 includes security control information identifying the encryption and/or authentication algorithm used, the key location, the location and length of the data to be encrypted and/or signed, and other relevant information. Based on the security control information, cryptographic processing is performed by the network controller 52 before the packet is sent to the network 47.

With further reference to FIG. 9B, a receive portion of the driver security routine 410 is illustrated. The driver security routine 410 receives (at 700) from the network controller 52 a packet received over the network 47 or a secondary usage packet that will be returned to the secondary usage application. The driver security routine 410 then determines (at 672) whether the packet is a secondary usage packet. If so, the packet is sent back (at 674) through its driver, e.g., a secondary usage process (e.g., 405).

If the received packet is not a secondary use packet, the driver security routine 410 determines (at 676) whether the received packet is an IPSEC packet. If not, the packet is sent (at 690) by the network device driver 408 up to the transport and network layer 406 for processing. If the packet is an IPSEC packet, the driver security routine 410 determines (at 678) whether the packet is "aligned (punt)" by the network controller 52. The network controller 52 cannot associate the SA with the received IPSEC packet based on a comparison with the limited SAD 520C. If the network controller 52 "aligns" the packet because the SA cannot be associated with the SAD520C stored in the network controller 52, the driver security routine 410 attempts (at 686) to match the received IPSEC packet with an entry in the SAD 520B. If no match is found, the packet is sent up (at 690) to the IP security routine 411 for processing. However, if the entry in the SAD 520B can match the aligned IPSEC packet, the IPSEC packet is modified to include the security control information for the associated SA and sent back (at 684) to the network controller 52 that is provided with loopback mode. Further cryptographic processing may be performed by the network controller 52. However, if the IPSEC packet is aligned because the network controller 52 cannot perform cryptographic processing, the packet is forwarded up to the transport and network layer 406 for processing.

If the driver security routine 410 determines (at 678) that the packet is not aligned by the network controller 52, the driver security routine 410 determines (at 680) whether additional IPSEC iterations are needed, such as for IPSEC packets with nested SAs. If not, the status information in the IPSEC packet (indicating that the network controller 52 performs processing such as including encryption and/or authentication) is converted (at 688) to a syntax that the IP security routine 411 can understand. The packet is then sent (at 684) to the IP security routine 411.

If at 680, additional IPSEC iterations are required, the driver security routine 410 attempts to match (at 682) the entry in the SAD 520B with the packet to identify its SA. If a match is found, the packet is sent back 684 to the network controller 52 with a loopback mode setting. If the SA for the packet is not found in the SAD 520B, the packet is sent back up (at 690) to the IP security routine 411 for processing.

Referring back to FIG. 8, when the IP Security routine 411 receives a packet from the driver Security routine 410, the IP Security routine 411 determines (at 662) whether the packet is an IPSEC packet. If not, the packet is sent (at 670) to the IP layer (406). If the packet is an IPSEC packet, the IP security routine 411 determines (at 664) whether the packet is aligned by the network controller 52 and the network device driver 410. If so, the IP security routine performs (at 666) full IPSEC processing, including cryptographic processing of the packet. Alternatively, the IP security routine 411 may determine the SA of the packet by accessing the SAD 520A or SPD 522, and security control information related to the SA may be sent down with the packet to the network controller 52 for cryptographic processing.

If the IPSEC packet is not aligned, then the IP security routine 411 performs (at 668) normal IPSEC processing to convert the packet into an IP datagram for transmission (at 670) to the IP layer.

Referring to fig. 10, the act of determining (at 652 of fig. 8) whether an IP packet can be associated with an SA performed by the IP security routine 411 includes determining (at 750) whether an entry related to the IP packet can be found in SAD 520A. This may be based, for example, on the particular selector described above. If a match is found in SAD 520A, then the SA is identified and a success flag is returned. However, if no match is found in the SAD 520A, the SPD 522 is accessed based on the selector (at 752). If a match cannot be identified, a failure flag is returned to indicate that there is no SA for the IP datagram. However, if a match is identified (at 752) in the SPD 522, the SA is identified (at 754) and loaded (at 756) into the SAD 520A. The IP security routine 411 then determines (at 758) whether security traffic associated with the identified SA can be offloaded to the network driver 52. In the preparation phase, the IP security routine 411 queries the driver security routine 410 to determine security traffic that is offloaded from the IP security routine 411 to the driver security routine 410. This information is maintained in the storage unit and identifies the type of encryption and authentication traffic performed by the drive security routine 410, the type of security protocols supported (e.g., AH and ESP), and so on. If security traffic can be offloaded, the SA is also copied (at 760) into the SAD 520B and optionally the SAD520C in the network controller 52. If security traffic cannot be offloaded, the identified SAs are not copied into SADs 520B and 520C.

When the SAD520C in the network controller 52 is updated, the IP security routine 411 determines whether the SAD520C is full and, if so, replaces the SA with some replacement strategy such as least recently used, first-in-first-out, random, etc. These update strategies may also be implemented in SADs 520A and 520B.

Referring to fig. 2, an embodiment of a device 50, which may be, for example, a computer system, includes a network controller 52, such as a Local Area Network (LAN) controller, in packet communication with other network devices, such as hosts, gateways, routers, etc., over a network 47. The network controller 52 is adapted to perform operations typically performed by a host processor 54, the host processor 54 executing one or more software layers (e.g., network layers and transport layers) of a network protocol stack (e.g., TCP/IP). As an example, these operations may include parsing the header of an incoming packet to obtain features (of the packet) that are typically extracted by the executing software layer.

In some embodiments, these features in turn identify the application process that receives the packet data. Because of this identification of the network controller 52, the network controller 52 (which is not a software layer of the stack) may directly control the transmission of packet data to the application-related buffer (in the system memory 56). As a result of this arrangement, data transmission between the network controller 52 and the system memory 56 will take less time and utilize memory space more efficiently, as described in detail below.

Referring to fig. 3, the network controller 52 includes circuitry such as a receive path 92 and a transmit path 94 that process packets received from or transmitted to the network 47. For example, the receive path 92 includes a receive parser 98 for parsing each packet header to extract packet characteristics, such as characteristics associated with a particular packet flow. Because the receive channel 92 may receive incoming packets from many different streams (packets from different devices of the network 47), the receive channel 92 includes a memory 100 that stores stream bursts 140. Each stream burst 140 uniquely identifies a stream to be parsed by the network controller 52.

Referring to fig. 6, each stream burst 140 includes fields that identify particular stream characteristics. By way of example, in some embodiments, at least one of stream bursts 140 is associated with a Transmission Control Protocol (TCP), a User Datagram Protocol (UDP), or the like. Stream burst 140 includes a field 142 indicating an Internet Protocol (IP) destination address (i.e., the address of the device receiving the packet); a field 144 indicating the IP source address (i.e., the address of the device sending the packet); a field 146 indicating the destination port of the TCP (i.e. the address of the application that caused the packet generation); a field 148 indicating the TCP source port (i.e., the address of the application receiving the packet); a domain 150 indicating security/authentication attributes of the packet; and an SPI field 152. Other fields are also included in the stream burst. Other stream bursts 140 may be associated with other network protocols, such as UDP.

Referring again to fig. 3, the transmit channel 94 of the network controller 52 includes a transmit parser 114 coupled to the system bus interface 130 to receive packet data outbound from the device 50 and form a header in the packet. To accomplish this, in some embodiments, the transmit parser 114 stores the headers of the predetermined streams in a header memory 116. Because the header of a particular flow indicates a significant amount of the same information (e.g., port and IP address), sending parser 114 may slightly modify the memory header of each outgoing packet and fit the modified header into the outgoing packet. As an example, for a particular flow, the transmit parser 114 receives a header from the header memory 116 and parses the header to add information such as a sequence number and an acknowledgement number (as an example) in the header of the outgoing packet. The checksum engine 120 computes a checksum of the IP and network header of the outgoing packet and incorporates the checksum into the packet.

The transmit channel 94 also includes a cryptographic engine 126 that encrypts and/or verifies data of the outgoing packet. As such, all packets of a particular flow are encrypted and/or authenticated by the key associated with that flow, and the keys for different flows are stored in key store 124. As described above, the cryptographic key is based on the cryptographic algorithm used.

In some embodiments, new keys may be added to the key store 124 and existing keys may be modified or deleted by information communicated in the control packet domain through the transmit channel 94. The transmit channel 94 also includes one or more FIFO memories 122 to synchronize the packet flow through the transmit channel 94. Parallel-to-serial conversion circuit 128 is coupled to FIFO memory 122 to retrieve packets ready for transmission for the purpose of serializing the data of outgoing packets. Once serialized, circuit 128 passes the data to network interface 90 for transmission to network 47.

Referring to fig. 5, the secure operation of the network controller 52 is illustrated. Upon receiving a datagram for transmission (at 602), the transmit parser 114 accesses the security control information and commands of the IPSEC packet to determine whether to use cryptographic processing. If the security information and commands indicate that no security protocol is implemented (at 604), then transmit parser 114 passes the datagram to queue 122, which is forwarded (at 614) to network interface 90 for transmission to network 47. In this case, the cryptographic engine 126 is bypassed.

If secure traffic is required (at 604) based on the security control information and command, the relevant key is retrieved from the key store 124 and passed to the cryptographic engine (at 606) to perform encryption and authentication operations. If the key is not available in the key store 124, the network controller 52 accesses another storage location external to the network controller 52 to retrieve the key, as described below. According to certain embodiments, the security control information of the IPSEC packet indicates various types of encryption algorithms, such as symmetric encryption algorithms including block ciphers or stream ciphers, public key algorithms, and other algorithms. The authentication algorithm includes the following examples: a key Message Authentication Code (MAC) based on a symmetric encryption algorithm such as the Data Encryption Standard (DES); a one-way hash function such as a message digest function (MD5) or a Secure Hash Algorithm (SHA); or other algorithms. Descriptions of MAC, DES, MD5, and SHA can be found in (second 1996) applied cryptography by John Wiley & Sons, Inc., Bruce Schneier.

The cryptographic engine 126 then performs encryption and authentication processing (at 608) on the data based on the type of algorithm employed and the key retrieved from the key store 124 (fig. 3). The cryptographic engine 126 then determines (at 610) whether a loopback mode is invoked, in which cryptographically processed data is routed (at 612) back to the receive channel 92 over the link 127 (FIG. 3). The data is sent back to other layers of the device 50 (e.g., security routines 410 and 411) for further processing. This is determined based on information contained in the ESP or AH header of the IPSEC packet. Loopback mode may be used for a number of reasons, including the use of datagrams of nested SAs that employ multiple passes to complete cryptographic processing by cryptographic engine 126. If not only one security protocol is applied to the datagram, such as a combination of AH and ESP protocols or the use of IP tunnels, multiple nested SAs may be used.

The application process (secondary usage process, e.g., process 405) in device 50 may also use the loopback function for data not sent over network 47. For example, data from the application 405 may be sent and received through some other interface in the device 50, such as a modem or other transceiver 75 coupled to the expansion bus 70 or other bus. These data also require cryptographic processing. Instead of performing a cryptographic operation using the host processor 54 or other co-processor, the operation may be performed by a cryptographic engine 126 in the network controller 52.

Loopback functionality may also be used when a received datagram cannot be identified based on stream burst 140 stored in SPD 522. Such datagrams are sent up through the receive path 92 to higher layers such as security routines 410 and 411. Security routines 410 and 411 can then determine how to further process the received datagram. For example, in embodiments where only a portion of the SAD520 is available in the network controller 52, the security routines 410 and 411 may access the entire SAD in the device to determine the SA for the received data. If the security routines 410 and 411 successfully determine the SA, the SAD section 520 in the network controller 52 may be updated and the data and associated security information may be sent back to the network controller 52 for cryptographic processing.

Security routines 410 and 411 also have other functions, such as preventing replay attacks. To implement such other functionality, the security routines 410 and 411 perform cryptographic processing as many times as necessary with the loopback function.

If loopback is not employed, as determined at 610, the data processed by the cryptographic engine 126 is forwarded (at 614) for transmission by the network interface 90.

Referring again to fig. 3, the receive parser 98 in the receive channel 92 uses the stored stream burst 140 to determine whether the received packet needs to be cryptographically processed in accordance with a particular security protocol. According to certain embodiments, in the receive path of the network controller 52, the receive parser 98 compares the information in the received datagram with a subset of the stream burst 140 (fig. 6) stored in the memory 100 to identify the SA of the datagram. For example, in some embodiments, receiving parser 98 uses fields 142, 150, and 152 (destination IP address; IPSEC protocol (AH or ESP; and SPI value) to identify a stream burst so that the SA of an incoming datagram can be determined. If a stream burst hit occurs, the stream burst is used to map into SAD520C to determine the SA of the data.

Additional stream bursts 140 are stored in memory 100 and existing stream bursts 140 may be purged from memory 100 by network device driver 408. In certain embodiments, memory 100 also stores information field 141. Each 141 field is associated with a particular stream burst 140 and indicates, for example, a handler that identifies (to the network protocol stack) the stream and cached pointers to system memory 56, as described below.

If the receive parser 98 identifies (via stream bursts 140) a stream associated with an incoming packet, the receive path 92 further processes the packet. In some embodiments, the receive parser 98 (for other circuits of the network controller 52 and finally for the network protocol stack) indicates the identification of the flow associated with a particular packet and other detection attributes of the packet.

If the receive parser 98 does not recognize the flow, the receive channel 92 identifies the packet as aligned and passes the incoming packet through the system bus interface 130 to the security routines 410 and 411 for processing, as described above.

In some embodiments, once the SA of an incoming packet is determined, the associated key is retrieved from the key store 104 so that the cryptographic engine 102 can perform its cryptographic operations. The keys in the key store 104 are indexed by the SA receiving the data.

The key may be added to or deleted from the key store 104 by the network device driver 408. In this manner, if the engine 102 determines that a particular decryption key is not stored in the key store 104, the engine 102 submits a request for the key to the device driver 408 (see FIG. 2) (via the system bus interface 130). In this manner, the device driver 408 causes the processor 54 to provide the key in response to the request and to interact with the system bus interface 130 to store the key in the key store 104. In some embodiments, if the key is not available (i.e., the key is not available from the device driver 408 or stored in the key store 104), the engine 102 does not decrypt the data portion of the packet. Instead, the system bus interface 130 stores the encrypted data at a predetermined location in the system memory 56 (see FIG. 2) so that software of one or more layers of the protocol stack may be executed to decrypt the data portion of the incoming packet, as described above.

After parsing has been performed, processing of the packet by the network controller 52 includes bypassing execution of one or more software layers associated with the network protocol stack. For example, the receive path 92 includes a zero copy parser 110 that may copy data associated with the packet to a memory cache associated with the application process via a system bus interface 130. As described below, the zero-copy parser 110 handles, among other things, control issues between the network controller 52 and the protocol stack, and handles incoming packet loss situations.

The receive channel 92 also includes one or more first-in-first-out (FIFO) memories 106 to synchronize the flow of incoming packets through the receive channel 92. The checksum engine 108 (of the receive channel 92) is coupled between the FIFO memory 106 and the system bus interface 130 to validate the checksum embedded in the packet.

The receive channel 92 may interface with the system bus 72 on a system bus interface 130. The system bus interface 130 includes an emulated Direct Memory Access (DMA) engine 131 for sending the data portion of the packet directly to the main memory 56.

In certain embodiments, receive path 92 includes additional circuitry, such as serial-to-parallel conversion circuitry 96 that receives a serial bit stream from network interface 90 when a packet is received from network 47. In this manner, conversion circuit 96 packs the bits into bytes and provides the bytes to receive parser 98. Network interface 90 may be coupled to generate and receive signals to and from network 47.

Referring to fig. 7, the operational flow in the network controller 52 in response to receiving a packet over the network 47 is illustrated. The receive parser 98 parses (at 200) the header of each incoming packet. From the parsed information, the receive parser 98 determines whether the packet (e.g., an IPSEC packet) is associated with certain security protocols (at 201).

If validation or decryption is required, the receiving parser 98 uses the parsed information from the header to determine (at 216) whether a stream burst hit occurred in order to determine the relevant SA. If not, the receiving parser 98 sends control to the zero-copy parser 110 to perform end-of-packet detection (at 202). Otherwise, the receiving parser 98 determines (at 220) whether the key indicated by the SA is available in the key store 104. If the key is available, the receiving parser 98 begins verification and/or decryption of the packet (at 218) before passing control to the zero-copy parser 110 which performs zero-copy of the packet (at 202). If the key is not available, the receiving parser 98 sends control to the zero-copy parser 110 to perform a zero-copy operation (at 202).

After performing the zero-copy operation (at 202), the zero-copy parser 110 performs end-of-packet detection (at 204). Among these tests, the receive parser 98 performs tests typically associated with the data link layer. For example, receive parser 98 ensures that the packet indicates a correct ethernet MAC address, that no Cyclic Redundancy Check (CRC) errors occur, that no receive status errors occur (e.g., collision, overrun, minimum/maximum frame length error), and that the length of the frame is greater than the minimum number of bytes (e.g., 64). The receiving parser 98 performs detection typically related to the network layer. For example, the receive parser 98 detects the size of the IP packet header, calculates a checksum of the IP header, determines whether the calculated checksum of the IP header is consistent with the checksum indicated by the IP header, ensures that the packet indicates the correct IP destination address, and determines whether the IP indicates an identifiable network protocol (e.g., TCP or UDP protocol).

The receive parser 98 also performs detection typically associated with functions performed by software of the processor associated with the transport layer. For example, the receive parser 98 determines whether the size of the protocol header is within predetermined limits, calculates a checksum of the protocol header, and determines whether flags referred to as ACK, URG, PHS, RST, FIN, and/or SYN flags are set. If the PSH flag is set, the receiving parser 98 indicates this event to the driver program. If the RST, FIN, or SYN flag is set, the receiving parser 98 passes control to the transport layer. If an ACK flag is sent, receive parser 98 interacts with device driver 408 or transmit channel 94 to send an acknowledgement packet, as described below.

After the detection is complete, the zero copy parser 110 determines (at 205) whether a data link error occurs that may result in the packet being unavailable. If this occurs, the zero copy parser 110 evicts (at 205) the memory allocated to the packet by the driver program, (at 207) evicts the memory allocated to the zero copy of the packet and (at 209) resets the DMA channel (emulated by the DMA engine 131) associated with the packet. Otherwise, the zero copy parser 110 compiles an error statistics stack for the protocol stack.

Referring back to FIG. 2, in addition to network controller 52, computer system 50 includes a processor 54 coupled to a host bus 58. The host bus 58 is coupled by a bridge or memory hub 60 to an Accelerated Graphics Port (AGP) bus 62, as described in the accelerated graphics port interface specification, revision 2.0, month 5 of 1998. The AGP bus 62 is coupled to, for example, a video controller 64 that controls a display 65. The memory hub 60 also couples the AGP bus 62 and the host bus 58 to the memory bus 61. The memory bus 61, in turn, is coupled to system memory 56, which stores a cache 304 and a copy of the device driver 408, for example.

The memory hub 60 is also coupled (via a hub link 66) to another bridge, or input/output (I/O) hub 68, that is coupled to an I/O expansion bus 70 and a system bus 72. The I/O hub 68 is also coupled to, for example, a Compact Disc (CD) or Digital Versatile Disc (DVD) drive 82 and a hard disk drive 84. The I/O expansion bus 70 may be coupled to an I/O controller 74 that controls the operation of a floppy disk drive 76 and receives input data, such as from a keyboard 78 and a mouse 80.

Various software or firmware (e.g., comprised of modules, routines, or other layers) including application programs, operating system modules or routines, device drivers, BIOS modules or routines, and interrupt handlers are stored on or otherwise tangibly embodied in one or more storage media of device 50 or other similar device. Storage media suitable for tangibly embodying software and firmware instructions include various forms of memory, including semiconductor memory devices such as dynamic or static Random Access Memory (RAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks such as fixed disks, floppy disks, and removable disks; other magnetic media including magnetic tape; and optical media such as CD or DVD discs. The instructions stored in the storage medium, when executed, cause the apparatus 50 to perform programmed operations.

The software and firmware may be loaded into the device 50 in one of many different ways. For example, instructions or other code segments stored on a storage medium or transmitted over a network interface card, modem, or other interface mechanism, are loaded into device 50 and executed to perform programmed operations. During loading or transmission, data signals embodied as carrier waves (transmitted over telephone lines, network lines, wireless links, cables, etc.) convey instructions or code segments to device 50.

While the invention has been disclosed with respect to a limited number of embodiments, those skilled in the art will appreciate numerous modifications and variations therefrom. It is intended that the appended claims cover all such modifications and variations as fall within the true spirit and scope of this present invention.

Claims (20)

1. A method for use in a device coupled to a communication channel, comprising:

determining a security service to be performed on the data block;

generating security information for communication with the data block, the security information identifying a security service; and

in a controller adapted to control communication with the communication channel, the data blocks are processed in accordance with the security information.

2. The method of claim 1, wherein processing comprises performing cryptographic processing of the data block.

3. The method of claim 1, further comprising:

receiving a block of data from a software routine; and

the processed data block is routed back to the software routine after processing.

4. The method of claim 1, further comprising:

determining whether the security service is executable by the controller; and

if not, the data block is processed according to a software routine rather than a security service in the controller.

5. The method of claim 1, further comprising identifying the security service according to an internet protocol security protocol.

6. A method for use in a device including a controller adapted to control communication with a transmission medium, comprising:

receiving data from a routine of the device;

sending data to the controller to perform cryptographic processing of the data; and

after cryptographic processing, the processed data block is sent back to the routine.

7. The method of claim 6, further comprising sending the processed data to the controller at least one additional time to perform further cryptographic processing.

8. A method for use in a device including a controller adapted to control communication with a transmission medium, comprising:

receiving data from a transmission medium;

determining from a portion of the data whether to use cryptographic processing of the data; and

cryptographic processing of the data is performed in the controller.

9. The method of claim 8, wherein the performing of the cryptographic process is performed by a cryptographic engine in the controller.

10. The method of claim 8, further comprising:

determining whether cryptographic processing is executable by the controller; and

if the controller is unable to perform cryptographic processing, the cryptographic processing is instead performed in a software routine.

11. An article comprising a machine-readable storage medium containing instructions for execution in a system comprising a controller adapted to control communication with a communication channel, the instructions when executed causing the system to:

identifying security traffic to be performed on data to be transmitted over a communication channel; and

security control information, which is passed to the controller together with the data, is prepared to perform processing according to the identified security service.

12. The article of claim 11, the storage medium comprising instructions that when executed further cause the system to perform processing in accordance with the identified security service in place of the controller if the security service cannot be executed by the controller.

13. An article comprising a machine-readable storage medium containing instructions for execution in a system comprising a controller adapted to control communication with a communication channel, the instructions when executed causing the system to:

receiving a data block from a controller;

determining from information in the data block whether a security service has been performed on the data block by the controller; and

the data block is processed if the security traffic is not executed by the controller on the data block.

14. The article of claim 13, the storage medium comprising instructions that when executed cause the system to retrieve security information associated with the data block and send the data block and the security information to the controller to perform the security service.

15. The article of claim 13, said storage medium comprising instructions that when executed cause a system to perform a security service on the data block.

16. A controller for controlling communication with a transmission medium, the controller comprising:

a receiving circuit that receives data and related security control information; and

a cryptographic engine to cryptographically process data based on security control information.

17. The controller of claim 16, further comprising a storage device containing information identifying the secure transaction to be performed, the received secure control information selecting a portion of the secure transaction information in the storage device, wherein the cryptographic engine processes data according to the selected portion of the secure transaction information.

18. The controller of claim 17, further comprising a device adapted to change the contents of the storage device to update the security service information.

19. The controller of claim 18, wherein the device is adapted to update the secure traffic information based on a predetermined replacement policy.

20. The controller of claim 17, wherein the secure traffic information includes security association information.