WO1997000471A2 - A system for securing the flow of and selectively modifying packets in a computer network - Google Patents

A system for securing the flow of and selectively modifying packets in a computer network Download PDF

Info

Publication number
WO1997000471A2
WO1997000471A2 PCT/IL1996/000017 IL9600017W WO9700471A2 WO 1997000471 A2 WO1997000471 A2 WO 1997000471A2 IL 9600017 W IL9600017 W IL 9600017W WO 9700471 A2 WO9700471 A2 WO 9700471A2
Authority
WO
WIPO (PCT)
Prior art keywords
packet
computer network
packet filter
network
data packets
Prior art date
Application number
PCT/IL1996/000017
Other languages
French (fr)
Other versions
WO1997000471A3 (en
Inventor
Gil Shwed
Shlomo Kramer
Nir Zuk
Gil Dogon
Ehud Ben-Reuven
Original Assignee
Check Point Software Technologies Ltd.
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 to US08/168,041 priority Critical patent/US5606668A/en
Priority to IL11418295A priority patent/IL114182A/en
Priority to IL114182 priority
Application filed by Check Point Software Technologies Ltd. filed Critical Check Point Software Technologies Ltd.
Priority claimed from JP50287697A external-priority patent/JP3847343B2/en
Publication of WO1997000471A2 publication Critical patent/WO1997000471A2/en
Publication of WO1997000471A3 publication Critical patent/WO1997000471A3/en

Links

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L29/00Arrangements, apparatus, circuits or systems, not covered by a single one of groups H04L1/00 - H04L27/00
    • H04L29/02Communication control; Communication processing
    • H04L29/06Communication control; Communication processing characterised by a protocol
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227Filtering policies
    • H04L63/0263Rule management
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0272Virtual private networks
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/123Applying verification of the received information received data contents, e.g. message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00Cryptographic mechanisms or cryptographic arrangements for secret or secure communication
    • H04L9/32Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
    • H04L9/3247Cryptographic mechanisms or cryptographic arrangements for secret or secure communication including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures

Abstract

A novel system for controlling the inbound and outbound data packet flow in a compute network by which private networks can be secured from outside attacks. A user generates a rule base (400) which is converted into a set of filter language instructions where each rule includes a source, destination, service, whether to accept or reject the packet and whether to log the event. The filter language instructions are executed on inspection engines (204) on computers acting as firewalls (124) positioned in the network such that all traffic is forced to pass through the firewall. Packets are filtered in accordance with the rule base. The inspection engine acts as a virtual packet filter machine (600) determinng whether to accept or reject a packet. If a packet is rejected, it is dropped, and if accepted may be modified. Modifications, performed in accordance with the rule base, may include encryption, decryption, signature generation or verification, or address translation.

Description

A SYSTEM FOR SECURING THE FLOW OF AND SELECTIVELY MODIFYING PACKETS IN A COMPUTER NETWORK

BACKGROUND OF THE INVENTION

This application relates, in general, to a method for controlling computer network security. More specifically it relates to an easily alterable or expandable method for computer network security which controls information flow on the network from/to extemal and intemal destinations. Connectivity and security are two conflicting objectives in the computing environment of most organizations. The typical modem computing system is built around network communications, supplying transparent access to a multitude of services. The global availability of these services is perhaps the single most important feature of modem computing solutions. Demand for connectivity comes both from within organizations and from outside them.

Protecting network services from unauthorized usage is of paramount importance to any organization. UNIX workstations, for example, once connected to the Intemet, will offer all the services which it offers another station on the next table to the entire world. Using current technology, an organization must give up much of its connectivity in order to prevent vulnerability, even to the extent of eliminating all connections to the outside world or other sites.

As the need for increased security grows, the means of controlling access to network resources has become an administrative priority. In order to save cost and maintain productivity, access control must be simple to configure and transparent to users and applications. The minimization of setup costs and down time are also important factors.

Packet filtering is a method which allows connectivity yet provides security by controlling the traffic being passed, thus preventing illegal communication attempts, both within single networks and between connected networks. Current implementation of packet filtering allows specification of access list tables according to a fixed format. This method is limited in its flexibility to express a given organization's security policy. It is also limited to the set of protocols and services defined in that particular table. This method does not allow the introduction of different protocols or services which are not specified in the original table. Another method of implementing packet filtering is tailoring the computer operating system code manually in every strategic point in the organization. This method is limited by its flexibility to future changes in network topology, new protocols, enhanced services and to future security threats. It requires a large amount of work by experts modifying proprietary computer programs, making it insufficient and expensive to setup and maintain.

In addition, the need for secure long distance communications between enteφrises, branch offices and business partners is becoming an essential requirement in modem day business practice. Historically, dedicated point-to-point connections between networks were employed for fully private inter-enteφrise commerce and long distance transactions. However, their inflexibility and prohibitive cost have prevented their widespread use. Public networks such as the Intemet provide a flexible and inexpensive solution for long distance inter¬ networking. Instead of establishing dedicated Iines, enteφrises can communicate using the Intemet as a mediator. Once connected to a local intemet provider, private networks can quickly connect to any destination around the world.

A private network that uses some public segments is called a virtual private network (VPN). A VPN is significantly less expensive and more flexible than a dedicated private network. Each of the private networks need only be connected to a local Intemet provider. Adding new connections is simple and inexpensive. However, a major disadvantage of a VPN is that it is insecure because of its insecure segments. The Intemet connection exposes the enteφrise to the following two dangers: (1) unauthorized Intemet access into intemal enteφrise networks (break-ins) and (2) eavesdropping on and tampering with enteφrise communication as they pass through the Intemet. The security risks involved in communicating over the Internet have deterred enteφrises from taking full advantage of VPNs. Doing business over the Internet (e.g., transferring funds, obtaining and verifying credit information, selling and delivering products) requires a reliable and effective security solution.

SUMMARY OF THE INVENTION

Accordingly, the present invention seeks to provide an improved flexible, easily-alterable security method which controls information flow on a computer network to that described in copending coassigned U.S. Patent Application 08/168,041.

Another object of the invention is to control information flow on the network from/to internal as well as external destinations where the control includes at least one of the encrypting the information and modify the source and/or destination address. Yet another object of the invention is to control information flow by means of a packet filter capable of examining every packet of information flowing past a node in the system, the packet being encrypted.

A further object of the invention is to control information flow by the packet filter wherein the packet filter is capable of passing the packet only if it is preauthorized, preferably after a nondestructive connection validity check.

Another object of the invention is to provide a generic packet filter module which is controlled by a set of instructions to implement a given security policy at a node to accept (pass) or reject (drop) the packet wherein the packet is passed only if it passage is preauthorized. Yet another object of the invention is to provide a security method for a computer network which is easily alterable by the system administrator without the need to change the nature of the packet filter itself or to write extensive code.

Another object of the invention is to provide an improved connection validity check. Yet another object of the invention is to provide the ability to modify the packet by any of encrypting it, modifying a destination address, accepting external inputs as criteria for accepting, rejecting or modifying the network communication. Another object of the present invention is to provide an encryption scheme for securing the flow of data over insecure public networks, such as the Internet, thus forming a VPN.

According to an aspect of the present invention, there is provided a computer system to secure transactions over networks by encrypting them, inter- connect various networks with different addressing schemes and provides ways to pass packets of information only when the source of the communication is authorized and detecting the validity of traffic through the network while minimizing the information required to achieve it, preferably in a fail-safe architecture. There is provided in accordance with a preferred embodiment of the present invention a method of inspecting and selectively modifying inbound and outbound data packets in a computer network, the inspection and selective modification of the data packets occurring in accordance with a security rule, the method including the steps of generating a definition of each aspect of the computer network inspected by the security rule, generating the security rule in terms of the aspect definitions, the security rule controlling at least one of the aspects, converting the security rule into a set of packet filter language instructions for controlling an operation of a packet filtering module which inspects and selectively modifies the data packets in accordance with the security rule, coupling the packet filter module to the computer network for inspecting and selectively modifying the data packets in accordance with the security rule, the packet filter module implementing a virtual packet filtering machine, and the packet filter module executing the packet filter language instructions for operating the virtual packet filtering machine to either accept or reject the passage of the data packets into and out of the network computer and selectively modify the data packets so accepted.

Further, the aspects can include network objects, network services or network services. In addition, the object definitions include the address of the object and the filter language instructions of the step of converting are in the form of script and further comprise a compiler to compile the script into the instructions executed in the step of executing.

Still further, both the steps of generating the aspects of the network and of the security rule are defined graphically and the selective modification is chosen from the group consisting of encryption, decryption, signature generation and signature verification.

There is also provided in accordance with a preferred embodiment of the present invention, in a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, the security system inspecting and selectively modifying the data packets in the computer network in accordance with a security rule, where each aspect of the computer network inspected by the security rule has been previously defined, the security rule being previously defined in terms of the aspects and converted into packet filter language instructions, a method for operating the security system including the steps of providing a packet filter module coupled to the computer network in at least one entity of the computer network to be inspected by the security rule, the packet filter module implementing a virtual packet filtering machine inspecting and selectively modifying the data packets passing into and out of the computer network, and the packet filter module executing the packet filter language instructions for operating the virtual packet filtering machine to either accept or reject the passage of the data packets into and out of the computer network and to selectively modify the data packets so accepted. Also provided in accordance with a preferred embodiment of the present invention, in a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, the security system inspecting and selectively modifying the data packets in the computer network in accordance with a security rule, where each aspect of the computer network inspected by the security rule has been previously defined, the security rule being previously defined in terms of the aspects and converted into packet filter language instructions, a method for operating the security system including the steps of providing a packet filter module coupled to the computer network in at least one entity of the computer network to be controlled by the security rule, the packet filter module emulating a virtual packet filtering machine inspecting and selectively modifying the data packets passing into and out of the computer network, the packet filter module reading and executing the packet filter language instructions for performing packet filtering operations, storing the results obtained in the step of reading and executing the packet filter language instructions in a storage device, and the packet filter module utilizing the stored results, from previous inspections, for operating the packet filter module to accept or reject the passage of the data packets into and out of the computer network and to selectively modify the data packets so accepted.

In addition, there is also provided in accordance with a preferred embodiment of the present invention, in a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, the security system inspecting and selectively modifying the data packets passing through the computer network in accordance with a security rule, where each aspect of the computer network controlled by the security rule has been previously defined, the security rule being previously defined in terms of the aspects and converted into packet filter language instructions, the security system including a packet filter module coupled to the computer network, the packet filter module operating in accordance with the security rule, the packet filter module implementing a virtual packet filtering machine inspecting and selectively modifying the data packets passing into and out of the computer network, and processing means for reading and executing the packet filter language instruction integral with the packet filter module, the processing means operating the packet filtering module to either accept or reject the passage of the packets into and out of the computer network and to selectively modify the data packets so accepted.

BRIEF DESCRIPTION OF THE DRAWINGS

Fig. 1 is an example of a network topology;

Fig. 2 shows a security system of the present invention applied to the network topology of Figure 1 ; Fig. 3 shows the computer screen of the network administrator of Figure 2 in greater detail;

Fig. 4 is a flow diagram of the subsystem for converting graphical information to filter script;

Fig. 5 is a flow diagram of an information flow on a computer network employing the present invention;

Fig. 6 is a flow diagram of the operation of the packet filter shown in Figure 5;

Fig. 7 is a flow diagram showing the virtual machine operations shown in Figure 6; Fig. 8 is a flow diagram of the data extraction method of Figure 7;

Fig. 9 is a flow diagram of the logical operation method of Figure 7; Fig. 10 is a flow diagram of the comparison operation method of Figure 7; Fig. 11 is a flow diagram of the method of entering a literal value to memory; Fig. 12 is a flow diagram of a conditional branch operation;

Fig. 13 is a flow diagram of an arithmetic and bitwise operation; Fig. 14 is a flow diagram of a lookup operation; Fig. 15 is a flow diagram of a record operation;

Fig. 16 is a high level block diagram illustrating an example configuration employing firewalls constructed in accordance with the present invention;

Fig. 17 is a high level block diagram illustrating the data transferred between two firewalls during a session key exchange;

Fig. 18 is a high level logic flow diagram illustrating the process performed by a firewall in transmitting a packet using encryption to another firewall during a session data exchange; Fig. 19 is a high level logic flow diagram illustrating the process performed by a firewall in receiving an encrypted packet from another firewall during a session data exchange;

Fig. 20 is a high level block diagram illustrating the data transferred between two firewalls during a basic key exchange;

Fig. 21 is a high level block diagram illustrating an example configuration employing a client personal computer and a firewall constructed in accordance with the present invention;

Fig. 22 is a high level block diagram illustrating the data transferred between a client personal computer and a firewall during a session key exchange; , and

Fig. 23 is a high level block diagram illustrating the data transferred between a client personal computer and a firewall during a basic key exchange.

DETAILED DESCRIPTION

Securing Inbound and Outbound Data Packet Flow

Referring now to Figure 1 , an example network topology is shown. In this example, the main site 100 contains a system administrator function embodied in workstation 102. This workstation is coupled to the network which includes workstations 104, router 110 and gateway 106. Router 110 is coupled via satellite 112 to a remote site via gateway 122. Gateway 106 is coupled via router 108 to the Internet. The remote site 120 comprises workstations 124 which are coupled to the network and via gateway 122 to the Internet. The particular configuration shown herein is chosen as an example only and is not meant to limit the type of network on which the present invention can work. The number configurations that networks can take are virtually limitless and techniques for setting up these configurations are well known to those skilled in the art. The present invention can operate on any of these possible configurations. Figure 2 shows the network of Figure 1 in which the present invention has been installed. In Figure 2, elements also shown in Figure 1 have the same reference numerals. As shown, the system administrator 102 includes a control module 210, a packet filter generator 208, a display 206 and a storage medium 212. Packet filters 204 have been installed on the system administrator, workstations 104 and gateway 106. Gateway 106 has two such filters, one on its connection to the network and one on its connection to the router 108. Routers 108 and 110 each have a programming script table which is generated by the security system, but which forms no part of the present invention, and will not be described in detail. These tables correspond to the tables that are currently utilized to program routers, as is well known to those skilled in the art.

Packet filters 204 are also installed on the gateway 122 of the remote site 120. One packet filter is installed on the connection between the satellite 112 and the gateway 122, a second packet filter is installed on the connection between the Internet and gateway 122 and a third packet filter is installed on the connection between the gateway and the network. Information flows on the network in the form of packets, as is well known to those skilled in the art. The location of the packet filters in Figure 2 is chosen so that data flow to or from a particular object of the network, such as a workstation, router or gateway can be controlled. Thus, workstations 104 each have a packet filter so that the information flow to/from these workstations is separately controlled. At the remote site 120, however, the packet filter is placed on the connection between the gateway 122 and the network, thus there is no individual control over the data flow to/from the workstations 124. If such individualized control were required, packet filters could be placed on each of the workstations 124, as well. Each of the packet filters is installed at the time that the network is set up or the security system is installed, although additional packet filters can be installed at a later date. The packet filters are installed on the host device such as the workstation or gateway at which protection is desired.

Each of the packet filters operates on a set of instructions which has been generated by the packet filter generator 208 in the system administrator 102. These instructions enable complex operations to be performed on the packet, rather than merely checking the content of the packet against a table containing the parameters for acceptance or rejection of the packet. Thus, each packet filter can handle changes in security rules with great flexibility as well as handle multiple security rules without changing the structure of the packet filter itself.

The system administrator enters the security rules via a graphical user interface (GUI) which is displayed upon the monitor 206 and explained in more detail with respect to Figure 3. This information is processed by the packet filter generator 208 and the resulting code is transmitted to the appropriate packet filter or filters in the network to perform the function that is desired. Control module 210 enables the system administrator to keep track of the operations of the network and storage 212 can be utilized to keep logs of operations on the network and attempts of illegal entry into the network. The system operator can thereby be provided with full reports as to the operation of the network and the success or failure of the security rules. This enables the security administrator to make those changes that are appropriate in order to maintain the security of the network without limiting its connectivity. Figure 3 shows the computer screen 206 in Figure 2 in more detail. The screen is broken into four windows, two smaller windows at the left side and two larger windows at the right side. Network objects and services are two aspects of the network which must be defined in the security method of the present invention. Window 304 is used to define network objects such as the workstations, gateways and other computer hardware connected to the system. It is also possible to group various devices together such as, for example, the finance department, the research and development department, the directors of the company. It is thus possible to control data flow not only to individual computers on the network, but also to groups of computers on the network by the appropriate placement of packet filters. This allows the system operator have a great deal of flexibility in the managing of communications on the network. It is possible for example to have the chief financial officer as well as other higher ranking officials of the company such as the CEO and the directors able to communicate directly with the finance group, but filter out communications from other groups. It is also possible to allow electronic mail from all groups but to limit other requests for information to a specified set of computers. This allows the system operator to provide internal as well as external security for the network. The object definition would include the address of the object on the network, as well as a name or group whether the object is internal or external to the network, whether or not a packet filter has been installed on this object and a graphical symbol. The graphical symbol is used in connection with the rule base manager 302.

Similarly, network services are defined in block 306 on the screen. These network services can include login, route, syslog and telnet, for example. Each service is defined by generic and specific properties. The generic properties include the code string that identifies the service, for example 'dpoif (destination port) which is equal to 23 for telnet. The code string that identifies the incoming and outgoing packets are identified. Specific properties include the name of the service, the port used to provide the service, the timeout in seconds of how long a connectionless session may stay inactive, that is, having no packet transmitted in either direction before assuming that the session is completed. Other elements of a service definition might include the program number for RPC services and the outbound connections for accepted services that use connectionless protocols such UDP. The graphic symbol and its color are specified.

Block 302 is the rule base manager which allows the new security rule to be entered into the system in a graphical manner, thus freeing the system administrator from having to write code to implement a particular security rule or to change a security rule. Only four elements are required to enter the new security rule into the system. The first element is the source of the data packet and the third element is the destination of the packet. The second element is the type of service that is involved and the fourth element is the action that should be taken. The action that can be taken includes accept the packet in which case the packet is passed from the source to the destination or reject the packet in which case the source is not passed from the source to the destination. If the packet is rejected, no action can be taken or a negative acknowledgment can be sent indicating that the packet was not passed to the destination. In addition, a further element which can be specified is the installation location for the rule which specifies on which objects the rule will be enforced (see Figure 2). If an installation location is not specified, the system places the packet filter module on the communication destination by default. These objects are not necessarily the destination. For example, a communication from the Internet and destined for a local host must necessarily pass through a gateway. Therefore, it is possible to enforce the rule on the gateway, even though the gateway is neither the source nor the destination. By entering the data with acronyms or graphic symbols, each rule can quickly be entered and verified without the need for writing, compiling and checking new code for this purpose. Thus, the system administrator need not be an expert in programming a computer for security purposes. As long as the service is one of the services already entered into the system, the computer serving as the host for the system administrator function will process the information into a set of instructions for the appropriate packet filter, as described in greater detail below. Block 308 is a system snapshot which summarizes the setup and operations of the security system. It is not required to practice the present invention. The system snapshot displays a summary of the system using graphical symbols. The summary can include, for example, the host icon, host name, rule base name, which is the name of the file containing the rule base, and the date the rule base was installed on the host. It can also show the status of the host indicating whether or not there have been communications with the host as well as the number of packets inspected by, dropped and logged by the host.

Figure 4 shows a flow chart of the subsystem for converting the information on the GUI to a filter script which contains the rules utilized for the packet filter. In the preferred embodiment, the output of the filter script generator is compiled into object code which is then implemented by the packet filter module, as described below.

The subsystem 400 starts at 402, proceeds to block 404 which is obtains the first rule from the GUI. The first rule is the first line on the screen in which a new security rule has been identified, as shown in Figure 3. Control then proceeds to block 406 in which code is generated to match the rule source network objects. That is, the source of the packet is entered into the source code block as representing one of objects of the system from which the data packet will emanate. Control then passes to block 408 in which code is generated in the destination code block to indicate which object of the network the data packet is destined for. Control then passes to block 410 in which code is generated to match the rule services that were chosen. The rule services have been defined previously and are stored within the system or, if not defined, will be defined at the time the security rule regulating the service is entered into the system. Control then passes to block 412 in which code is generated to accept or reject the packet if the data blocks 406, 408 and 410 were matched, that is, the results of the checks were true. The action to accept or reject is based upon the action chosen in the security rule. Control then passes to the decision block 414 which determines whether or not more rules are to be entered into the system. If no more rules are to be entered into the system, the subsystem terminates at block 418. If more rules are to be entered into the system, control passes to block 416 which obtains the next rule and passes control back to block 406 at which time the process repeats and the next security rule, found on the next line the GUI is processed. Communication protocols are layered, which is also referred as a protocol stack. The ISO (International Standardization Organization) has defined a general model which provides a framework for design of communication protocol layers. This model serves as a basic reference for understanding the functionality of existing communication protocols.

ISO MODEL

Layer Functionality Example

7 Application Telnet, NFS, Novell NCP

6 Presentation XDR

5 Session RPC

4 Transport TCP, Novel SPX

3 Network IP, Novell IPX

2 Data Link (Hardware Interface)

1 Physical (Hardware Connection)

Different communication protocols employ different levels of the ISO model. A protocol in a certain layer may not be aware to protocols employed at other layers. This is an important factor when making security actions. For example, an application (Level 7) may not be able to identify the source computer for a communication attempt (Levels 2-3), and therefore, may not be able to provide sufficient security.

Figure 5 shows how a filter packet module of the present invention is utilized within the ISO model. The communication layers of the ISO model are shown at 502 at the left hand portion of Figure 5. Level 1 , block 504, is the hardware connection of the network which may be the wire used to connect the various objects of the network. The second level, block 506 in Figure 5 is the network interface hardware which is located in each computer on the network. The packet filter module of the present invention intercedes between this level and level 3 which is the network software. Briefly, for the sake of completeness, the other levels of the ISO model are level 4, block 510 which relates to the delivery of data from one segment to the next, level 5, block 512, synchronizes the opening and closing of a "session" on the network. Level 6, block 514 relates to the changing of data between various computers on the network, and level 7, block 516 is the application program.

A packet entering the computer on which the packet filter module resides passes through layers 1 and 2 and then is diverted to the packet filter 520, shown on the right hand portion of Figure 5. The packet is received in block 522. In block 524, the packet is compared with the security rule and a determination is made as to whether or not the packet matches the rule. If the packet matches the rule, it may be logged on the system administrator's log and, if an illegal attempt has been made to enter the system, an alert may be issued. Control then passes to block 534 in which a decision is made whether or not to pass the packet based upon the requirements of the security rule. If the decision is to pass the packet, the packet is then passed to level 3, block 508. If a decision is not to pass the packet, a negative acknowledgment (NACK) is sent at block 528, if this option has been chosen, and control passes to block 530 where the packet is dropped, that is, it is not passed to its destination. Similarly, if an application generates a packet which is to be sent to anther destination, the packet leaves the ISO model at level 3, block 508 and enters block 522 and proceeds by an identical process except that if the packet is to be passed it is passed to level 2, block 506 and not level 3, block 508. On level 2, the packet is then sent onto the network at block 504, level 1. If the packet does not match the rule, the next rule will be retrieved and the packet examined to see if it matches this rule. A default rule is provided which matches any packet regardless of the source destination or service specified. This "empty rule" only has an action, which is to drop the packet. If no other rule is matched, this rule will be retrieved and will be effective to drop the packet. Dropping the packet is the safest step to take under these circumstances. The "empty rule" could, of course, be written to pass the packet.

Referring to Figure 6, 600 is a detailed description of the block 520 of Figure 5. The generalized description in Figure 6 and the more detailed descriptions shown in Figures 7-10 comprise a definition of the term "packet filter module" as the term is utilized herein. The capabilities shown in those figures are the minimal capabilities for the packet filter module to operate. Figures 11-15 show addition features which may also be included in the packet filter module, but are not required in the minimal definition of the term.

The packet filter module is embodied in a "virtual machine", which, for the purposes of this application, may be defined as an emulation of the machine shown in Figures 6-10 residing in the host computer, which is a computer on the network.

The virtual machine starts at block 602 in which the packet is received, which corresponds to block 522 of Figure 5. Control passes to block 604 in which the filter operations are obtained from the instruction a memory (not shown). These filter operations are the filter operations that have been generated by the packet filter generator 208 shown in Figure 2. Control then passes to block 604 in which the filter operations are obtained and then to block 606 in which the memory 618 is initialized. In block 608, the first virtual machine operation is obtained and performed in block 610. The virtual machine contains a memory mechanism such as a stack or register 618 which may be utilized to store intermediate values. The utilization of this stack or register is shown in greater detail in connection with the table shown below. Control then passes to decision block 614 in which it is determined whether or not the stop state has been reached. If the stop state has been reached, the decision will have been made to accept or reject the packet, which decision is implemented at block 616. If the packet has been passed, the packet will proceed as shown in Figure 5. If the packet is rejected, it will be dropped and a negative acknowledgment may be sent as shown in blocks 528 and 530. If the stop state has not been reached in block 614, the next operation is obtained in block 616 and the process repeats starting with block 610. The type of operations that can be performed in step 5, block 610 are shown more clearly in Figure 7. In Figure 7, block 610 and block 614 are identical to the blocks shown in Figure 6. Connection 613 is interrupted by three operations which are shown in parallel. For the operation that is to be performed in block 610, control will pass to the appropriate block 702, 704 or 706 in which that task will be performed. In block 702 data extraction will be performed, in block 704 logical operations will be performed and in block 706 a comparison operation will be performed. As shown at the right hand portion of Figure 7, other blocks can be added in parallel to the operations capable of being performed by the virtual machine. The subset shown as blocks 702, 704 and 706 are the essential elements of the virtual machine of the present invention. These elements are shown in greater detail in Figures 8, 9 and 10, respectively. Additional elements which may optionally be included in the operations capable of being performed by the virtual machine are shown in Figures 11-15, respectively.

The data extraction block 702 is shown in greater detail in Figure 8. The process starts at block 802 and control passes to block 804 in which data is extracted from a specific address within the packet 806. This address is taken from the stack memory 618 or from the instruction code. The amount of data extracted is also determined by the stack memory or the instruction code. The extracted data is put into the memory stack 810 at block 808. The process terminates at block 812. In these figures, control flow is shown by arrows having a single line whereas data flow is shown by arrows having double Iines. Figure 9 shows logical operation 704 in greater detail. The logical operation starts at block 902 and control passes to block 904 in which the first value is obtained from the memory 906. In block 908 a second value is obtained from the memory and the logical operation is performed in block 910. If the logical operation is true, a one is placed in the memory 906 at block 912 and if the logical operation is false, a zero is placed in the memory 906 at block 914. The process terminates at block 916.

The third and last required operation for the virtual machine is shown in greater detail in Figure 10. The comparison operation, block 706, starts at block 1002 and control passes to block 1004 in which the first value is obtained from memory 1006. Control passes to block 1008 in which a second value is obtained from memory 1006. A comparison operation between the first and second values takes place at block 1010. If the comparison operation is true, a one is placed in memory 1006 at block 1012 and if the comparison operation is false a zero is placed in memory 1006 at block 1014. The process terminates in block 1016. The following operations are not shown in Figure 7 but may be added at the right side of the figure at the broken Iines and are connected in the same manner as blocks 702, 704 and 706, that is, in parallel. Figure 11 shows the entering of a literal value into the memory. The process starts at block 1102 and control passes to block 1106 in which the literal value is obtained from the instruction code. The value is placed into the memory at block 1108 and the process ends at block 1110. A conditional branch operation is shown in Figure 12. The process starts at block 1202 and control passes to block 1204 in which the branch condition, taken from the instruction code, is checked. If the branch condition is true, the value is obtained from the memory stack 1206 at block 1208 and checked at block 1210. If the results of the comparison in block 1210 is true, the next step is set to N and the process terminates at block 1216. If the comparison in block 1210 is false, the process terminates at block 1216. If the branch condition is false, at block 1204, control passes directly to block 1214.

An arithmetic or bitwise operation is shown in Figure 13. The process starts at block 1302 and control passes to block 1304 in which the first value is obtained from memory 1306. The second value is obtained from memory 1306 at block 1308 and an arithmetic or bitwise operation is perfoπned on the two values obtained from the memory 1306 in block 1310. The result of the arithmetic or bitwise operation is placed in the memory in block 1312 and the process terminates in block 1314. Figure 14 illustrates a lookup operation which is useful if data needs to passed from a first set of instructions implementing a security rule to a second set of instructions for a second security rule. As shown in block 606 of Figure 6, the memory is initialized whenever a new security rule is processed. Therefore, information placed in the memory by a first security rule will not be available for use by a second security rule. In order to overcome this problem, a separate memory 1410 is supplied which contains Tables 1-3 which can be utilized for this purpose. The entry of data into the tables is shown in Figure 15 and described below. The lookup operation starts at 1402 and control passes to 1404 in which values are obtained from memory 1406. Control passes to block 1408 in which data is obtained from Tables 1-3 at block 1410 by searching the values in the referred table. Control passes to block 1412 in which a decision is made as to whether the block is in the table. If the decision is yes, a one is placed in memory 1406 at block 1416. If the decision is no, a zero is placed in memory 1406 at block 1414. The process terminates at block 1418.

Referring to Figure 15, the process starts at block 1502 and control passes to block 1504 in which values are obtained from memory 1506. Control then passes to block 1508 in which values obtained from memory 1506 are placed in the appropriate locations in Tables 1-3 at block 1510. Control passes to block 1512 in which a decision is made as to whether or not the storage values in the table has succeeded. If the storage has succeeded a one is placed in memory 1506 at block 1516. If the process has not succeeded, a zero is placed in memory 1506 at block 1514. The process terminates at block 1518.

An example of a security rule is implemented using the packet filtering method of the present invention will now be described utilizing as an example the security rule to disallow any Telnet services in the system. Telnet is defined as being a TCP service and having a specific TCP destination port. It will be identified by having a TCP protocol value of 6 in byte location 9 of the packet and by having a destination Telnet protocol number of 23 in byte location 22 of the packet, the value being a two-byte value. This is found in every Telnet request packet.

The first operation in the table shown below is to extract the IP protocol from the packet location 9 and place this in memory. As shown in the "Memory Values" column at the right side of the table, this value, 6, is placed at the top of the stack.

The second operation, the TCP protocol (port) number, which is stated to be 6 above, is placed at the second location in memory. In step 3, the values of the first two layers of the stack are compared, obtaining a positive result.

Drop Telnet Process Packet Virtual Machine Operation Memory Values

Filter Code (Stack Order)

pushbyte Extract Operation: Extract IP protocol [9] number from packet location 9 to memory

push 6 Enter Literal Value to Memory: Put TCP protocol number in memory

eq Comparison Operation: Compare IP protocol to TCP, obtaining a positive result

pushs [22] Extract Operation: Extract 23

TCP protocol number from packet location

22 to memory

push 23 Enter Literal Value to Memory: Put 23 23 TELNET protocol number in memory

eq Comparison Operation: Compare TCP protocol to TELNET, obtaining a positive result

and Logical Operation: Check if protocol both

TCP and TELNET are matched

btrue drop Conditional Branch Operation: If memory value is true, branch to drop state The values of 6 at the top two layers of the stack are deleted and a 1 , indicative of the positive result, is placed at the top of the stack. In step 4, the TCP protocol number for packet location 23 is extracted and placed in the memory location at the second layer of the stack. In step 5, the literal value which is the Telnet protocol number is placed into the memory at the third layer of the stack. In step 6, the memory layers 2 and 3 containing the TCP protocol for Telnet is compared with the expected value, obtaining a positive result. The values of the second and third layers of the stack are deleted and replaced by a 1 , indicative of the positive result. In step 7, a logical operation is performed to see if both the TCP and Telnet have been matched. This is deteimined by a AND operation. In this case the result is positive and the ones in the first two layers of the stack are deleted and replaced by a 1 indicative of the positive result. In step 8, a conditional branch operation is performed in which if the memory value is true, the program branches to the drop state. In this case, the result is true and the program branches to the drop state in which the Telnet request is not passed. Thus the rule to drop Telnet has been implemented.

Encrypting Data Flow - An Introduction

As stated earlier, long distance communications between enteφrises, branch offices and business partners have become an essential part of modern day business practice. Utilizing the present invention, virtual private networks (VPNs) can be constructed over insecure public networks such as the Intemet to provide secure and flexible communications.

The modification of packets by, e.g., encryption of outbound packets, decryption of inbound packets, signing of packets or address translation is performed by the packet filter module. The decision whether to modify a packet is determined from the rule base. All modifications, i.e., encryption, decryption, signing and address translation are performed on a selective basis in accordance with the contents of the rule base. For encryption, for example, to occur, a rule in the rule base must explicitly call for encryption to occur on packets which have a particular source, destination and service type. The encryption instructions are translated into the packet filter language that are installed and executed on the virtual packet filter machines in the network.

As described previously, the packet filter module determines whether a packet is rejected or accepted. If rejected, the packet is dropped. If accepted, the packet may be modified in a number of ways. Example of types of possible modifications include, but are not limited to, encryption, decryption and address translation. The following describes in detail the encryption and decryption of packets that is selectively performed by the packet filter module.

Notation Used Throughout

The following notation is used throughout this document:

Symbol Description g common root used for all Diffie-Hellman keys

P common modulus used for all Diffie-Hellman keys

Spvt source private key

Spub source public key

Dpvt destination private key

Dpub destination public key

B basic key

TB truncated basic key

A auxiliary key

R session key

E session data encryption key

1 session data integrity key

M data portion of a packet

P unencrypted password

ENCX(Y) encrypt Y using X as the key

DCRX(Y) decrypt Y using X as the key

SIG(Y) signature of Y Definitions of Terms Used Throughout

The following definitions are helpful in understanding the operation of the present invention.

Term Definition plaintext text that is not encrypted cleartext another term for text that is not encrypted ciphertext encrypted text key a piece of information known only to the sender and the intended recipient encryption converting the plaintext of a message into ciphertext in order to make the message unintelligible to those without the key decryption converting ciphertext into plaintext using the same key used to encrypt the message certification a trusted third party, known as a Certificate Authority (CA), from which one can reliably obtain a public key, even over an insecure communication channel, generates a certificate for the public key which can be verified by the recipient digital information generated from the contents of the message itself signature and used by the recipient to verify the data integrity of the message and/or its origin network a piece of hardware that is connected to a network and which object has some interaction with the network gateway a network object that is connected to at least two networks and passes information between them firewall or a network object, usually a gateway or an end host, that firewalled secures the flow of inbound and outbound data packets on a network computer network and also selectively modifies data packets in object accordance with a security rule base A high level block diagram illustrating an example configuration employing firewalls constructed in accordance with the present invention is shown in Figure 16. The example network shown in this figure will be used to explain the encryption capabilities of the present invention. The network configuration shown is only for illustrative puφoses only. Once skilled in the art can adapt the present invention to other network configurations as well. Both hosti and host2 are connected to their respective private LANs. In addition, firewalU 1604 is coupled to hosti through its LAN and fιrewall2 is coupled to host2 through its LAN. Both firewalls are coupled to a public network 1606 such as the Internet. It is also assumed that the public network is insecure and cannot be trusted. Certificate Authorityl (CA1) 1602 functions as the certificate authority for hosti and firewalU . CA2 1612 functions as the certificate authority for host2 and firewall2. In other embodiments, there may be only a single CA that serves both firewalls. In either embodiment, the functions of the CA remain the same. The only difference is which CA the firewall uses to obtain public keys.

It is desired that the communications between hosti and host2 be secured. The communications from hosti is routed to the Internet (i.e., the public network) via firewalU which acts as a firewalled network object. Similarly, communications from host2 is routed to the Internet via firewall2 which also acts as a firewalled network object. In communications to host2, firewalU intercepts and encrypts the packets it receives from hosti enroute to host2. Firewall2 receives the encrypted packets destined for host2 and decrypts those packets. In the opposite direction, fιrewall2 encrypts the packets from host2 destined for host! FirewalU receives the encrypted packets, decrypts them and passes them to hosti . The encryption and decryption operations performed by firewalU and fιrewall2 are transparent to hosti and host2.

Assuming hosti initiates the session with host2, it sends an Internet Protocol (IP) packet to host2. FirewalU will intercept the packet and determine that communications between hosti and host2 are to be modified in some way, e.g., encryption, decryption, address translation, etc. The decision is made separately for each connection based on information from all the ISO layers and based on information retained from previous packets. This decision process is termed stateful multi-layer inspection (SMLI). Each firewall maintains a rule base that instructs the firewall how to handle both inbound and outbound communications between network objects, as described in detail earlier. After determining that communications between hosti and host2 are to be encrypted or digitally signed, firewalU temporarily parks the packet and initiates a session key exchange, which is described in more detail below. Before encrypted communications or signing can take place, both sides need to agree on a shared key. This key is called the session key, R, and is generated anew at the start of every session. It is important to note that only the communications between firewalU and firewall2 is encrypted because of the use of the insecure Internet or public network. The communications between hosti and firewalU and between host2 and fιrewall2 are not encrypted because it takes place over private LANs which can be assumed to be private and secure.

Session Key Exchange - Firewall/Firewall A high level block diagram illustrating the data transferred between two firewalls during a session key exchange is shown in Figure 17. The following scheme is only one example of implementing encryption with SMLI and is not meant to limit the scope of the present invention to other encryption techniques. It would be obvious to one skilled in the art to adapt other encryption techniques to the SMLI process to carry out the teachings of the present invention. For example, in an alternative embodiment the SKIP standard is utilized. To initiate the encryption of data, firewalU first sends a request packet to host2. The request packet is sent to host2 and not firewall2 because firewalU may not know the IP address of the firewall that is responsible for host2. Firewall2 intercepts this request packet and returns a reply packet. The request and reply packets allow both sides to agree on shared session key R that will be used for all communications to be encrypted between hosti and host2. As stated previously, only the communications between firewalU and firewall2 are actually encrypted.

In general, the session key R is generated by the non-initiator (i.e., firewall2 1608) also called the destination and is sent encrypted to the initiator (i.e., firewalU 1604) also called the source. This two packet exchange must occur before encrypted communications can proceed. After the encrypted session is established, state information is maintained in both firewalls and the original packet that was parked is now passed encrypted through the firewalls. The same session key R is used by firewall2 to encrypt packets that are sent from host2 to host

The session key exchange will now be described in more detail. In order to agree on a common secret session key R, the present invention uses a 'static' Diffie-Hellman scheme. Each Diffie-Hellman key comprises a private part and public part. Each side has its own private and public parts. The private key for the source (i.e., firewalU) and destination (i.e., firewall2) is SPVτ and DPvτ, respectively. The public parts for source and destination are then defined as follows:

Spub = 9Spvt (mod) p

DpUb = gDpvt (mod) p

Both source and destination must know each others public key for the session key exchange to work. If one side does not know the other's public key or the key it does have is determined to be out of date, than a basic key exchange is triggered which is explained in more detail below. Both sides use each other's public key to derive at the basic key B. The source performs the following:

B = {gDpvt (mod) p}Spvt (mod) p = gSp Op* (mod) p

Similarly, the destination performs the following:

B = {gSpvt (mod) p}Dpvt (mod) p = gSpvtDpvt (mod) p

Thus, both sides share the basic key B. For use in encrypting the session key R, a truncated version of the basic key B is generated, called TB. In general, each firewall maintains a table of bindings between Diffie-

Hellman keys and firewalled network objects. In addition, a firewall must have a binding between IP addresses and such an object. In the configuration shown in Figure 17, a database within firewalU must be configured so that it knows of firewall2's existence. FirewalU must also know that host2's encrypting firewall is firewall2. FirewalU can have a list of potential firewalls that may serve as encrypting firewalls for firewall2. The bindings and the network object database for each firewall are managed in static fashion by a separate management unit. In order to encrypt communications between firewalls, a firewall must have knowledge of its own basic private key and the basic public keys of each firewalled network object it needs to communicate with. The basic public keys belonging to external firewalled network objects such as a firewall belonging to a business partner must also be known in order for encrypted sessions to occur. This static binding of basic keys to firewalled network objects may already be established in a database intemal to the firewall or it can be obtained on the fly using the basic key exchange described below.

Once a common shared secret basic key B is agreed upon by the two firewalls, it is used to encrypt the actual key used for the session, i.e., the session key R. The same session key R is used by both source and destination to encrypt the data from hosti to host2 and from host2 to hosti .

The elements of the request from the source to the destination is shown above the right arrow in Figure 17. The cipher method comprises one or more encryption methods for encrypting the session data that the source is able to perform (e.g., DES, FWZ1, RC4, RC5, IDEA, Tripple-DES, etc.). The key method comprises one or more encryption methods for encrypting the session key R that the source is able to perform (e.g., DES, FWZ1 , RC4, RC5, IDEA, Tripple-DES, etc.). The md method (i.e., message digest method) or the message integrity method comprises one or more methods or algorithms for performing data integrity that the source is able to perform (i.e., MD5, SHA, etc.). The data integrity typically entails calculating a cryptographic hash of a part of or all of the message.

The suggested source public key ID identifies, via an ID number, the basic public key that the source assumes the destination will use. Likewise, the suggested destination basic public key ID identifies the basic public key that the source assumes the destination will use. If there are more than one possible firewalled network object serving host2, the source will include multiple suggested basic public keys in the request packet since it does not know which of the firewalled network object actually serves host2. Each suggested basic public key corresponds to a different firewalled network object.

The request also comprises a challenge key C which is a random bit field chosen by the source (i.e., firewalU) which is used to thwart man in the middle attacks against the session key exchange or the session data itself.

The destination (i.e., firewall2) receives the request packet and based on its contents generates a reply packet to be sent back to the source. The elements of the reply packet are shown above the left arrow in Figure 17. The reply packet has a similar format as the request packet with the exception of the challenge key C field replaced by a field holding the encrypted session key R. Each of the cipher method, key method and md method now have only one element rather than a list of options as in the request. The elements listed are the elements chosen by the destination from the options listed in the request. Similarly, the chosen source basic public key ID and the chosen destination basic public key ID both comprise a single key ID representing the key ID chosen by the destination from the option list sent in the request.

The session key R that is sent in the reply actually comprises two keys: a session data encryption key E and a session data integrity key I. Thus, the session key R is defined as

R = E + I

The session key is a random stream of bytes that is generated for both the cipher method (i.e., encryption method) and the md method or method digest method. Its length is the sum of the key lengths needed by the cipher method and the md method. Once generated, a signature of the session key is obtained using the chosen md method, e.g., MD5, and represented by SIG(R). The combination of session R and SIG(R) are then encrypted using a key formed by the combination of the truncated basic key TB and the challenge C, thus forming

ENC c + c)(R + SIG(R))

