 |
Claims  |
|
|
What is claimed is:
1. 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 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 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 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 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 enapsulation header, including:
(a) key management information identifying the predetermined encryption
method, and
(b) a new address header representing the source and destination for the
data packet,
thereby generating a modified data packet;
(5) transmitting the data packet from the first bridge computer via the
internetwork to the second computer network;
(6) intercepting the data packet at the second bridge computer;
(7) in the second bridge computer, reading the encapsulation header, and
determining therefrom whether the data packet was encrypted, and if not,
proceeding to step 10, and if so, proceeding to step 8;
(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 data packet at the second host computer.
2. The method of claim 1, wherein the new address header for the modified
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
data packet includes an identifier of the second bridge computer.
4. The method of claim 1, wherein the new address header of the modified
data packet includes the address of the second host computer.
5. The method of claim 4, wherein the new address header for the modified
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 host to said second host;
a 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 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 first data packet, thereby
generating a modified first data packet, and transmitting said modified
data packet on to the second host computer;
instructions stored in said second memory for intercepting said first data
packet upon arrival at said second network, determining whether said
correlation is present in said 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, wherein said new address header includes the
internetwork broadcast addresses of the first and second computer
networks.
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 computers including
a processor and a memory for storing instructions for execution by the
processor, each said memory storing at least one 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 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 data packet
including information representing an internetwork address of a source of
the packet and an internetwork address of a destination of the 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 first data
packet an enapsulation header, including:
(a) key management information identifying the predetermined encryption
method, and
(b) a new address header identifying the source and destination for the
data packet,
thereby generating a modified data packet;
(5) transmitting the data packet from the first host computer via the
internetwork to the second computer network;
(6) in the second host computer, reading the encapsulation header, and
determining therefrom whether the data packet was encrypted, and if not,
ending the method, and if so, 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
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 processor and a first memory, via an internetwork to a
second host computer on a second computer network and having a second
processor and a second memory, the system including:
security data stored said first and 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
data packets, by determining whether said predetermined criterion is met
by said data packet;
instructions stored in said first memory for executing encryption according
to said predetermined encryption/decryption mechanism of at least a first
said data packet, when said 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 at least said new
address header;
instructions stored in said second memory for receiving said first data
packet, determining whether it has been encrypted by reference to said
security data, and if so then determining which encryption/decryption
mechanism was used for encryption, and decrypting said 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 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;
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 and appending said new address
header to said first data packet, thereby generating a modified first data
packet, and transmitting said 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 including a processor and a memory for storing
instructions for execution by the processor, 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 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 enapsulation header, including:
(a) key management information identifying the predetermined encryption
method, and
(b) a new address header representing the source and destination for the
data packet,
thereby generating a modified data packet; and
(5) transmitting the data packet from the first bridge computer via the
internetwork to the second computer network. |
|
 |
|
 |
Claims |
|
|
|
Description |
|
|
BACKGROUND OF THE INVENTION
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.
FIG. 1 illustrates a network of computer networks, including networks N1,
N2 and N3 interconnected via a public network 10 (such as the Internet).
When network N1 is designed in conventional fashion, it includes several
to many computers (hosts), such as host A and additional hosts 20 and 30.
Likewise, network N2 includes host B and additional hosts 40 and 50, while
network N3 includes hosts 60-90. There may be many hosts on each network,
and many more individual networks than shown here.
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 packet 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 recipient (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.
SUMMARY OF THE INVENTION
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 tunneling 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.
BRIEF DESCRIPTION OF THE DRAWINGS
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 N1 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 N1-N3 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.
DESCRIPTION OF THE PREFERRED EMBODIMENTS
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 N1, N2 and N3 according to the
invention, where each network includes a tunneling bridge--TB1, TB2 and
TB3, respectively--which intercepts all data packets from or to the
respective networks. Networks N1-N3 may in other respects be identical to
networks N1-N3 in conventional designs. In the following description, any
references to networks N1-N3 or hosts A and B should be taken as referring
to the configuration shown in FIG. 3, unless specified otherwise.
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.
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. In the case of transmissions over the
Internet, this will be the IP header. Though 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.
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 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) of 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 section 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.
The Encapsulation Header
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 instructions,
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 host 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 specifics 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 a 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 (see 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.
APPENDIX A
Simple Key-Management For Internet Protocols (SKIP) Abstract
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.
1.0 Overview
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.
2.0 Simple Key-Management for Internet Protocols (SKIP)
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 p | | |
