▶ 13.1 Communications Security
Earlier in the text, we focused on protecting information by keeping threats away from our network. If we connect our network with the internet, we firewall the connection to try to exclude internet-based threats—but this doesn’t help us when we need to transfer information between internet sites. The data leaves our control, so we need cryptography to protect it.
This is the traditional purpose of encryption: to protect data in motion. Although we introduced encryption in Chapter 7 as a way to protect diaries or copyrighted materials, most of cryptography’s history applies to communications security. Julius Caesar created his cipher to protect military dispatches from being read by enemies. The first large-scale application of DES was to protect financial transactions on early computer networks.
Modern mobile systems rely extensively on cryptography for security. The original cell phone systems faced two particularly troublesome attack vectors. First, the systems delivered voice traffic over analog radio channels. Owners of analog “radio scanners” could sometimes intercept and listen to analog cell channels.
The second vector was the “cloned” cell phone. Like today, each phone contained a unique identifier, and the cell service associated the identifier with a paying customer. The identifier was transmitted when setting up a cell phone call, and the service charged the owner for the call. As cell phones became more popular and dropped in price, criminals developed techniques to “clone” a phone’s identifier. This yielded two or more new phones with the same identifier. Services used by the new phones were charged to the original phone’s owner, not to the actual owner.
Mobile phone systems blocked these attack vectors as they converted from analog to digital technology. Digital voice channels were encrypted, eliminating simple eavesdropping. Cryptographic authentication techniques, like those described in Section 12.5, replaced the easy-to-clone cell phone identifiers.
In earlier chapters, Alice and Bob shared files on a single computer or by copying files onto a shared USB drive. With a network, Alice and Bob can sit on their own computers and send data directly back and forth. After an unexpected stop at a coffee shop, Bob owes Alice $5. To remind him, Alice emails Bob the following message:
Dear Bob,
Pay me $5.
Alice
FIGURE 13.1 shows the message being sent to Bob’s computer from Alice. Their friend Eve continues to be curious about other people’s business. She also knows enough about networking to intercept a copy of Alice’s message. In the best case, such behavior is rude and annoying. In the worst case, the network opens Alice or Bob up to trouble.
FIGURE 13.1 A passive attack on an unprotected network message.
There are six general types of attacks in terms of networks. (See Section 10.1.1.) This attack is a disclosure: Eve has intercepted private information. The attacker simply reads the data without interference. Because Eve just eavesdropped without interfering with communications, we call this a passive attack.
In some cases, disclosure poses no risk. In this case, the message tells nothing salacious or secret about Bob or Alice. The eavesdropping represents a security incident, if not an attack.
However, Eve is curious about how Bob reacts to messages like this. Eve constructs a message to Bob telling him to pay her $5 (FIGURE 13.2). Although we would call eavesdropping a passive attack, this is clearly an active attack: a network attack in which she forges network traffic. Active attacks may be forgeries or masquerades. If Eve simply pretends to be Alice and takes Alice’s $5, then it is a masquerade.
FIGURE 13.2 An active attack on Bob.
Bob might not be foolish enough to respond to Eve’s message. Alice’s message was just a reminder of something Bob already knew. Eve’s message suggests that Bob borrowed money and forgot entirely. Bob ignores the message because he knows it’s bogus.
Many network messages pass between computer hardware and programs, not between people. Programs are relatively easy to trick, because they know nothing beyond what their inputs tell them.
Imagine what happens if Bob installs a simple cash dispenser on his computer. This allows him to pay people back without actually being present. Alice sends her message, and the computer counts out $5 as requested; then Eve sends her message. How do we keep the dispenser from paying her, too? This is the real forgery problem.
Cryptographic Protections
We use cryptography to apply the following protections to network traffic:
■ Confidentiality
■ Integrity
■ Authenticity
■ Nonrepudiation
Crypto techniques originally focused on confidentiality: We kept data secret by encrypting it. Secrecy also may provide a weak type of integrity protection; attackers can’t change a message’s text reliably without knowing the message’s contents already. An attacker who knows the message’s contents can modify its contents if we used a stream cipher to protect it. We saw this in Chapter 7.
The remaining three protections don’t actually prevent attackers from damaging a packet. Instead, they give us a way to detect such damage. Secret-key techniques allow us to verify data integrity. This, in turn, gives us some evidence that the data is authentic. We use public-key techniques to unambiguously authenticate a message and associate it with a particular person or entity. Public-key techniques also provide a degree of nonrepudiation: If the message is signed by the entity’s public key, then it is hard for the entity to repudiate the message—that is, to deny having produced the signed data.
Some researchers have proposed ways to block certain denial of service attacks using puzzles or other crypto-like techniques. These may show promise in the future, although none of them are used widely today.
13.1.1 Crypto by Layers
We saw how firewalls handle traffic in terms of protocol layers (see Section 12.4). Although this is easy to do at lower layers, the firewall must reconstruct parts of the protocol when interpreting a TCP connection or examining application-level data items. It’s hard to scan an email message for viruses without reconstructing the entire message.
Network cryptography also works in relation to protocol layers. We get very different kinds of protection, depending on where we apply encryption or verify authenticity within the protocol stack. Today’s internet products provide cryptography at several different layers of the stack, as shown in FIGURE 13.3.
FIGURE 13.3 Adding cryptography to internet software.
When we place crypto in different protocol layers, we often balance two important properties: application transparency and network transparency. If the crypto is “transparent to the application,” we can add—or omit—the crypto without making any changes to the application software. Thus, we easily can add encryption without changing the application. When crypto is “transparent to the network,” the encrypted traffic may be sent across the internet. Thus, we can apply our protections and still transmit the data. Some protocols achieve one but not the other, while some achieve both.
Link Layer Encryption and 802.11 Wireless
Traditionally, someone who tried to protect a communications line used link encryption, which protects point-to-point data links or broadcasts to an exclusive cryptonet. Because it applies protection at the link layer, it is application transparent, and it encrypts everything on the link. This was popular in the pre-internet era, when networked sites often used leased lines. The two endpoints either belonged to the same organization or they had a close relationship, so they trusted each other with encryption keys.
Even though few sites use classic link encryption today, many devices use encryption at the link layer: They encrypt their wireless LAN. As the data link gets more sophisticated, there needs to be control information to manage the encryption. Some of this is essentially plaintext, because it tells the recipient how to decrypt the data. This is true especially for traffic on an 802.11 wireless network. FIGURE 13.4 illustrates the packet format for encrypted 802.11 data.
FIGURE 13.4 A packet with 802.11 link encryption.
Since the introduction of 802.11 products in the late 1990s, a series of security protocols have been developed. Earlier protocols were not effective against clever attacks on their cryptography. The typical protocol today, Wi-Fi Protected Access, version 2 (WPA2), has resisted those attacks, partly by using AES encryption. WPA2 protects the traffic as it travels over the air between the laptop or other wireless host and the network base station. WPA2 is not without vulnerabilities: A set of attacks named Key Reinstallation Attack (KRACK) can exploit weaknesses in the protocol. One set of attacks can trick a connection into reusing a crypto key, making possible the attack described in Section 8.2. Security updates have addressed many of the KRACK-related attack vectors.
Link layer encryption techniques, including both link encryptors and WPA2, do not provide network transparency. When a packet destined for the internet arrives at a wireless gateway or link endpoint, the device strips off the encryption and forwards the packet to its destination. If the encryption were left in place, the routers could not interpret the IP header and route the packet. We look at wireless encryption further in Section 13.5.
Network Layer Encryption and IPsec
When a company needed to connect LANs at two separate sites, the initial solution was to lease a point-to-point network link between them. Sites couldn’t connect across the internet because link-level encryption would encrypt the whole packet, including the IP addresses. The only way we can route a packet through protocol stacks is if the appropriate packet headers remain in plaintext.
The IP Security Protocol was introduced in the mid-1990s to solve this problem. The internet community generally abbreviates the name as IPsec (pronounced I-P-seck). FIGURE 13.5 shows how IPsec cryptography is applied to a packet.
FIGURE 13.5 A packet with IPsec protection.
IPsec encryption leaves the link and IP headers in plaintext. The IPsec header provides the information needed to decrypt the packet at the other end. Everything normally following an IP header is encrypted, including the TCP/UDP header and the application data. The IPsec header also contains an integrity check on the IP header contents.
IPsec allows two sites to establish an encrypted connection across the internet through which they may exchange packets securely. This is called a virtual private network (VPN). Some sites also use IPsec to provide a secure connection to workers at home or traveling with laptops. When a computer connects through the VPN, it can see the same network as those physically inside the organization. Sites often implement VPNs by installing encrypting gateways. This off-loads the encryption from most hosts on-site. Traveling laptops still must perform their own IPsec crypto to connect through a site gateway.
IPsec achieves both application transparency and network transparency. Any or all internet application software traffic may be encrypted with IPsec, without making any changes to the applications. Because the encryption leaves the IP header in plaintext, the encrypted packets are handled normally by internet routers.
Although this may seem like the best of both worlds, a problem remains: Neither the applications nor the users can necessarily tell whether or not messages will be protected. This is especially true in sites that use encrypting gateways. Sites often configure specific types of traffic to be encrypted and leave the rest in plaintext. This allows users to exchange IPsec traffic with particular destinations, usually other sites within the organization. The remaining internet traffic, which is probably directed at public internet servers, does not use IPsec because that would not allow connections to public servers.
We look at IPsec further in Section 13.4.
Socket Layer Encryption with SSL/TLS
Socket layer encryption appears outside the OS boundary. It is not part of the operating system, the hardware, or the standard protocol stack shown in Figure 13.3. It is most often part of a networking application, usually a browser. This makes the crypto software much easier to implement and deploy, although it requires modifying the application. We give up application transparency, but we achieve network transparency. The software may also clearly indicate to the user whether or not encryption is being used.
Socket layer encryption is traditionally called Secure Sockets Layer (SSL), although the modern version of the protocol is named Transport Layer Security (TLS). The official SSL protocol is no longer supported, and modern products implement TLS. Despite this, people still refer to the protocol by its traditional acronym, SSL.
We first encountered the socket interface in Section 11.3. The interface resides between the TCP/UDP layer and the applications. Because SSL encrypts the data before it reaches TCP/UDP, the network protocol stack treats it as any other application data: It breaks the data into packets, addresses it with IP and port numbers, and sends it on its way. The receiving host relays the encrypted data to the application indicated by the port number. The receiving host’s protocol stack doesn’t even pay attention to the fact that the data is encrypted. FIGURE 13.6 illustrates the packet layout used with SSL encryption.
FIGURE 13.6 A packet with SSL encryption.
This is the protocol that usually protects secure web applications. It was developed in 1994 and originally distributed by Netscape Communications, the first company to make serious money out of a commercial crypto product. Netscape produced two products: The Navigator was a browser, and the Commerce Server was a web server. These two products introduced SSL.
If Alice visits a website to buy a book, most of her browsing takes place without encryption. When it’s actually time to pay for the book, the site redirects her to a web page protected with SSL. Such pages have HTTPS (Hypertext Transfer Protocol Secure) as the URL prefix.
SSL was originally a commercial product of Netscape; when the IETF started work on an internet standard for transport encryption, it adopted the new name and acronym, TLS. Although many people use the terms SSL and TLS interchangeably, the up-to-date protocol is TLS.
Application Layer Encryption with S/MIME or PGP
Arguably, application layer encryption is even older than link encryption: When people first sent encrypted telegrams, they encrypted the message before bringing it to the telegraph office. Telegraph codes date back to the 1800s; Gilbert Vernam produced link encryption for teletypes in the 1920s. Internet email protocols emerged in the late 1980s, before network encryption flourished.
There are many ways to apply encryption at the application level. SSL provides a form of application encryption because the developers usually bundle the SSL software with the application. However, SSL generally appears at the very bottom of the application protocol, right at the socket interface. True application layer encryption interacts with the end user. We call this end-to-end crypto. The application performs the crypto operations at the top of the application layer or above the protocol stack. This clearly shows the end user whether an individual message or transaction carries crypto protection.
In end-to-end crypto, the actual sender applies the protection and the actual recipient decrypts the message and verifies the digital signature. Applications rely on personal cryptographic keys, while lower-layer crypto uses host-related or network node-related keys.
End-to-end crypto for email, like SSL, sacrifices application transparency for network transparency. Unlike SSL, there may be plaintext application headers that coordinate the handling of the encrypted data (FIGURE 13.7).
FIGURE 13.7 A packet with end-to-end crypto.
A common attack vector in many cryptosystems, and especially in end-to-end systems, is through metadata, the networking data carried with the encrypted content. Although eavesdroppers can’t read encrypted messages, they might identify the sender and recipient from the packets carrying the messages. This is called “traffic analysis” in military circles. For example, a whistleblower might leak documents to a journalist. Even if investigators can’t read the encrypted messages, phone call or message routing data might identify the person communicating with the journalist.
Layer-Oriented Variations
Because the different layers encrypt different parts of the packet, they achieve different results. Here is a summary of essential differences. We will examine them further in later sections.
■ Which protocols actually use this technique?
■ Where in the network and/or protocol stack is the plaintext visible?
■ Is the encryption transparent to the application?
■ Is the encryption transparent to the network, and to what extent? In other words, how much addressing information remains in plaintext?
■ Where do the working keys reside?
■ How are working keys updated?
■ To what degree can we identify or authenticate the source of the packets retrieved from an encrypted connection?
The technical elements noted here may vary from layer to layer and from one crypto algorithm to another. Modern crypto protocols often allow the hosts to choose which crypto algorithms to use for key exchange, authentication, integrity protection, or encryption. The protocols often provide a list of choices called cipher suites. Each cipher suite provides a set of algorithms, protocols, and modes that together implement a set of security services. Here are examples:
■ Cipher suites in SSL allow the choice of RSA or Diffie–Hellman for key exchange; some still support RC4 encryption, and more recent suites support AES.
■ Cipher suites for wireless LAN encryption allow the choice of RC4 in three weak alternatives or AES with a strong encryption and integrity-protecting mode.
We need to choose our crypto solutions depending on what we need for communication and security. The next section reviews some fundamental administrative and policy issues.
13.1.2 Administrative and Policy Issues
The end of the previous section summarized various technical features of different cryptographic protocols. In practice, however, our security decisions depend on what we’re trying to achieve, not on technical features by themselves.
There are six basic issues we need to address when deploying cryptography on the internet. Some have to do with protection and control, while others have to do with the difficulties of deployment. Here they are:
Scope of sniffing protection: If we use this type of encryption, how thoroughly does it protect the traffic from sniffing?
Traffic filtering: Some environments analyze incoming and outgoing traffic for potential security risks. Encryption interferes with filtering.
Automatic encryption: If we use this type of encryption, must the users activate it, or can it take place automatically?
Access to internet sites: Can we use the encryption to block user access to internet sites?
End-to-end crypto: Is the encryption associated with the end users, instead of the host computers or networks?
Keying: Do end users have to manage keys?
Now we talk about each one.
Sniffing Protection
We clearly need to use encryption if we wish to protect against sniffing. Different protocols protect our traffic in different environments. 802.11 wireless encryption protects the wireless transmissions on our LAN, but the gateway removes the encryption before forwarding the data to the internet. We need to apply encryption at higher protocol levels to protect traffic as it crosses the internet.
There is, however, a benefit to encrypting as many packet headers as possible: It defeats traffic analysis. Attackers rely on traffic analysis when the defenders use encryption that is too difficult to attack. Instead of focusing on message contents, the attackers focus on whatever other traffic properties are visible. Often the attackers can identify the traffic senders and recipients. This, by itself, may provide significant information. In practice, however, few defenders specifically try to defeat traffic analysis, except some in military and intelligence circles.
Traffic Filtering
Encryption works against traffic filtering. If the packet is encrypted, the filtering process can’t possibly identify sensitive or malicious contents. Some sites that implement both encryption and traffic filtering have configured the filters to decrypt the data, apply the filters, and then forward the data if it passes inspection. This is difficult and poses serious key-management headaches.
Automatic Encryption
People can be very careless about using encryption. Although most employees strive to fulfill their responsibilities in both letter and spirit, encryption is a security measure that many don’t understand. Forgetting encryption isn’t a security lapse akin to an open door or window. We rarely see the problem; it is an invisible weakness, like a defective burglar alarm.
This makes it easy for people to forget encryption; it’s a step that seems to just slow things down. Communications seem faster, easier, and more reliable without encryption, so there is a strong inducement to omit it.
This is why many applications try to apply encryption automatically. Websites activate encryption automatically when needed to protect an e-commerce transaction. Some enterprise sites automatically encrypt data flowing to other enterprise sites. However, it’s not always practical to enable automatic encryption, because it may interfere with other essential, though unencrypted, communications.
Internet Site Access
When the system applies encryption automatically, we don’t have to worry about forgetting to encrypt important information. On the other hand, if the system always applies encryption and decryption, we can’t communicate with hosts or users who aren’t part of the same cryptonet or who don’t share the same encryption mechanism. If we automatically encrypt all internet traffic, we can’t communicate with public internet sites, which don’t necessarily use encryption.
End-to-End Crypto
As explained earlier, end-to-end crypto places the security measures in the hands of the sender and recipient. We achieve greater certainty when the end users apply the security measures or validate them through their own direct actions.
Policies should call for end-to-end crypto when we send messages that require clear and reliable accountability. In an end-to-end system, the sender can apply a digital signature and also can apply encryption that only specific recipients can decrypt. This ensures that we clearly and reliably identify the message’s author. It also ensures that only the authorized recipients may retrieve the message’s contents.
End-to-end message authentication may provide nonrepudiation, that is, provide strong evidence that a particular user did indeed write a particular message. It is hard for Eve to deny sending a message if it contains her digital signature. Nonrepudiation is one of the generic security services introduced in Section 2.6.
End-to-end crypto is also preferred when sending secret information to a small number of specific individuals. The message is less likely to leak if the intended recipients must specifically decrypt the message themselves. A message is more likely to leak if it is decrypted automatically by protocol software.
Keying
The fundamental challenge of any cryptosystem is to create and distribute the keys safely and reliably. In practice, end users hate to handle and manage keys. Passwords are keys, for most practical purposes, and people are notoriously bad at managing passwords. Successful systems put as little keying burden as possible on end users. Before we review different crypto implementations, we will review basic techniques for sharing crypto keys on a network.