which is what is sent in the reply to the source. The signature or hash checksum computation provides authentication to the source that the packet it received is indeed formed by an entity that knows the basic key B thus providing strong authentication for the reply packet. In addition, since the source chose the challenge key C, there is no possibility of replay.

Session Data Exchange

A high level logic flow diagram illustrating the process performed by a firewall in transmitting a packet using encryption to another firewall during a session data exchange is shown in Figure 18. Although not shown in the Figures, an alternative embodiment utilizes the IPSEC standard for performing session data exchange. As mentioned earlier, once the source and the destination agree on a session key R, encrypted communication between both firewalls can proceed. Interception of and modifications to the packets occur between level 2 and level 3 of the ISO model. Communications occurring both ways is to be encrypted and decrypted using the same session key R. The packets that are sent out closely resemble normal TCP/IP packets. The packets do not include any information indicating whether the packets are encrypted or not and if so which key to use. This information only exists in the state maintained by the two firewalls. The encryption is performed in place without changing the length of the packet which serves to increase the efficiency and bandwidth of encrypted traffic. In general, each transmitted packet is divided into two parts, a cleartext part which is not encrypted and a ciphertext part which is encrypted. The cleartext part includes the IP header and the TCP/UDP header. The rest of the packet meaning its data M is encrypted using a combination of the session key R and an auxiliary key A computed from its cleartext part. The process will now be described in more detail.

