USRE39360E1 - System for signatureless transmission and reception of data packets between computer networks - Google Patents
System for signatureless transmission and reception of data packets between computer networks Download PDFInfo
- Publication number
- USRE39360E1 USRE39360E1 US09/136,954 US13695498A USRE39360E US RE39360 E1 USRE39360 E1 US RE39360E1 US 13695498 A US13695498 A US 13695498A US RE39360 E USRE39360 E US RE39360E
- Authority
- US
- United States
- Prior art keywords
- data packet
- computer
- encrypted
- host
- network
- Prior art date
- Legal status (The legal status 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 status listed.)
- Expired - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/04—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks
- H04L63/0428—Network architectures or network communication protocols for network security for providing a confidential data exchange among entities communicating through data packet networks wherein the data content is protected, e.g. by encrypting or encapsulating the payload
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/02—Details
- H04L12/22—Arrangements for preventing the taking of data from a data transmission channel without authorisation
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L12/00—Data switching networks
- H04L12/28—Data switching networks characterised by path configuration, e.g. LAN [Local Area Networks] or WAN [Wide Area Networks]
- H04L12/46—Interconnection of networks
- H04L12/4604—LAN interconnection over a backbone network, e.g. Internet, Frame Relay
- H04L12/462—LAN interconnection over a bridge based backbone
- H04L12/4625—Single bridge functionality, e.g. connection of two networks over a single bridge
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/16—Implementing security features at a particular protocol layer
- H04L63/164—Implementing security features at a particular protocol layer at the network layer
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2212/00—Encapsulation of packets
Definitions
- the present invention relates to the field of secure transmission of data packets, and in particular to a new system for automatically encrypting and decrypting data packets between sites on the Internet or other networks of computer networks.
- FIG. 1 illustrates a network of computer networks, including networks N 1 , N 2 and N 3 interconnected via a public network 10 (such as the Internet).
- network N 1 When network N 1 is designed in conventional fashion, it includes several to many computers (hosts), such as host A and additional hosts 20 and 30 .
- network N 2 includes host B and additional hosts 40 and 50
- network N 3 includes hosts 60 - 90 . There may be many hosts on each network, and many more individual networks than shown here.
- each data packet is routed via the internetwork 10 to the receiving network N 2 , and ultimately to the receiving host B.
- IP internet protocol
- IP Internet Protocol
- the system of the invention includes a tunnelling bridge positioned at the interface between a private network and a public network (or internetwork) for each of a number of such private networks.
- Each tunnelling bridge is a stand-alone computer with a processor and a memory, and in each tunnelling bridge's memory is a hosts table identifying which hosts should have their data packets (sent or received) encrypted.
- a networks table could be used, indicating whether data packets to and from particular networks should be encrypted; or other predetermined criteria may be stored that indicate whether particular data packets should be encrypted.
- the tunnelling bridge for a given private network intercepts all packets sent outside the network, and automatically determines from the tables whether each such packet should be encrypted. If so, then the tunnelling bridge encrypts the packet using an encryption method and key appropriate for the destination host, adds an encapsulation header with source and destination address information (either host address or IP broadcast address for the network) and sends the packet out onto the internetwork.
- another tunnelling bridge intercepts all incoming data packets, inspects the source and destination address information, and determines from its local hosts (or networks) table whether the packet should be decrypted, and if so, by what method and using what key. The packet is decrypted, if necessary, and sent on to the destination host.
- the encapsulation header may include a field with an identifier of the source tunnelling bridge. This is particularly useful if more than one tunnelling bridge is to be used for a given network (each tunnelling bridge having different encryption requirements and information), and in this case the receiving tunnelling bridge decrypts the data packets according to locally stored information indicating the encryption type and decryption key for all packets coming from the source tunnelling bridge.
- FIG. 1 is a diagram of a network of computer networks in conjunction with which the system of the present invention may be used.
- FIG. 2 is a block diagram of a host computer A on computer network N 1 shown in FIG. 1 .
- FIG. 3 is a diagram of a network of computer networks incorporating tunnelling bridges according to the present invention.
- FIG. 4 is a block diagram of several tunnelling bridges of the present invention in a network of computer networks N 1 -N 3 as shown in FIG. 3 .
- FIG. 5 is a diagram of another configuration of networks incorporating tunnelling bridges according to the present invention.
- FIG. 6 is a flow chart illustrating the method of signatureless tunnelling of the present invention.
- FIG. 7 illustrates a conventional data structure for a data packet.
- FIGS. 8-11 illustrate modified data structures for use in different embodiments of the system of the invention.
- FIG. 12 is a block diagram of a network of computer networks including two tunnelling bridges of the invention on a single computer network.
- the system of the present invention is designed to be implemented in existing computer networks, and in the preferred embodiment uses the addition of a tunnelling bridge at junctions between local computer networks and public or larger-scale networks such as the Internet.
- the mechanisms for carrying out the method of the invention are implemented by computers acting as these tunnelling bridges, incorporating program instructions stored in memories of the tunnelling bridges and appropriate (standard) network connections and communications protocols.
- FIG. 3 shows a network 100 of networks N 1 , N 2 and N 3 according to the invention, where each network includes a tunnelling bridge—TB 1 , TB 2 and TB 3 , respectively—which intercepts all data packets from or to the respective networks.
- Networks N 1 -N 3 may in other respects be identical to networks N 1 -N 3 in conventional designs.
- any references to networks N 1 -N 3 or hosts A and B should be taken as referring to the configuration shown in FIG. 3 , unless specified otherwise.
- Mode 1 uses the configuration of FIG. 1
- the other modes all use the configuration of FIG. 3
- the features of the tunnelling bridges TB 1 and TB 2 (including their program instructions, actions taken, etc.) in modes 2 - 3 A are, in mode 1 , features of, respectively, hosts A and B.
- Each of the tunnelling bridges TB 1 -TB 3 is preferably implemented in a separate, conventional computer having a processor and a memory, as shown in FIG. 4 .
- the memory may be some combination of random-access-memory (RAM), read-only-memory (ROM), and other storage media, such as disk drives, CD-ROMs, etc.
- the program instructions for each of the bridges TB 1 -TB 3 are stored in their respective memories, and are executed by their respective microprocessors. The method of the present invention is carried out by a combination of steps executed as necessary by each of the processors of the sending host A, the tunnelling bridges TB 1 and TB 2 , and the receiving host B.
- Encryption of data is an important step in the overall method of the invention, but the particular encryption mechanism used is not critical. It is preferable to use a flexible, powerful encryption approach such as the Diffie-Hellman method (see W. Diffie and M. Hellman, “New Directions in Cryptography”, IEEE Transactions of Information Theory, November 1976). (The use of encryption in connection with IP data transfers is discussed in some detail in applicant's copending patent application, “Method and Apparatus for Key-Management Scheme for Use With Internet Protocols at Site Firewalls” by A. Aziz, Ser. No. 08/258,344 filed Jun. 10, 1994, which application is incorporated herein by reference.) However, any encryption scheme that provides for encryption by a first machine, which sends the data packets, and decryption by a receiving machine, will be appropriate.
- FIG. 6 illustrates the method of the invention, and commences with the generation of data packets at the sending host A.
- the user at host A enters conventional commands for transmitting a file or the like from host A to host B, and the host computer A carries out the standard procedures for breaking the file down into data packets as in FIG. 7 , each including both the data 410 and a header 400 .
- this will be the IP header.
- the current discussion will be directed in large part to IP-specific implementations, it should be understood that any network protocol may be used in conjunction with the present invention.
- each data packet initially has a structure like that of data packet 400 shown in FIG. 7 , including a data field 410 and a header field 420 .
- the header 420 includes the destination address, in this example the IP address of host B.
- each packet is intercepted by the tunnelling bridge TB 1 (see FIGS. 3 and 4 ), when any of the modes 2 , 2 A, 3 or 3 A is used (see discussion below).
- steps 220 and 280 are omitted, since this mode does not use tunnelling bridges; instead, the actions taken by the tunnelling bridges in modes 2 - 3 A are all accomplished by the source and destination hosts themselves in mode 1 .
- TB 1 or TB 2 it should be understood that in the case of mode 1 , the same feature will be present in host A or host B, respectively.
- TB 1 Stored in the memory of TB 1 (or host A, for mode 1 ) is a look-up table (not separately shown) of the addresses of hosts, both on the local network N 1 and on remote networks such as N 2 and N 3 , and an indication for each network whether data packets from or to that host should be encrypted. For instance, in this case the hosts table of TB 1 indicates that any messages sent from host A to host B should be encrypted. Thus, bridge TB 1 (or host A) looks up hosts A and B in its tables, and determines that the data packets to be transmitted must first be encrypted, as indicated at boxes 230 and 240 of FIG. 6 .
- the table could stored the network identifiers (e.g. broadcast addresses) or networks N 1 and N 2 , indicating that anything sent from network N 1 to network N 2 is to be encrypted.
- the table need not list each host in each network, which makes the table smaller and easier to maintain.
- the look-up table lists the networks N 1 and N 2 as networks to and from which packets should be encrypted, and also includes a hosts sections of the table indicating exceptions to the normal encryption rule for these networks. Thus, if networks N 1 and N 2 are listed in the look-up table, then packets travelling from N 1 to N 2 should normally be encrypted; however, if there is an “exceptions” subtable indicating that no packets from host A are to be encrypted, then the normal rule is superseded.
- the exceptions can, of course, go both ways: where the normal rule is that the packets for a given network pair should/should not be encrypted, and the exception is that for this given host (source or recipient) or host pair, the packet should not/should nonetheless be encrypted.
- the small size and ease of maintenance of the network tables is by and large retained, while the flexibility of the hosts table is achieved.
- step 270 the packet in question is transmitted unencrypted to the destination, via the Internet (or other intervening network).
- the packets are encrypted at box 250 .
- This is carded out by the tunnelling bridge TB 1 , according to whichever predetermined encryption scheme was selected, the primary requirement being that of ensuring that TB 2 is provided with the same encryption scheme so that it can decrypt the data packets.
- TB 2 must also be provided in advance with the appropriate key or keys for decryption.
- an encapsulation header is appended to the encrypted data packet.
- This header can take one of several alternative forms, according to the requirements of the user. Several modes of packet modification can be accommodated using the same basic data structure (but with differences in the information that is appended in the encapsulation header), such as the following:
- Mode Appended information Encryption key management information (itself unencrypted) New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 2 Encryption key management information (in encrypted form) Tunnelling bridge identifier for sender (unencrypted) New IP header including broadcast addresses of source and destination networks (unencrypted) 2A (Same as mode 2, but without the tunnelling bridge identifier.) 3 Encryption key management information (encrypted) Optional: tunnelling bridge identifier for sender (unencrypted) New IP header including originally generated IP addresses of source and destination hosts (unencrypted) 3A (Same as mode 3, but without the tunnelling bridge identifier.)
- FIGS. 8 , 9 and 10 Data structures for modes 1 , 2 and 3 are depicted in FIGS. 8 , 9 and 10 , respectively, wherein like reference numerals indicate similar features, as described below.
- the data structure for mode 2 A is illustrated in FIG. 11
- mode 3 A may use the data structure of FIG. 8 .
- the data structure 402 for mode 1 is represented in FIG. 8 .
- the original data 410 and original header 420 are now encrypted, indicated as ( 410 ) and ( 420 ).
- Encryption key management information 440 is appended (in encrypted form) as pan of the new encapsulation header 430 , along with a new IP header 450 , including the addresses of the source and destination hosts.
- the information 430 includes indicates which encryption scheme was used.
- Key management information can include a variety of data, depending upon the key management and encryption schemes used. For instance, it would be appropriate to use applicant's Simple Key-Management for Internet Protocols (SKIP), which is described in detail in the attached Appendix A.
- SSLIP Simple Key-Management for Internet Protocols
- the fields with reference numerals in parentheses are encrypted, and the other fields are unencrypted.
- the original data field 410 and address field 420 are encrypted, while the new encapsulation header 430 , including the key management information 440 and the IP header 450 , is not encrypted.
- the tunnelling bridges TB 1 and TB 2 might not be used at all, but rather the hosts A and B could include all the instruction, tables, etc. necessary to encrypt, decrypt, and determine which packets are to be encrypted and using which encryption scheme.
- Mode 1 allows any intervening observer to identify the source and destination hosts, and thus does not provide the highest level of security. It does, however, provide efficient and automatic encryption and decryption for data packets between hosts A and B, without the need for additional computers to serve as TB 1 and TB 2 .
- mode 1 field 440 could include the IP broadcast addresses of the source and destination networks (instead of that of the hosts themselves), and in addition may include a code in the encryption key management information indicating which encryption scheme was used. This information would then be used by an intercepting computer (such as a tunnelling bridge) on the destination network, which decrypts the data packet and sends it on to the destination host.
- an intercepting computer such as a tunnelling bridge
- a data structure 404 is used, and includes a new encapsulation header 432 . It includes key encryption management information 440 , which is appended to the original data packet 400 , and both are encrypted, resulting in encrypted fields ( 410 ), ( 420 ) and ( 440 ) shown in FIG. 9.
- a new IP header 470 including the broadcast addresses of the source and destination networks (not the addresses of the hosts, as in field 450 in FIG. 8 ) is appended.
- a tunnelling bridge identifier field 460 is appended as part of the encapsulation header 432 .
- fields 410 , 420 and 440 in this embodiment are all encrypted, while fields 460 and 470 are not.
- the tunnelling bridge identifier identifies the source tunnelling bridge, i.e. the tunnelling bridge at the network containing the host from which the packet was sent.
- the recipient tunnelling bridge contains a tunnelling bridge look-up table, indicating for each known tunnelling bridge any necessary information for decryption, most notably the decryption method and key.
- An appropriate tunnelling bridge identifier might be a three-byte field, giving 224 or over 16 million unique tunnelling bridge identifiers.
- An arbitrarily large number of individual tunnelling bridges may each be given a unique identifier in this way, simply by making the field as large as necessary, and indeed the field may be of a user-selected arbitrarily variable size. If desired, a four-byte field can be used, which will accommodate over 4 billion tunnelling bridges, far exceeding present needs.
- any observer along the circuit taken by a given data packet can discern only the tunnelling bridge identifier and the IP broadcast addresses for the source and destination networks.
- the IP broadcast address for the destination network will typically be something like “129.144.0.0”, which represents a particular network (in this case, “Eng.Sun.COM”) but not any specific host.
- 129.144.0.0 represents a particular network (in this case, “Eng.Sun.COM”) but not any specific host.
- the identification number of the receiving tunnelling bridge can be determined, but that is the extent of it; the source and destination hosts, the key management information, and the contents of the data packet are all hidden.
- Mode 2 A uses the data structure shown in FIG. 11 , wherein the IP broadcast addresses for the source and recipient networks N 1 and N 2 are included in the encapsulation header field 470 , but no tunnelling bridge identifier is used.
- This embodiment is particularly suitable for networks where there is only one tunnelling bridge for the entire network, or indeed for several networks, as illustrated in FIG. 5 .
- a packet sent from host C to host D will first be sent from network N 4 to network N 5 , and will then be intercepted by the tunnelling bridge TB 4 , which intercepts all messages entering or leaving these two networks.
- TB 4 will encrypt the packet or not, as indicated by its hosts look-up table.
- the packet traverses the public network and is routed to network N 7 , first being intercepted by tunnelling bridge TB 5 (which intercepts all messages entering or leaving networks N 6 -N 8 ), and at that point being decrypted if necessary.
- a tunnelling bridge identifier is not a necessary field in the encapsulation header. Since in this case only a given tunnelling bridge could have intercepted packets from a given host (e.g., TB 4 for host C in FIG. 5 ), the identity of the source tunnelling bridge is unambiguous, and the destination tunnelling bridge TB 5 will include a table of hosts and/or networks cross-correlated with TB 4 . Having determined that tunnelling bridge TB 4 was the source tunnelling bridge, TB 5 then proceeds with the correct decryption.
- a tunnelling bridge identifier field provides flexibility.
- subnetworks N 11 and N 12 are part of one larger network N 10 , and each subnetwork N 11 and N 12 has its own assigned tunnelling bridge (TB 7 and TB 8 , respectively).
- tunnelling bridge TB 7 and TB 8 , respectively.
- subnetworks N 11 and N 12 can be subjected to different types of encryption, automatically, and that encryption can be altered at will for one subnetwork, without altering it for the other.
- a packet traveling from host F to host E in FIG. 12 will include a source tunnelling bridge identifier (TB 7 ) so that, when it reaches TB 6 at network N 9 , it is identified correctly as having been encrypted by TB 7 and not TB 8 .
- tunnelling bridge TB 6 need maintain a table only the information pertaining to the tunnelling bridges, and does not need to maintain encryption/decryption specifies for the host or network level. (Note that TB 6 still maintains information relating to whether to encrypt messages sent between host A and host B or network N 1 and network N 2 , as the case may be, as discussed above.)
- the tunnelling bridge identifier may be used for a variety of other purposes relating to the source tunnelling bridge, such as statistics recording the number of packets received from that tunnelling bridge, their dates and times of transmission, sizes of packets, etc.
- An alternative to the use of hosts or networks tables in the memories of the source and destination tunnelling bridges would be any information identifying one or more predetermined criteria by which the source host or source tunnelling bridge determines whether to encrypt a given data packet.
- criteria need not merely be source and destination information, but could include packet contents, time of transmission, subject header information, user id., presence of a key word (such as “encrypt”) in the body of the packet, or other criteria.
- Mode 3 uses a data structure 406 as shown in FIG. 10 , which is identical to the data structure 402 except for the addition of field 460 containing the tunnelling bridge identifier, which is the same as the tunnelling bridge identifier discussed above relative it mode 2 .
- field 450 includes the original host IP addresses for the source and destination hosts (not the addresses of the networks, as in mode 2 ), and thus an observer of a mode 3 packet will be able to determine both the original sender of the data packet and the intended receiver.
- Either mode contains sufficient information to route packets through an internet to recipient network's tunnelling bridge for decryption and ultimate delivery to the recipient host.
- Mode 3 A may use the data structure shown in FIG. 8 , in conjunction with a network configuration such as those shown in FIGS. 3 or 12 .
- the mechanisms and relative advantages are identical to those described above for mode 2 A, while the structure reveals the source and destination host addresses.
- the packet is, at box 270 , then transmitted to the destination network.
- the destination network's tunnelling bridge (here, TB 2 shown in FIG. 3 ) intercepts the packet, which is accomplished by an instruction routine by which all packets are intercepted and inspected for encapsulation header information indicating encryption.
- the encapsulation header of the packet is read, and at box 300 it is determined whether the packet was encrypted. If a tunnelling bridge identifier forms a part of the encapsulated packet, then the method of encryption and decryption key are determined from the destination tunnelling bridge's (or destination host's, in the case of mode 1 ) local tables.
- the certificates used by PEM are RSA public key certificates. Use of RSA public key certificates also enable the establishment of an authenticated session key [2,3]. (By an RSA public key certificate, what is meant here is that the key being certified is an RSA public key.)
- IP One way to obtain authenticity and privacy at a datagram layer like IP is to use RSA public key certificates. (In the following description we use the term IP, although IP is replacable by IPng in this context).
- RSA certificates can be used to provide authenticity and privacy for a datagram protocol.
- the first way is to use out-of-band establishment of an authenticated session key, using one of several session key establishment protocols. This session key can then be used to encrypt IP data traffic.
- Such a scheme has the disadvantage of establishing and maintaining a pseudo session state underneath a session-less protocol. The IP source would need to first communicate with the IP destination in order to acquire this session key.
- the IP source and the IP destination need to communicate again in order to make this happen.
- Each such communication involves the use of a computationally expensive public-key operation.
- the second way an RSA certificate can be used is to do in-band signalling of the packet encryption key, where the packet encryption key is encrypted in the recipient's public key.
- This is the way, e.g, PEM and other public-key based secure e-mail systems do message encryption.
- PEM and other public-key based secure e-mail systems do message encryption.
- this scheme avoids the session state establishment requirement, and also does not require the two parties to communicate in order to set up and change packet encryption keys, this scheme has the disadvantage of having to carry the packet encryption key encrypted in the recipient's public key in every packet.
- This kind of key-management scheme is better suited to protocols like IP, because it doesn't even require the remote side to be up in order to establish and change packet encryption keys. This scheme is described in more detail below.
- each IP based source and destination has a certified Diffie-Hellman public key.
- This public-key is distributed in the form of a certificate.
- the certificate can be signed using either an RSA or DSA signature algorithm. How the certificates are managed is described in more detail later.
- each IP source or destination I has a secret value i, and a public value g**i mod p.
- IP node J has a secret value j and a public value g**j mod p.
- Each pair of IP source and destination I and J can acquire a shared secret g**ij mod p. They can acquire this shared secret without actually having to communicate, as long as the certificate of each IP node is known to all the other IP nodes. Since the public-key is obtained from a certificate, one natural way for all parties to discover the relevant public-keys is to distribute these certificates using a directory service.
- This computable shared secret is used as the basis for a key-encrypting-key to provide for IP packet based authentication and encryption.
- g**ij mod p the long-term secret, and derive from it a key Kij.
- Kij is used as the key for a shared-key cryptosystem (SKCS) like DES or RC 2 .
- SKCS shared-key cryptosystem
- Kij is derived from g**ij mod p by taking the high order key-size bits of g**ij mod p. Since g**ij mod p is minimally going to be 512 bits and for greater security is going to be 1024 bits or higher, we can always derive enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are typically in the range of 40-256 bits.
- Kij is an implicit pair-wise shared key. It does not need to be sent in every packet or negotiated out-of-band. Simply by examining the source of an IP packet, the destination IP node can compute this shared key Kij. Because this key is implicit, and is used as a master key, its length can be made as long as desired, without any additional protocol overhead, in order to make cryptanalysis of Kij arbitrarily difficult.
- Kij we use Kij to encrypt a transient key, which we call Kp (for packet key). Kp is then used to encrypt/authenticate an IP packet or collection of packets. This is done in order to limit the actual amount of data in the long-term key. Since we would like to keep the long-term key for a relatively long period of time, say one or two years, we don't encrypt the actual IP data traffic in key Kij.
- IP source I which has a secret value i
- IP destination J which has a secret value j
- IP source I then generates a random key Kp and encrypts this key using Kij. It encrypts the relevant portion of the IP packet in key Kp (which may be the entire IP packet or just the payload of the IP packet depending on the next-protocol field in IPSP protected data potion).
- the value of the SAID field is used by SKIP to indicate the mode of processing and to identify the implicit interchange key. Typical modes of processing are encrypted, encrypted-authenticated, authenticated, compression etc.
- the modes of operation are identified by the upper 6 bits of the SAID field.
- the meanings of these upper 6 bits is specified in section 2.5 below on SAID derived processing modes.
- the low 22 bits of the SAID field are zero.
- next protocol field is IP
- IPSP is operating in encrypted-encapsulated mode
- the packet looks as follows. It sends the encrypted IP packet, the encrypted key Kp, encapsulated in a clear outer IP Header.
- IP node J When IP node J receives this packet, it also computes the shared secret Kij and caches it for later use. (In order to do this, if it didn't already possess I's certificate, it may have obtained this from the local directory service.) Using Kij it obtains Kp, and using Kp it obtains the original IP packet, which it then delivers to the appropriate place which is either a local transport entity or another outbound interface.
- the Message Indicator is a field that is needed to preserve the statelessness of the protocol. If a single key is used in order to encrypt multiple packets, (which is highly desirable since changing the key on a per packet basis constitutes too much overhead) then the packets need to be decryptable regardless of lost or out-of-order packets.
- the message indicator field serves this purpose.
- the MI for the first packet encrypted in key Kp is the Initialization Vector (IV).
- the MI is the last blocksize-bits of ciphertext of the last (in transmit order) packet.
- the MI is simply the count of bytes that have already been encrypted in key Kp (and can be 64 bits long also).
- the receiving IP node J can discover this fact without having to perform a public-key operation. It uses the cached value Kij to decrypt the encrypted packet key Kp, and this is a shared-key crypto-system operation. Thus, without requiting communication between transmitting and receiving ends, and without necessitating the use of a public-key operation, the packet encrypting key can be changed by the transmitting side.
- the nodes themselves have no public-key signature algorithm. This is not a major problem, since signing on a per-packet basis using a public-key cryptosystem is too cumbersome in any case.
- the integrity of the packets is determined in a pairwise fasion using a symmetric cryptosystem.
- SKIP compliant implementation use the encrypted packet key Kp to encrypt a message-digest of the packet, instead of the packet itself.
- This encrypted digest is appended at the end of the data portion of the IPSP.
- Kij alg and Kp alg identify the two encryption algorithms for keys Kij and Kp.
- MD alg is a 1 byte identifier for the message digest algorithm.
- This mode of operation is indicated by the SAID value which is further specified in Section 2.x.
- Unauthenticated Diffie-Hellman is susceptible to an intruder in the middle attack.
- authenticated Diffie-Hellman schemes have been proposed, that include a signature operation with the parties private signature keys.
- SKIP is not susceptible to intruder in the middle types of attacks. This is because the Diffie-Hellman public parameters are long-term and certified. Intruder in the middle attacks on Diffie-Hellman assume that the parties cannot determine who the public Diffie-Hellman keys belong to. Certified Diffie-Hellman public keys eliminate this possibility, without requiting any exchange of messages between the two parties or incurring the computational overhead of large exponent exponentiations (e.g., RSA signatures).
- large exponent exponentiations e.g., RSA signatures
- One possible way to do this is to provide a hardware device to computer, store and perform operations using these keys. This device can ensure that there are no interfaces to extract the key from the device.
- the pair key Kij can be the key that is manually set up.
- the upper 6 bits of the SAID field are used to indicate the processing mode.
- the processing modes defined so far are, encryption, authentication, compression, and packet sequencing (for playback protection). Since none of these modes is mutually exclusive, multiple bits being on indicate the employment of all the relevant processing modes.
- Bits 22 and 23 shall be one.
- a group membership creation primitive will need to establish the group secret value Km and the membership list of addresses that are allowed to transmit and receive encrypted multicast data-grams to and from group address M.
- the group key Km is not used as a packet encryption key, but rather as the group Interchange Key (IK).
- Nodes wishing to transmit/receive encrypted datagrams to multicast address M need to acquire the group IK Km. This is done by sending an encrypted/authenticated request to join primitive to the group owner. If the requesting node's address is part of the group's membership, then the group owner will send the IK Km, and associated lifetime information in an encrypted packet, using the pairwise secure protocol described in Section 2 above.
- Transmitting nodes to group address M will randomly generate packet encryption keys Kp, and encrypt these keys using Km.
- the packet structure is similar to the structure used for encrypted unicast IPSP packets, except for the fact that the packet keys Kp are not encrypted in the pair-wise keys Kij, but instead are encrypted using the group IK Km.
- An example encrypted multicast packet is shown below.
- Every member of the multicast group can change packet encryption keys as often as it desires, without involving key-setup communications overhead involving every member of the group.
- TLCA Top Level Certifying Authority
- IPRA Internet Policy Registration Authority
- PCAs Policy Certifying authorities
- DN Distinguished Name
- the nodes Since the nodes only have DH public keys, which have no signature capability, the nodes are themselves unable to issue certificates. This means that there is an algorithmic termination of a certificate path in a leaf node, unlike the certificate hierarchy employed in, e.g PEM, where every leaf node is potentially a rogue CA.
- the node certificates are issued by organizational CAs which have jurisdiction over the range of IP addresses that are being certified.
- the PCAs will have to perform suitable checks (in line with the advertised policy of that PCA) to confirm that the organization which has jurisdiction over a range of addresses is issued a certificate giving it the authority to certify the DH values of individual nodes with those addresses.
- This authority will be delegated in the form of a authorization certificate signed by the PCA.
- the CA's Distinguished Name (DN) will be bound to the range of IP addresses over which it has jurisdiction.
- the CA has either an RSA or DSA certificate issued by the PCA.
- An authorization certificate will also contain information about whether the CA to whom authority is being delegated can sub-delegate that authority.
- the CA which has delegatable authority over a range of IP addresses can delegate authority over part of the range to a subordinate CA, by signing another authorization certificate using its own private key. If the authority is non-delegatable, then the CA cannot delegate authority for that range of addresses.
- the range of IP addresses are identified in the authorization certificate in the form of a list of IP address prefix, length pairs.
- DHPublicKey: INTEGER and from PKCS #3,
- AlgorithmIdentifier SEQUENCE ⁇ algorithm OBJECT IDENTIFIER SEQUENCE ⁇ prime INTEGER, — p base INTEGER, — g privateValueLength INTEGER OPTIONAL ⁇ ⁇ with the OBJECT IDENTIFIER value being
- dhKeyAgreement OBJECT IDENTIFIER ⁇ iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) 3 1 ⁇ which is also taken from PKCS #3.
- DHPublicKey is what gets encapsulated as the BIT STRING in SubjectPublicKeyInfo of an X.509 certificate in the obvious manner.
- the certificate is allowed to bind multiple IP addresses to a single public value to accommodate cases where a single IP node has multiple IP addresses.
- the SEQUENCE OF construct in a DN readily allows for this. What is needed is an OBJECT IDENTIFIER for an AttributeType specifying an IP address. This is defined here as,
- the DN in the certificate can contain multiple of these by iterating on the SEQUENCE OF construct of the Relative Distinguished Name Sequence.
- the Printable string contains either the hexadecimal representation or standard dot notation representation of an IP address.
- An authorization certificate is associated with each CA below the PCA level.
- the authorization certificate in effect entitles a CA to bind IP addresses to DH public keys.
- a major advantage of this scheme is that establishing and changing packet encrypting keys requires no communication between sending and receiving nodes and no establishment of a pseudo-session state between the two sides is required.
- the key-management scheme here has structural similarities with the scheme used by PEM [1]. Both use the concept of an inter-change key (in our case that is the pair keys Kij) and data encrypting keys (the packet encryption keys Kp). By using the Implicit shared secret property of long-term DH public values, and treating the resulting keys as keys for a SKCS, we have reduced the protocol overhead substantially as compared to the overhead of PEM when used in conjunction with an asymmetric key-management system.
Abstract
A system for automatically encrypting and decrypting data packet sent from a source host to a destination host across a public internetwork. A tunnelling bridge is positioned at each network, and intercepts all packets transmitted to or from its associated network. The tunnelling bridge includes tables indicated pairs of hosts or pairs of networks between which packets should be encrypted. When a packet is transmitted from a first host, the tunnelling bridge of that host's network intercepts the packet, and determines from its header information whether packets from that host that are directed to the specified destination host should be encrypted; or, alternatively, whether packets from the source host's network that are directed to the destination host's network should be encrypted. If so, the packet is encrypted, and transmitted to the destination network along with an encapsulation header indicating source and destination information: either source and destination host addresses, or the broadcast addresses of the source and destination networks (in the latter case, concealing by encryption the hosts' respective addresses). An identifier of the source network's tunnelling bridge may also be included in the encapsulation header. At the destination network, the associated tunnelling bridge intercepts the packet, inspects the encapsulation header, from an internal table determines whether the packet was encrypted, and from either the source (host or network) address or the tunnelling bridge identifier determines whether and how the packet was encrypted. If the packet was encrypted, it is now decrypted using a key stored in the destination tunnelling bridge's memory, and is sent on to the destination host. The tunnelling bridge identifier is used particularly in an embodiment where a given network has more than one tunnelling bridge, and hence multiple possible encryption/decryption schemes and keys. In an alternative embodiment, the automatic encryption and decryption may be carried out by the source and destination hosts themselves, without the use of additional tunnelling bridges, in which case the encapsulation header includes the source and destination host addresses.
Description
Cross-reference is made to U.S. application Ser. No. 10/147,933 which is a continuation Reissue Application of U.S. Pat. No. 5,548,646.
The present invention relates to the field of secure transmission of data packets, and in particular to a new system for automatically encrypting and decrypting data packets between sites on the Internet or other networks of computer networks.
It is becoming increasingly useful for businesses to transmit sensitive information via networks such as the Internet from one site to another, and concomitantly more urgent that such information be secured from uninvited eyes as it traverses the internetwork. At present, unsecured data is replicated at many sites in the process of being transmitted to a destination site, and trade secret or other private information, unless secured, is thereby made available to the public.
It is possible for a user at the sending host to encrypt the data to be sent, and to inform the user who is to receive the data of the encryption mechanism used, along with the key necessary to decrypt. However, this requires communication and coordinated effort on the parts of both the sending and receiving users, and often the users will not take the requisite trouble and the packets will go unencrypted.
Even when these packets are encrypted, the very fact of their being transmitted from user A to user B may be sensitive, and a system is needed that will also make this information private.
When a user at host A wishes to send a file, email or the like to host B, the file is split into packets, each of which typically has a structure such as network 400 shown in FIG. 7 , including data 410 and a header 420. For sending over the Internet, the header 420 will be an internet protocol (IP) header containing the address of the receipt (destination) host B. In conventional fashion, each data packet is routed via the internetwork 10 to the receiving network N2, and ultimately to the receiving host B.
As indicated above, even if the user at host A encrypts the file or data packets before sending, and user B is equipped with the necessary key to decrypt them, the identities of the sending and receiving hosts are easily discernible from the Internet Protocol (IP) addresses in the headers of the packets. Current internetworks do not provide an architecture or method for keeping this information private. More basically, they do not even provide a system for automatic encryption and decryption of data packets sent from one host to another.
The system of the invention includes a tunnelling bridge positioned at the interface between a private network and a public network (or internetwork) for each of a number of such private networks. Each tunnelling bridge is a stand-alone computer with a processor and a memory, and in each tunnelling bridge's memory is a hosts table identifying which hosts should have their data packets (sent or received) encrypted. Alternatively, a networks table could be used, indicating whether data packets to and from particular networks should be encrypted; or other predetermined criteria may be stored that indicate whether particular data packets should be encrypted.
The tunnelling bridge for a given private network (or subnetwork of a private network) intercepts all packets sent outside the network, and automatically determines from the tables whether each such packet should be encrypted. If so, then the tunnelling bridge encrypts the packet using an encryption method and key appropriate for the destination host, adds an encapsulation header with source and destination address information (either host address or IP broadcast address for the network) and sends the packet out onto the internetwork.
At the destination host, another tunnelling bridge intercepts all incoming data packets, inspects the source and destination address information, and determines from its local hosts (or networks) table whether the packet should be decrypted, and if so, by what method and using what key. The packet is decrypted, if necessary, and sent on to the destination host.
In this way, all messages that are predetermined to require encryption, e.g. all messages from a given host A to another host B, are automatically encrypted, without any separate action on the part of the user. In this way, no one on the public internetwork can determine the contents of the packets. If the encapsulation header utilizes the network IP source and destination addresses, with the source and destination host addresses encrypted, then the host identities are also concealed, and an intervening observer can discern only the networks' identities.
The encapsulation header may include a field with an identifier of the source tunnelling bridge. This is particularly useful if more than one tunnelling bridge is to be used for a given network (each tunnelling bridge having different encryption requirements and information), and in this case the receiving tunnelling bridge decrypts the data packets according to locally stored information indicating the encryption type and decryption key for all packets coming from the source tunnelling bridge.
The system of the present invention is designed to be implemented in existing computer networks, and in the preferred embodiment uses the addition of a tunnelling bridge at junctions between local computer networks and public or larger-scale networks such as the Internet. The mechanisms for carrying out the method of the invention are implemented by computers acting as these tunnelling bridges, incorporating program instructions stored in memories of the tunnelling bridges and appropriate (standard) network connections and communications protocols.
In this system, there are several modes of operation, numbered and discussed below as modes 1, 2, 2A, 3 and 3A. Mode 1 uses the configuration of FIG. 1 , while the other modes all use the configuration of FIG. 3. The features of the tunnelling bridges TB1 and TB2 (including their program instructions, actions taken, etc.) in modes 2-3A are, in mode 1, features of, respectively, hosts A and B.
Each of the tunnelling bridges TB1-TB3 is preferably implemented in a separate, conventional computer having a processor and a memory, as shown in FIG. 4. The memory may be some combination of random-access-memory (RAM), read-only-memory (ROM), and other storage media, such as disk drives, CD-ROMs, etc. The program instructions for each of the bridges TB1-TB3 are stored in their respective memories, and are executed by their respective microprocessors. The method of the present invention is carried out by a combination of steps executed as necessary by each of the processors of the sending host A, the tunnelling bridges TB1 and TB2, and the receiving host B.
Encryption of data is an important step in the overall method of the invention, but the particular encryption mechanism used is not critical. It is preferable to use a flexible, powerful encryption approach such as the Diffie-Hellman method (see W. Diffie and M. Hellman, “New Directions in Cryptography”, IEEE Transactions of Information Theory, November 1976). (The use of encryption in connection with IP data transfers is discussed in some detail in applicant's copending patent application, “Method and Apparatus for Key-Management Scheme for Use With Internet Protocols at Site Firewalls” by A. Aziz, Ser. No. 08/258,344 filed Jun. 10, 1994, which application is incorporated herein by reference.) However, any encryption scheme that provides for encryption by a first machine, which sends the data packets, and decryption by a receiving machine, will be appropriate.
At box 200, the user at host A (see FIGS. 3 and 6 ) enters the conventional command for sending the file, email, or the like to a recipient, and host A generates data packets for sending over the Internet in the normal fashion. Each data packet initially has a structure like that of data packet 400 shown in FIG. 7 , including a data field 410 and a header field 420. The header 420 includes the destination address, in this example the IP address of host B.
The data packets are transmitted by host A at box 210, again in conventional fashion. However, at box 220, each packet is intercepted by the tunnelling bridge TB1 (see FIGS. 3 and 4), when any of the modes 2, 2A, 3 or 3A is used (see discussion below). When mode 1 (described below) is used, steps 220 and 280 are omitted, since this mode does not use tunnelling bridges; instead, the actions taken by the tunnelling bridges in modes 2-3A are all accomplished by the source and destination hosts themselves in mode 1. Thus, in the following discussion, wherever TB1 or TB2 is mentioned, it should be understood that in the case of mode 1, the same feature will be present in host A or host B, respectively.
Stored in the memory of TB1 (or host A, for mode 1) is a look-up table (not separately shown) of the addresses of hosts, both on the local network N1 and on remote networks such as N2 and N3, and an indication for each network whether data packets from or to that host should be encrypted. For instance, in this case the hosts table of TB1 indicates that any messages sent from host A to host B should be encrypted. Thus, bridge TB1 (or host A) looks up hosts A and B in its tables, and determines that the data packets to be transmitted must first be encrypted, as indicated at boxes 230 and 240 of FIG. 6.
Alternatively, the table could stored the network identifiers (e.g. broadcast addresses) or networks N1 and N2, indicating that anything sent from network N1 to network N2 is to be encrypted. In this case, the table need not list each host in each network, which makes the table smaller and easier to maintain.
If each host is listed, however, greater flexibility can be retained, since it may be that messages to or from particular hosts need or should not be encrypted. In an alternative embodiment, the look-up table lists the networks N1 and N2 as networks to and from which packets should be encrypted, and also includes a hosts sections of the table indicating exceptions to the normal encryption rule for these networks. Thus, if networks N1 and N2 are listed in the look-up table, then packets travelling from N1 to N2 should normally be encrypted; however, if there is an “exceptions” subtable indicating that no packets from host A are to be encrypted, then the normal rule is superseded. The exceptions can, of course, go both ways: where the normal rule is that the packets for a given network pair should/should not be encrypted, and the exception is that for this given host (source or recipient) or host pair, the packet should not/should nonetheless be encrypted. In this embodiment, the small size and ease of maintenance of the network tables is by and large retained, while the flexibility of the hosts table is achieved.
If the data to be transmitted from host A to host B (or network N1 to network N2) should not be encrypted, then the method proceeds directly to step 270, and the packet in question is transmitted unencrypted to the destination, via the Internet (or other intervening network).
In this example, the packets are encrypted at box 250. This is carded out by the tunnelling bridge TB1, according to whichever predetermined encryption scheme was selected, the primary requirement being that of ensuring that TB2 is provided with the same encryption scheme so that it can decrypt the data packets. TB2 must also be provided in advance with the appropriate key or keys for decryption.
At box 260, an encapsulation header is appended to the encrypted data packet. This header can take one of several alternative forms, according to the requirements of the user. Several modes of packet modification can be accommodated using the same basic data structure (but with differences in the information that is appended in the encapsulation header), such as the following:
Mode | Appended information |
1 | Encryption key management information (itself |
unencrypted) New IP header including originally | |
generated IP addresses of source and destination | |
hosts (unencrypted) | |
2 | Encryption key management information (in encrypted |
form) Tunnelling bridge identifier for sender | |
(unencrypted) New IP header including broadcast | |
addresses of source and destination networks | |
(unencrypted) | |
2A | (Same as mode 2, but without the tunnelling bridge |
identifier.) | |
3 | Encryption key management information (encrypted) |
Optional: tunnelling bridge identifier for sender | |
(unencrypted) New IP header including originally | |
generated IP addresses of source and destination | |
hosts (unencrypted) | |
3A | (Same as mode 3, but without the tunnelling |
bridge identifier.) | |
Data structures for modes 1, 2 and 3 are depicted in FIGS. 8 , 9 and 10, respectively, wherein like reference numerals indicate similar features, as described below. The data structure for mode 2A is illustrated in FIG. 11 , and mode 3A may use the data structure of FIG. 8.
The data structure 402 for mode 1 is represented in FIG. 8. The original data 410 and original header 420 are now encrypted, indicated as (410) and (420). Encryption key management information 440 is appended (in encrypted form) as pan of the new encapsulation header 430, along with a new IP header 450, including the addresses of the source and destination hosts. The information 430 includes indicates which encryption scheme was used.
Key management information can include a variety of data, depending upon the key management and encryption schemes used. For instance, it would be appropriate to use applicant's Simple Key-Management for Internet Protocols (SKIP), which is described in detail in the attached Appendix A.
In FIGS. 7-11 , the fields with reference numerals in parentheses are encrypted, and the other fields are unencrypted. Thus, in FIG. 8 , the original data field 410 and address field 420 are encrypted, while the new encapsulation header 430, including the key management information 440 and the IP header 450, is not encrypted.
In this embodiment, the tunnelling bridges TB1 and TB2 might not be used at all, but rather the hosts A and B could include all the instruction, tables, etc. necessary to encrypt, decrypt, and determine which packets are to be encrypted and using which encryption scheme. Mode 1 allows any intervening observer to identify the source and destination hosts, and thus does not provide the highest level of security. It does, however, provide efficient and automatic encryption and decryption for data packets between hosts A and B, without the need for additional computers to serve as TB1 and TB2.
Alternatively, in mode 1 field 440 could include the IP broadcast addresses of the source and destination networks (instead of that of the hosts themselves), and in addition may include a code in the encryption key management information indicating which encryption scheme was used. This information would then be used by an intercepting computer (such as a tunnelling bridge) on the destination network, which decrypts the data packet and sends it on to the destination host.
In mode 2, a data structure 404 is used, and includes a new encapsulation header 432. It includes key encryption management information 440, which is appended to the original data packet 400, and both are encrypted, resulting in encrypted fields (410), (420) and (440) shown in FIG. 9. A new IP header 470 including the broadcast addresses of the source and destination networks (not the addresses of the hosts, as in field 450 in FIG. 8 ) is appended. In addition, a tunnelling bridge identifier field 460 is appended as part of the encapsulation header 432. Here, fields 410, 420 and 440 in this embodiment are all encrypted, while fields 460 and 470 are not.
The tunnelling bridge identifier identifies the source tunnelling bridge, i.e. the tunnelling bridge at the network containing the host from which the packet was sent. The recipient tunnelling bridge contains a tunnelling bridge look-up table, indicating for each known tunnelling bridge any necessary information for decryption, most notably the decryption method and key.
An appropriate tunnelling bridge identifier might be a three-byte field, giving 224 or over 16 million unique tunnelling bridge identifiers. An arbitrarily large number of individual tunnelling bridges may each be given a unique identifier in this way, simply by making the field as large as necessary, and indeed the field may be of a user-selected arbitrarily variable size. If desired, a four-byte field can be used, which will accommodate over 4 billion tunnelling bridges, far exceeding present needs.
Using mode 2, any observer along the circuit taken by a given data packet can discern only the tunnelling bridge identifier and the IP broadcast addresses for the source and destination networks.
The IP broadcast address for the destination network will typically be something like “129.144.0.0”, which represents a particular network (in this case, “Eng.Sun.COM”) but not any specific host. Thus, at intermediate points on the route of the packet, it can be discerned that a message is traveling from, say, “washington.edu” to “Eng.Sun.COM”, and the identification number of the receiving tunnelling bridge can be determined, but that is the extent of it; the source and destination hosts, the key management information, and the contents of the data packet are all hidden.
Mode 2A uses the data structure shown in FIG. 11 , wherein the IP broadcast addresses for the source and recipient networks N1 and N2 are included in the encapsulation header field 470, but no tunnelling bridge identifier is used. This embodiment is particularly suitable for networks where there is only one tunnelling bridge for the entire network, or indeed for several networks, as illustrated in FIG. 5.
In FIG. 5 , a packet sent from host C to host D will first be sent from network N4 to network N5, and will then be intercepted by the tunnelling bridge TB4, which intercepts all messages entering or leaving these two networks. TB4 will encrypt the packet or not, as indicated by its hosts look-up table. The packet traverses the public network and is routed to network N7, first being intercepted by tunnelling bridge TB5 (which intercepts all messages entering or leaving networks N6-N8), and at that point being decrypted if necessary.
In this embodiment or any embodiment where a packet is sent from a tunnelling bridge on a network where a single tunnelling bridge is used for the entire source network or for multiple networks which include the source network, a tunnelling bridge identifier is not a necessary field in the encapsulation header. Since in this case only a given tunnelling bridge could have intercepted packets from a given host (e.g., TB4 for host C in FIG. 5), the identity of the source tunnelling bridge is unambiguous, and the destination tunnelling bridge TB5 will include a table of hosts and/or networks cross-correlated with TB4. Having determined that tunnelling bridge TB4 was the source tunnelling bridge, TB5 then proceeds with the correct decryption.
This approach has certain advantages, namely that it eliminates the need to “name” or number tunnelling bridges, and reduces the sizes of the data packets by eliminating a field. However, a tunnelling bridge identifier field provides flexibility. For instance, in FIG. 12 , subnetworks N11 and N12 are part of one larger network N10, and each subnetwork N11 and N12 has its own assigned tunnelling bridge (TB7 and TB8, respectively). Thus, subnetworks N11 and N12 can be subjected to different types of encryption, automatically, and that encryption can be altered at will for one subnetwork, without altering it for the other.
A packet traveling from host F to host E in FIG. 12 will include a source tunnelling bridge identifier (TB7) so that, when it reaches TB6 at network N9, it is identified correctly as having been encrypted by TB7 and not TB8. In this way, tunnelling bridge TB6 need maintain a table only the information pertaining to the tunnelling bridges, and does not need to maintain encryption/decryption specifies for the host or network level. (Note that TB6 still maintains information relating to whether to encrypt messages sent between host A and host B or network N1 and network N2, as the case may be, as discussed above.)
The tunnelling bridge identifier may be used for a variety of other purposes relating to the source tunnelling bridge, such as statistics recording the number of packets received from that tunnelling bridge, their dates and times of transmission, sizes of packets, etc.
An alternative to the use of hosts or networks tables in the memories of the source and destination tunnelling bridges (or source and destination hosts, as the case may be) would be any information identifying one or more predetermined criteria by which the source host or source tunnelling bridge determines whether to encrypt a given data packet. Such criteria need not merely be source and destination information, but could include packet contents, time of transmission, subject header information, user id., presence of a key word (such as “encrypt”) in the body of the packet, or other criteria.
Mode 3 uses a data structure 406 as shown in FIG. 10 , which is identical to the data structure 402 except for the addition of field 460 containing the tunnelling bridge identifier, which is the same as the tunnelling bridge identifier discussed above relative it mode 2.
In this embodiment, as in mode 1, field 450 includes the original host IP addresses for the source and destination hosts (not the addresses of the networks, as in mode 2), and thus an observer of a mode 3 packet will be able to determine both the original sender of the data packet and the intended receiver. Either mode contains sufficient information to route packets through an internet to recipient network's tunnelling bridge for decryption and ultimate delivery to the recipient host.
Mode 3A may use the data structure shown in FIG. 8 , in conjunction with a network configuration such as those shown in FIGS. 3 or 12. The mechanisms and relative advantages are identical to those described above for mode 2A, while the structure reveals the source and destination host addresses.
Whichever encapsulation header is added at box 260 (sec FIG. 6), the packet is, at box 270, then transmitted to the destination network. At box 280, the destination network's tunnelling bridge (here, TB2 shown in FIG. 3 ) intercepts the packet, which is accomplished by an instruction routine by which all packets are intercepted and inspected for encapsulation header information indicating encryption.
Thus, at box 290, the encapsulation header of the packet is read, and at box 300 it is determined whether the packet was encrypted. If a tunnelling bridge identifier forms a part of the encapsulated packet, then the method of encryption and decryption key are determined from the destination tunnelling bridge's (or destination host's, in the case of mode 1) local tables.
If no encryption was carried out on the packet, then it is sent on without further action to the correct host, as indicated at box 340. Otherwise, its encryption method is determined (box 320), and the packet is decrypted accordingly (box 330), and then sent on as in box 340.
There are occasions where it is advantageous to put authenticity and privacy features at the network layer. The vast majority of the privacy and authentication protocols in the literature deal with session oriented key-management schemes. However, many of the commonly used network layer protocols (e.g IP and IPng) are session-less datagram oriented protocols. We describe a key-management scheme that is particularly well suited for use in conjunction with a session-less datagram protocol like IP or IPng. We also describe how this protocol may be used in the context of Internet multicasting protocols. This key-management scheme is designed to be plugged into the IP Security Protocol (IPSP) or IPng.
Any kind of scalable and robust key-management scheme that needs to scale to the number of nodes possible in the Internet needs to be based on an underlying public-key certificate based infrastructure. This is the direction that, e.g, the key-management scheme for secure Internet e-mail, Privacy Enhanced Mail or PEM [1], is taking.
The certificates used by PEM are RSA public key certificates. Use of RSA public key certificates also enable the establishment of an authenticated session key [2,3]. (By an RSA public key certificate, what is meant here is that the key being certified is an RSA public key.)
One way to obtain authenticity and privacy at a datagram layer like IP is to use RSA public key certificates. (In the following description we use the term IP, although IP is replacable by IPng in this context).
There are two ways RSA certificates can be used to provide authenticity and privacy for a datagram protocol. The first way is to use out-of-band establishment of an authenticated session key, using one of several session key establishment protocols. This session key can then be used to encrypt IP data traffic. Such a scheme has the disadvantage of establishing and maintaining a pseudo session state underneath a session-less protocol. The IP source would need to first communicate with the IP destination in order to acquire this session key.
Also, as and when the session key needs to be changed, the IP source and the IP destination need to communicate again in order to make this happen. Each such communication involves the use of a computationally expensive public-key operation.
The second way an RSA certificate can be used is to do in-band signalling of the packet encryption key, where the packet encryption key is encrypted in the recipient's public key. This is the way, e.g, PEM and other public-key based secure e-mail systems do message encryption. Although this avoids the session state establishment requirement, and also does not require the two parties to communicate in order to set up and change packet encryption keys, this scheme has the disadvantage of having to carry the packet encryption key encrypted in the recipient's public key in every packet.
Since an RSA encrypted key would minimally need to be 64 bytes, and can be 128 bytes, this scheme incurs the overhead of 64-128 bytes of keying information in every packet. (As time progresses, the RSA block size would need to be closer to 128 bytes simply for security reasons.) Also, as and when the packet encryption key changes, a public key operation would need to be performed in order to recover the new packet encryption key. Thus both the protocol and computational overhead of such a scheme is high.
Use of certified Diffie-Hellman (DH) [4] public-keys can avoid the pseudo session state establishment and the communications requirement between the two ends in order to acquire and change packet encrypting keys. Furthermore, this scheme does not incur the overhead of carrying 64-128 bytes of keying information in every packet.
This kind of key-management scheme is better suited to protocols like IP, because it doesn't even require the remote side to be up in order to establish and change packet encryption keys. This scheme is described in more detail below.
We stipulate that each IP based source and destination has a certified Diffie-Hellman public key. This public-key is distributed in the form of a certificate. The certificate can be signed using either an RSA or DSA signature algorithm. How the certificates are managed is described in more detail later.
Thus each IP source or destination I has a secret value i, and a public value g**i mod p. Similarly, IP node J has a secret value j and a public value g**j mod p.
Each pair of IP source and destination I and J can acquire a shared secret g**ij mod p. They can acquire this shared secret without actually having to communicate, as long as the certificate of each IP node is known to all the other IP nodes. Since the public-key is obtained from a certificate, one natural way for all parties to discover the relevant public-keys is to distribute these certificates using a directory service.
This computable shared secret is used as the basis for a key-encrypting-key to provide for IP packet based authentication and encryption. Thus we call g**ij mod p the long-term secret, and derive from it a key Kij. Kij is used as the key for a shared-key cryptosystem (SKCS) like DES or RC2.
Kij is derived from g**ij mod p by taking the high order key-size bits of g**ij mod p. Since g**ij mod p is minimally going to be 512 bits and for greater security is going to be 1024 bits or higher, we can always derive enough bits for use as Kij which is a key for a SKCS. SKCS key sizes are typically in the range of 40-256 bits.
An important point here is that Kij is an implicit pair-wise shared key. It does not need to be sent in every packet or negotiated out-of-band. Simply by examining the source of an IP packet, the destination IP node can compute this shared key Kij. Because this key is implicit, and is used as a master key, its length can be made as long as desired, without any additional protocol overhead, in order to make cryptanalysis of Kij arbitrarily difficult.
We use Kij to encrypt a transient key, which we call Kp (for packet key). Kp is then used to encrypt/authenticate an IP packet or collection of packets. This is done in order to limit the actual amount of data in the long-term key. Since we would like to keep the long-term key for a relatively long period of time, say one or two years, we don't encrypt the actual IP data traffic in key Kij.
Instead we only encrypt transient keys in this long-term key, and use the transient keys to encrypt/authenticate IP data traffic. This limits the amount of data encrypted in the long-term key to a relatively small amount even over a long period of time like, say, one year.
Thus the first time an IP source I, which has a secret value i, needs to communicate with IP destination J, which has a secret value j, it computes the shared secret g**ij mod p. It can then derive from this shared secret the long-term key Kij. IP source I then generates a random key Kp and encrypts this key using Kij. It encrypts the relevant portion of the IP packet in key Kp (which may be the entire IP packet or just the payload of the IP packet depending on the next-protocol field in IPSP protected data potion).
The value of the SAID field is used by SKIP to indicate the mode of processing and to identify the implicit interchange key. Typical modes of processing are encrypted, encrypted-authenticated, authenticated, compression etc.
The modes of operation are identified by the upper 6 bits of the SAID field. The meanings of these upper 6 bits is specified in section 2.5 below on SAID derived processing modes. The low 22 bits of the SAID field are zero.
If the next protocol field is IP, (in other words IPSP is operating in encrypted-encapsulated mode), the packet looks as follows. It sends the encrypted IP packet, the encrypted key Kp, encapsulated in a clear outer IP Header.
In order to prepare this packet for emission on the outbound side of IP node I, no communication was necessary with IP node J.
When IP node J receives this packet, it also computes the shared secret Kij and caches it for later use. (In order to do this, if it didn't already possess I's certificate, it may have obtained this from the local directory service.) Using Kij it obtains Kp, and using Kp it obtains the original IP packet, which it then delivers to the appropriate place which is either a local transport entity or another outbound interface.
The Message Indicator (MI) is a field that is needed to preserve the statelessness of the protocol. If a single key is used in order to encrypt multiple packets, (which is highly desirable since changing the key on a per packet basis constitutes too much overhead) then the packets need to be decryptable regardless of lost or out-of-order packets. The message indicator field serves this purpose.
The actual content of the MI field is dependent on the choice of SKCS used for Kp and its operating mode. If Kp refers to a block cipher (e.g., DES) operating in Cipher-Block-Chaining (CBC) mode, then the MI for the first packet encrypted in key Kp is the Initialization Vector (IV). For subsequent packets, the MI is the last blocksize-bits of ciphertext of the last (in transmit order) packet. For DES or RC2 this would be last 64 bits of the last packet. For stream ciphers like RC4, the MI is simply the count of bytes that have already been encrypted in key Kp (and can be 64 bits long also).
If the source IP node (I in this case) decides to change the packet encryption key Kp, the receiving IP node J can discover this fact without having to perform a public-key operation. It uses the cached value Kij to decrypt the encrypted packet key Kp, and this is a shared-key crypto-system operation. Thus, without requiting communication between transmitting and receiving ends, and without necessitating the use of a public-key operation, the packet encrypting key can be changed by the transmitting side.
Since the public keys in the certificates are DH public keys, the nodes themselves have no public-key signature algorithm. This is not a major problem, since signing on a per-packet basis using a public-key cryptosystem is too cumbersome in any case. The integrity of the packets is determined in a pairwise fasion using a symmetric cryptosystem.
In order to achieve authentication in the absence of privacy, SKIP compliant implementation use the encrypted packet key Kp to encrypt a message-digest of the packet, instead of the packet itself. This encrypted digest is appended at the end of the data portion of the IPSP. As before, Kij alg and Kp alg identify the two encryption algorithms for keys Kij and Kp. MD alg is a 1 byte identifier for the message digest algorithm.
Unauthenticated Diffie-Hellman is susceptible to an intruder in the middle attack. To overcome this, authenticated Diffie-Hellman schemes have been proposed, that include a signature operation with the parties private signature keys.
SKIP is not susceptible to intruder in the middle types of attacks. This is because the Diffie-Hellman public parameters are long-term and certified. Intruder in the middle attacks on Diffie-Hellman assume that the parties cannot determine who the public Diffie-Hellman keys belong to. Certified Diffie-Hellman public keys eliminate this possibility, without requiting any exchange of messages between the two parties or incurring the computational overhead of large exponent exponentiations (e.g., RSA signatures).
Since the Kij values need to be cached for efficiency, reasonable safeguards need to be taken to protect these keys.
One possible way to do this is to provide a hardware device to computer, store and perform operations using these keys. This device can ensure that there are no interfaces to extract the key from the device.
As an interim measure, in the absence of certification hierarchies, nodes may wish to employ manually exchanged keying information. To handle such cases, the pair key Kij can be the key that is manually set up.
Since manual re-keying is a slow and awkward process, it still makes sense to use the two level keying structure, and encrypt the packets has the same benefit as before, namely it avoids over-exposing the pair key which is advantageous to maintain over relatively long periods of time. This is particularly true for high-speed network links, where it is easy to encrypt large amounts of data over a short period of time.
The upper 6 bits of the SAID field are used to indicate the processing mode. The processing modes defined so far are, encryption, authentication, compression, and packet sequencing (for playback protection). Since none of these modes is mutually exclusive, multiple bits being on indicate the employment of all the relevant processing modes.
- Bit 22=1 if packet is encrypted, Bit 22=0 otherwise
- Bit 23=1 if packet is authenticated, Bit 23=0 otherwise
- Bit 24=1 if packet is compressed before encryption, Bit 24=0 otherwise,
- Bit 25=1 if packets are sequenced, Bit 25=0 otherwise
- Bits 26 and 27 are reserved for future use, and shall be 0 until specified.
For example, to indicate that a packet is encrypted and authenticated, Bits 22 and 23 shall be one.
It is possible to use this kind of scheme in conjunction with datagram multicasting protocols like IP (or IPng) multicast [5]. This requires key-management awareness in the establishment and joining process of multicast groups.
In order to distribute multicast keying material, the notion of a group owner needs to exist. When secure multicasting to multicast address M is required, a group membership creation primitive will need to establish the group secret value Km and the membership list of addresses that are allowed to transmit and receive encrypted multicast data-grams to and from group address M.
The group key Km is not used as a packet encryption key, but rather as the group Interchange Key (IK).
Nodes wishing to transmit/receive encrypted datagrams to multicast address M need to acquire the group IK Km. This is done by sending an encrypted/authenticated request to join primitive to the group owner. If the requesting node's address is part of the group's membership, then the group owner will send the IK Km, and associated lifetime information in an encrypted packet, using the pairwise secure protocol described in Section 2 above.
Transmitting nodes to group address M will randomly generate packet encryption keys Kp, and encrypt these keys using Km. The packet structure is similar to the structure used for encrypted unicast IPSP packets, except for the fact that the packet keys Kp are not encrypted in the pair-wise keys Kij, but instead are encrypted using the group IK Km. An example encrypted multicast packet is shown below.
There are two distinct advantages of this scheme. First, every member of the multicast group can change packet encryption keys as often as it desires, without involving key-setup communications overhead involving every member of the group.
Second, since all the packet encryption keys are different, there is no, problem in using stream-ciphers with multicast. This is because each source of encrypted traffic uses a different key-stream and thus there is no key-stream reuse problem. If all members of the multicast group used the same packet encryption key (as e.g stipulated in the current draft of 802.10 key-management), then key-seeded stream ciphers could not be used with multicast.
How the identity of the group owner is established and communicated to the participating nodes is left to the application layer. However, this also needs to be done in a secure fashion, otherwise the underlying key-management facility can be defeated.
Since the nodes' public DH values are communicated in the form of certificates, the same sort of multi-tier certification structure that is being deployed for PEM [6] and also by the European PASSWORD project can be used. Namely, there can be a Top Level Certifying Authority (TLCA) which may well be the same the Internet Policy Registration Authority (IPRA), Policy Certifying Authorities (PCAs) at the second tier and organizational CAs below that.
In addition to the identity certificates, which are what are part of PEM certificate infrastructure, we also need additional authorization certificates, in order to properly track the ownership of IP addresses. Since we would like to directly use IP addresses in the DH certificates, we cannot use name subordination principles alone (as e.g used by PEM) in order to determine if a particular CA has the authority to bind a particular IP address to a DH public value.
We can still use the X.509/PEM certificate format, since the subject Distinguished Name (DN) in the certificate can be the numeric string representation of a list of IP addresses.
Since the nodes only have DH public keys, which have no signature capability, the nodes are themselves unable to issue certificates. This means that there is an algorithmic termination of a certificate path in a leaf node, unlike the certificate hierarchy employed in, e.g PEM, where every leaf node is potentially a rogue CA.
The node certificates are issued by organizational CAs which have jurisdiction over the range of IP addresses that are being certified. The PCAs will have to perform suitable checks (in line with the advertised policy of that PCA) to confirm that the organization which has jurisdiction over a range of addresses is issued a certificate giving it the authority to certify the DH values of individual nodes with those addresses. This authority will be delegated in the form of a authorization certificate signed by the PCA. For the purposes of authorization, the CA's Distinguished Name (DN) will be bound to the range of IP addresses over which it has jurisdiction. The CA has either an RSA or DSA certificate issued by the PCA.
An authorization certificate will also contain information about whether the CA to whom authority is being delegated can sub-delegate that authority. The CA which has delegatable authority over a range of IP addresses can delegate authority over part of the range to a subordinate CA, by signing another authorization certificate using its own private key. If the authority is non-delegatable, then the CA cannot delegate authority for that range of addresses.
The range of IP addresses are identified in the authorization certificate in the form of a list of IP address prefix, length pairs.
The encoding of a DH Public value in an X.509 certificate will be in the form of an INTEGER. The algorithm indentifier will be as defined in PKCS #3 [7]. Thus
DHPublicKey:=INTEGER
and from PKCS #3,
DHPublicKey:=INTEGER
and from PKCS #3,
AlgorithmIdentifier ::= |
SEQUENCE { |
algorithm OBJECT IDENTIFIER |
SEQUENCE { |
prime INTEGER, — p | |
base INTEGER, — g | |
privateValueLength INTEGER OPTIONAL |
} |
} | ||
with the OBJECT IDENTIFIER value being
dhKeyAgreement OBJECT IDENTIFIER ::= |
{iso(1) member-body(2) US(840) |
rsadsi(113549) pkcs(1) 3 1} | ||
which is also taken from PKCS #3.
DHPublicKey is what gets encapsulated as the BIT STRING in SubjectPublicKeyInfo of an X.509 certificate in the obvious manner.
The certificate is allowed to bind multiple IP addresses to a single public value to accommodate cases where a single IP node has multiple IP addresses. The SEQUENCE OF construct in a DN readily allows for this. What is needed is an OBJECT IDENTIFIER for an AttributeType specifying an IP address. This is defined here as,
ipAddress ATTRIBUTE WITH ATTRIBUTE-SYNTAX |
PrintableString (SIZE(1..nh-ipAddress)) |
::= {ipsec-odd 1} — Need to register this XXX |
The DN in the certificate can contain multiple | ||
of these by iterating on the SEQUENCE OF construct of the Relative Distinguished Name Sequence.
The Printable string contains either the hexadecimal representation or standard dot notation representation of an IP address.
An authorization certificate is associated with each CA below the PCA level. The authorization certificate in effect entitles a CA to bind IP addresses to DH public keys.
We have described a scheme, Simple Key-Management for Internet Protocols (SKIP) that is particularly well suited to connectionless datagram protocols like IP and its replacement candidate SIPP. Both the protocol and computational overheads of this scheme are relatively low. In-band signalled keys incur the length overhead of the block size of a shared-key cipher. Also, setting and changing packet encrypting keys involves only a shared-key cipher operation. Yet the scheme has the scalability and robustness of a public-key certificate based infrastructure.
A major advantage of this scheme is that establishing and changing packet encrypting keys requires no communication between sending and receiving nodes and no establishment of a pseudo-session state between the two sides is required.
In many ways the key-management scheme here has structural similarities with the scheme used by PEM [1]. Both use the concept of an inter-change key (in our case that is the pair keys Kij) and data encrypting keys (the packet encryption keys Kp). By using the Implicit shared secret property of long-term DH public values, and treating the resulting keys as keys for a SKCS, we have reduced the protocol overhead substantially as compared to the overhead of PEM when used in conjunction with an asymmetric key-management system.
We have also described how this scheme may be used in conjunction with datagram multicast protocols, allowing a single encrypted datagram to be multicast to all the receiving nodes.
- [1] IETF PEM RFCs 1421-1424
- [2] A. Aziz, W. Diffie, “Privacy and Authentication for Wireless LANs”, IEEE Personal Communications, Feb 1994.
- [3] W. Diffie, M. Wiener, P. Oorschot, “Authentication and Authenticated Key Exchanges”, in Designs Codes and Cryptography, Kluwer Academic Publishers, 1991.
- [4] W. Diffie, M. Hellman, “New Directions in Cryptography”, IEEE Transactions on Information Theory
- [5] S. Deering, “IP Multicast”, Ref needed
- [6] S. Kent, “Certificate Based Key Management,” RFC 1422 for PEM
- [7] “Public Key Cryptography Standards” 1-10 from RSA Data Security Inc., Redwood City, Calif.
Each of the above references is incorporated into this Appendix A by reference.
Claims (48)
1. A method for transmitting and receiving packets of data via a an internetwork from a first host computer on a first computer network to a second host computer on a second computer network, the first and second computer networks including, respectively, first and second bridge computers, each of said first and second host computers and first and second bridge computers including a processor and a memory for storing instructions for execution by the processor, each of said first and second bridge computers further including memory for storing at least one predetermined encryption/decryption mechanism and information identifying a predetermined plurality of host computers as hosts requiring security for packets transmitted between them, the method being carded carried out be by means of the instructions stored in said respective memories and including the steps of:
(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a portion of the first data packet including information representing an internetwork address of the first host computer and an internetwork address of the second host computer;
(2) in the first bridge computer, intercepting the first data packet and determining whether the first and second host computers are among the predetermined plurality of host computers for which security is required, and if not, proceeding to step 5, and if so, proceeding to step 3;
(3) encrypting the first data packet in the first bridge computer;
(4) in the first bridge computer, generating and appending to the encrypted first data packet an encapsulation header, including:
(a) key management information identifying providing a mechanism for identifying the predetermined encryption method, and
(b) a new address header representing the source and destination for the first data packet, hereby generating a modified first data packet;
(5) transmitting the first data packet or the modified first data packet from the first bridge computer via the internetwork to the second computer network;
(6) intercepting the first data packet or the modified first data packet at the second bridge computer;
(7) in the second bridge computer, if the encapsulation header has been appended to the first data packet, reading the encapsulation header, and determining therefrom whether the first data packet was encrypted, and if not, proceeding to step 10, and if so, proceeding to step 8 and if it is determined that the first data packet has been encrypted, proceeding to step 8 and otherwise proceeding to step 10;
(8) in the second bridge computer, determining which encryption mechanism was used to encrypt the first data packet;
(9) decrypting the first data packet by the second bridge computer;
(10) transmitting the first data packet from the second bridge computer to the second host computer, ; and
(11) receiving the unencrypted first data packet at the second host computer.
2. The method of claim 1 , wherein the new address header for the modified first data packet includes the internetwork broadcast addresses of the first and second computer networks.
3. The method of claim 2 , wherein the new address header for the modified first data packet includes an identifier of the second bridge computer.
4. The method of claim 1 , wherein the new address header of the modified first data packet includes the address of the second host computer.
5. The method of claim 4 , wherein the new address header for the modified first data packet includes an identifier of the second bridge computer.
6. A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first computer network to a second host computer on a second computer network, including:
a first bridge computer coupled to the first computer network for intercepting data packets transmitted from said first computer network, the first bridge computer including a first processor and a first memory storing instructions for executing encryption of data packets according to a predetermined encryption/decryption mechanism;
a second bridge computer coupled to the second computer network for intercepting data packets transmitted to said second computer network, the second bridge computer including a second processor and a second memory storing instructions for executing decryption of the data packets;
said first host computer including a third processor and a third memory including instructions for transmitting a first said data packet from said first to said second host;
a first table stored in said first memory including a correlation of at least one of the first host computer and the first network with one of the second host computer and the second network, respectively;
instructions stored in said first memory for intercepting said first data packet before departure from said first network, determining whether said correlation is present in said first table, and if so, then executing encryption of said first data packet according to said predetermined encryption/decryption mechanism, generating a new address header including a mechanism for identifying said predetermined encryption/decryption mechanism and appending said new address header to said encrypted first data packet, thereby generating a modified first data packet, and transmitting said modified data packet on to the second host computer;
a second table stored in said second memory including a correlation of at least one of the first host computer and the first network with one of the second host computer and the second network, respectively; and
instruction stored in said second memory for intercepting said modified first data packet upon arrival at said second network, determining whether said correlation is present in said second table, and if so, then executing decryption of said first data packet according to said predetermined encryption/decryption mechanism, and transmitting the first data packet to the second host computer.
7. The method of claim 6 , A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first computer network to a second host computer on a second computer network, including:
a first bridge computer coupled to the first computer network for intercepting data packets transmitted from said first computer network, the first bridge computer including a first processor and a first memory storing instructions for executing encryption of data packets according to a predetermined encryption/decryption mechanism;
a second bridge computer coupled to the second computer network for intercepting data packets transmitted to said second computer network, the second bridge computer including a second processor and a second memory storing instructions for executing decryption of the data packets;
said first host computer including a third processor and a third memory including instructions for transmitting a first data packet from said first host to said second host;
a first table stored in said first memory including a correlation of at least one of the first host computer and the first network with one of the second host computer and the second network, respectively;
instructions stored in said first memory for intercepting said first data packet before departure from said first network, determining whether said correlation is present in said first table, and if so, then executing encryption of said first data packet according to said predetermined encryption/decryption mechanism, generating a new address header and appending said new address header to said encrypted first data packet, thereby generating a modified first data packet, and transmitting said modified first data packet on to the second host computer, wherein said new address header includes the internetwork broadcast addresses of the first and second computer networks.;
a second table stored in said second memory including a correlation of at least one of the first host computer and the first network with one of the second host computer and the second network, respectively; and
instructions stored in said second memory for intercepting said modified first data packet upon arrival at said second network, determining whether said correlation is present in said second table, and if so, then executing decryption of said first data packet according to said predetermined encryption/decryption mechanism, and transmitting the first data packet to the second host computer.
8. The method of claim 7 , wherein said new address header includes an identifier of the second bridge computer.
9. The method of claim 6 , wherein said new address header includes the address of the second host computer.
10. The method of claim 9 , wherein said new address header includes an identifier of the second bridge computer.
11. A method for transmitting and receiving packets of data via an internetwork from a first host computer on a first computer network to a second host computer on a second computer network, the first and second computer networks, each of said first and second host computer networks, each of said first and second host computers including a processor and a memory for storing instructions for execution by the processor, each said memory storing at least on a predetermined encryption/decryption mechanism and a source/destination table identifying a predetermined plurality of sources and destinations requiring security for packets transmitted between them, the method being carded carried out by means of the instructions stored in said respective memories and including the steps of:
(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a portion of the first data packet including information representing an internetwork address of a source of the first data packet and an internetwork address of a destination of the first data packet;
(2) in the first host computer, determining whether the source and destination of the first data packet are among the predetermined plurality of sources and destinations identified in said source/destination table for which security is required, and if not, proceeding to step 5, and if so, proceeding to step 3;
(3) encrypting the first data packet in the first host computer;
(4) in the first host computer, generating and appending to the encrypted first data packet an encapsulation header, including:
(a) key management information providing a mechanism for identifying the predetermined encryption method, and
(b) a new address header identifying the source and destination for the first data packet, hereby generating a modified first data packet;
(5) transmitting the first data packet or the modified first data packet from the first host computer via the internetwork to the second computer network;
(6) in the second host computer, if the encapsulation header has been appended to the first data packet, reading the encapsulation header, and determining therefrom whether the first data packet was encrypted, and if not the first data packet was not encrypted, ending the method, and if so the first data packet was encrypted, proceeding to step 7;
(7) in the second host computer, determining which encryption mechanism was used to encrypt the first data packet; and
(8) decrypting the first data packet by the second host computer.
12. The method of claim 11 , wherein the new address header for the modified first data packet includes internetwork broadcast addresses of the first and second computer networks.
13. The method of claim 11 , wherein the source/destination table includes data identifying internetwork addresses of the first and second host computers.
14. A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first computer network and having a first host computer on a first computer network and , the first host computer having a first processor and a first memory, via an internetwork to a second host computer on a second computer network and having a second host computer on a second computer network and , the second host computer having a second processor and a second memory, the system including:
security data stored in said first and second memories indicating that data packets meeting at least one predetermined criterion are to be encrypted;
a predetermined encryption/decryption mechanism stored in said first and second memories;
a decryption key stored in said second memory;
instructions stored in said first memory for determining whether to encrypt one or more data packets, by determining whether said at least one predetermined criterion is met by said data packet one or more data packets;
instructions stored in said first memory for executing encryption according to said predetermined encryption/decryption mechanism of at least a first said data packet one of said one or more data packets,when said at least one predetermined criterion is met, for generating a new address header for said first data packet and for appending an encapsulation header to said first data packet and transmitting said first data packet to said second host, said new address header identifying broadcast addresses of the first and second computer networks, said encapsulation header including at least said new address header; and
instructions stored in said second memory for receiving said first data packet, determining whether it has been encrypted by reference to said security data in said second memory, and if so then determining which encryption/decryption mechanism was used for encryption, and decrypting said first data packet by use of said decryption key.
15. The system of claim 14 , wherein:
said security data comprises correlation data stored in each of said first and second memories identifying at least one of said first and second memories identifying at least one of said first host computer and said first network correlated with at least one of said second host computer and said second network;
the system further including instructions stored in said first memory for determining whether to encrypt data packets by inspecting for a match between source and destination addresses of said data packets with said correlation data.
16. A system for automatically encrypting data packets for transmission from a first host computer on a first computer network to a second host computer on a second computer network, said first host computer including a first processor and a first memory including instructions for transmitting said data packets from said first host to said second host, the system including:
a bridge computer coupled to the first computer network for intercepting at least a first said data packet transmitted from said first computer network, said bridge computer including a second processor and a second memory storing instructions for executing encryption of said first data packet according to a predetermined encryption/decryption mechanism;
information stored in said second memory correlating at least one of the first host computer and the first network with one of the second host computer and the second network, respectively; and
instructions stored in said second memory for intercepting said first data packet before departure from said first network, determining whether said correlation is present, and if so, then executing encryption of said first data packet according to said predetermined encryption/decryption mechanism, generating a new address header including a mechanism for identifying said predetermined encryption/decryption mechanism and appending said new address header to said first data packet, thereby generating a modified first data packet on to the second host computer.
17. A method for transmitting packets of data via an internetwork from a first host computer on a first computer network to a second host computer on a second computer network, the first computer networks including a first bridge computer, each of said first and second host computers and said bridge computer further including memory storing at least one predetermined encryption/decryption mechanism and information identifying a predetermined plurality of host computers as hosts requiring security for packets transmitted between them, the method being carried out according to the instructions stored in said respective memories and including the steps of:
(1) generating, by the first host computer, a first data packet for transmission to the second host computer, a portion of the first data packet including information representing an internetwork address of the first host computer and an internetwork address of the second host computer;
(2) in the first bridge computer, intercepting the first data packet and determining whether the first and second host computers are among the predetermined plurality of host computers for which security is required, and if not, proceeding to step 5, and if so, proceeding to step 3;
(3) encrypting the first data packet in the first bridge computer;
(4) in the first bridge computer, generating and appending to the first data packet an encapsulation header, including:
(a) key management information providing a mechanism for identifying the predetermined encryption method, and
(b) a new address header representing the source and destination for the data packet, thereby generating a modified first data packet; and
(5) transmitting the first data packet or the modified first data packet from the first bridge computer via the internetwork to the second computer network.
18. A system for automatically decrypting data packets transmitted from a first computer to a second computer, the system comprising:
a bridge coupled to the second computer for intercepting a data packet from the first computer, the data packet having an address header and a body, the address header including broadcast addresses of the first and second computers, the bridge including a processor and a memory that stores instructions for decrypting data packets;
information stored in the memory of the bridge correlating the first and second computers; and
instructions stored in the memory for intercepting the data packet, determining whether the information stored in the memory of the bridge correlates the first and second computers, and if so, decrypting at least a portion of the data packet to generate a new data packet including a new address header, and transmitting the new data packet onto the second computer.
19. The system of claim 18 , wherein the data packet includes the new data packet in encrypted form.
20. The method of claim 18 , wherein the new address header includes information indicating the first computer is a source of the new data packet and the second computer is a destination of the new data packet.
21. A system for automatically decrypting data packets transmitted from a first computer to a second computer, the system comprising:
a bridge coupled to the second computer for intercepting a data packet from the first computer, the data packet including a header storing key management information providing a mechanism for identifying an encryption method used to encrypt the data packet, the bridge including a processor and a memory that stores instructions for decrypting data packets;
information stored in the memory of the bridge correlating the first and second computers; and
instructions stored in the memory for intercepting the data packet, determining whether the information stored in the memory of the bridge correlates the first and second computers, and if so, decrypting the data packet to generate a new data packet including a new address header, and transmitting the new data packet onto the second computer.
22. A method for receiving data packets from a first computer to a second computer through a bridge including a processor and a memory that stores instructions for decrypting data packets and information correlating the first and second computers, the method being carried out according to instructions in the memory of the bridge and comprising:
intercepting a data packet from the first computer to the second computer, the data packet including an address header and a body, the address header including broadcast addresses of the first and second computers and the body including address information representing an internetwork address of the first computer and an internetwork address of the second computer, wherein the address information is encrypted;
determining whether the information stored in the memory of the bridge correlates the first and second computers, and if so, decrypting the data packet to generate a new data packet including a new address header; and
transmitting the new data packet on to the second computer.
23. The method of claim 22 , wherein the body includes the new data packet in encrypted form.
24. The method of claim 22 , wherein the new address header includes information indicating the first computer is a source of the new data packet and the second computer is a destination of the new data packet.
25. A method for receiving data packets from a first computer to a second computer through a bridge including a processor and a memory that stores instructions for decrypting data packets and information correlating the first and second computers, the method being carried out according to instructions in the memory of the bridge and comprising:
intercepting a data packet from the first computer to the second computer, the data packet including information representing an internetwork address of the first computer and an internetwork address of the second computer;
determining whether the information stored in the memory of the bridge correlates the first and second computers, and if so, decrypting the data packet to generate a new data packet including a new address header; and
transmitting the new data packet on to the second computer;
wherein the data packet includes a header storing key management information providing a mechanism for identifying an encryption method used to encrypt the new data packet.
26. A method of encrypting data packets, comprising:
receiving a data packet from a source for a destination, the data packet including a header section and a data section, the header section storing a source identifier and a destination identifier;
determining whether the data packet should be encrypted upon reference to at least one of the source and destination identifiers;
if the data packet should be encrypted, encrypting the data packet to produce an encrypted data packet; and
generating a new address header and appending the new address header to the encrypted data packet, thereby generating a modified data packet;
wherein the new address header includes a mechanism for identifying an encryption method used to generate the encrypted data packet.
27. The method of claim 26 , further comprising transmitting the modified data packet to the destination.
28. The method of claim 26 , wherein the determining whether the data packet should be encrypted comprises accessing stored information that indicates by presence or absence of the source identifier that data packets from the source should be encrypted.
29. The method of claim 26 , wherein the determining whether the data packet should be encrypted comprises accessing stored information that indicates by presence or absence of a correlation between the source and destination identifiers that data packets from the source for the destination should be encrypted.
30. The method of claim 26 , wherein the encrypted data packet includes an encrypted data packet header section and an encrypted data packet data section, the encrypted data packet header section including the header section of the data packet after encryption and the encrypted data packet data section including the data section of the data packet after encryption, the modified data packet including a header portion storing the new address header and a data portion storing the encrypted data packet.
31. The method of claim 30 , wherein the encrypted data packet header section stores the source and destination identifiers.
32. The method of claim 26 , wherein the source is a host computer or a network.
33. The method of claim 26 , wherein the destination is a host computer or a network.
34. A computer program product adapted for encrypting data packets, comprising:
computer code that when executed causes the reception of a data packet from a source for a destination, the data packet including a header section and a data section, and the header section storing a source identifier and a destination identifier;
computer code that when executed causes the determination of whether the data packet should be encrypted upon reference to at least one of the source and destination identifiers;
computer code that when executed, if the data packet should be encrypted, causes the encryption of the data packet to produce an encrypted data packet;
computer code that when executed causes the generation of a new address header and appends the new address header to the encrypted data packet, the new address header including a mechanism for identifying an encryption method used to generate the encrypted data packet, thereby generating a modified data packet; and
a computer readable medium that stores the computer codes.
35. The computer program product of claim 34 , wherein the computer readable medium is a memory, random-access-memory, read-only-memory, disk drive, or CD-ROM.
36. A computer system for encrypting data packets, comprising:
a processor;
a computer readable medium coupled to the processor and storing a computer program comprising:
computer code that when executed by the processor causes the processor to receive a data packet from a source for a destination, the data packet including a header section and a data section, and the header section storing a source identifier and a destination identifier;
computer code that when executed by the processor causes the processor to determine whether the data packet should be encrypted upon reference to at least one of the source and destination identifiers;
computer code that when executed by the processor causes the processor to encrypt the data packet to produce an encrypted data packet when it is determined that the data packet should be encrypted; and
computer code that when executed by the processor causes the processor to generate a new address header and append the new address header to the encrypted data packet, thereby generating a modified data packet;
wherein the new address header includes a mechanism for identifying an encryption method used to generate the encrypted data packet.
37. The computer program product of claim 36 , wherein the computer readable medium is a memory, random-access-memory, read-only-memory, disk drive, or CD-ROM.
38. A system for automatically encrypting and decrypting data packets transmitted from a first host computer on a first computer network, the first host computer having a first processor and a first memory, via an internetwork to a second host computer on a second computer network, the second host computer having a second processor and a second memory, the system including:
security data stored in said first and second memories indicating that data packets meeting at least one predetermined criterion are to be encrypted;
instructions stored in said first memory for determining whether to encrypt one or more data packets, by determining whether said at least one predetermined criterion is met by said one or more data packets;
instructions stored in said first memory for executing encryption of at least a first one of said one or more data packets according to a predetermined encryption/decryption mechanism, when said at least one predetermined criterion is met, for generating a new address header for said first data packet and for appending an encapsulation header to said first data packet and transmitting said first data packet to said second host, said encapsulation header including said new address header and a mechanism for identifying said predetermined encryption/decryption mechanism;
instructions stored in said second memory for receiving said first data packet, determining whether it has been encrypted by reference to said security data in said second memory, and if so then determining which encryption/decryption mechanism was used for encryption, and decrypting said first data packet by use of said encryption/decryption mechanism.
39. The system as recited in claim 38 , wherein said predetermined encryption/decryption mechanism is provided in encrypted form within said encapsulation header.
40. The system of claim 15 , wherein said correlation data includes:
encryption rules identifying source and destination networks to and from which packets are to be encrypted; and
host information indicating exceptions to the encryption rules.
41. A system for automatically encrypting data packets for transmission from a first host computer on a first computer network to a second host computer on a second computer network, said first host computer including a first processor and a first memory including instructions for transmitting said data packets from said first host to said second host, the system including:
a bridge computer coupled to the first computer network for intercepting at least a first data packet transmitted from said first computer network, said bridge computer including a second processor and a second memory storing instructions for executing encryption of said first data packet according to a predetermined encryption/decryption mechanism;
information stored in said second memory correlating at least one of the first host computer and the first network with one of the second host computer and the second network, respectively; and
instructions stored in said second memory for intercepting said first data packet before departure from said first network, determining whether said correlation is present, and if so, then executing encryption of said first data packet according to said predetermined encryption/decryption mechanism, generating a new address header including the internetwork broadcast addresses of the first and second computer networks and appending said new address header to said first data packet, thereby generating a modified first data packet on to the second host computer.
42. A computer program product adapted for encrypting data packets, comprising:
computer code that when executed on a computer causes the computer to receive a data packet from a source for a destination, the data packet including a header section and a data section, and the header section storing a source identifier and a destination identifier;
computer code that when executed on a computer causes the computer to determine whether the data packet should be encrypted upon reference to at least one of the source and destination identifiers;
computer code that when executed on a computer causes the computer to, if the data packet should be encrypted, encrypt the data packet to produce an encrypted data packet;
computer code that when executed on a computer causes the computer to generate a new address header storing at least one of a broadcast address associated with the source and a broadcast address associated with the destination, and append the new address header to the encrypted data packet, thereby generating a modified data packet; and
a computer readable medium that stores the computer codes.
43. A computer system for encrypting data packets, comprising:
a processor;
a computer readable medium coupled to the processor storing a computer program comprising:
computer code that when executed by the processor causes the processor to receive a data packet from a source for a destination, the data packet including a header section and a data section, the header section storing a source identifier and a destination identifier;
computer code that when executed by the processor causes the processor to determine whether the data packet should be encrypted upon reference to at least one of the source and destination identifiers;
computer code that when executed by the processor causes the processor to if the data packet should be encrypted, encrypt the data packet to produce an encrypted data packet; and
computer code that when executed by the processor causes the processor to generate a new address header storing at least one of a broadcast address associated the source and a broadcast address associated with the destination, and append the new address header to the encrypted data packet, thereby generating a modified data packet.
44. The system as recited in claim 16 , wherein the mechanism indirectly references said predetermined encryption/decryption mechanism.
45. The system as recited in claim 20 , wherein the mechanism indirectly identifies the encryption method.
46. The method as recited in claim 26 , wherein the mechanism indirectly identifies the encryption method.
47. The computer program product as recited in claim 34 , wherein the mechanism indirectly identifies the encryption method.
48. The computer system as recited in claim 36 , wherein the mechanism indirectly identifies the encryption method.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/136,954 USRE39360E1 (en) | 1994-09-15 | 1998-08-19 | System for signatureless transmission and reception of data packets between computer networks |
US10/147,933 US20030037235A1 (en) | 1998-08-19 | 2002-05-15 | System for signatureless transmission and reception of data packets between computer networks |
Applications Claiming Priority (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US08/306,337 US5548646A (en) | 1994-09-15 | 1994-09-15 | System for signatureless transmission and reception of data packets between computer networks |
US09/136,954 USRE39360E1 (en) | 1994-09-15 | 1998-08-19 | System for signatureless transmission and reception of data packets between computer networks |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/306,337 Reissue US5548646A (en) | 1994-09-15 | 1994-09-15 | System for signatureless transmission and reception of data packets between computer networks |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/147,933 Continuation US20030037235A1 (en) | 1998-08-19 | 2002-05-15 | System for signatureless transmission and reception of data packets between computer networks |
Publications (1)
Publication Number | Publication Date |
---|---|
USRE39360E1 true USRE39360E1 (en) | 2006-10-17 |
Family
ID=23184846
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/306,337 Ceased US5548646A (en) | 1994-09-15 | 1994-09-15 | System for signatureless transmission and reception of data packets between computer networks |
US09/136,954 Expired - Lifetime USRE39360E1 (en) | 1994-09-15 | 1998-08-19 | System for signatureless transmission and reception of data packets between computer networks |
Family Applications Before (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US08/306,337 Ceased US5548646A (en) | 1994-09-15 | 1994-09-15 | System for signatureless transmission and reception of data packets between computer networks |
Country Status (5)
Country | Link |
---|---|
US (2) | US5548646A (en) |
EP (1) | EP0702477B1 (en) |
JP (1) | JPH0927804A (en) |
KR (1) | KR100388606B1 (en) |
DE (1) | DE69533953T2 (en) |
Cited By (95)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030200341A1 (en) * | 1999-12-30 | 2003-10-23 | Nortel Networks Corporation, A Canadian Corporation | Port switch |
US20040168056A1 (en) * | 2003-02-26 | 2004-08-26 | Microsoft Corporation | Revocation of a certificate and exclusion of other principals in a digital rights management (DRM) system based on a revocation list from a delegated revocation authority |
US20040172559A1 (en) * | 2002-11-26 | 2004-09-02 | Huawei Technologies Co., Ltd. | 802.1X protocol-based multicasting control method |
US20050228864A1 (en) * | 2002-04-26 | 2005-10-13 | Research In Motion Limited | System and method for selection of messaging settings |
US20060288219A1 (en) * | 2005-06-21 | 2006-12-21 | Research In Motion Limited | Automated selection and inclusion of a message signature |
US20100054462A1 (en) * | 2000-04-04 | 2010-03-04 | Sony Corporation | Information recording/reproducing apparatus and method |
US20100138560A1 (en) * | 1999-06-15 | 2010-06-03 | Ssh Communications Security Ltd. | Method and arrangement for providing security through network address translations using tunneling and compensations |
US7739497B1 (en) * | 2001-03-21 | 2010-06-15 | Verizon Corporate Services Group Inc. | Method and apparatus for anonymous IP datagram exchange using dynamic network address translation |
US20110035578A1 (en) * | 2008-01-17 | 2011-02-10 | Eads Defence And Security Systems Limited | Secure communication system |
US8843643B2 (en) | 1998-10-30 | 2014-09-23 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8874771B2 (en) | 1998-10-30 | 2014-10-28 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US8943201B2 (en) | 1998-10-30 | 2015-01-27 | Virnetx, Inc. | Method for establishing encrypted channel |
US20160043940A1 (en) * | 2014-08-11 | 2016-02-11 | Palo Alto Research Center Incorporated | Reputation-based instruction processing over an information centric network |
US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
US9686194B2 (en) | 2009-10-21 | 2017-06-20 | Cisco Technology, Inc. | Adaptive multi-interface use for content networking |
US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
US9860283B2 (en) | 1998-10-30 | 2018-01-02 | Virnetx, Inc. | Agile network protocol for secure video communications with assured system availability |
US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
US10098051B2 (en) | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
US10104041B2 (en) | 2008-05-16 | 2018-10-16 | Cisco Technology, Inc. | Controlling the spread of interests and content in a content centric network |
US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
US10264099B2 (en) | 2016-03-07 | 2019-04-16 | Cisco Technology, Inc. | Method and system for content closures in a content centric network |
US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
US10320760B2 (en) * | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
US10511573B2 (en) | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
US11310256B2 (en) | 2020-09-23 | 2022-04-19 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
US11388072B2 (en) * | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11431744B2 (en) | 2018-02-09 | 2022-08-30 | Extrahop Networks, Inc. | Detection of denial of service attacks |
US11438247B2 (en) | 2019-08-05 | 2022-09-06 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11463299B2 (en) | 2018-02-07 | 2022-10-04 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
US11463465B2 (en) | 2019-09-04 | 2022-10-04 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11496378B2 (en) | 2018-08-09 | 2022-11-08 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
US11546153B2 (en) | 2017-03-22 | 2023-01-03 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
US11665207B2 (en) | 2017-10-25 | 2023-05-30 | Extrahop Networks, Inc. | Inline secret sharing |
US11706233B2 (en) | 2019-05-28 | 2023-07-18 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
US11916771B2 (en) | 2021-09-23 | 2024-02-27 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
Families Citing this family (311)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6122403A (en) * | 1995-07-27 | 2000-09-19 | Digimarc Corporation | Computer system linked by using information in data objects |
US5832119C1 (en) | 1993-11-18 | 2002-03-05 | Digimarc Corp | Methods for controlling systems using control signals embedded in empirical data |
US5748763A (en) | 1993-11-18 | 1998-05-05 | Digimarc Corporation | Image steganography system featuring perceptually adaptive and globally scalable signal embedding |
US6408082B1 (en) | 1996-04-25 | 2002-06-18 | Digimarc Corporation | Watermark detection using a fourier mellin transform |
US6424725B1 (en) | 1996-05-16 | 2002-07-23 | Digimarc Corporation | Determining transformations of media signals with embedded code signals |
US6516079B1 (en) | 2000-02-14 | 2003-02-04 | Digimarc Corporation | Digital watermark screening and detecting strategies |
US6983051B1 (en) | 1993-11-18 | 2006-01-03 | Digimarc Corporation | Methods for audio watermarking and decoding |
US5841886A (en) | 1993-11-18 | 1998-11-24 | Digimarc Corporation | Security system for photographic identification |
US6580819B1 (en) | 1993-11-18 | 2003-06-17 | Digimarc Corporation | Methods of producing security documents having digitally encoded data and documents employing same |
US5822436A (en) | 1996-04-25 | 1998-10-13 | Digimarc Corporation | Photographic products and methods employing embedded information |
US6614914B1 (en) | 1995-05-08 | 2003-09-02 | Digimarc Corporation | Watermark embedder and reader |
US5862260A (en) | 1993-11-18 | 1999-01-19 | Digimarc Corporation | Methods for surveying dissemination of proprietary empirical data |
US7171016B1 (en) | 1993-11-18 | 2007-01-30 | Digimarc Corporation | Method for monitoring internet dissemination of image, video and/or audio files |
US5768426A (en) | 1993-11-18 | 1998-06-16 | Digimarc Corporation | Graphics processing system employing embedded code signals |
US6611607B1 (en) | 1993-11-18 | 2003-08-26 | Digimarc Corporation | Integrating digital watermarks in multimedia content |
US6522770B1 (en) | 1999-05-19 | 2003-02-18 | Digimarc Corporation | Management of documents and other objects using optical devices |
US5588060A (en) * | 1994-06-10 | 1996-12-24 | Sun Microsystems, Inc. | Method and apparatus for a key-management scheme for internet protocols |
EP0693836A1 (en) * | 1994-06-10 | 1996-01-24 | Sun Microsystems, Inc. | Method and apparatus for a key-management scheme for internet protocols. |
US5864683A (en) * | 1994-10-12 | 1999-01-26 | Secure Computing Corporartion | System for providing secure internetwork by connecting type enforcing secure computers to external network for limiting access to data based on user and process access rights |
US6560349B1 (en) | 1994-10-21 | 2003-05-06 | Digimarc Corporation | Audio monitoring using steganographic information |
US5623601A (en) * | 1994-11-18 | 1997-04-22 | Milkway Networks Corporation | Apparatus and method for providing a secure gateway for communication and data exchanges between networks |
JP4008049B2 (en) * | 1995-03-20 | 2007-11-14 | 富士通株式会社 | Address transmitting apparatus, address transmitting method and address transmitting system |
US6728390B2 (en) | 1995-05-08 | 2004-04-27 | Digimarc Corporation | Methods and systems using multiple watermarks |
US6760463B2 (en) | 1995-05-08 | 2004-07-06 | Digimarc Corporation | Watermarking methods and media |
US6721440B2 (en) | 1995-05-08 | 2004-04-13 | Digimarc Corporation | Low visibility watermarks using an out-of-phase color |
US6041166A (en) * | 1995-07-14 | 2000-03-21 | 3Com Corp. | Virtual network architecture for connectionless LAN backbone |
US6829368B2 (en) | 2000-01-26 | 2004-12-07 | Digimarc Corporation | Establishing and interacting with on-line media collections using identifiers in media signals |
US6577746B1 (en) | 1999-12-28 | 2003-06-10 | Digimarc Corporation | Watermark-based object linking and embedding |
US6788800B1 (en) | 2000-07-25 | 2004-09-07 | Digimarc Corporation | Authenticating objects using embedded data |
JP3590143B2 (en) * | 1995-07-28 | 2004-11-17 | 株式会社東芝 | Email transfer device |
US5757924A (en) * | 1995-09-18 | 1998-05-26 | Digital Secured Networks Techolognies, Inc. | Network security device which performs MAC address translation without affecting the IP address |
JPH0991358A (en) * | 1995-09-28 | 1997-04-04 | Fujitsu Ltd | Device and method for providing information |
US5768391A (en) * | 1995-12-22 | 1998-06-16 | Mci Corporation | System and method for ensuring user privacy in network communications |
US5784566A (en) * | 1996-01-11 | 1998-07-21 | Oracle Corporation | System and method for negotiating security services and algorithms for communication across a computer network |
WO1997026735A1 (en) * | 1996-01-16 | 1997-07-24 | Raptor Systems, Inc. | Key management for network communication |
WO1997026734A1 (en) * | 1996-01-16 | 1997-07-24 | Raptor Systems, Inc. | Transferring encrypted packets over a public network |
US5781550A (en) * | 1996-02-02 | 1998-07-14 | Digital Equipment Corporation | Transparent and secure network gateway |
US5898830A (en) * | 1996-10-17 | 1999-04-27 | Network Engineering Software | Firewall providing enhanced network security and user transparency |
US5826014A (en) * | 1996-02-06 | 1998-10-20 | Network Engineering Software | Firewall system for protecting network elements connected to a public network |
US5913024A (en) | 1996-02-09 | 1999-06-15 | Secure Computing Corporation | Secure server utilizing separate protocol stacks |
US5918018A (en) * | 1996-02-09 | 1999-06-29 | Secure Computing Corporation | System and method for achieving network separation |
US7130888B1 (en) * | 1996-02-16 | 2006-10-31 | G&H Nevada-Tek | Method and apparatus for controlling a computer over a TCP/IP protocol network |
US9094384B2 (en) * | 1996-02-16 | 2015-07-28 | Reference Ltd., Limited Liability Company | TCP/IP protocol network with satellite nodes |
US6173332B1 (en) | 1996-03-06 | 2001-01-09 | Paul L. Hickman | Method and apparatus for computing over a wide area network |
US7100069B1 (en) * | 1996-02-16 | 2006-08-29 | G&H Nevada-Tek | Method and apparatus for controlling a computer over a wide area network |
US6003007A (en) * | 1996-03-28 | 1999-12-14 | Dirienzo; Andrew L. | Attachment integrated claims system and operating method therefor |
US9619841B2 (en) | 1996-03-28 | 2017-04-11 | Integrated Claims Systems, Llc | Systems to assist in the creation, transmission, and processing of health insurance claims |
US6381341B1 (en) | 1996-05-16 | 2002-04-30 | Digimarc Corporation | Watermark encoding method exploiting biases inherent in original signal |
US5826023A (en) * | 1996-06-03 | 1998-10-20 | International Business Machines Corporation | Communications tunneling |
US5748736A (en) * | 1996-06-14 | 1998-05-05 | Mittra; Suvo | System and method for secure group communications via multicast or broadcast |
US5822434A (en) * | 1996-06-19 | 1998-10-13 | Sun Microsystems, Inc. | Scheme to allow two computers on a network to upgrade from a non-secured to a secured session |
JP3446482B2 (en) * | 1996-06-28 | 2003-09-16 | 三菱電機株式会社 | Encryption device |
US6754212B1 (en) * | 1996-07-12 | 2004-06-22 | Hitachi, Ltd. | Repeater and network system utililzing the same |
US6003084A (en) * | 1996-09-13 | 1999-12-14 | Secure Computing Corporation | Secure network proxy for connecting entities |
US5983350A (en) * | 1996-09-18 | 1999-11-09 | Secure Computing Corporation | Secure firewall supporting different levels of authentication based on address or encryption status |
US5950195A (en) * | 1996-09-18 | 1999-09-07 | Secure Computing Corporation | Generalized security policy management system and method |
US6072942A (en) * | 1996-09-18 | 2000-06-06 | Secure Computing Corporation | System and method of electronic mail filtering using interconnected nodes |
US6229809B1 (en) | 1996-10-11 | 2001-05-08 | Novell, Inc. | Method and system for combining computer network protocols |
US5944823A (en) * | 1996-10-21 | 1999-08-31 | International Business Machines Corporations | Outside access to computer resources through a firewall |
JP4497099B2 (en) * | 1996-11-27 | 2010-07-07 | ソニー株式会社 | Information transmission equipment |
US5915087A (en) * | 1996-12-12 | 1999-06-22 | Secure Computing Corporation | Transparent security proxy for unreliable message exchange protocols |
US5864666A (en) * | 1996-12-23 | 1999-01-26 | International Business Machines Corporation | Web-based administration of IP tunneling on internet firewalls |
US6240513B1 (en) | 1997-01-03 | 2001-05-29 | Fortress Technologies, Inc. | Network security device |
US6055575A (en) * | 1997-01-28 | 2000-04-25 | Ascend Communications, Inc. | Virtual private network system and method |
US5812764A (en) * | 1997-01-30 | 1998-09-22 | International Business Machines | Password management system over a communications network |
US6169805B1 (en) | 1997-02-28 | 2001-01-02 | International Business Machines Corporation | System and method of operation for providing user's security on-demand over insecure networks |
ATE367701T1 (en) | 1997-03-12 | 2007-08-15 | Nomadix Inc | NOMADIC TRANSLATOR OR PATH FINDER |
US6226748B1 (en) * | 1997-06-12 | 2001-05-01 | Vpnet Technologies, Inc. | Architecture for virtual private networks |
US6173399B1 (en) * | 1997-06-12 | 2001-01-09 | Vpnet Technologies, Inc. | Apparatus for implementing virtual private networks |
WO1999000958A1 (en) * | 1997-06-26 | 1999-01-07 | British Telecommunications Plc | Data communications |
US6816966B1 (en) * | 1997-06-30 | 2004-11-09 | Sun Microsystems, Inc. | Techniques for securing data flow in internet multicasting |
US6671810B1 (en) | 1997-09-18 | 2003-12-30 | Intel Corporation | Method and system for establishing secure communication over computer networks |
US6347338B1 (en) | 1997-11-26 | 2002-02-12 | International Business Machines Corporation | Precomputed and distributed security system for a communication network |
US6345299B2 (en) * | 1997-11-26 | 2002-02-05 | International Business Machines Corporation | Distributed security system for a communication network |
US6098133A (en) * | 1997-11-28 | 2000-08-01 | Motorola, Inc. | Secure bus arbiter interconnect arrangement |
JP3892558B2 (en) * | 1997-12-16 | 2007-03-14 | 富士通株式会社 | Agent device and program recording medium |
FI108827B (en) * | 1998-01-08 | 2002-03-28 | Nokia Corp | A method for implementing connection security in a wireless network |
US6804376B2 (en) | 1998-01-20 | 2004-10-12 | Digimarc Corporation | Equipment employing watermark-based authentication function |
US6321336B1 (en) | 1998-03-13 | 2001-11-20 | Secure Computing Corporation | System and method for redirecting network traffic to provide secure communication |
US6188691B1 (en) | 1998-03-16 | 2001-02-13 | 3Com Corporation | Multicast domain virtual local area network |
US6453419B1 (en) | 1998-03-18 | 2002-09-17 | Secure Computing Corporation | System and method for implementing a security policy |
US6182226B1 (en) | 1998-03-18 | 2001-01-30 | Secure Computing Corporation | System and method for controlling interactions between networks |
US6092108A (en) * | 1998-03-19 | 2000-07-18 | Diplacido; Bruno | Dynamic threshold packet filtering of application processor frames |
EP0946022B1 (en) * | 1998-03-26 | 2013-12-18 | Nippon Telegraph And Telephone Corporation | Email access control scheme for communication network using identification concealment mechanism |
US6373986B1 (en) | 1998-04-08 | 2002-04-16 | Ncr Corporation | Compression of data transmission by use of prime exponents |
US6230186B1 (en) * | 1998-04-28 | 2001-05-08 | Rhoda Yaker | Private electronic message system |
JP4273535B2 (en) * | 1998-05-12 | 2009-06-03 | ソニー株式会社 | Data transmission control method, data transmission system, data receiving apparatus and data transmitting apparatus |
US6201792B1 (en) | 1998-05-14 | 2001-03-13 | 3Com Corporation | Backpressure responsive multicast queue |
US6269076B1 (en) | 1998-05-28 | 2001-07-31 | 3Com Corporation | Method of resolving split virtual LANs utilizing a network management system |
US6223149B1 (en) | 1998-05-28 | 2001-04-24 | 3Com Corporation | Non-distributed LAN emulation server redundancy method |
US6289017B1 (en) | 1998-05-29 | 2001-09-11 | 3Com Corporation | Method of providing redundancy and load sharing among multiple LECs in an asynchronous mode network |
DE19831190C1 (en) * | 1998-07-11 | 1999-10-28 | Tracto Technik | Appliance for dividing subterranean pipes and laying of new ones etc. |
US6567914B1 (en) * | 1998-07-22 | 2003-05-20 | Entrust Technologies Limited | Apparatus and method for reducing transmission bandwidth and storage requirements in a cryptographic security system |
US9361243B2 (en) | 1998-07-31 | 2016-06-07 | Kom Networks Inc. | Method and system for providing restricted access to a storage medium |
US6771597B2 (en) | 1998-07-31 | 2004-08-03 | International Business Machines Corporation | Method and apparatus for transmitting messages |
US8234477B2 (en) | 1998-07-31 | 2012-07-31 | Kom Networks, Inc. | Method and system for providing restricted access to a storage medium |
US7194554B1 (en) | 1998-12-08 | 2007-03-20 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization authentication and accounting |
US8266266B2 (en) | 1998-12-08 | 2012-09-11 | Nomadix, Inc. | Systems and methods for providing dynamic network authorization, authentication and accounting |
US8713641B1 (en) | 1998-12-08 | 2014-04-29 | Nomadix, Inc. | Systems and methods for authorizing, authenticating and accounting users having transparent computer access to a network using a gateway device |
US6480891B1 (en) | 1999-01-04 | 2002-11-12 | 3Com Corporation | Embedded code memory size reduction in asynchronous mode transfer devices |
JP4838422B2 (en) | 1999-01-28 | 2011-12-14 | コーニンクレッカ フィリップス エレクトロニクス エヌ ヴィ | Transmission system |
US6606706B1 (en) * | 1999-02-08 | 2003-08-12 | Nortel Networks Limited | Hierarchical multicast traffic security system in an internetwork |
US6532237B1 (en) | 1999-02-16 | 2003-03-11 | 3Com Corporation | Apparatus for and method of testing a hierarchical PNNI based ATM network |
US6678270B1 (en) * | 1999-03-12 | 2004-01-13 | Sandstorm Enterprises, Inc. | Packet interception system including arrangement facilitating authentication of intercepted packets |
US7349391B2 (en) * | 1999-03-19 | 2008-03-25 | F5 Networks, Inc. | Tunneling between a bus and a network |
US7505455B1 (en) | 1999-03-19 | 2009-03-17 | F5 Networks, Inc. | Optimizations for tunneling between a bus and a network |
AU1180000A (en) * | 1999-04-26 | 2000-11-10 | Outserv Co., Ltd. | E-mail system, e-mail transmission/reception system, and recording medium |
WO2000068814A1 (en) * | 1999-05-06 | 2000-11-16 | General Dynamics Information Systems, Inc. | Transient network architecture |
US6754214B1 (en) * | 1999-07-19 | 2004-06-22 | Dunti, Llc | Communication network having packetized security codes and a system for detecting security breach locations within the network |
US7778259B1 (en) | 1999-05-14 | 2010-08-17 | Dunti Llc | Network packet transmission mechanism |
US6487171B1 (en) | 1999-05-19 | 2002-11-26 | 3Com Corporation | Crossbar switching matrix with broadcast buffering |
US6470022B1 (en) * | 1999-05-19 | 2002-10-22 | 3Com Corporation | Method of distributing network resources fairly between users in an asynchronous transfer mode network |
US6580693B1 (en) | 1999-05-24 | 2003-06-17 | 3Com Corporation | Methods and apparatus for detecting leaks in ATM networks |
US6539019B1 (en) | 1999-05-24 | 2003-03-25 | 3Com Corporation | Methods and apparatus for automatically connecting a dynamic host configuration protocol (DHCP) client network device to a virtual local area network (VLAN) |
US6574232B1 (en) | 1999-05-26 | 2003-06-03 | 3Com Corporation | Crossbar switch utilizing broadcast buffer and associated broadcast buffer management unit |
US6614792B1 (en) | 1999-05-27 | 2003-09-02 | 3Com Corporation | Proxy MPC for providing MPOA services to legacy lane clients in an asynchronous transfer mode network |
US20040181668A1 (en) * | 1999-06-30 | 2004-09-16 | Blew Edwin O. | Methods for conducting server-side encryption/decryption-on-demand |
AU6082199A (en) * | 1999-09-13 | 2001-04-30 | Nokia Corporation | Intelligent data network router |
WO2001031885A2 (en) | 1999-10-22 | 2001-05-03 | Nomadix, Inc. | Gateway device having an xml interface and associated method |
JP3259724B2 (en) * | 1999-11-26 | 2002-02-25 | 三菱電機株式会社 | Cryptographic device, encryptor and decryptor |
US6798782B1 (en) | 1999-12-10 | 2004-09-28 | Sun Microsystems, Inc. | Truly anonymous communications using supernets, with the provision of topology hiding |
US6870842B1 (en) | 1999-12-10 | 2005-03-22 | Sun Microsystems, Inc. | Using multicasting to provide ethernet-like communication behavior to selected peers on a network |
WO2001043369A2 (en) * | 1999-12-10 | 2001-06-14 | Sun Microsystems, Inc. | Private network using a public-network infrastructure |
US6970941B1 (en) * | 1999-12-10 | 2005-11-29 | Sun Microsystems, Inc. | System and method for separating addresses from the delivery scheme in a virtual private network |
US7336790B1 (en) | 1999-12-10 | 2008-02-26 | Sun Microsystems Inc. | Decoupling access control from key management in a network |
US6938169B1 (en) | 1999-12-10 | 2005-08-30 | Sun Microsystems, Inc. | Channel-specific file system views in a private network using a public-network infrastructure |
US7765581B1 (en) | 1999-12-10 | 2010-07-27 | Oracle America, Inc. | System and method for enabling scalable security in a virtual private network |
US6977929B1 (en) | 1999-12-10 | 2005-12-20 | Sun Microsystems, Inc. | Method and system for facilitating relocation of devices on a network |
GB9929880D0 (en) * | 1999-12-18 | 2000-02-09 | Roke Manor Research | Nested TCP/IP protocol enhancement |
US7925693B2 (en) * | 2000-01-24 | 2011-04-12 | Microsoft Corporation | NAT access control with IPSec |
US6625297B1 (en) | 2000-02-10 | 2003-09-23 | Digimarc Corporation | Self-orienting watermarks |
US20020023209A1 (en) * | 2000-02-14 | 2002-02-21 | Lateca Computer Inc. N.V.United | Encryption and decryption of digital messages in packet transmitting networks |
US6732209B1 (en) * | 2000-03-28 | 2004-05-04 | Juniper Networks, Inc. | Data rate division among a plurality of input queues |
US7814208B2 (en) * | 2000-04-11 | 2010-10-12 | Science Applications International Corporation | System and method for projecting content beyond firewalls |
WO2001080024A2 (en) * | 2000-04-17 | 2001-10-25 | Circadence Corporation | Gateway buffer prioritization |
US8898340B2 (en) | 2000-04-17 | 2014-11-25 | Circadence Corporation | Dynamic network link acceleration for network including wireless communication devices |
US8065399B2 (en) | 2000-04-17 | 2011-11-22 | Circadence Corporation | Automated network infrastructure test and diagnostic system and method therefor |
US8510468B2 (en) | 2000-04-17 | 2013-08-13 | Ciradence Corporation | Route aware network link acceleration |
US8195823B2 (en) * | 2000-04-17 | 2012-06-05 | Circadence Corporation | Dynamic network link acceleration |
US20110128972A1 (en) | 2000-04-17 | 2011-06-02 | Randy Thornton | Peer to peer dynamic network link acceleration |
US8996705B2 (en) | 2000-04-17 | 2015-03-31 | Circadence Corporation | Optimization of enhanced network links |
US8024481B2 (en) * | 2000-04-17 | 2011-09-20 | Circadence Corporation | System and method for reducing traffic and congestion on distributed interactive simulation networks |
US6804377B2 (en) | 2000-04-19 | 2004-10-12 | Digimarc Corporation | Detecting information hidden out-of-phase in color channels |
GB2362548B (en) * | 2000-05-15 | 2004-03-24 | Vodafone Ltd | A method and apparatus for asynchronous information transactions |
KR100601634B1 (en) * | 2000-06-07 | 2006-07-14 | 삼성전자주식회사 | High speed copy protection method |
US20040073617A1 (en) | 2000-06-19 | 2004-04-15 | Milliken Walter Clark | Hash-based systems and methods for detecting and preventing transmission of unwanted e-mail |
GB2369213B (en) | 2000-07-04 | 2005-02-23 | Honda Motor Co Ltd | Electronic file management system |
US7111163B1 (en) | 2000-07-10 | 2006-09-19 | Alterwan, Inc. | Wide area network using internet with quality of service |
JP2002044135A (en) * | 2000-07-25 | 2002-02-08 | Mitsubishi Electric Corp | Encryption device and encryption communication system |
US6731649B1 (en) | 2000-07-26 | 2004-05-04 | Rad Data Communication Ltd. | TDM over IP (IP circuit emulation service) |
US20020015496A1 (en) * | 2000-08-03 | 2002-02-07 | Weaver J. Dewey | Method and system for controlling content to a user |
US6834342B2 (en) | 2000-08-16 | 2004-12-21 | Eecad, Inc. | Method and system for secure communication over unstable public connections |
US8037530B1 (en) * | 2000-08-28 | 2011-10-11 | Verizon Corporate Services Group Inc. | Method and apparatus for providing adaptive self-synchronized dynamic address translation as an intrusion detection sensor |
US7870599B2 (en) | 2000-09-05 | 2011-01-11 | Netlabs.Com, Inc. | Multichannel device utilizing a centralized out-of-band authentication system (COBAS) |
WO2002027503A1 (en) * | 2000-09-27 | 2002-04-04 | Sony Corporation | Home network system |
KR100382372B1 (en) * | 2000-11-01 | 2003-05-01 | 주식회사 익산노즐 | Intermingle apparatus of compound fiber gauze used in false twisting machine for industry |
US6629103B1 (en) * | 2000-11-02 | 2003-09-30 | Oridus, Inc. | Method for securely providing a text file for execution |
JP2003204323A (en) | 2000-12-21 | 2003-07-18 | Yasumasa Uyama | Secret communication method |
EP1244267B1 (en) * | 2000-12-21 | 2007-02-14 | Yasumasa Uyama | Method and apparatus for automatic enciphering/deciphering in a protected communication system |
US20020083344A1 (en) * | 2000-12-21 | 2002-06-27 | Vairavan Kannan P. | Integrated intelligent inter/intra networking device |
US6959346B2 (en) * | 2000-12-22 | 2005-10-25 | Mosaid Technologies, Inc. | Method and system for packet encryption |
US9100457B2 (en) | 2001-03-28 | 2015-08-04 | Qualcomm Incorporated | Method and apparatus for transmission framing in a wireless communication system |
US8077679B2 (en) | 2001-03-28 | 2011-12-13 | Qualcomm Incorporated | Method and apparatus for providing protocol options in a wireless communication system |
US8121296B2 (en) | 2001-03-28 | 2012-02-21 | Qualcomm Incorporated | Method and apparatus for security in a data processing system |
US20020161998A1 (en) * | 2001-04-27 | 2002-10-31 | International Business Machines Corporation | Method and system for providing hardware cryptography functionality to a data processing system lacking cryptography hardware |
US20020164027A1 (en) * | 2001-05-04 | 2002-11-07 | Stephenson Gary V. | Compression for asymmetric data links |
US7023996B2 (en) * | 2001-05-04 | 2006-04-04 | The Boeing Company | Encryption for asymmetric data links |
JP2003051853A (en) * | 2001-08-07 | 2003-02-21 | Matsushita Electric Ind Co Ltd | Communication method and communication device |
US7983419B2 (en) * | 2001-08-09 | 2011-07-19 | Trimble Navigation Limited | Wireless device to network server encryption |
US7697523B2 (en) * | 2001-10-03 | 2010-04-13 | Qualcomm Incorporated | Method and apparatus for data packet transport in a wireless communication system using an internet protocol |
US7352868B2 (en) | 2001-10-09 | 2008-04-01 | Philip Hawkes | Method and apparatus for security in a data processing system |
US7649829B2 (en) | 2001-10-12 | 2010-01-19 | Qualcomm Incorporated | Method and system for reduction of decoding complexity in a communication system |
SE523290C2 (en) * | 2001-10-19 | 2004-04-06 | Smarttrust Systems Oy | Method and device in a communication network |
AU2002357000A1 (en) * | 2001-11-23 | 2003-06-10 | Cyberscan Technology, Inc. | Method and systems for large scale controlled and secure data downloading |
US7444506B1 (en) * | 2001-12-28 | 2008-10-28 | Ragula Systems | Selective encryption with parallel networks |
US6658091B1 (en) | 2002-02-01 | 2003-12-02 | @Security Broadband Corp. | LIfestyle multimedia security system |
US7673136B2 (en) * | 2002-02-26 | 2010-03-02 | Stewart Ian A | Method for secure multicast repeating on the public Internet |
WO2003096612A1 (en) * | 2002-05-09 | 2003-11-20 | Niigata Seimitsu Co., Ltd. | Encryption device, encryption method, and encryption system |
US7599655B2 (en) | 2003-01-02 | 2009-10-06 | Qualcomm Incorporated | Method and apparatus for broadcast services in a communication system |
US20050084139A1 (en) * | 2003-05-13 | 2005-04-21 | Biocom, Llc | Identity verification system with interoperable and interchangeable input devices |
US8098818B2 (en) | 2003-07-07 | 2012-01-17 | Qualcomm Incorporated | Secure registration for a multicast-broadcast-multimedia system (MBMS) |
US8718279B2 (en) | 2003-07-08 | 2014-05-06 | Qualcomm Incorporated | Apparatus and method for a secure broadcast system |
US7769994B2 (en) * | 2003-08-13 | 2010-08-03 | Radware Ltd. | Content inspection in secure networks |
US8724803B2 (en) | 2003-09-02 | 2014-05-13 | Qualcomm Incorporated | Method and apparatus for providing authenticated challenges for broadcast-multicast communications in a communication system |
TW200529623A (en) * | 2004-01-14 | 2005-09-01 | Nec Corp | Communication encryption method, communication encryption system, terminal device, DNS server and program |
US10200504B2 (en) | 2007-06-12 | 2019-02-05 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11368327B2 (en) | 2008-08-11 | 2022-06-21 | Icontrol Networks, Inc. | Integrated cloud system for premises automation |
US11277465B2 (en) | 2004-03-16 | 2022-03-15 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US10156959B2 (en) | 2005-03-16 | 2018-12-18 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US10444964B2 (en) | 2007-06-12 | 2019-10-15 | Icontrol Networks, Inc. | Control system user interface |
US10313303B2 (en) | 2007-06-12 | 2019-06-04 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US10522026B2 (en) | 2008-08-11 | 2019-12-31 | Icontrol Networks, Inc. | Automation system user interface with three-dimensional display |
US8635350B2 (en) | 2006-06-12 | 2014-01-21 | Icontrol Networks, Inc. | IP device discovery systems and methods |
US8963713B2 (en) | 2005-03-16 | 2015-02-24 | Icontrol Networks, Inc. | Integrated security network with security alarm signaling system |
US10375253B2 (en) | 2008-08-25 | 2019-08-06 | Icontrol Networks, Inc. | Security system with networked touchscreen and gateway |
US9531593B2 (en) | 2007-06-12 | 2016-12-27 | Icontrol Networks, Inc. | Takeover processes in security network integrated with premise security system |
US10237237B2 (en) | 2007-06-12 | 2019-03-19 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11677577B2 (en) | 2004-03-16 | 2023-06-13 | Icontrol Networks, Inc. | Premises system management using status signal |
US10348575B2 (en) | 2013-06-27 | 2019-07-09 | Icontrol Networks, Inc. | Control system user interface |
US11916870B2 (en) | 2004-03-16 | 2024-02-27 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US11113950B2 (en) | 2005-03-16 | 2021-09-07 | Icontrol Networks, Inc. | Gateway integrated with premises security system |
US11201755B2 (en) | 2004-03-16 | 2021-12-14 | Icontrol Networks, Inc. | Premises system management using status signal |
US10721087B2 (en) | 2005-03-16 | 2020-07-21 | Icontrol Networks, Inc. | Method for networked touchscreen with integrated interfaces |
US9609003B1 (en) | 2007-06-12 | 2017-03-28 | Icontrol Networks, Inc. | Generating risk profile using data of home monitoring and security system |
US11582065B2 (en) | 2007-06-12 | 2023-02-14 | Icontrol Networks, Inc. | Systems and methods for device communication |
EP1738540B1 (en) | 2004-03-16 | 2017-10-04 | Icontrol Networks, Inc. | Premises management system |
US10339791B2 (en) | 2007-06-12 | 2019-07-02 | Icontrol Networks, Inc. | Security network integrated with premise security system |
US9729342B2 (en) | 2010-12-20 | 2017-08-08 | Icontrol Networks, Inc. | Defining and implementing sensor triggered response rules |
US11343380B2 (en) | 2004-03-16 | 2022-05-24 | Icontrol Networks, Inc. | Premises system automation |
US10142392B2 (en) | 2007-01-24 | 2018-11-27 | Icontrol Networks, Inc. | Methods and systems for improved system performance |
US7711796B2 (en) | 2006-06-12 | 2010-05-04 | Icontrol Networks, Inc. | Gateway registry methods and systems |
US11811845B2 (en) | 2004-03-16 | 2023-11-07 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11244545B2 (en) | 2004-03-16 | 2022-02-08 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US9141276B2 (en) | 2005-03-16 | 2015-09-22 | Icontrol Networks, Inc. | Integrated interface for mobile device |
US11368429B2 (en) | 2004-03-16 | 2022-06-21 | Icontrol Networks, Inc. | Premises management configuration and control |
US9191228B2 (en) | 2005-03-16 | 2015-11-17 | Icontrol Networks, Inc. | Cross-client sensor user interface in an integrated security network |
US11316958B2 (en) | 2008-08-11 | 2022-04-26 | Icontrol Networks, Inc. | Virtual device systems and methods |
US11159484B2 (en) | 2004-03-16 | 2021-10-26 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US20090077623A1 (en) | 2005-03-16 | 2009-03-19 | Marc Baum | Security Network Integrating Security System and Network Devices |
US11190578B2 (en) | 2008-08-11 | 2021-11-30 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US10382452B1 (en) | 2007-06-12 | 2019-08-13 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10062273B2 (en) | 2010-09-28 | 2018-08-28 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US11489812B2 (en) | 2004-03-16 | 2022-11-01 | Icontrol Networks, Inc. | Forming a security network including integrated security system components and network devices |
US8988221B2 (en) | 2005-03-16 | 2015-03-24 | Icontrol Networks, Inc. | Integrated security system with parallel processing architecture |
US8458453B1 (en) | 2004-06-11 | 2013-06-04 | Dunti Llc | Method and apparatus for securing communication over public network |
US7546454B2 (en) * | 2004-06-30 | 2009-06-09 | At&T Intellectual Property I, L.P. | Automated digital certificate discovery and management |
US20060034497A1 (en) * | 2004-08-15 | 2006-02-16 | Michael Manansala | Protometric authentication system |
US7730298B2 (en) * | 2004-11-22 | 2010-06-01 | Hubspan Inc. | Method and apparatus for translating information between computers having different security management |
KR100645517B1 (en) * | 2004-12-16 | 2006-11-15 | 삼성전자주식회사 | Method and system for routing VoIP call based on subscriber service class |
JP4759382B2 (en) * | 2004-12-21 | 2011-08-31 | 株式会社リコー | COMMUNICATION DEVICE, COMMUNICATION METHOD, COMMUNICATION PROGRAM, AND RECORDING MEDIUM |
US7552464B2 (en) * | 2005-01-29 | 2009-06-23 | Cisco Technology, Inc. | Techniques for presenting network identities at a human interface |
US11700142B2 (en) | 2005-03-16 | 2023-07-11 | Icontrol Networks, Inc. | Security network integrating security system and network devices |
US9306809B2 (en) | 2007-06-12 | 2016-04-05 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US11615697B2 (en) | 2005-03-16 | 2023-03-28 | Icontrol Networks, Inc. | Premise management systems and methods |
US20110128378A1 (en) | 2005-03-16 | 2011-06-02 | Reza Raji | Modular Electronic Display Platform |
US10999254B2 (en) | 2005-03-16 | 2021-05-04 | Icontrol Networks, Inc. | System for data routing in networks |
US20120324566A1 (en) | 2005-03-16 | 2012-12-20 | Marc Baum | Takeover Processes In Security Network Integrated With Premise Security System |
US11496568B2 (en) | 2005-03-16 | 2022-11-08 | Icontrol Networks, Inc. | Security system with networked touchscreen |
US20170180198A1 (en) | 2008-08-11 | 2017-06-22 | Marc Baum | Forming a security network including integrated security system components |
US8069470B1 (en) * | 2005-04-13 | 2011-11-29 | Oracle America, Inc. | Identity and authentication in a wireless network |
US20060236124A1 (en) * | 2005-04-19 | 2006-10-19 | International Business Machines Corporation | Method and apparatus for determining whether to encrypt outbound traffic |
WO2006116396A2 (en) * | 2005-04-26 | 2006-11-02 | Anders Joseph C | Voice over internet protocol system and method for processing of telephonic voice over a data network |
US8204039B2 (en) * | 2005-11-30 | 2012-06-19 | Symbol Technologies, Inc. | System and method for data communication in a wireless network |
US20070180237A1 (en) * | 2005-12-22 | 2007-08-02 | Cisco Technology, Inc. | Apparatus and methods for interaction between message groups and encryption methods |
US7894607B1 (en) * | 2006-03-10 | 2011-02-22 | Storage Technology Corporation | System, method and media drive for selectively encrypting a data packet |
US8060744B2 (en) * | 2006-03-23 | 2011-11-15 | Harris Corporation | Computer architecture for an electronic device providing single-level secure access to multi-level secure file system |
US8041947B2 (en) * | 2006-03-23 | 2011-10-18 | Harris Corporation | Computer architecture for an electronic device providing SLS access to MLS file system with trusted loading and protection of program execution memory |
US8127145B2 (en) * | 2006-03-23 | 2012-02-28 | Harris Corporation | Computer architecture for an electronic device providing a secure file system |
US7979714B2 (en) * | 2006-06-02 | 2011-07-12 | Harris Corporation | Authentication and access control device |
US10079839B1 (en) | 2007-06-12 | 2018-09-18 | Icontrol Networks, Inc. | Activation of gateway device |
EP2035948B1 (en) * | 2006-06-27 | 2016-04-13 | Waterfall Security Solutions Ltd. | Unidirectional secure links from and to a security engine |
WO2008007432A1 (en) * | 2006-07-13 | 2008-01-17 | T T T Kabushikikaisha | Relay device |
IL177756A (en) * | 2006-08-29 | 2014-11-30 | Lior Frenkel | Encryption-based attack prevention |
IL180020A (en) * | 2006-12-12 | 2013-03-24 | Waterfall Security Solutions Ltd | Encryption -and decryption-enabled interfaces |
IL180748A (en) * | 2007-01-16 | 2013-03-24 | Waterfall Security Solutions Ltd | Secure archive |
US11706279B2 (en) | 2007-01-24 | 2023-07-18 | Icontrol Networks, Inc. | Methods and systems for data communication |
US7633385B2 (en) | 2007-02-28 | 2009-12-15 | Ucontrol, Inc. | Method and system for communicating with and controlling an alarm system from a remote server |
US8451986B2 (en) | 2007-04-23 | 2013-05-28 | Icontrol Networks, Inc. | Method and system for automatically providing alternate network access for telecommunications |
US10051078B2 (en) | 2007-06-12 | 2018-08-14 | Icontrol Networks, Inc. | WiFi-to-serial encapsulation in systems |
US11212192B2 (en) | 2007-06-12 | 2021-12-28 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11089122B2 (en) | 2007-06-12 | 2021-08-10 | Icontrol Networks, Inc. | Controlling data routing among networks |
US10498830B2 (en) | 2007-06-12 | 2019-12-03 | Icontrol Networks, Inc. | Wi-Fi-to-serial encapsulation in systems |
US10523689B2 (en) | 2007-06-12 | 2019-12-31 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US11646907B2 (en) | 2007-06-12 | 2023-05-09 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10616075B2 (en) | 2007-06-12 | 2020-04-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10423309B2 (en) | 2007-06-12 | 2019-09-24 | Icontrol Networks, Inc. | Device integration framework |
US10389736B2 (en) | 2007-06-12 | 2019-08-20 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11423756B2 (en) | 2007-06-12 | 2022-08-23 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11237714B2 (en) | 2007-06-12 | 2022-02-01 | Control Networks, Inc. | Control system user interface |
US11218878B2 (en) | 2007-06-12 | 2022-01-04 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US10666523B2 (en) | 2007-06-12 | 2020-05-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11601810B2 (en) | 2007-06-12 | 2023-03-07 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11316753B2 (en) | 2007-06-12 | 2022-04-26 | Icontrol Networks, Inc. | Communication protocols in integrated systems |
US11831462B2 (en) | 2007-08-24 | 2023-11-28 | Icontrol Networks, Inc. | Controlling data routing in premises management systems |
US8223205B2 (en) * | 2007-10-24 | 2012-07-17 | Waterfall Solutions Ltd. | Secure implementation of network-based sensors |
US11916928B2 (en) | 2008-01-24 | 2024-02-27 | Icontrol Networks, Inc. | Communication protocols over internet protocol (IP) networks |
US8683572B1 (en) | 2008-01-24 | 2014-03-25 | Dunti Llc | Method and apparatus for providing continuous user verification in a packet-based network |
US20090228700A1 (en) * | 2009-03-05 | 2009-09-10 | Raytheon Company | Internet Gatekeeper Protocol |
US20170185278A1 (en) | 2008-08-11 | 2017-06-29 | Icontrol Networks, Inc. | Automation system user interface |
US11758026B2 (en) | 2008-08-11 | 2023-09-12 | Icontrol Networks, Inc. | Virtual device systems and methods |
US11729255B2 (en) | 2008-08-11 | 2023-08-15 | Icontrol Networks, Inc. | Integrated cloud system with lightweight gateway for premises automation |
US11792036B2 (en) | 2008-08-11 | 2023-10-17 | Icontrol Networks, Inc. | Mobile premises automation platform |
US11258625B2 (en) | 2008-08-11 | 2022-02-22 | Icontrol Networks, Inc. | Mobile premises automation platform |
US20100146120A1 (en) * | 2008-12-09 | 2010-06-10 | Microsoft Corporation | Caller-specific visibility masks for networking objects |
JP5408608B2 (en) * | 2009-03-02 | 2014-02-05 | 公立大学法人大阪市立大学 | Cryptographic traffic identification device and cryptographic traffic identification system including the same |
US8638211B2 (en) | 2009-04-30 | 2014-01-28 | Icontrol Networks, Inc. | Configurable controller and interface for home SMA, phone and multimedia |
US9912654B2 (en) * | 2009-11-12 | 2018-03-06 | Microsoft Technology Licensing, Llc | IP security certificate exchange based on certificate attributes |
AU2011250886A1 (en) | 2010-05-10 | 2013-01-10 | Icontrol Networks, Inc | Control system user interface |
US8836467B1 (en) | 2010-09-28 | 2014-09-16 | Icontrol Networks, Inc. | Method, system and apparatus for automated reporting of account and sensor zone information to a central station |
US11750414B2 (en) | 2010-12-16 | 2023-09-05 | Icontrol Networks, Inc. | Bidirectional security sensor communication for a premises security system |
US9147337B2 (en) | 2010-12-17 | 2015-09-29 | Icontrol Networks, Inc. | Method and system for logging security event data |
US10177957B1 (en) | 2012-07-06 | 2019-01-08 | Cradlepoint, Inc. | Connecting a cloud network to the internet |
US10560343B1 (en) | 2012-07-06 | 2020-02-11 | Cradlepoint, Inc. | People centric management of cloud networks via GUI |
US10880162B1 (en) | 2012-07-06 | 2020-12-29 | Cradlepoint, Inc. | Linking logical broadcast domains |
US10601653B2 (en) | 2012-07-06 | 2020-03-24 | Cradlepoint, Inc. | Implicit traffic engineering |
US10135677B1 (en) * | 2012-07-06 | 2018-11-20 | Cradlepoint, Inc. | Deployment of network-related features over cloud network |
US9992062B1 (en) | 2012-07-06 | 2018-06-05 | Cradlepoint, Inc. | Implicit traffic engineering |
US9118495B1 (en) | 2012-07-06 | 2015-08-25 | Pertino, Inc. | Communication between broadcast domains |
US10110417B1 (en) | 2012-07-06 | 2018-10-23 | Cradlepoint, Inc. | Private networks overlaid on cloud infrastructure |
US9635037B2 (en) | 2012-09-06 | 2017-04-25 | Waterfall Security Solutions Ltd. | Remote control of secure installations |
US9271188B2 (en) | 2012-12-18 | 2016-02-23 | At&T Intellectual Property I, L.P. | Dynamic in-band service control mechanism in mobile network |
US10104060B2 (en) * | 2013-01-30 | 2018-10-16 | Hewlett Packard Enterprise Development Lp | Authenticating applications to a network service |
US9326144B2 (en) | 2013-02-21 | 2016-04-26 | Fortinet, Inc. | Restricting broadcast and multicast traffic in a wireless network to a VLAN |
US9419975B2 (en) | 2013-04-22 | 2016-08-16 | Waterfall Security Solutions Ltd. | Bi-directional communication over a one-way link |
KR101491730B1 (en) * | 2013-12-09 | 2015-02-09 | 에스케이 텔레콤주식회사 | Method for Providing Machine to Machine Encryption Service and Apparatus Therefor |
US11146637B2 (en) | 2014-03-03 | 2021-10-12 | Icontrol Networks, Inc. | Media content management |
US11405463B2 (en) | 2014-03-03 | 2022-08-02 | Icontrol Networks, Inc. | Media content management |
US9584492B2 (en) * | 2014-06-23 | 2017-02-28 | Vmware, Inc. | Cryptographic proxy service |
IL235175A (en) | 2014-10-19 | 2017-08-31 | Frenkel Lior | Secure remote desktop |
IL250010B (en) | 2016-02-14 | 2020-04-30 | Waterfall Security Solutions Ltd | Secure connection with protected facilities |
CN111628972A (en) * | 2020-04-30 | 2020-09-04 | 京东数字科技控股有限公司 | Data encryption and decryption device, method, system and storage medium |
Citations (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO1992002095A1 (en) * | 1990-07-18 | 1992-02-06 | Gpt Limited | A data communication system using encrypted data packets |
JPH04154233A (en) | 1990-10-17 | 1992-05-27 | Fujitsu Ltd | Communication concealing method |
US5161192A (en) * | 1989-12-06 | 1992-11-03 | 3Com Technologies, Ltd. | Repeaters for secure local area networks |
US5204961A (en) * | 1990-06-25 | 1993-04-20 | Digital Equipment Corporation | Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols |
US5416842A (en) * | 1994-06-10 | 1995-05-16 | Sun Microsystems, Inc. | Method and apparatus for key-management scheme for use with internet protocols at site firewalls |
US5442708A (en) * | 1993-03-09 | 1995-08-15 | Uunet Technologies, Inc. | Computer network encryption/decryption device |
US5444782A (en) * | 1993-03-09 | 1995-08-22 | Uunet Technologies, Inc. | Computer network encryption/decryption device |
Family Cites Families (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JPS63311830A (en) * | 1987-06-15 | 1988-12-20 | Nec Corp | Bridge device for local area network |
JPH0669962A (en) * | 1992-08-17 | 1994-03-11 | Fuji Xerox Co Ltd | Network connector and network communication system |
-
1994
- 1994-09-15 US US08/306,337 patent/US5548646A/en not_active Ceased
-
1995
- 1995-09-14 EP EP95306466A patent/EP0702477B1/en not_active Expired - Lifetime
- 1995-09-14 DE DE69533953T patent/DE69533953T2/en not_active Expired - Fee Related
- 1995-09-15 KR KR1019950030294A patent/KR100388606B1/en not_active IP Right Cessation
- 1995-09-18 JP JP7262037A patent/JPH0927804A/en active Pending
-
1998
- 1998-08-19 US US09/136,954 patent/USRE39360E1/en not_active Expired - Lifetime
Patent Citations (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5161192A (en) * | 1989-12-06 | 1992-11-03 | 3Com Technologies, Ltd. | Repeaters for secure local area networks |
US5204961A (en) * | 1990-06-25 | 1993-04-20 | Digital Equipment Corporation | Computer network operating with multilevel hierarchical security with selectable common trust realms and corresponding security protocols |
WO1992002095A1 (en) * | 1990-07-18 | 1992-02-06 | Gpt Limited | A data communication system using encrypted data packets |
US5303303A (en) * | 1990-07-18 | 1994-04-12 | Gpt Limited | Data communication system using encrypted data packets |
JPH04154233A (en) | 1990-10-17 | 1992-05-27 | Fujitsu Ltd | Communication concealing method |
US5442708A (en) * | 1993-03-09 | 1995-08-15 | Uunet Technologies, Inc. | Computer network encryption/decryption device |
US5444782A (en) * | 1993-03-09 | 1995-08-22 | Uunet Technologies, Inc. | Computer network encryption/decryption device |
US5416842A (en) * | 1994-06-10 | 1995-05-16 | Sun Microsystems, Inc. | Method and apparatus for key-management scheme for use with internet protocols at site firewalls |
Non-Patent Citations (6)
Title |
---|
Chuck Semeria, Understanding IP Addressing: Everything You Ever Wanted to Know. 1996. 3Com CorOporation. * |
Forne et al., "Hardware Implementation of a Secure Bridge in Ethernet Environments," Nov. 29, 1993, IEEE. |
Japanese Office Action dated Mar. 15, 2005, from corresponding Japanese Application No. 262037/95. |
O'Higgins, et al, "Securing Information in X.25 Networks," Dec. 2-5, 1990, Globecom '90 IEEE Global Telecommunications Conference & Exhibition. |
Sharp et al., "Network Security in a Heterogeneous Environment," Sep. 1994, AT&T Technical Journal. |
Yamaguchi et al., "A design for LAN cipher communications," Jan. 21, 1994, Technical Report of IEICE, vol. 93, No. 436. |
Cited By (153)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8904516B2 (en) | 1998-10-30 | 2014-12-02 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US9479426B2 (en) | 1998-10-30 | 2016-10-25 | Virnetz, Inc. | Agile network protocol for secure communications with assured system availability |
US9860283B2 (en) | 1998-10-30 | 2018-01-02 | Virnetx, Inc. | Agile network protocol for secure video communications with assured system availability |
US9077695B2 (en) | 1998-10-30 | 2015-07-07 | Virnetx, Inc. | System and method for establishing an encrypted communication link based on IP address lookup requests |
US9819649B2 (en) | 1998-10-30 | 2017-11-14 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US9038163B2 (en) | 1998-10-30 | 2015-05-19 | Virnetx, Inc. | Systems and methods for connecting network devices over communication network |
US10187387B2 (en) | 1998-10-30 | 2019-01-22 | Virnetx, Inc. | Method for establishing connection between devices |
US9027115B2 (en) | 1998-10-30 | 2015-05-05 | Virnetx, Inc. | System and method for using a registered name to connect network devices with a link that uses encryption |
US8943201B2 (en) | 1998-10-30 | 2015-01-27 | Virnetx, Inc. | Method for establishing encrypted channel |
US9413766B2 (en) | 1998-10-30 | 2016-08-09 | Virnetx, Inc. | Method for establishing connection between devices |
US9037713B2 (en) | 1998-10-30 | 2015-05-19 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9386000B2 (en) | 1998-10-30 | 2016-07-05 | Virnetx, Inc. | System and method for establishing a communication link |
US9374346B2 (en) | 1998-10-30 | 2016-06-21 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9077694B2 (en) | 1998-10-30 | 2015-07-07 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US8874771B2 (en) | 1998-10-30 | 2014-10-28 | Virnetx, Inc. | Agile network protocol for secure communications with assured system availability |
US9094399B2 (en) | 1998-10-30 | 2015-07-28 | Virnetx, Inc. | Method for establishing secure communication link between computers of virtual private network |
US9967240B2 (en) | 1998-10-30 | 2018-05-08 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US10511573B2 (en) | 1998-10-30 | 2019-12-17 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US9100375B2 (en) | 1998-10-30 | 2015-08-04 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8868705B2 (en) | 1998-10-30 | 2014-10-21 | Virnetx, Inc. | Agile network protocol for secure communications using secure domain names |
US8843643B2 (en) | 1998-10-30 | 2014-09-23 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US8850009B2 (en) | 1998-10-30 | 2014-09-30 | Virnetx, Inc. | System and method employing an agile network protocol for secure communications using secure domain names |
US9071578B2 (en) | 1999-06-15 | 2015-06-30 | Ssh Communications Security Oyj | Maintaining network address translations |
US8365273B2 (en) * | 1999-06-15 | 2013-01-29 | Tectia Oyj | Method and arrangement for providing security through network address translations using tunneling and compensations |
US20100318682A1 (en) * | 1999-06-15 | 2010-12-16 | Tectia Oyj | Method and arrangement for providing security through network address translations using tunneling and compensations |
US8914872B2 (en) | 1999-06-15 | 2014-12-16 | Ssh Communications Security Oyj | Revealing occurrence of network address translations |
US8914873B2 (en) | 1999-06-15 | 2014-12-16 | Ssh Communications Security Oyj | Revealing address information in systems where network address translations occur |
US8918858B2 (en) | 1999-06-15 | 2014-12-23 | Ssh Communications Security Oyj | Communications across a network address translator |
US20100138560A1 (en) * | 1999-06-15 | 2010-06-03 | Ssh Communications Security Ltd. | Method and arrangement for providing security through network address translations using tunneling and compensations |
US8973127B2 (en) | 1999-06-15 | 2015-03-03 | Ssh Communications Security Oyj | Communications across a network address translator |
US8973126B2 (en) | 1999-06-15 | 2015-03-03 | Ssh Communications Security Oyj | Determining occurrence of a network address translation |
US8544079B2 (en) | 1999-06-15 | 2013-09-24 | Tectia Oyj | Method and arrangement for providing security through network address translations using tunneling and compensations |
US9667594B2 (en) | 1999-06-15 | 2017-05-30 | Ssh Communications Security Oyj | Maintaining network address translations |
US8539111B2 (en) * | 1999-12-30 | 2013-09-17 | Avaya Inc. | Port switch |
US20030200341A1 (en) * | 1999-12-30 | 2003-10-23 | Nortel Networks Corporation, A Canadian Corporation | Port switch |
US8112811B2 (en) * | 2000-04-04 | 2012-02-07 | Sony Corporation | Information playing/reproducing apparatus and method |
US20100054462A1 (en) * | 2000-04-04 | 2010-03-04 | Sony Corporation | Information recording/reproducing apparatus and method |
US7739497B1 (en) * | 2001-03-21 | 2010-06-15 | Verizon Corporate Services Group Inc. | Method and apparatus for anonymous IP datagram exchange using dynamic network address translation |
US20120117376A1 (en) * | 2001-03-21 | 2012-05-10 | Raytheon Bbn Technologies Corp. | Method and apparatus for anonymous ip datagram exchange using dynamic newtork address translation |
US8549285B2 (en) * | 2001-03-21 | 2013-10-01 | Verizon Corporate Services Group Inc. | Method and apparatus for anonymous IP datagram exchange using dynamic network address translation |
US20050228864A1 (en) * | 2002-04-26 | 2005-10-13 | Research In Motion Limited | System and method for selection of messaging settings |
US10284511B2 (en) | 2002-04-26 | 2019-05-07 | Blackberry Limited | System and method for selection of messaging settings on a messaging client |
US20040172559A1 (en) * | 2002-11-26 | 2004-09-02 | Huawei Technologies Co., Ltd. | 802.1X protocol-based multicasting control method |
US7502926B2 (en) * | 2002-11-26 | 2009-03-10 | Huawei Technologies Co., Ltd. | 802.1X protocol-based multicasting control method |
US20040168056A1 (en) * | 2003-02-26 | 2004-08-26 | Microsoft Corporation | Revocation of a certificate and exclusion of other principals in a digital rights management (DRM) system based on a revocation list from a delegated revocation authority |
US7543140B2 (en) * | 2003-02-26 | 2009-06-02 | Microsoft Corporation | Revocation of a certificate and exclusion of other principals in a digital rights management (DRM) system based on a revocation list from a delegated revocation authority |
US8429411B2 (en) | 2005-06-21 | 2013-04-23 | Research In Motion Limited | Automated selection and inclusion of a message signature |
US20060288219A1 (en) * | 2005-06-21 | 2006-12-21 | Research In Motion Limited | Automated selection and inclusion of a message signature |
US8578171B2 (en) | 2005-06-21 | 2013-11-05 | Blackberry Limited | Automated selection and inclusion of a message signature |
US9998412B2 (en) | 2005-06-21 | 2018-06-12 | Blackberry Limited | Automated selection and inclusion of a message signature |
US9781076B2 (en) * | 2008-01-17 | 2017-10-03 | Cassidian Limited | Secure communication system |
US20110035578A1 (en) * | 2008-01-17 | 2011-02-10 | Eads Defence And Security Systems Limited | Secure communication system |
US10104041B2 (en) | 2008-05-16 | 2018-10-16 | Cisco Technology, Inc. | Controlling the spread of interests and content in a content centric network |
US9686194B2 (en) | 2009-10-21 | 2017-06-20 | Cisco Technology, Inc. | Adaptive multi-interface use for content networking |
US10098051B2 (en) | 2014-01-22 | 2018-10-09 | Cisco Technology, Inc. | Gateways and routing in software-defined manets |
US9954678B2 (en) | 2014-02-06 | 2018-04-24 | Cisco Technology, Inc. | Content-based transport security |
US10445380B2 (en) | 2014-03-04 | 2019-10-15 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
US9836540B2 (en) | 2014-03-04 | 2017-12-05 | Cisco Technology, Inc. | System and method for direct storage access in a content-centric network |
US9626413B2 (en) | 2014-03-10 | 2017-04-18 | Cisco Systems, Inc. | System and method for ranking content popularity in a content-centric network |
US9716622B2 (en) | 2014-04-01 | 2017-07-25 | Cisco Technology, Inc. | System and method for dynamic name configuration in content-centric networks |
US9473576B2 (en) | 2014-04-07 | 2016-10-18 | Palo Alto Research Center Incorporated | Service discovery using collection synchronization with exact names |
US9992281B2 (en) | 2014-05-01 | 2018-06-05 | Cisco Technology, Inc. | Accountable content stores for information centric networks |
US10158656B2 (en) | 2014-05-22 | 2018-12-18 | Cisco Technology, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
US9609014B2 (en) | 2014-05-22 | 2017-03-28 | Cisco Systems, Inc. | Method and apparatus for preventing insertion of malicious content at a named data network router |
US9699198B2 (en) | 2014-07-07 | 2017-07-04 | Cisco Technology, Inc. | System and method for parallel secure content bootstrapping in content-centric networks |
US10237075B2 (en) | 2014-07-17 | 2019-03-19 | Cisco Technology, Inc. | Reconstructable content objects |
US9621354B2 (en) | 2014-07-17 | 2017-04-11 | Cisco Systems, Inc. | Reconstructable content objects |
US9929935B2 (en) | 2014-07-18 | 2018-03-27 | Cisco Technology, Inc. | Method and system for keeping interest alive in a content centric network |
US9729616B2 (en) | 2014-07-18 | 2017-08-08 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
US9590887B2 (en) | 2014-07-18 | 2017-03-07 | Cisco Systems, Inc. | Method and system for keeping interest alive in a content centric network |
US10305968B2 (en) | 2014-07-18 | 2019-05-28 | Cisco Technology, Inc. | Reputation-based strategy for forwarding and responding to interests over a content centric network |
US9882964B2 (en) | 2014-08-08 | 2018-01-30 | Cisco Technology, Inc. | Explicit strategy feedback in name-based forwarding |
US9503365B2 (en) * | 2014-08-11 | 2016-11-22 | Palo Alto Research Center Incorporated | Reputation-based instruction processing over an information centric network |
US9729662B2 (en) | 2014-08-11 | 2017-08-08 | Cisco Technology, Inc. | Probabilistic lazy-forwarding technique without validation in a content centric network |
US20160043940A1 (en) * | 2014-08-11 | 2016-02-11 | Palo Alto Research Center Incorporated | Reputation-based instruction processing over an information centric network |
US9800637B2 (en) | 2014-08-19 | 2017-10-24 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
US10367871B2 (en) | 2014-08-19 | 2019-07-30 | Cisco Technology, Inc. | System and method for all-in-one content stream in content-centric networks |
US10715634B2 (en) | 2014-10-23 | 2020-07-14 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
US10069933B2 (en) | 2014-10-23 | 2018-09-04 | Cisco Technology, Inc. | System and method for creating virtual interfaces based on network characteristics |
US9590948B2 (en) | 2014-12-15 | 2017-03-07 | Cisco Systems, Inc. | CCN routing using hardware-assisted hash tables |
US10237189B2 (en) | 2014-12-16 | 2019-03-19 | Cisco Technology, Inc. | System and method for distance-based interest forwarding |
US10003520B2 (en) | 2014-12-22 | 2018-06-19 | Cisco Technology, Inc. | System and method for efficient name-based content routing using link-state information in information-centric networks |
US9660825B2 (en) | 2014-12-24 | 2017-05-23 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
US10091012B2 (en) | 2014-12-24 | 2018-10-02 | Cisco Technology, Inc. | System and method for multi-source multicasting in content-centric networks |
US9916457B2 (en) | 2015-01-12 | 2018-03-13 | Cisco Technology, Inc. | Decoupled name security binding for CCN objects |
US10440161B2 (en) | 2015-01-12 | 2019-10-08 | Cisco Technology, Inc. | Auto-configurable transport stack |
US9832291B2 (en) | 2015-01-12 | 2017-11-28 | Cisco Technology, Inc. | Auto-configurable transport stack |
US9954795B2 (en) | 2015-01-12 | 2018-04-24 | Cisco Technology, Inc. | Resource allocation using CCN manifests |
US9946743B2 (en) | 2015-01-12 | 2018-04-17 | Cisco Technology, Inc. | Order encoded manifests in a content centric network |
US10333840B2 (en) | 2015-02-06 | 2019-06-25 | Cisco Technology, Inc. | System and method for on-demand content exchange with adaptive naming in information-centric networks |
US10075401B2 (en) | 2015-03-18 | 2018-09-11 | Cisco Technology, Inc. | Pending interest table behavior |
US10075402B2 (en) | 2015-06-24 | 2018-09-11 | Cisco Technology, Inc. | Flexible command and control in content centric networks |
US10701038B2 (en) | 2015-07-27 | 2020-06-30 | Cisco Technology, Inc. | Content negotiation in a content centric network |
US9986034B2 (en) | 2015-08-03 | 2018-05-29 | Cisco Technology, Inc. | Transferring state in content centric network stacks |
US10419345B2 (en) | 2015-09-11 | 2019-09-17 | Cisco Technology, Inc. | Network named fragments in a content centric network |
US9832123B2 (en) | 2015-09-11 | 2017-11-28 | Cisco Technology, Inc. | Network named fragments in a content centric network |
US10355999B2 (en) | 2015-09-23 | 2019-07-16 | Cisco Technology, Inc. | Flow control with network named fragments |
US10313227B2 (en) | 2015-09-24 | 2019-06-04 | Cisco Technology, Inc. | System and method for eliminating undetected interest looping in information-centric networks |
US9977809B2 (en) | 2015-09-24 | 2018-05-22 | Cisco Technology, Inc. | Information and data framework in a content centric network |
US10454820B2 (en) | 2015-09-29 | 2019-10-22 | Cisco Technology, Inc. | System and method for stateless information-centric networking |
US10263965B2 (en) | 2015-10-16 | 2019-04-16 | Cisco Technology, Inc. | Encrypted CCNx |
US9912776B2 (en) | 2015-12-02 | 2018-03-06 | Cisco Technology, Inc. | Explicit content deletion commands in a content centric network |
US10097346B2 (en) | 2015-12-09 | 2018-10-09 | Cisco Technology, Inc. | Key catalogs in a content centric network |
US10581967B2 (en) | 2016-01-11 | 2020-03-03 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
US10257271B2 (en) | 2016-01-11 | 2019-04-09 | Cisco Technology, Inc. | Chandra-Toueg consensus in a content centric network |
US10305864B2 (en) | 2016-01-25 | 2019-05-28 | Cisco Technology, Inc. | Method and system for interest encryption in a content centric network |
US10043016B2 (en) | 2016-02-29 | 2018-08-07 | Cisco Technology, Inc. | Method and system for name encryption agreement in a content centric network |
US10742596B2 (en) | 2016-03-04 | 2020-08-11 | Cisco Technology, Inc. | Method and system for reducing a collision probability of hash-based names using a publisher identifier |
US10051071B2 (en) | 2016-03-04 | 2018-08-14 | Cisco Technology, Inc. | Method and system for collecting historical network information in a content centric network |
US10003507B2 (en) | 2016-03-04 | 2018-06-19 | Cisco Technology, Inc. | Transport session state protocol |
US10264099B2 (en) | 2016-03-07 | 2019-04-16 | Cisco Technology, Inc. | Method and system for content closures in a content centric network |
US10067948B2 (en) | 2016-03-18 | 2018-09-04 | Cisco Technology, Inc. | Data deduping in content centric networking manifests |
US10091330B2 (en) | 2016-03-23 | 2018-10-02 | Cisco Technology, Inc. | Interest scheduling by an information and data framework in a content centric network |
US10320760B2 (en) * | 2016-04-01 | 2019-06-11 | Cisco Technology, Inc. | Method and system for mutating and caching content in a content centric network |
US10348865B2 (en) | 2016-04-04 | 2019-07-09 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
US9930146B2 (en) | 2016-04-04 | 2018-03-27 | Cisco Technology, Inc. | System and method for compressing content centric networking messages |
US10425503B2 (en) | 2016-04-07 | 2019-09-24 | Cisco Technology, Inc. | Shared pending interest table in a content centric network |
US10693852B2 (en) | 2016-05-13 | 2020-06-23 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
US10404537B2 (en) | 2016-05-13 | 2019-09-03 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
US10063414B2 (en) | 2016-05-13 | 2018-08-28 | Cisco Technology, Inc. | Updating a transport stack in a content centric network |
US10084764B2 (en) | 2016-05-13 | 2018-09-25 | Cisco Technology, Inc. | System for a secure encryption proxy in a content centric network |
US10103989B2 (en) | 2016-06-13 | 2018-10-16 | Cisco Technology, Inc. | Content object return messages in a content centric network |
US10305865B2 (en) | 2016-06-21 | 2019-05-28 | Cisco Technology, Inc. | Permutation-based content encryption with manifests in a content centric network |
US10148572B2 (en) | 2016-06-27 | 2018-12-04 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
US10581741B2 (en) | 2016-06-27 | 2020-03-03 | Cisco Technology, Inc. | Method and system for interest groups in a content centric network |
US10009266B2 (en) | 2016-07-05 | 2018-06-26 | Cisco Technology, Inc. | Method and system for reference counted pending interest tables in a content centric network |
US9992097B2 (en) | 2016-07-11 | 2018-06-05 | Cisco Technology, Inc. | System and method for piggybacking routing information in interests in a content centric network |
US10122624B2 (en) | 2016-07-25 | 2018-11-06 | Cisco Technology, Inc. | System and method for ephemeral entries in a forwarding information base in a content centric network |
US10069729B2 (en) | 2016-08-08 | 2018-09-04 | Cisco Technology, Inc. | System and method for throttling traffic based on a forwarding information base in a content centric network |
US10956412B2 (en) | 2016-08-09 | 2021-03-23 | Cisco Technology, Inc. | Method and system for conjunctive normal form attribute matching in a content centric network |
US10033642B2 (en) | 2016-09-19 | 2018-07-24 | Cisco Technology, Inc. | System and method for making optimal routing decisions based on device-specific parameters in a content centric network |
US10897518B2 (en) | 2016-10-03 | 2021-01-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
US10212248B2 (en) | 2016-10-03 | 2019-02-19 | Cisco Technology, Inc. | Cache management on high availability routers in a content centric network |
US10447805B2 (en) | 2016-10-10 | 2019-10-15 | Cisco Technology, Inc. | Distributed consensus in a content centric network |
US10721332B2 (en) | 2016-10-31 | 2020-07-21 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
US10135948B2 (en) | 2016-10-31 | 2018-11-20 | Cisco Technology, Inc. | System and method for process migration in a content centric network |
US10243851B2 (en) | 2016-11-21 | 2019-03-26 | Cisco Technology, Inc. | System and method for forwarder connection information in a content centric network |
US11546153B2 (en) | 2017-03-22 | 2023-01-03 | Extrahop Networks, Inc. | Managing session secrets for continuous packet capture systems |
US11665207B2 (en) | 2017-10-25 | 2023-05-30 | Extrahop Networks, Inc. | Inline secret sharing |
US11463299B2 (en) | 2018-02-07 | 2022-10-04 | Extrahop Networks, Inc. | Ranking alerts based on network monitoring |
US11431744B2 (en) | 2018-02-09 | 2022-08-30 | Extrahop Networks, Inc. | Detection of denial of service attacks |
US11496378B2 (en) | 2018-08-09 | 2022-11-08 | Extrahop Networks, Inc. | Correlating causes and effects associated with network activity |
US11706233B2 (en) | 2019-05-28 | 2023-07-18 | Extrahop Networks, Inc. | Detecting injection attacks using passive network monitoring |
US11438247B2 (en) | 2019-08-05 | 2022-09-06 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11388072B2 (en) * | 2019-08-05 | 2022-07-12 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11652714B2 (en) | 2019-08-05 | 2023-05-16 | Extrahop Networks, Inc. | Correlating network traffic that crosses opaque endpoints |
US11463465B2 (en) | 2019-09-04 | 2022-10-04 | Extrahop Networks, Inc. | Automatic determination of user roles and asset types based on network monitoring |
US11310256B2 (en) | 2020-09-23 | 2022-04-19 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11558413B2 (en) | 2020-09-23 | 2023-01-17 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11463466B2 (en) | 2020-09-23 | 2022-10-04 | Extrahop Networks, Inc. | Monitoring encrypted network traffic |
US11349861B1 (en) | 2021-06-18 | 2022-05-31 | Extrahop Networks, Inc. | Identifying network entities based on beaconing activity |
US11916771B2 (en) | 2021-09-23 | 2024-02-27 | Extrahop Networks, Inc. | Combining passive network analysis and active probing |
US11843606B2 (en) | 2022-03-30 | 2023-12-12 | Extrahop Networks, Inc. | Detecting abnormal data access based on data similarity |
Also Published As
Publication number | Publication date |
---|---|
KR960012819A (en) | 1996-04-20 |
JPH0927804A (en) | 1997-01-28 |
DE69533953T2 (en) | 2006-04-06 |
EP0702477A2 (en) | 1996-03-20 |
DE69533953D1 (en) | 2005-03-03 |
KR100388606B1 (en) | 2003-11-05 |
EP0702477A3 (en) | 1999-07-28 |
EP0702477B1 (en) | 2005-01-26 |
US5548646A (en) | 1996-08-20 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
USRE39360E1 (en) | System for signatureless transmission and reception of data packets between computer networks | |
US20030037235A1 (en) | System for signatureless transmission and reception of data packets between computer networks | |
US5588060A (en) | Method and apparatus for a key-management scheme for internet protocols | |
US6026167A (en) | Method and apparatus for sending secure datagram multicasts | |
US6091820A (en) | Method and apparatus for achieving perfect forward secrecy in closed user groups | |
EP0693836A1 (en) | Method and apparatus for a key-management scheme for internet protocols. | |
US5416842A (en) | Method and apparatus for key-management scheme for use with internet protocols at site firewalls | |
US7509491B1 (en) | System and method for dynamic secured group communication | |
JP3816337B2 (en) | Security methods for transmission in telecommunications networks | |
US8700894B2 (en) | Method and system for securing routing information of a communication using identity-based encryption scheme | |
US6976177B2 (en) | Virtual private networks | |
US6240513B1 (en) | Network security device | |
US6038322A (en) | Group key distribution | |
JP3688830B2 (en) | Packet transfer method and packet processing apparatus | |
US7774594B2 (en) | Method and system for providing strong security in insecure networks | |
US6049878A (en) | Efficient, secure multicasting with global knowledge | |
CN100566285C (en) | Content delivering system | |
CN101103593B (en) | Method of authenticating multicast messages | |
US20080298592A1 (en) | Technique for changing group member reachability information | |
JP5144685B2 (en) | Signaling delegation in mobile networks | |
JP2003101523A (en) | Communication network system and communication method having concealment function | |
Lee | A survey on IPSec Key Management Protocols | |
WO2004039016A1 (en) | Data transmitting method and apparatus thereof | |
Calvert et al. | Secure, customizable, many-to-one communication | |
Delgrossi et al. | The design of supranet security mechanisms |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
FPAY | Fee payment |
Year of fee payment: 12 |