Link versus End-to-End Encryption
The most powerful and most common approach to securing the
points of vulnerability highlighted in the preceding section is encryption. If
encryption is to be used to counter these attacks, then we need to decide what
to encrypt and where the encryption gear should be located. As Figure 7.2 indicates, there are two fundamental
alternatives: link encryption and end-to-end encryption.
Basic Approaches
With link encryption, each vulnerable communications link is
equipped on both ends with an encryption device. Thus, all traffic over all
communications links is secured. Although this recourse requires a lot of
encryption devices in a large network, its value is clear. One of its
disadvantages is that the message must be decrypted each time it enters a switch
(such as a frame relay switch) because the switch must read the address (logical
connection number) in the packet header in order to route the frame. Thus, the
message is vulnerable at each switch. If working with a public network, the user
has no control over the security of the nodes.
Several implications of link encryption should be noted. For
this strategy to be effective, all the potential links in a path from source to
destination must use link encryption. Each pair of nodes that share a link
should share a unique key, with a different key used on each link. Thus, many
keys must be provided.
With end-to-end encryption, the encryption process is carried
out at the two end systems. The source host or terminal encrypts the data. The
data in encrypted form are then transmitted unaltered across the network to the
destination terminal or host. The destination shares a key with the source and
so is able to decrypt the data. This plan seems to secure the transmission
against attacks on the network links or switches. Thus, end-to-end encryption
relieves the end user of concerns about the degree of security of networks and
links that support the communication. There is, however, still a weak spot.
Consider the following situation. A host connects to a frame
relay or ATM network, sets up a logical connection to another host, and is
prepared to transfer data to that other host by using end-to-end encryption.
Data are transmitted over such a network in the form of packets that consist of
a header and some user data. What part of each packet will the host encrypt?
Suppose that the host encrypts the entire packet, including the header. This will not
work because, remember, only the other host can perform the decryption. The
frame relay or ATM switch will receive an encrypted packet and be unable to read
the header. Therefore, it will not be able to route the packet. It follows that
the host may encrypt only the user data portion of the packet and must leave the
header in the clear.
Thus, with end-to-end encryption, the user data are secure.
However, the traffic pattern is not, because packet headers are transmitted in
the clear. On the other hand, end-to-end encryption does provide a degree of
authentication. If two end systems share an encryption key, then a recipient is
assured that any message that it receives comes from the alleged sender, because
only that sender shares the relevant key. Such authentication is not inherent in
a link encryption scheme.
To achieve greater security, both link and end-to-end
encryption are needed, as is shown in Figure
7.2. When both forms of encryption are employed, the host encrypts the user
data portion of a packet using an end-to-end encryption key. The entire packet
is then encrypted using a link encryption key. As the packet traverses the
network, each switch decrypts the packet, using a link encryption key to read
the header, and then encrypts the entire packet again for sending it out on the
next link. Now the entire packet is secure except for the time that the packet
is actually in the memory of a packet switch, at which time the packet header is
in the clear.
Table 7.1 summarizes
the key characteristics of the two encryption strategies.
|
Link Encryption
|
End-to-End Encryption
|
|---|---|
|
Security within End Systems and
Intermediate Systems
| |
|
Message exposed in sending host
|
Message encrypted in sending host
|
|
Message exposed in intermediate nodes
|
Message encrypted in intermediate nodes
|
|
Role of User
| |
|
Applied by sending host
|
Applied by sending process
|
|
Transparent to user
|
User applies encryption
|
|
Host maintains encryption facility
|
User must determine algorithm
|
|
One facility for all users
|
Users selects encryption scheme
|
|
Can be done in hardware
|
Software implementation
|
|
All or no messages encrypted
|
User chooses to encrypt, or not, for each message
|
|
Implementation
Concerns
| |
|
Requires one key per (host-intermediate node) pair and
(intermediate node-intermediate node) pair
|
Requires one key per user pair
|
|
Provides host authentication
|
Provides user
authentication
|
Logical Placement of End-to-End Encryption Function
With link encryption, the encryption function is performed at a
low level of the communications hierarchy. In terms of the Open Systems
Interconnection (OSI) model, link encryption occurs at either the physical or
link layers.
For end-to-end encryption, several choices are possible for
the logical placement of the encryption function. At the lowest practical level,
the encryption function could be performed at the network layer. Thus, for
example, encryption could be associated with the frame relay or ATM protocol, so
that the user data portion of all frames or ATM cells is encrypted.
With network-layer encryption, the number of identifiable and
separately protected entities corresponds to the number of end systems in the
network. Each end system can engage in an encrypted exchange with another end
system if the two share a secret key. All the user processes and applications
within each end system would employ the same encryption scheme with the same key
to reach a particular target end system. With this arrangement, it might be
desirable to off-load the encryption function to some sort of front-end
processor (typically a communications board in the end system).
Figure 7.3 shows the
encryption function of the front-end processor (FEP). On the host side, the FEP
accepts packets. The user data portion of the packet is encrypted, while the
packet header bypasses the encryption process.[1] The resulting packet is delivered to
the network. In the opposite direction, for packets arriving from the network,
the user data portion is decrypted and the entire packet is delivered to the
host. If the transport layer functionality (e.g., TCP) is implemented in the
front end, then the transport-layer header would also be left in the clear and
the user data portion of the transport protocol data unit is encrypted.
Deployment of encryption services on end-to-end protocols, such
as a network-layer frame relay or TCP, provides end-to-end security for traffic
within a fully integrated internetwork. However, such a scheme cannot deliver
the necessary service for traffic that crosses internetwork boundaries, such as
electronic mail, electronic data interchange (EDI), and file transfers.
Figure 7.4 illustrates
the issues involved. In this example, an electronic mail gateway is used to
interconnect an internetwork that uses an OSI-based architecture with one that uses a TCP/IP-based
architecture.[2] In such a configuration, there is no end-to-end
protocol below the application layer. The transport and network connections from
each end system terminate at the mail gateway, which sets up new transport and
network connections to link to the other end system. Furthermore, such a
scenario is not limited to the case of a gateway between two different
architectures. Even if both end systems use TCP/IP or OSI, there are plenty of
instances in actual configurations in which mail gateways sit between otherwise
isolated internetworks. Thus, for applications like electronic mail that have a
store-and-forward capability, the only place to achieve end-to-end encryption is
at the application layer.
No comments:
Post a Comment