The first step performed by a firewall in transmitting a packet is to generate an auxiliary key A from the cleartext contents of the packet itself (step 1800). The portions used depend on the type of packet and protocol (e.g., RPC, UDP, TCP, ICMP, etc.) and may include the following fields, for example, IP-ID (only a portion), RPC-XID, RPC-PROGNUM, TCP-SEQ, TCP-ACK, UDP-LEN, ICMP- TYPE, ICMP-CODE and IP-PROTO. Next, the auxiliary key A, session data integrity key I and the data portion of the packet M are placed in a buffer (step 1802). A signature is then generated on the contents of the buffer using the md method (step 1804) and expressed as

SIG(A + I + M) The bits of the signature generated are then placed in the packet header

(step 1806). Adding the signature bits to the packet is important for ensuring data integrity. Since the length of the packet is not modified some portions of the packet must be overwritten with the signature bits. Note that the signature bits are stored in the packet before the packet is encrypted. For TCP packets a 28 bit signature is stored as follows:

• the 8 LSBits of the signature replace the 8 MSBits of the IP-ID

• the next 16 bits are added to the TCP-CSUM field using 1's complement arithmetic

• the next 4 bits are stored in the unused TCP-X2 nibble (this is optional)

For UDP packets a 32 bit signature is stored as follows:

