|
This paper outlines the benefits and uses of encryption and highlights the added value of Cisco Systems' Cisco IOS software network-layer encryption. It gives an overview of the technologies that enable this feature, including the Data Encryption Standard (DES), Diffie-Hellman key exchange, and the Digital Signature Standard (DSS). It explains the importance of key secrecy and shows how the Cisco IOS software ensures it. The paper also explains where encryption can be implemented in a network and presents some performance guidelines and specifics for each platform. It then explains design issues and provides sample configurations.
Many organizations are wary about transmitting sensitive data over networks. Hospitals transmit sensitive patient information to insurance companies. Banks and stock exchange companies transfer vital financial information over networks. There is a valid fear that this data could be viewed or altered in transit or used by malicious people to harm patients, create lawsuits, or defraud corporations. People want these kinds of data communication to remain private. Almost every company has transactions which, if viewed by an eavesdropper, could have negative consequences. Companies want to ensure that when sensitive data passes over a medium susceptible to eavesdropping, it cannot be altered or observed. Data encryption is designed to protect sensitive data.
Cisco's implementation of network-layer encryption lets a network manager smoothly integrate the security of encryption into a network. The integration is transparent to end users and their applications, as well as to all intermediate routers, other network media, and devices. Encryption need only happen at the edge of the network on the LAN where the sensitive data originates, and decryption is not necessary until the data reaches the router on the far LAN where the destination host resides. Network Managers retain the option of encrypting anywhere in the data path. By encrypting after the User Datagram Protocol (UDP) or TCP headers so that only the IP payload is encrypted, Cisco IOS network-layer encryption allows all intermediate routers and switches to forward the traffic as they would any other IP packets. This payload-only encryption allows flow switching and all access-list features to work with the encrypted traffic just as they would with plain text traffic, thereby preserving desired quality of service (QoS) for all data. Users can send encrypted data over the Internet transparently.
Network administrators have the choice of implementing encryption in data communications at one of three layers of the Open Systems Interconnection (OSI) model: the application, the data link, or the network layers. Figure 1 shows the three OSI layer options for encryption. There are advantages to placing this function at any one of these three layers, but at different costs.
To use application-layer encryption, each application on a host that is generating sensitive data needs to be upgraded to support encryption. All hosts with which that application communicates must speak the same encryption language, even if they reside on different platforms.
Data link-layer encryption can be implemented in devices outside of the router on sensitive links, but users must decrypt the traffic before it enters the router. This process must be repeated on every link where security is a concern. Because this method does not leave IP addresses in the clear for routing, decryption and reencryption may need to occur several times, leading to increased delay in the network, and possibly compromising security, since these routers need to be trusted with clear text.
Network-layer encryption can be done anywhere in the network, and it can be implemented on all traffic without upgrading all of the host applications. It also leaves pertinent Layer 3 and 4 information in the clear for use in routing. So while adding to the overall security throughout the network, users continue to enable QoS end to end.
Several U.S. government agencies and regulations control the export of encryption hardware and software. Cryptography is considered to be a munition and, as such, is subject to very strict export rules. Currently, Cisco can export 56-bit and 40-bit DES with little restriction. However, it is important to keep abreast of current regulations to avoid being personally charged in an international arms-smuggling prosecution. Direct questions about export regulation via e-mail to export@cisco.com. Many other countries have similar import laws, so it is important to be aware of local regulations too.
Cryptography is a technology that helps ensure that private communications remain private. The essence of cryptography is the use of an algorithm to combine a key with clear text (which is unencrypted data) in order to change it into a series of seemingly random bits. This encrypted data, or ciphertext, can then be transmitted via whatever means available and subsequently decrypted on the receiving side, where it becomes meaningful data again. The random bits, or ciphertext, are meaningless to an eavesdropper attempting to discover what the transmission is, or possibly worse, attempting to change the contents of the data to alter its meaning.
Many different algorithms are used to encrypt data. They range from very secure to totally insecure, and from very practical to very impractical. An algorithm that has been a standard for over 20 years and that is known to be secure and practical is DES. This algorithm was reviewed by the National Security Agency (NSA) in the early 1970s and has been used by the U.S. government ever since. DES is widely used in both hardware and software encryption today. For all of these reasons, as well as the fact that DES is faster than the competing algorithm, Rivest-Shamir-Adelman (RSA), DES was the algorithm chosen for Cisco's network-layer encryption. Also, because it is global, it can be exported, with restriction, allowing interoperation between corporate partners residing in different parts of the world.
The most important thing about a cryptographic algorithm is its security against being compromised. The security of a cryptosystem, that is, the degree of difficulty for an attacker to figure out the contents of the ciphertext, is a function of a few variables. In most protocols, the cornerstone to security lies in the secrecy of the key used to encrypt data. The DES algorithm is built so that it is too difficult for anyone to be able to determine the clear text without having this key. Therefore, in any cryptosystem, great lengths are taken to protect the secrecy of the encryption key. Cisco recognizes the importance of key secrecy; therefore, two of the three algorithms in the cryptosystem that the Cisco IOS software employs have more to do with key distribution and secrecy than with the actual encryption of data.
After two routers obtain their shared secret key, they can use it to communicate with each other using the DES encryption algorithm. Key length is a factor, because it is more difficult to guess more digits than less. Even DES encrypted data can be decrypted by an attacker, given enough computing power and time dedicated to finding the key. Estimates as to the amount of time and money required for such an attack vary, but it is certainly no small undertaking. If a key were to be discovered, every packet that was encrypted with that key would easily be decrypted by the attacker. Frequently changing session keys makes it less likely that attackers could decrypt the data, because there is less ammunition for a key attack and less to be gained if a key were to be discovered.
Many standards have emerged to protect the secrecy of keys and to facilitate the changing of these keys. One of these, DSS, uses a public/private key system to ensure the identity of another party and also to prove a user's own identity when communicating via electronic means. Diffie-Hellman is used to do key exchange without exchanging keys. This is the most well-known and widely used algorithm for establishing session keys to encrypt data. DES, DSS, and Diffie-Hellman are integral parts of the Cisco IOS Release 11.2 network-layer encryption.
The Internet Engineering Task Force (IETF) has also developed standards for IP encryption. The IP security (IPSec) protocol is discussed in RFC 1825, with more detailed information on the different modes in RFCs 1826 to 1829 as well as in several newer drafts. The key management standard that the Internet community will most likely select is Internet Security Association Key Management Protocol (ISAKMP), which works with the IPSec encryption and authentication protocols. For further information on IPSec and ISAKMP/Oakley, see the indicated RFCs and the IPSec drafts on the IETF Web site (www.ietf.org). Cisco will be integrating support for the IPsec protocols as well as ISAKMP/Oakley in the next major release of the Cisco IOS software. This paper describes Cisco's current encryption algorithm. When Cisco IOS software begins support for IPSec, users will be able to migrate to this new technology from Cisco's current encryption technology.
To better understand the security and operation of Cisco's encryption system, the following sections explain the three different security algorithms, DSS, Diffie-Hellman, and DES, and show how they complement one another. The routers use DSS to ensure that each router is speaking to a trusted peer when generating a session key for encryption. DSS prevents a "man in the middle" from intercepting the transmission of a valid peer and substituting his own. After this process is in place, Diffie-Hellman is used to securely generate a session key for DES encryption.
DES encryption requires the encrypting and decrypting parties to share a secret key. Before the parties can safely and securely agree on a shared secret key, they need to be sure of the other party's identity. This action is done in the world of electronic security with DSS. Simply put, DSS verifies the identity of a person or a computer with whom a user is communicating electronically, just like a signature verifies the identity of a check. DSS uses the concept of a public key/private key pair. The public key is derived from the private key by a one-way transform. Each user or device has a public key (which is known by everyone who wants to communicate with that user) and a private key. It is computationally infeasible to determine the private key from the public key. The algorithm relies on a "hash function" to verify the authenticity of the data sent. A hash function is a way of taking a message's "fingerprint." The idea is that if two fingerprints match, the message has not been altered. The hash is then run through a function that uses the private key to "sign" the message. The values are reversible only if someone has the public key. The other party then runs the same hash and verifies the signature to ensure the identity and content of the message. (Figure 2 shows this function.) This method is a very secure way of exchanging data, because the other person's identity is verified by that person's possession of the private key, which is authenticated the person's public key. All users keep their private key secret but share the public key with everyone who might want to communicate with them. Ideally, these public keys would be held in a known and trusted repository such as a Certification Authority (CA).
The following example explains how the protocol works in practice. Alice performs a hash of a message that she is sending to Bob. She then signs the message by encrypting the hash using her private key. When Bob gets the message, he first unsigns the message to reveal Alice's hash. Then Bob performs the same hash and ensures that the encrypted value matches his hash of the message. This assures the pair that they are speaking to one another and that the contents of the message have not been altered.
While using DSS to ensure the identity of a peer for establishment of the session key, users need a way to generate this key. Because it is very important that this key remain secret, key exchange must ensure that a third party cannot determine the session key, even if the exchange takes place over what is suspected to be an insecure link—generally the link currently in use. There are algorithms designed for just this purpose. The protocol that Cisco selected to do key exchange is Diffie-Hellman, which is one of the oldest, most trusted, and most used key-exchange methods. It is very secure, because at no time is the key actually transmitted, (transmission would allow it to be viewed by a third party), nor can a third party determine the key. Diffie-Hellman prevents key interception by using two known prime numbers (for example, n and g). These shared numbers have a special mathematical relationship to one another that makes it possible to agree on a shared secret key and makes it impossible for eavesdroppers to determine what this secret key is, even if they know the shared primes. Here is how it basically works:
n1 = prime number, g1 = a primitive root of n
User a chooses a large random integer, A, and user b chooses his own large random number, B
Each user can now calculate the shared secret key (K) by raising the received number to his own secret number and calculating mod n, because:
The intractability of calculating discrete logarithms in a finite field provides this security. Simply put, no one can figure out how to get the shared secret number without having one of the random secrets before this operation. In Cisco IOS Release 11.2, n and g are hard coded. When Cisco begins support for ISAKMP/Oakley, users will be able to negotiate these numbers. This feature will allow interoperability with other vendors and could increase security by allowing the use of larger number fields.
Cisco IOS software uses the DES algorithm to encrypt data. The DES algorithm is published; therefore, its secrecy is not part of its security. This openness is an advantage, because it has allowed the security and cryptographic communities to review the algorithm and note any possible flaws that may have existed, so the world can be that much more confident in its security. The DES algorithm was designed by IBM in the early 1970s. The NSA made some changes to the algorithm, approved it for general use, and then it was published. It is believed to be very secure, and no one has been able to disprove this fact thus far. DES is a block-cipher algorithm, which means that it performs operations on a fixed length of bits—in this case, 64. First, DES does a permutation of the plain text, after which it divides the bits into two 32-bit halves. One of the halves is run through a complex, table-specified substitution that is dependent on the key; then the output is exclusive ORed with the other half of the bits. This function takes place in 16 cycles, called rounds. After each round, the two 32-bit halves are swapped. Following the final round, a final permutation is applied. The resulting cyphertext is a series of bits, each of which depends on every bit of the input and every bit of the key. These operations are fairly easily implemented in hardware.
With block ciphers, it is possible to further guarantee the integrity of the data received by using feedback. Cisco's encryption algorithm incorporates cipher feedback (CFB), which does an exclusive OR of the plain text data with each block of encrypted data. This scenario provides a means by which to verify that all data was received as transmitted.
DES was originally designed to be performed by hardware, and for years those implementations were the only ones that the National Institute of Standards and Technology (NIST) would certify. Eventually, software was written to perform this function. Software made it much cheaper and easier for people to implement DES. Prior to the creation of this software, DES required specialized and, therefore expensive hardware. Cisco is currently doing encryption using Cisco IOS software. The software crypto engine can be located on the main CPU, and on the Cisco 7500 series routers, it can alternately be located on the Versalite Interface Processor (VIP)2-40 card. Cisco also has a hardware assist option to do encryption on the Cisco 7500 and Cisco 7200 series routers, the Encryption Service Adapter (ESA) . The ESA is in the form of a port adapter for the VIP2-40 card or a standalone port adapter for the Cisco 7200. This arrangement allows use of either a hardware adapter or the VIP2 software engine to encrypt and decrypt data that comes into or leaves through the interfaces on the Cisco 7500 VIP2 card. The Cisco 7200 allows hardware assist to encrypt traffic for any interfaces on the Cisco 7200 chassis. Using an encryption assist saves precious CPU cycles that can be used for other purposes such as routing or for any of the many other functions that the Cisco IOS software performs.
In order to use the encryption feature on a router, the subset images running on it must support encryption. These images will contain the number 40 (for 40-bit DES) or 56 (for 56-bit DES). It is not important to the intermediate routers that the IP payload is encrypted; they forward the traffic according to their routing tables and therefore do not need to support encryption (as seen in Figure 3). Special software licenses must be purchased to use this feature.
To configure a router for encryption, a "crypto map" must be defined. This crypto map specifies the access list to be used to define the traffic to encrypt, the algorithm that will be used in encrypting data, and the peer with whom the router will exchange this data. Extended IP access lists describe the traffic that will be encrypted; the inverse of this access list is used to decrypt. Therefore, these lists must be symmetric on peers. Currently, IP encryption is supported, and users can tunnel other protocols inside of IP and encrypt the encapsulating IP packets and payload. This procedure can be done using the keyword gre in access-list entries, for example.
The algorithm specified in this map must be running on the router in order to use it, so if the map specifies "40-bit-des cfb-64," the global command "algorithm 40-bit-des cfb-64" must be in the configuration in order to encrypt data. By default, the 56-bit image runs 56-bit-DES CFB-64, and the 40-bit image runs 40-bit-DES CFB-64. Everything else has to be configured in addition to these algorithms if their use is desired. As with any route map configurations, crypto maps have to be carefully written before applying them to the interface, in order to verify what will be encrypted. Console access is recommended for application of the map.
CFB is a mode specified by DES which does an Xor of ciphertext with the plain-text for prior to performing the DES encryption. In almost every situation, CFB-64 is preferred, since it is performed more quickly.
Cisco IOS software network-layer encryption allows traffic to be specified for encryption by source and destination IP address, port number, and protocol type, because extended access lists are used to define this traffic. This means that, for example, Telnet traffic between certain hosts can be encrypted but not Hypertext Transfer Protocol (HTTP) traffic between the same pair. This degree of granularity allows users to preserve CPU cycles.
Crypto maps must be written carefully, so that the wrong key is not used to encrypt or decrypt traffic. Where one or more peers exist between another set of encrypting routers, it is important that any encrypted traffic is not redundantly encrypted, or first decrypted and then reencrypted, before being sent back out of the box. Either of these reencryption situations is a waste of network resources and adds no extra security. Access-list entries should be reviewed logically; the first match encrypts and the inverse decrypts traffic. Even if a later access list matches packet, it will not necessarily make it to that point in the crypto map.
Changing session keys on the router must also be considered. The key timeout can be changed from the default 30 minutes to any interval up to 1440 minutes, or one day. A lot of computing power is required to discover the key and then decrypt data. Statistically speaking, encrypted data is very secure and is not likely to be read, even with the key timeout extended to the maximum value.
An important consideration when designing a network with an encryption component is CPU load. The overhead on the CPU can be quite high while performing encryption. This load is equal for encryption and decryption, because DES is a symmetric algorithm. Table 1 lists some general guidelines to assist in network design.
Table 1 Encryption Performance
|
| 1 In most cases the cpu utilization was high during the test. For example, on the 7505 the cpu utilization was running between 70 and 75%. In general, Cisco prefers to see the cpu utilization below these numbers. So one needs to consider what other cpu intensive tasks the router might be doing, when estimating the amount of traffic that will need IP Security services. |
These numbers do not imply that encryption should take place on serial lines equal to or below the listed bandwidth. However, the approximate amount of data that should be selected to encrypt and decrypt should ideally be less than these values . When generating these numbers as a guideline for the mission-specific access boxes (the Cisco 1000, 1600, and 2500) it was expected that there would be little else running on the routers when they are configured for encryption. On the higher-end access boxes (the Cisco 4000, 4500, and 4700) as well as the core products (Cisco 7200 and 7500), more leeway was left for other simultaneous CPU-intensive processes. Deploying encryption on one of the platforms in the first group while doing many other CPU-intensive operations requires the amount of encrypted traffic to be pared down. In either case, the total CPU load on the router while just doing encryption should be below 60 percent.
Currently, Cisco does not support encryption and compression of the same traffic. The traffic is encrypted first, so an attempt to compress it will actually expand the data because it is so randomized after this first process, and compression relies on similar patterns. Cisco will deliver both services in a later release of Cisco IOS software.
Packets can be dropped during key exchange on some platforms, even with pregeneration of the Diffie-Hellman pairs, because keying is extremely CPU intensive. If a router has a large number of peers, rekeying could become a significant issue. Keying can also get into sync, resulting in a large number of peers trying to calculate all their session keys at the same time. For example, this might occur after reloading a router. Two Cisco 2500s take less than 30 seconds to renegotiate a key with one another, while two Cisco 4500s or two Cisco 7200s take about one second. This should not be significant in the larger routers but could cause problems with time-sensitive protocols on the Cisco 2500 or smaller router.
Memory constraint is not a major issue, but if a router needs to have a large number of encrypting peers, there must be enough RAM and NVRAM to store the keys. Each of the public DSS keys belonging to the router's peers is stored in NVRAM. Because they are stored as ASCII characters for easy reading of the configuration, each 64-byte key takes about 300 bytes. The router needs slightly more for its own DSS key pair. Session keys, which are kept in RAM, take 128 bytes while they are in use. For most configurations, this is a trivial amount of memory. Unless a router peers with a large number of other routers, there should be no issue with memory.
The first release of Cisco IOS encryption does not support an automatic key management scheme. Every peer with whom the router wants to exchange encrypted traffic must go through a one-time manual key exchange. This process should include voice authentication to ensure that the keys were exchanged unaltered with the right party.
At this time, encryption of broadcast and multicast packets is not supported. If "secure" routing updates are important to a network design, a protocol with a message digit algorithm 5 (MD5)-type hash built in should be used, such as Enhanced Interior Gateway Routing Protocol (IGRP), Open Shortest Path First (OSPF), or Routing Information Protocol Version 2 (RIPv2) to ensure update integrity.
When using encryption, it is important to know which router will be decrypting the encrypted traffic. In order to do this, some kinds of redundancy cannot be used with the encryption feature. For example, when using Hot Standby Router Protocol (HSRP), the router that is using HSRP will not be able to be an encryption peer with a remote peer. If traffic is decrypted prior to reaching the HSPR routers, there should be no problems using both Cisco IOS features in a network. Figure 4 identifies the kinds of redundancy that work well with encryption.
The two routers shown in Figure 5 are encrypting packets for TCP traffic sourced on an Ethernet behind the local router and destined for the two Ethernets off the remote router. Traffic sourced from the router is not encrypted in this example. This does not leave a security hole, because there is no sensitive information coming from the router itself. It is important to select only traffic that needs to be encrypted. All IP should not be used in the acl entry if only a specific application requires encrypting. There is no reason to encrypt most traffic that traverses between these two LANs. For example, it is probably not desirable to encrypt HTTP traffic, so if there is a server on one of these LANs, those port numbers should be excluded. Encryption should be performed only on packets that truly need to be encrypted, depending on the security policy that needs to be enforced. Encryption should be a part of the overall solution. Never use an access list that permits traffic from any host to any destination.
crypto public-key 4500A 01373822
DD6C7AAB 14829C0C 3835026A 3F3948A9 9ABEFF03 976AB5D2 D6DDFE3A 54D3D135
0B0DB853 0746A266 3500FA16 E55DBDFC F5AEDA23 3079F1D1 927297DB 2F7AF170
!don't type in! the router receives this value when you do key-exchange!
!increases session key-timeout to one full day
!the name of the crypto map and the line
number for ordering entries
!specifies the encryption algorithm and key length (DES w/ 40-bit key)
!specifies the peer whose current shared secret session key is used to encrypt data
! identifies the access-list to be used to determine what traffic to encrypt
ip address 192.168.1.1 255.255.255.0
With a hub-and-spoke architecture or any network design where encrypted traffic passes both to and through a router, no traffic should be redundantly encrypted and traffic should not be unnecessarily decrypted and reencrypted. Crypto maps should not overlap. A router identifies the key to use to encrypt traffic by going down the crypto map applied to the interface. When it hits the first access list that matches the traffic it is trying to send on that interface, the corresponding key is used to encrypt the traffic.
In Figure 6, any traffic that goes from Router_A to Router_C and back must to go through Router_B. This means that if crypto maps are not carefully written, there may be problems. Traffic that traverses Router_B should not be reencrypted, because this prevents it from being decrypted when it hits its destination. Another issue to look out for is decrypting and reencrypting designs, which is a waste of CPU cycles.
In some situations, dial backup to the same router is desirable, for example, in cases where users want to protect against the failure of a particular link in their WAN networks. Figure 7 shows a design which is relevant here. If the two interfaces go to the same peer, the same crypto map can be used on both interfaces. The backup interface must be used for this feature to function properly. If a backup design has a router dial into a different box, different crypto maps should be created and the peers set accordingly. Again, the backup interface command should be used.
Because the Cisco IOS software relies on the Internet Control Message Protocol (ICMP) to establish encryption sessions, ICMP traffic must be classified as "interesting" in the dialer list when doing encryption over a dial-on-demand routing (DDR) link. In the previous case, where the dialer is used for dial backup, the peer was already established so it was not an issue. The dialer list's access list and the crypto map's access list have different purposes, and they are almost certainly different.
Since Cisco IOS software only supports encryption of IP traffic at this time, it is necessary to use a tunnel interface when encrypting other protocols. When encrypting tunneled traffic, the crypto map needs to be applied to both the tunnel interface and the physical interface where the tunnel traffic enters and leaves the router. When writing the crypto map, it is important to consider what the packet will look like when it leaves the physical interface. For example, the keyword gre should be used if the traffic is encapsulated by generic routing encapsulation GRE. Packets are put into the tunneling IP packet before they are run through the crypto map.
Then IPX packets can be tunneled in GRE IP packets, encrypted, and sent out over the Internet. IP traffic is not encrypted in this case.
This paper provides information to help with the design of networks that use Cisco IOS network-layer encryption. For further questions about encryption, contact Cisco's Technical Assistance Center (TAC) by sending e-mail to tac@cisco.com or by calling 800 553-2447.
1. Curry, David A., UNIX System Security; A Guide for System Administrators, Addison-Wesley, Reading, Massachusetts, 1992.
2. Ford, Warwick, Computer Communications Security: Principles, Standard Protocols and Techniques, Prentice Hall, Englewood Cliffs, New Jersey, 1995.
3. Kaufman, Charlie, Radia Pearlman and Mike Speciner, Network Security; Private Communication in a Public World, Prentice Hall, Englewood Cliffs, New Jersey, 1995.
4. Schneier, Bruce, Applied Cryptography, Second Edition, John Wiley and Sons, Oak Park, Illinois, 1996.
5. Stallings, William, Network and Internetwork Security; Principles and Practice, Prentice Hall, Englewood Cliffs, New Jersey, 1995.
1 These numbers need not be secret and need to be shared
Posted: Fri Aug 29 11:17:25 PDT 2003
All contents are Copyright © 1992--2003 Cisco Systems, Inc. All rights reserved.
Important Notices and Privacy Statement.