• the first 16 bits of the signature are added to the UDP-CSUM field using 1's complement arithmetic; if the original UDP-CSUM field is zero, the UDP- SPORT and UDP-DPORT fields are added to the UDP-CSUM also using 1's complement arithmetic • the next 16 bits are stored in the UDP-LEN field

Once the signature bits are stored in the packet, the data portion of the packet M is encrypted (step 1808), and can be expressed by

ENC(E + A)(M)

The encryption is performed using the cipher method with a combination of the session data encryption key E and the auxiliary key A. Finally, the packet is transmitted over the public network (step 1810).

A high level logic flow diagram illustrating the process performed by a firewall in receiving an encrypted packet from another firewall during a session data exchange is shown in Figure 19. First, in order to verify the signature, the auxiliary key A must be generated from the contents of the packet (step 1900). Then, the packet's data portion M is decrypted using the cipher method and a combination of the session data encryption key E and the auxiliary key A (step 1902), which can be expressed as

DCR(E + A)(ENC(E + A)(M))

Next, the signature bits are extracted from the packet header (step 1904). A signature on the auxiliary key A, session data integrity key I and the packet data M is then generated using the md method (step 1906), and expressed as

SIG(A + I + M)

Then the two signatures are compared with each other (step 1908). If they match the packet is passed after replacing any data in the packet that was overwritten with signature data (step 1910). If the signatures do not match the packet is dropped (step 1912).

Basic Key Exchange As explained previously, in order to encrypt communications between firewalled network objects, a firewall must have knowledge of its own private basic key and the public basic keys of each firewall it needs to communicate with. The public basic keys belonging to external firewalls such as a firewall belonging to a business partner must also be known in order for encrypted sessions to occur. This static binding of basic keys to firewalls can already be established in a database internal to the firewall or it can be obtained on the fly using the basic key exchange. In addition, the basic keys may be updated on an infrequent basis to improve security. The present invention provides for basic public keys to be obtained on the fly if they are not already in a database within the firewall. In general, a basic public key must be obtained if the source does not have knowledge of the destination's basic public key or the destination determines that the destination basic pubic key used by the source is out of date.

In either case, the exchange of the basic public key is certified in order to be sure as to the authenticity of the Diffie-Hellman key being transmitted. Certification of messages, in general, serve to thwart man in the middle attacks against the system.

The process of exchanging the basic keys will now be described in more detail. A high level block diagram illustrating the data transferred between two firewalls during a basic key exchange is shown in Figure 20. Whenever any of the two sides recognizes that either it does not have a valid key for its peer or that it has an outdated key it requests the other side to send it a certified basic key.

The basic key exchange can be triggered in two ways depending on which side discovers that the basic public key has to be updated or exchanged. Typically, it will be the side that discovers it does not have the other sides' basic key. For example, referring to Figure 16, a basic key exchange will be triggered if the initiating side i.e., firewalU, discovers that it does not have the basic public key for firewall2. In another scenario, firewall2, upon receiving a request from firewalU , sees that it has an outdated version of the basic public key for firewalU (by comparing what is in its database to the suggested basic public key sent in the request). The latter scenario is the one depicted in Figure 20.

The elements of the basic key request are shown above the left arrow in Figure 20. The basic request comprises the source basic public key ID, destination basic public key ID, cipher method, key method and md method. These elements are identical to those discussed above in the section entitled Session Key Exchange - Firewall/Firewall. When a basic key exchange must occur, the side that wants the other to send it a certified key update or key sync will add a CA public key ID field to the request. This new field indicates which key requires updating and is the ID of the certificate authority key (e.g., RSA key) by which firewall2 wants to receive the reply from firewalU . Upon receiving this message, firewalU will send its basic public key Spub to firewall2 after certifying it with the CA public key against a certification that was made by the CA. Certification is the process of generating a digital signature of the basic public key. For firewalU , CA1 1602 generates the CA public keys for verifying firewalU 's basic public keys (Figure 16). In order for firewall2 to verify the signature, it must obtain the CA public key from CA1 , the certificate authority for firewalU . The elements of the response by firewalU are shown above the right arrow in Figure 20. The elements comprise the CA public key ID, the source basic public key Spub and the IP address or addresses of the source. In addition, the signature of the source basic public key is sent, which can be represented by

SIG(Spub)

In a preferred embodiment, the signature is generated by first generating an intermediate signature from the basic public key to be sent using the md method of generating digital signatures. Then, this intermediate signature is input to the RSA decrypting function to generate the signature that is finally transmitted. The IP address of the source (i.e., firewalU) is included in order to verify the binding between the firewall, i.e., firewalU , and a basic public key (Spub).

Upon receipt of the certificate from firewalU , firewall2 can verify it using the CA public key. If it verifies correctly, firewall2 updates its database with the new basic public key of firewalU . Now, the session key exchange can be completed and session data can then to be communicated.

Note that the basic public keys are communicated between each firewall and its CA over secure communication channels. If there is more than a single CA the public key of one CA is sent in the clear to the other CA. This message is either signed using a previous value of the CA public key or the newly obtained CA public key can be verified by some other manual means, such as facsimile or telephone.

Session Key Exchange - Client/Firewall

As described earlier, there is a growing business need for external access to corporate networks. More and more employees are working physically outside the corporate LAN or WAN environment but need to connect to it. The present invention provides the capability of verifying external users of a system and providing encrypted communications between the external user or client and the host system.

A high level block diagram illustrating an example configuration employing a client personal computer and a firewall constructed in accordance with the present invention is shown in Figure 21. A personal computer (PC) 2100, called the source for purposes of explanation, is used by the client or external user to login to the host 2104 shown coupled to a LAN. The PC is coupled to a public network 1606 and communicates with the host via firewall 2102, called the destination or server for purposes of explanation. All communications between the PC and the host is routed through the firewall. The PC is suitably programmed to perform the functions needed to login to the host and carry out encrypted communication between itself and the firewall. Similar to the configuration shown in Figure 16, encrypted communications is only between the PC and the firewall in the configuration shown in Figure 21. To the host, the firewall is transparent and thinks data is coming straight from the PC.

The session data exchange processes for client to firewall encryption are similar to those of firewall to firewall encryption. The differences lie, however, in the session key exchange and the basic key exchange processes. With firewall to firewall session key exchange, each session received a different session key. A session is not only a connection between two particular network objects but may include different services between the same network object. In contrast, the client initiates a session with the host and ali communications between the client and the host during that session is encrypted using the same key, no matter what activities or services the client requests. In addition, in firewall to firewall communications, both sides have each other's certified public key. In client to firewall communication, this is true only for the client, while the server identifies the client using a name/password pair sent to it by the client.

A high level block diagram illustrating the data transferred between a client personal computer and a firewall during a session key exchange is shown in Figure 22. The elements sent in the request by the client are shown above the right arrow. The elements include a name, cipher method, key method, md method, password method, source basic public key Spub, suggested destination basic public key ID, challenge key C, encrypted password and a signature. The name is used to identify the user who is currently using the client. The cipher method, key method and md method are as described earlier. The password method indicates which encryption method to use in encrypting the password. The encrypted password can be expressed as

ENCfTB ^P)

The source basic public key Spub is always sent as the firewall does not maintain a list of users and their associated basic public keys. The data that is sent is similar to the data sent by firewalU to firewaII2 (Figure 20) as described in the section entitled Basic Key Exchange - Firewall/Firewall. The destination basic public key ID is as was described above in the section entitled Session Key Exchange - Firewall/Firewall. The signature functions to ensure to the destination , the receiving side, that the message was not modified. The signature is generated by taking the entire contents of the request or message, represented as T in Figure 22, except for the signature field, and combining T with the unencrypted password and the truncated basic public key TB, expressed as the following

SIG(T + P + TB)

The signature is added to the request and the request then sent to the firewall.

After receipt of the request, the firewall knows the client's basic public key Spub. It can now generate the basic key B and the truncated basic key TB. It then can decrypt the password P. Once P is known, the firewall can verify the signature in the request. The firewall next generates a random session key R and encrypts R and the signature of R using the truncated basic key TB and the challenge C sent in the request from the client, and given by

ENC β + ofR + SIGtR))

A signature is then generated of the content of the request denoted by U in Figure 22 in combination with the truncated basic public key TB, as given by

SIG(U + TB) The firewall then generates a reply whose elements are shown above the left arrow in Figure 22. The reply comprises the destination basic public key ID, the cipher method, key method and md method, encrypted session key and the signature. Once the session key is known by both the client and the firewall, the communications session can proceed between the PC and the host via the firewall and the encrypted communication between the PC and the firewall is transparent to the host. In order to reduce the number of key exchanges, the session key R is used for all encrypted connections passing through the same firewall. After a predetermined time duration, e.g., several minutes, the session key R is dropped.

- Basic Key Exchange - Client/Firewall

In contrast to firewall to firewall communications, a certified key exchange is only necessary to update the client with the firewall's basic public key. A basic key exchange may be triggered in either of two ways. The first, if the client does not have the firewall's basic public key or, second, if the firewall determines that the basic public key used by the client in the request is outdated.

The process is similar to the basic key exchange as explained previously in the section entitled Basic Key Exchange - Firewall/Firewall. However, there are differences as explained below. If the client realizes that it does not have the firewall's basic public key, it substitutes a CA public key ID field for the destination basic public key ID field in the request. This is shown above the top right arrow in Figure 23 which is a high level block diagram illustrating the data transferred between a client personal computer and a firewall during a basic key exchange. This key ID is the ID of the certificate authority key (e.g., RSA key) by which the client wants to receive the reply from the firewall.

When the firewall receives the request from the client, it determines from the request whether the client is requesting the firewall's basic public key or the key ID in the request does not correspond to the firewall's basic public key. The elements of firewall's reply is shown above the left arrow. The reply comprises the original suggested destination basic public key ID, CA public key ID, destination basic public key Dpub, IP address of the destination and a signature. The original destination basic public key is taken as is from the request. The signature of the destination basic public key is sent, which is represented by

SIG(Dpub) In a preferred embodiment, the signature is generated by first generating an intermediate signature from the basic public key to be sent using the md method of generating digital signatures. Then, this intermediate signature is input to the RSA decrypting function to generate the signature that is finally transmitted. The IP address of the destination (i.e., the firewall) is included in order to verify the binding between the firewall, and a basic public key (Dpub). Upon receipt of the certificate from the firewall, the client can verify it using the CA public key. If it verifies correctly, the client updates its database with the new basic public key of the firewall.

After receiving the firewall's reply, the client sends back a message to complete the authentication. The elements of the message are shown above the bottom right arrow in Figure 23. The message comprises the password encrypted and a signature. Once the reply is received, the client can generate the basic key B and the truncated basic key TB. The client then encrypts the password P, expressed as

ENCfTB + ofP)

The signature is generated using the md method on the combination of the contents of the original request sent to the firewall as shown above the right arrow in Figure 22, represented as T, the cleartext password P and the truncated basic public key TB, as expressed as

SIG(T + P + TB)

The encrypted password and the signature are then sent to the firewall. The session key exchange then completes and session data communications can begin. While the invention has been described with respect to a limited number of embodiments, it will be appreciated that many variations, modifications and other applications of the invention may be made.

Claims

What is claimed is:
1. A method of inspecting and selectively modifying inbound and outbound data packets in a computer network, the inspection and selective modification of said data packets occurring in accordance with a security rule, the method comprising the steps of: generating a definition of each aspect of the computer network inspected by said security rule; generating said security rule in terms of said aspect definitions, said security rule controlling at least one of said aspects; converting said security rule into a set of packet filter language instructions for controlling an operation of a packet filtering module which inspects and selectively modifies said data packets in accordance with said security rule; coupling said packet filter module to said computer network for inspecting and selectively modifying said data packets in accordance with said security rule, said packet filter module implementing a virtual packet filtering machine; and said packet filter module executing said packet filter language instructions for operating said virtual packet filtering machine to either accept or reject the passage of said data packets into and out of said network computer and selectively modify said data packets so accepted.
2. The method according to claim 1 , wherein said aspects include network objects.
3. The method according to claim 1 , wherein said aspects include network services.
4. The method according to claim 2, wherein said aspects include network services.
5. The method according to claim 4, wherein said object definitions include the address of said object.
6. The method according to claim 1 , wherein the filter language instructions of said step of converting are in the form of script and further comprising a compiler to compile said script into said instructions executed in said step of executing.
7. The method according to claim 1 , wherein in both said steps of generating said aspects of said network and of said security rule are defined graphically.
8. The method according to claim 1 , wherein said selective modification is chosen from the group consisting of encryption, decryption, signature generation and signature verification.
9. In a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, said security system inspecting and selectively modifying said data packets in said computer network in accordance with a security rule, where each aspect of said computer network inspected by said security rule has been previously defined, said security rule being previously defined in terms of said aspects and converted into packet filter language instructions, a method for operating said security system comprising the steps of: providing a packet filter module coupled to said computer network in at least one entity of said computer network to be inspected by said security rule, said packet filter module implementing a virtual packet filtering machine inspecting and selectively modifying said data packets passing into and out of said computer network; and said packet filter module executing said packet filter language instructions for operating said virtual packet filtering machine to either accept or reject the passage of said data packets into and out of said computer network and to selectively modify said data packets so accepted.
10. The method according to claim 9 wherein said aspects include network objects.
11. The method according to claim 9 wherein said aspects include network services.
12. The method according to claim 10 wherein said aspects include network services.
13. The method according to claim 12 wherein said object definitions include the address of said object.
14. The method according to claim 9 wherein said virtual machine performs a data extraction operation.
15. The method according to claim 14 wherein said virtual machine performs a logical operation.
16. The method according to claim 15 wherein said virtual machine performs a comparison operation.
17. The method according to claim 9, wherein said selective modification is chosen from the group consisting of encryption, decryption, signature generation and signature verification.
18. In a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, said security system inspecting and selectively modifying said data packets in said computer network in accordance with a security rule, where each aspect of said computer network inspected by said security rule has been previously defined, said security rule being previously defined in terms of said aspects and converted into packet filter language instructions, a method for operating said security system comprising the steps of: providing a packet filter module coupled to said computer network in at least one entity of said computer network to be controlled by said security rule, said packet filter module emulating a virtual packet filtering machine inspecting and selectively modifying said data packets passing into and out of said computer network; said packet filter module reading and executing said packet filter language instructions for performing packet filtering operations; storing the results obtained in said step of reading and executing said packet filter language instructions in a storage device; and said packet filter module utilizing said stored results, from previous inspections, for operating said packet filter module to accept or reject the passage of said data packets into and out of said computer network and to selectively modify said data packets so accepted.
19. The method according to claim 18 wherein said aspects include network objects.
20. The method according to claim 18 wherein said aspects include network services.
21. The method according to claim 19 wherein said aspects include network services.
22. The method according to claim 21 wherein said object definitions include the address of said object.
23. The method according to claim 18, wherein said selective modification is chosen from the group consisting of encryption, decryption, signature generation and signature verification.
24. In a security system for inspecting and selectively modifying inbound and outbound data packets in a computer network, said security system inspecting and selectively modifying said data packets passing through said computer network in accordance with a security rule, where each aspect of said computer network controlled by said security rule has been previously defined, said security rule being previously defined in terms of said aspects and converted into packet filter language instructions, said security system comprising: a packet filter module coupled to said computer network, said packet filter module operating in accordance with said security rule, said packet filter module implementing a virtual packet filtering machine inspecting and selectively modifying said data packets passing into and out of said computer network; and processing means for reading and executing said packet filter language instruction integral with said packet filter module, said processing means operating said packet filtering module to either accept or reject the passage of said packets into and out of said computer network and to selectively modify said data packets so accepted.
25. The method according to claim 24, wherein said selective modification is chosen from the group consisting of encryption, decryption, signature generation and signature verification. t2, A method substantially as claimed hereinabove and substantially as illustrated in any of the drawings.
PCT/IL1996/000017 1993-12-15 1996-06-16 A system for securing the flow of and selectively modifying packets in a computer network WO1997000471A2 (en)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US08/168,041 US5606668A (en) 1993-12-15 1993-12-15 System for securing inbound and outbound data packet flow in a computer network
IL11418295A IL114182A (en) 1995-06-15 1995-06-15 Method for controlling computer network security
IL114182 1995-06-15

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
JP50287697A JP3847343B2 (en) 1995-06-15 1996-06-16 The method and system and method of operating the system checks the data packet for communication security in a computer network performs selective changes
AU61356/96A AU6135696A (en) 1995-06-15 1996-06-16 A system for securing the flow of and selectively modifying packets in a computer network
EP19960918822 EP0807347B1 (en) 1995-06-15 1996-06-16 A system for securing the flow of and selectively modifying packets in a computer network
DE1996636513 DE69636513D1 (en) 1995-06-15 1996-06-16 System for securing the flow and for the selective alteration of packets in a computer network
DE1996636513 DE69636513T2 (en) 1995-06-15 1996-06-16 System for securing the flow and for the selective alteration of packets in a computer network
CA 2197548 CA2197548C (en) 1995-06-15 1996-06-16 A system for securing the flow of and selectively modifying packets in a computer network
NO970611A NO324332B1 (en) 1995-06-15 1997-02-10 A system for a secure flow of and for a selectively modify packets in a computer network

Publications (2)

Publication Number Publication Date
WO1997000471A2 true WO1997000471A2 (en) 1997-01-03
WO1997000471A3 WO1997000471A3 (en) 1997-03-06

Family

ID=26323080

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IL1996/000017 WO1997000471A2 (en) 1993-12-15 1996-06-16 A system for securing the flow of and selectively modifying packets in a computer network

Country Status (1)

Country Link
WO (1) WO1997000471A2 (en)

Cited By (42)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0858201A2 (en) * 1997-02-06 1998-08-12 Sun Microsystems Inc. Method and apparatus for allowing secure transactions through a firewall
EP0862105A2 (en) * 1997-02-28 1998-09-02 Xcert Software, Inc. Method of and apparatus for providing secure distributed directory services and public key infrastructure
WO1998057464A1 (en) * 1997-06-12 1998-12-17 Vpnet Technologies, Inc. An apparatus for implementing virtual private networks
WO1998057465A1 (en) * 1997-06-12 1998-12-17 Vpnet Technologies, Inc. Architecture for virtual private networks
WO1999012298A2 (en) * 1997-09-02 1999-03-11 Telefonaktiebolaget Lm Ericsson Arrangement in a data communication system
EP0909074A1 (en) * 1997-09-12 1999-04-14 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with multiple domain support
WO1999055052A1 (en) * 1998-04-20 1999-10-28 Sun Microsystems, Inc. Method and apparatus for using digital signatures to filter packets in a network
FR2778290A1 (en) * 1998-04-30 1999-11-05 Bull Sa Method and device securisee interconnection between computers, organized as a network, by controlling a filtering module residing in the communication layer ip
WO1999067930A2 (en) * 1998-06-19 1999-12-29 Ssh Communications Security Ltd. Method and arrangement for implementing ipsec policy management using filter code
WO2000002114A2 (en) * 1998-07-02 2000-01-13 Effnet Group Ab Firewall apparatus and method of controlling network data packet traffic between internal and external networks
WO2000016530A2 (en) * 1998-09-11 2000-03-23 Telia Ab (Publ) A transmission system, a method and an apparatus providing access for ip data packets to a firewall protected network
WO2000025194A1 (en) * 1998-10-27 2000-05-04 Saios Technologies Holding S.A. Security interface for data exchange
WO2000031931A1 (en) * 1998-11-24 2000-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for securing data objects
US6098172A (en) * 1997-09-12 2000-08-01 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with proxy reflection
US6141749A (en) * 1997-09-12 2000-10-31 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with stateful packet filtering
US6154775A (en) * 1997-09-12 2000-11-28 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with dynamic rule processing with the ability to dynamically alter the operations of rules
US6170012B1 (en) 1997-09-12 2001-01-02 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with cache query processing
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network
EP1105809A2 (en) * 1998-06-29 2001-06-13 Internet Dynamics, Inc. Generalized policy server
EP1113641A2 (en) * 1999-12-30 2001-07-04 Samsung Electronics Co., Ltd. System and method for filtering mobile Internet access at BTS/BSC
GB2372413A (en) * 2001-02-20 2002-08-21 Hewlett Packard Co Digital credential exchange
WO2002067544A2 (en) * 2001-02-17 2002-08-29 Inktomi Corporation Header-based network api
EP1494420A2 (en) * 2003-06-30 2005-01-05 Microsoft Corporation Reducing network configuration complexity with transparent virtual private networks
US6847609B1 (en) 1999-06-29 2005-01-25 Adc Telecommunications, Inc. Shared management of a network entity
WO2005094192A2 (en) * 2004-03-31 2005-10-13 Lg Electronics, Inc. Home network system
US6959006B1 (en) 1999-06-29 2005-10-25 Adc Telecommunications, Inc. Service delivery unit for an enterprise network
US7127741B2 (en) 1998-11-03 2006-10-24 Tumbleweed Communications Corp. Method and system for e-mail message transmission
US7162738B2 (en) 1998-11-03 2007-01-09 Tumbleweed Communications Corp. E-mail firewall with stored key encryption/decryption
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US7380274B2 (en) 1997-07-24 2008-05-27 Tumbleweed Communications Corp. E-mail firewall
US7469418B1 (en) 2002-10-01 2008-12-23 Mirage Networks, Inc. Deterring network incursion
US7506360B1 (en) 2002-10-01 2009-03-17 Mirage Networks, Inc. Tracking communication for determining device states
DE102005046935B4 (en) * 2005-09-30 2009-07-23 Nokia Siemens Networks Gmbh & Co.Kg Network access node computer to a communication network, communication system and method for allocating a protection device
US7580919B1 (en) 1997-03-10 2009-08-25 Sonicwall, Inc. Query interface to policy server
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
US7912856B2 (en) 1998-06-29 2011-03-22 Sonicwall, Inc. Adaptive encryption
US8250624B2 (en) 2001-03-14 2012-08-21 Gemalto Sa Portable device for securing packet traffic in a host platform
US8819285B1 (en) 2002-10-01 2014-08-26 Trustwave Holdings, Inc. System and method for managing network communications
US8914410B2 (en) 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US9338026B2 (en) 2003-09-22 2016-05-10 Axway Inc. Delay technique in e-mail filtering system
USRE46439E1 (en) 1997-03-10 2017-06-13 Dropbox, Inc. Distributed administration of access to information and interface for same
US10320748B2 (en) 2017-02-23 2019-06-11 At&T Intellectual Property I, L.P. Single packet authorization in a cloud computing environment

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247963A (en) * 1990-09-10 1993-09-28 Ziggity Systems, Inc. Flush apparatus for watering systems
US5329623A (en) * 1992-06-17 1994-07-12 The Trustees Of The University Of Pennsylvania Apparatus for providing cryptographic support in a network
US5473607A (en) * 1993-08-09 1995-12-05 Grand Junction Networks, Inc. Packet filtering for data networks
US5485455A (en) * 1994-01-28 1996-01-16 Cabletron Systems, Inc. Network having secure fast packet switching and guaranteed quality of service
US5515376A (en) * 1993-07-19 1996-05-07 Alantec, Inc. Communication apparatus and methods
US5555346A (en) * 1991-10-04 1996-09-10 Beyond Corporated Event-driven rule-based messaging system

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5247963A (en) * 1990-09-10 1993-09-28 Ziggity Systems, Inc. Flush apparatus for watering systems
US5555346A (en) * 1991-10-04 1996-09-10 Beyond Corporated Event-driven rule-based messaging system
US5329623A (en) * 1992-06-17 1994-07-12 The Trustees Of The University Of Pennsylvania Apparatus for providing cryptographic support in a network
US5515376A (en) * 1993-07-19 1996-05-07 Alantec, Inc. Communication apparatus and methods
US5473607A (en) * 1993-08-09 1995-12-05 Grand Junction Networks, Inc. Packet filtering for data networks
US5485455A (en) * 1994-01-28 1996-01-16 Cabletron Systems, Inc. Network having secure fast packet switching and guaranteed quality of service

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP0807347A2 *

Cited By (81)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0858201A3 (en) * 1997-02-06 1999-01-13 Sun Microsystems Inc. Method and apparatus for allowing secure transactions through a firewall
EP0858201A2 (en) * 1997-02-06 1998-08-12 Sun Microsystems Inc. Method and apparatus for allowing secure transactions through a firewall
EP0862105A2 (en) * 1997-02-28 1998-09-02 Xcert Software, Inc. Method of and apparatus for providing secure distributed directory services and public key infrastructure
EP0862105A3 (en) * 1997-02-28 2002-04-17 Xcert Software, Inc. Method of and apparatus for providing secure distributed directory services and public key infrastructure
US9154489B2 (en) 1997-03-10 2015-10-06 Dell Software Inc. Query interface to policy server
US7272625B1 (en) 1997-03-10 2007-09-18 Sonicwall, Inc. Generalized policy server
US7821926B2 (en) 1997-03-10 2010-10-26 Sonicwall, Inc. Generalized policy server
US8935311B2 (en) 1997-03-10 2015-01-13 Sonicwall, Inc. Generalized policy server
USRE46439E1 (en) 1997-03-10 2017-06-13 Dropbox, Inc. Distributed administration of access to information and interface for same
US9438577B2 (en) 1997-03-10 2016-09-06 Dell Software Inc. Query interface to policy server
US7580919B1 (en) 1997-03-10 2009-08-25 Sonicwall, Inc. Query interface to policy server
US9331992B2 (en) 1997-03-10 2016-05-03 Dell Software Inc. Access control
US9276920B2 (en) 1997-03-10 2016-03-01 Dell Software Inc. Tunneling using encryption
US6173399B1 (en) * 1997-06-12 2001-01-09 Vpnet Technologies, Inc. Apparatus for implementing virtual private networks
WO1998057465A1 (en) * 1997-06-12 1998-12-17 Vpnet Technologies, Inc. Architecture for virtual private networks
WO1998057464A1 (en) * 1997-06-12 1998-12-17 Vpnet Technologies, Inc. An apparatus for implementing virtual private networks
EP1515491A2 (en) * 1997-06-12 2005-03-16 VPNET Technologies, Inc. Architecture for virtual private networks
US7617527B2 (en) 1997-06-12 2009-11-10 Avaya Inc. Architecture for virtual private networks
US7010702B1 (en) 1997-06-12 2006-03-07 Vpnet Technologies, Inc. Architecture for virtual private networks
EP1515491A3 (en) * 1997-06-12 2006-05-17 VPNET Technologies, Inc. Architecture for virtual private networks
US8255683B2 (en) 1997-07-24 2012-08-28 Axway Inc. E-mail firewall with policy-based cryptosecurity
US7380274B2 (en) 1997-07-24 2008-05-27 Tumbleweed Communications Corp. E-mail firewall
US7401356B2 (en) 1997-07-24 2008-07-15 Tumbleweed Communications Corp. Method and system for e-mail message transmission
USRE43302E1 (en) 1997-07-24 2012-04-03 Axway, Inc. E-mail firewall with stored key encryption/decryption
WO1999012298A2 (en) * 1997-09-02 1999-03-11 Telefonaktiebolaget Lm Ericsson Arrangement in a data communication system
US6578151B1 (en) 1997-09-02 2003-06-10 Telefonaktiebolaget Lm Ericsson Arrangement in a data communication system
WO1999012298A3 (en) * 1997-09-02 1999-07-29 Ericsson Telefon Ab L M Arrangement in a data communication system
US6141749A (en) * 1997-09-12 2000-10-31 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with stateful packet filtering
US6098172A (en) * 1997-09-12 2000-08-01 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with proxy reflection
EP0909074A1 (en) * 1997-09-12 1999-04-14 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with multiple domain support
US6170012B1 (en) 1997-09-12 2001-01-02 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with cache query processing
US7143438B1 (en) 1997-09-12 2006-11-28 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with multiple domain support
US6154775A (en) * 1997-09-12 2000-11-28 Lucent Technologies Inc. Methods and apparatus for a computer network firewall with dynamic rule processing with the ability to dynamically alter the operations of rules
US6226751B1 (en) * 1998-04-17 2001-05-01 Vpnet Technologies, Inc. Method and apparatus for configuring a virtual private network
US6389532B1 (en) 1998-04-20 2002-05-14 Sun Microsystems, Inc. Method and apparatus for using digital signatures to filter packets in a network
WO1999055052A1 (en) * 1998-04-20 1999-10-28 Sun Microsystems, Inc. Method and apparatus for using digital signatures to filter packets in a network
FR2778290A1 (en) * 1998-04-30 1999-11-05 Bull Sa Method and device securisee interconnection between computers, organized as a network, by controlling a filtering module residing in the communication layer ip
EP0955758A1 (en) * 1998-04-30 1999-11-10 Bull S.A. Method and arrangement for secure interconnection of networked computers
WO1999067930A2 (en) * 1998-06-19 1999-12-29 Ssh Communications Security Ltd. Method and arrangement for implementing ipsec policy management using filter code
WO1999067930A3 (en) * 1998-06-19 2001-10-04 Pekka Nikander Method and arrangement for implementing ipsec policy management using filter code
US6253321B1 (en) 1998-06-19 2001-06-26 Ssh Communications Security Ltd. Method and arrangement for implementing IPSEC policy management using filter code
US7912856B2 (en) 1998-06-29 2011-03-22 Sonicwall, Inc. Adaptive encryption
EP1105809A2 (en) * 1998-06-29 2001-06-13 Internet Dynamics, Inc. Generalized policy server
EP1105809A4 (en) * 1998-06-29 2005-10-05 Internet Dynamics Inc Generalized policy server
WO2000002114A2 (en) * 1998-07-02 2000-01-13 Effnet Group Ab Firewall apparatus and method of controlling network data packet traffic between internal and external networks
WO2000002114A3 (en) * 1998-07-02 2000-02-17 Andrej Brodnik Firewall apparatus and method of controlling network data packet traffic between internal and external networks
US7036141B1 (en) 1998-09-11 2006-04-25 Teliasonera Ab Transmission system, a method and an apparatus providing access for IP data packets to a firewall protected network
WO2000016530A2 (en) * 1998-09-11 2000-03-23 Telia Ab (Publ) A transmission system, a method and an apparatus providing access for ip data packets to a firewall protected network
WO2000016530A3 (en) * 1998-09-11 2000-05-25 Telia Ab A transmission system, a method and an apparatus providing access for ip data packets to a firewall protected network
WO2000025194A1 (en) * 1998-10-27 2000-05-04 Saios Technologies Holding S.A. Security interface for data exchange
US7162738B2 (en) 1998-11-03 2007-01-09 Tumbleweed Communications Corp. E-mail firewall with stored key encryption/decryption
US7127741B2 (en) 1998-11-03 2006-10-24 Tumbleweed Communications Corp. Method and system for e-mail message transmission
WO2000031931A1 (en) * 1998-11-24 2000-06-02 Telefonaktiebolaget Lm Ericsson (Publ) Method and system for securing data objects
US8914410B2 (en) 1999-02-16 2014-12-16 Sonicwall, Inc. Query interface to policy server
US6847609B1 (en) 1999-06-29 2005-01-25 Adc Telecommunications, Inc. Shared management of a network entity
US6959006B1 (en) 1999-06-29 2005-10-25 Adc Telecommunications, Inc. Service delivery unit for an enterprise network
EP1113641A2 (en) * 1999-12-30 2001-07-04 Samsung Electronics Co., Ltd. System and method for filtering mobile Internet access at BTS/BSC
EP1113641A3 (en) * 1999-12-30 2002-07-10 Samsung Electronics Co., Ltd. System and method for filtering mobile Internet access at BTS/BSC
US7870293B2 (en) 2001-02-17 2011-01-11 Yahoo! Inc. Header-based network API
US9331983B2 (en) 2001-02-17 2016-05-03 Yahoo! Inc. Content-based billing
WO2002067544A3 (en) * 2001-02-17 2003-11-06 Inktomi Corp Header-based network api
WO2002067544A2 (en) * 2001-02-17 2002-08-29 Inktomi Corporation Header-based network api
GB2372413A (en) * 2001-02-20 2002-08-21 Hewlett Packard Co Digital credential exchange
US8250624B2 (en) 2001-03-14 2012-08-21 Gemalto Sa Portable device for securing packet traffic in a host platform
US10116621B2 (en) 2001-06-22 2018-10-30 Axway Inc. Method and system for messaging security
US8407780B2 (en) 2001-06-22 2013-03-26 Axway Inc. Method and system for messaging security
US7469418B1 (en) 2002-10-01 2008-12-23 Mirage Networks, Inc. Deterring network incursion
US8819285B1 (en) 2002-10-01 2014-08-26 Trustwave Holdings, Inc. System and method for managing network communications
US7506360B1 (en) 2002-10-01 2009-03-17 Mirage Networks, Inc. Tracking communication for determining device states
US9667589B2 (en) 2002-10-01 2017-05-30 Trustwave Holdings, Inc. Logical / physical address state lifecycle management
US8260961B1 (en) 2002-10-01 2012-09-04 Trustwave Holdings, Inc. Logical / physical address state lifecycle management
US7305705B2 (en) 2003-06-30 2007-12-04 Microsoft Corporation Reducing network configuration complexity with transparent virtual private networks
EP1494420A2 (en) * 2003-06-30 2005-01-05 Microsoft Corporation Reducing network configuration complexity with transparent virtual private networks
EP1494420A3 (en) * 2003-06-30 2006-06-07 Microsoft Corporation Reducing network configuration complexity with transparent virtual private networks
US9338026B2 (en) 2003-09-22 2016-05-10 Axway Inc. Delay technique in e-mail filtering system
WO2005094192A3 (en) * 2004-03-31 2006-01-26 Seung-Myun Baek Home network system
WO2005094192A2 (en) * 2004-03-31 2005-10-13 Lg Electronics, Inc. Home network system
CN1938991A (en) * 2004-03-31 2007-03-28 Lg电子株式会社 Home network system
US7668074B2 (en) 2004-03-31 2010-02-23 Lg Electronics Inc. Home network system
DE102005046935B4 (en) * 2005-09-30 2009-07-23 Nokia Siemens Networks Gmbh & Co.Kg Network access node computer to a communication network, communication system and method for allocating a protection device
US10320748B2 (en) 2017-02-23 2019-06-11 At&T Intellectual Property I, L.P. Single packet authorization in a cloud computing environment

Also Published As

Publication number Publication date
WO1997000471A3 (en) 1997-03-06

Similar Documents

Publication Publication Date Title
Strand Adaptive distributed firewall using intrusion detection
Dzung et al. Security for industrial communication systems
US6154839A (en) Translating packet addresses based upon a user identifier
US7536715B2 (en) Distributed firewall system and method
US6931529B2 (en) Establishing consistent, end-to-end protection for a user datagram
US8239960B2 (en) Method for network traffic mirroring with data privacy
US6131120A (en) Enterprise network management directory containing network addresses of users and devices providing access lists to routers and servers
US6076168A (en) Simplified method of configuring internet protocol security tunnels
US5983350A (en) Secure firewall supporting different levels of authentication based on address or encryption status
US7231664B2 (en) System and method for transmitting and receiving secure data in a virtual private group
Scott et al. Virtual private networks
US7299353B2 (en) Firewall system for interconnecting two IP networks managed by two different administrative entities
US7562386B2 (en) Multipoint server for providing secure, scaleable connections between a plurality of network devices
US6550012B1 (en) Active firewall system and methodology
US7346770B2 (en) Method and apparatus for traversing a translation device with a security protocol
US7774837B2 (en) Securing network traffic by distributing policies in a hierarchy over secure tunnels
US7003662B2 (en) System and method for dynamically determining CRL locations and access methods
EP1494420B1 (en) Reducing network configuration complexity with transparent virtual private networks
US20040250072A1 (en) Network connectable device and method for its installation and configuration
US6304973B1 (en) Multi-level security network system
US6874089B2 (en) System, method and computer program product for guaranteeing electronic transactions
US6061454A (en) System, method, and computer program for communicating a key recovery block to enable third party monitoring without modification to the intended receiver
KR100414238B1 (en) Secure network protocol system and method
US6751728B1 (en) System and method of transmitting encrypted packets through a network access point
US7552323B2 (en) System, apparatuses, methods, and computer-readable media using identification data in packet communications

Legal Events

Date Code Title Description
AK Designated states

Kind code of ref document: A2

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A2

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA

ENP Entry into the national phase in:

Ref country code: CA

Ref document number: 2197548

Kind code of ref document: A

Format of ref document f/p: F

WWE Wipo information: entry into national phase

Ref document number: 2197548

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: 1019970700981

Country of ref document: KR

WWE Wipo information: entry into national phase

Ref document number: 1996918822

Country of ref document: EP

AK Designated states

Kind code of ref document: A3

Designated state(s): AL AM AT AU AZ BB BG BR BY CA CH CN CZ DE DK EE ES FI GB GE HU IL IS JP KE KG KP KR KZ LK LR LS LT LU LV MD MG MK MN MW MX NO NZ PL PT RO RU SD SE SG SI SK TJ TM TR TT UA UG US UZ VN AM AZ BY KG KZ MD RU TJ TM

AL Designated countries for regional patents

Kind code of ref document: A3

Designated state(s): KE LS MW SD SZ UG AT BE CH DE DK ES FI FR GB GR IE IT LU MC NL PT SE BF BJ CF CG CI CM GA

WWP Wipo information: published in national office

Ref document number: 1019970700981

Country of ref document: KR

WWP Wipo information: published in national office

Ref document number: 1996918822

Country of ref document: EP

REG Reference to national code

Ref country code: DE

Ref legal event code: 8642

WWR Wipo information: refused in national office

Ref document number: 1019970700981

Country of ref document: KR

WWG Wipo information: grant in national office

Ref document number: 1996918822

Country of ref document: EP