7.6. Understanding Cryptography Standards and Protocols

Numerous standards are available to establish secure services. Some of the standards that will be presented in the following sections have already been discussed in greater detail in earlier chapters. Here I will quickly remind you of them and introduce you to a few more standards.

The movement from proprietary governmental standards toward more unified and global standards is a growing trend that has both positive and negative implications. Higher interoperability between disparate systems will also mean that these standards will be widely utilized. The more the standards are used, the more miscreants will focus on them as they try to break them.

As a security administrator, you have to weigh the pros and cons of the different standards and evaluate them against your organization's needs. The following sections introduce you to the major standards, discuss their focus, and describe how they were developed.

7.6.1. The Origins of Encryption Standards

As mentioned in the beginning of the chapter, early cryptography standards were primarily designed to secure communications for the government and military. Many different standards groups exist today, and they often provide standards that are incompatible with the standards of other groups. These standards are intended to address the specific environments in which these groups work.

The following sections describe key U.S. government agencies, a few well-known industry associations, and public-domain cryptography standards.

7.6.1.1. The Role of Governmental Agencies

Several U.S. government agencies are involved in the creation of standards for secure systems. They either directly control specific sectors of government or provide validation, approval, and support to government agencies. We'll look at each of these agencies in the following sections.

7.6.1.1.1. National Security Agency

The National Security Agency (NSA) is responsible for creating codes, breaking codes, and coding systems for the U.S. government. The NSA was chartered in 1952. It tries to keep a low profile; for many years, the government didn't publicly acknowledge its existence.

The NSA is responsible for obtaining foreign intelligence and supplying it to the various U.S. government agencies that need it. It's said to be the world's largest employer of mathematicians. The NSA's missions are extremely classified, but its finger is in everything involving cryptography and cryptographic systems for the U.S. government, government contractors, and the military.

7.6.1.1.2. National Security Agency/Central Security Service

The National Security Agency/Central Security Service (NSA/CSS) is an independently functioning part of the NSA. It was created in the early 1970s to help standardize and support Department of Defense (DoD) activities. The NSA/CSS supports all branches of the military. Each branch of the military used to have its own intelligence activities. Frequently, these branches didn't coordinate their activities well. NSA/CSS was created to help coordinate their efforts.

7.6.1.1.3. National Institute of Standards and Technology

The National Institute of Standards and Technology (NIST), which was formerly known as the National Bureau of Standards (NBS), has been involved in developing and supporting standards for the U.S. government for over 100 years. NIST has become very involved in cryptography standards, systems, and technology in a variety of areas. It's primarily concerned with governmental systems, and it exercises a great deal of influence on them. NIST shares many of its findings with the security community because business needs are similar to government needs.

NIST publishes information about known vulnerabilities in operating systems and applications. You'll find NIST very helpful in your battle to secure your systems.

7.6.1.2. Industry Associations and the Developmental Process

The need for security in specific industries, such as the banking industry, has driven the development of standards. Standards frequently begin as voluntary or proprietary efforts.

The Request for Comments (RFC), originated in 1969, is the mechanism used to propose a standard. It's a document-creation process with a set of practices. An RFC is categorized as standard (draft or standard), best practice, informational, experimental, or historic.

Draft documents are processed through a designated RFC editor who makes sure the document meets publication standards. Editors play a key role in the RFC process; they are responsible for making sure proposals are documented properly, and they manage the discussion. The RFC is then thrown open to the computer-user community for comments and critique. This process ensures that all interested parties have the opportunity to comment on an RFC.

The RFC process allows open communications about the Internet and other proposed standards. Virtually all standards relating to the Internet that are adopted go through this process.

Several industrial associations have assumed roles that allow them to address specific environments. The following sections briefly discuss some of the major associations and the specific environments they address.

7.6.1.2.1. American Bankers Association

The American Bankers Association (ABA) has been very involved in the security issues facing the banking and financial industries. Banks need to communicate with each other in a secure manner. The ABA sponsors and supports several key initiatives regarding financial transactions.

7.6.1.2.2. Internet Engineering Task Force

The Internet Engineering Task Force (IETF) is an international community of computer professionals that includes network engineers, vendors, administrators, and researchers. The IETF is mainly interested in improving the Internet; it's also very interested in computer security issues. The IETF uses working groups to develop and propose standards.

IETF membership is open to anyone. Members communicate primarily through Internet list servers and public conferences.

7.6.1.2.3. Internet Society

The Internet Society (ISOC) is a professional group whose membership consists primarily of Internet experts. The ISOC oversees a number of committees and groups, including the IETF.

You can find a history of ISOC and IETF at http://www.isoc.org/internet/history/ietfhis.shtml.

7.6.1.2.4. World Wide Web Consortium

The World Wide Web Consortium (W3C) is an association concerned with the interoperability, growth, and standardization of the World Wide Web (WWW). It's the primary sponsor of XML and other web-enabled technologies. Although not directly involved in cryptography, the W3C recently published a proposed standard for encryption in XML.

7.6.1.2.5. International Telecommunications Union

The International Telecommunications Union (ITU) is responsible for virtually all aspects of telecommunications and radio communications standards worldwide. The ITU is broken into three main groups that are targeted at specific areas of concern: ITU-R is concerned with radio communication and spectrum management, ITU-T is concerned with telecommunications standards, and ITU-D is concerned with expanding telecommunications throughout undeveloped countries. The ITU is headquartered in Switzerland, and it operates as a sponsored agency of the United Nations.

7.6.1.2.6. Comité Consultatif International Téléphonique et Télégraphique

The Comité Consultatif International Téléphonique et Télégraphique (CCITT) standards committee has been involved in developing telecommunications and data communications standards for many years. The functions performed by the CCITT have been taken over by the ITU, and the ITU-T committee now manages CCITT standards. Existing CCITT standards (such as X.400 and X.500) are still referred to as CCITT standards, but soon they will be reclassified and referred to as ITU-T standards.

7.6.1.2.7. Institute of Electrical and Electronics Engineers

The Institute of Electrical and Electronics Engineers (IEEE) is an international organization focused on technology and related standards. Pronounced "I Triple-E," the IEEE is organized into several working groups and standards committees. IEEE is actively involved in the development of PKC, wireless, and networking protocol standards.

7.6.1.3. Public Domain Cryptography

Public domain cryptography refers to the standards and protocols that emerge from individual or corporate efforts and are released to the general public for use. Public domain structures are developed for many reasons: Developers may merely have a passing interest in something, or they may want to test a new theory.

PGP and RSA are two common public cryptographic initiatives:

Pretty Good Privacy

One of the most successful involves a system called Pretty Good Privacy (PGP). It was developed by Phil Zimmerman, who developed this encryption system for humanitarian reasons. In 1991, he published the encryption system on the Internet. His stated objective was to preserve privacy and protect citizens from oppressive governments. Since its release, PGP has become a de facto standard for e-mail encryption. PGP uses both symmetrical and asymmetrical encryption.

RSA

RSA provides cryptographic systems to both private businesses and the government. The name RSA comes from the initials of its three founders (Rivest, Shamir, and Adleman). RSA has been very involved in developing Public-Key Cryptography Standards (PKCS), and it maintains a list of standards for PKCS.

7.6.2. Public-Key Infrastructure X.509/Public-Key Cryptography Standards

The Public-Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models for the PKI environment. The PKIX working group is responsible for the X.509 standard, which is discussed in the next section.

The Public-Key Cryptography Standards (PKCS) is a set of voluntary standards created by RSA and security leaders. Early members of this group included Apple, Microsoft, DEC (now HP), Lotus, Sun, and MIT.

Currently, there are 15 published PKCS standards:

• PKCS #1: RSA Cryptography Standard

• PKCS #2: Incorporated in PKCS #1

• PKCS #3: Diffie-Hellman Key Agreement Standard

• PKCS #4: Incorporated in PKCS #1

• PKCS #5: Password-Based Cryptography Standard

• PKCS #6: Extended-Certificate Syntax Standard

• PKCS #7: Cryptographic Message Syntax Standard

• PKCS #8: Private-Key Information Syntax Standard

• PKCS #9: Selected Attribute Types

• PKCS #10: Certification Request Syntax Standard

• PKCS #11: Cryptographic Token Interface Standard

• PKCS #12: Personal Information Exchange Syntax Standard

• PKCS #13: Elliptic Curve Cryptography Standard

• PKCS #14: Pseudorandom Number Generators

• PKCS #15: Cryptographic Token Information Format Standard

These standards are coordinated through RSA; however, experts worldwide are welcome to participate in the development process.

7.6.3. X.509

The X.509 standard defines the certificate formats and fields for public keys. It also defines the procedures that should be used to distribute public keys. The X.509 version 2 certificate is still used as the primary method of issuing Certificate Revocation List (CRL) certificates. The current version of X.509 certificates is version 3, and it comes in two basic types:

• The most common is the end-entity certificate, which is issued by a certificate authority (CA) to an end entity. An end entity is a system that doesn't issue certificates but merely uses them.

• The CA certificate is issued by one CA to another CA. The second CA can, in turn, issue certificates to an end entity.

All X.509 certificates have the following:

• Signature, which is the primary purpose for the certificate

• Version

• Serial number

• Signature algorithm ID

• Issuer name

• Validity period

• Subject name

• Subject public key information

• Issuer unique identifier (relevant for versions 2 and 3 only)

• Subject unique identifier (relevant for versions 2 and 3 only)

• Extensions (in version 3 only)

7.6.4. SSL and TLS

Secure Sockets Layer (SSL) is used to establish a secure communication connection between two TCP-based machines. This protocol uses the handshake method of establishing a session. The number of steps in the handshake depends on whether steps are combined and/or mutual authentication is included. The number of steps is always between four and nine, inclusive, based on who is doing the documentation.

You can find details on how the SSL process works at http://support.microsoft.com:80/support/kb/articles/Q257/5/91.ASP.

Regardless of which vendor's implementation is being discussed, the steps can be summarized as illustrated in Figure 7.18. When a connection request is made to the server, the server sends a message back to the client indicating that a secure connection is needed. The client sends the server a certificate indicating the capabilities of the client. The server then evaluates the certificate and responds with a session key and an encrypted key. The session is secure at the end of this process.

This session will stay open until one end or the other issues a command to close it. The command is typically issued when a browser is closed or another URL is requested.

As a security administrator, you will occasionally need to know how to configure SSL settings for a website running on your operating system. You should also know that in order for SSL to work properly, the clients must be able to accept the level of encryption that you apply. Internet Explorer 5.5 and later, as well as Netscape 4.72 and later, can work with 128-bit encrypted sessions/certificates. Earlier browsers often needed to use 40- or 56-bit SSL encryption. As an administrator, you should push for the latest browsers on all clients.

VeriSign used a clever advertising strategy that makes this point readily comprehensible: It mailed flyers in a clear bag with the lines, "Sending sensitive information over the Web without the strongest encryption is like sending a letter in a clear envelope. Anyone can see it." This effectively illustrates the need for the strongest SSL possible.

Transport Layer Security (TLS) is a security protocol that expands upon SSL. Many industry analysts predict that TLS will replace SSL in the near future. Figure 7.19 illustrates the connection process in the TLS network.

The TLS protocol is also referred to as SSL 3.1, but despite its name, it doesn't interoperate with SSL. The TLS standard is supported by the IETF.

7.6.5. Certificate Management Protocols

Certificate Management Protocol (CMP) is a messaging protocol used between PKI entities. This protocol isn't yet widely used, but you may encounter it in some PKI environments.

XML Key Management Specification (XKMS) is designed to allow XML-based programs access to PKI services. XKMS is being developed and enhanced as a cooperative standard of the World Wide Web Consortium (W3C). XKMS is a standard that is built upon CMP and uses it as a model.

CMP is expected to be an area of high growth as PKI usage grows.

7.6.6. Secure Multipurpose Internet Mail Extensions

Secure Multipurpose Internet Mail Extensions (S/MIME) is a standard used for encrypting e-mail. S/MIME contains signature data. It uses the PKCS #7 standard (Cryptographic Message Syntax Standard) and is the most widely supported standard used to secure e-mail communications.

MIME is the de facto standard for e-mail messages. S/MIME, which is a secure version of MIME, was originally published to the Internet as a standard by RSA. It provides encryption, integrity, and authentication when used in conjunction with PKI. S/MIME version 3, the current version, is supported by IETF.

7.6.7. Secure Electronic Transaction

Secure Electronic Transaction (SET) provides encryption for credit card numbers that can be transmitted over the Internet. It was developed by Visa and MasterCard and is becoming an accepted standard by many companies.

SET works in conjunction with an electronic wallet that must be set up in advance of the transaction. An electronic wallet is a device that identifies you electronically in the same way as the cards you carry in your wallet.

Figure 7.20 illustrates the process used in an SET transaction. The consumer must establish an electronic wallet that is issued by the consumer/issuing bank. When the consumer wants to make a purchase, they communicate with the merchant. The wallet is accessed to provide credit/payment information. The merchant then contacts the credit processor to complete the transaction. The credit processor interfaces with the existing credit network. In this situation, the transactions between the issuing bank, the consumer, the merchant, and the credit processor all use SET.

7.6.8. Secure Shell

Secure Shell (SSH) is a tunneling protocol originally used on Unix systems. It's now available for both Unix and Windows environments. The handshake process between the client and server is similar to the process described in SSL. SSH is primarily intended for interactive terminal sessions.

SSH can be used in place of the older Remote Shell (RSH) utility that used to be a standard in the Unix world. It can also be used in place of rlogin and Telnet.

Figure 7.21 illustrates the SSH connection process. Notice that SSH connections are established in two phases: The first phase is a secure channel to negotiate the channel connection, and the second phase is a secure channel used to establish the connection.

Real World Scenario: Working with Credit Card Information Online You've been asked to participate in a project that involves the transmission of credit card information between a group of retail stores and a credit card processing center. The security of this information is very important. Store employees will be using direct dial-in connections to the credit card processing center or the Internet. What should you evaluate? You have several ways to go in this situation. Your dial-up and Internet connections present different concerns. Because you're dealing with credit card information, the volume of information to be transmitted is relatively small. The information will include a card number, name, and the amount of the sale, as well as the expiration date. The processing center will probably send back a coded message and approval. Compared to a lot of interactions, this is a fairly small amount of data. Your direct dial-in connections to the credit card center may not need to be encrypted. It's difficult to tap a telephone line, and public access is hard to create. If your organization feels this is necessary, you'll want to use a relatively quick encryption system, such as SET. Your Internet connections could use SET, SSL, TLS, or one of the other secure protocols discussed in this chapter.

Real World Scenario: Securing Unix Interactive Users You've been asked to examine your existing Unix systems and evaluate them for potential security weaknesses. Several remote users need to access Telnet and FTP capabilities in your network. Telnet and FTP connections send the logon and password information in the clear. How could you minimize security risks for Telnet and FTP connections? You should consider using a VPN connection between these remote connections and your corporate systems. One workable solution might be to provide SSH to your clients and install it on your Unix servers. Doing so would allow FTP and Telnet connectivity in a secure environment.

7.6.9. Pretty Good Privacy

Pretty Good Privacy (PGP) is a freeware e-mail encryption system. As mentioned earlier in the chapter, PGP was introduced in the early 1990s, and it's considered to be a very good system. It's widely used for e-mail security.

PGP uses both symmetrical and asymmetrical systems as a part of its process. Figure 7.22 provides an overview of how the various components of a PGP process work together to provide security. During the encryption process, the document is encrypted with the public key and also a session key, which is a one-use random number, to create the ciphertext. The session key is encrypted into the public key and sent with the ciphertext.

On the receiving end, the private key is used to weed out the session key. The session key and the private key are then used to decrypt the ciphertext back into the original document.

7.6.10. HTTP Secure

Hypertext Transport Protocol Secure (HTTPS) is the secure version of HTTP, the language of the World Wide Web. HTTPS uses SSL to secure the channel between the client and server. Many e-business systems use HTTPS for secure transactions. An HTTPS session is identified by the https in the URL and by a key that is displayed on the web browser.

7.6.11. Secure HTTP

Secure Hypertext Transport Protocol (S-HTTP) is HTTP with message security (added by using RSA or a digital certificate). Whereas HTTPS creates a secure channel, S-HTTP creates a secure message. S-HTTP can use multiple protocols and mechanisms to protect the message. It also provides data integrity and authentication.

7.6.12. IP Security

IP Security (IPSec) is a security protocol that provides authentication and encryption across the Internet. IPSec is becoming a standard for encrypting virtual private network (VPN) channels. It's available on most network platforms, and it's considered to be highly secure.

One of the primary uses of IPSec is to create VPNs. IPSec, in conjunction with Layer 2 Tunneling Protocol (L2TP) or Layer 2 Forwarding (L2F), creates packets that are difficult to read if intercepted by a third party. IPSec works at layer 3 of the OSI model.

As a security administrator, it's important to know the operations under way on your servers. As an administrator, you need to be able to evaluate operations and performance at all times and be able to establish a baseline of current operations.

The two primary protocols used by IPSec at the bottom layer are Authentication Header (AH) and Encapsulating Security Payload (ESP). Both can operate in either the transport or tunnel mode. Protocol 50 is used for ESP, while protocol 51 is used for AH.

7.6.13. Tunneling Protocols

Tunneling protocols add a capability to the network: the capability to create tunnels between networks that can be more secure, support additional protocols, and provide virtual paths between systems. The best way to think of tunneling is to imagine sensitive data being encapsulated in other packets that are sent across the public network. After they're received at the other end, the sensitive data is stripped from the other packets and recompiled into its original form.

The most common protocols used for tunneling are as follows:

Point-to-Point Tunneling Protocol

Point-to-Point Tunneling Protocol (PPTP) supports encapsulation in a single point-to-point environment. PPTP encapsulates and encrypts Point-to-Point Protocol (PPP) packets. This makes PPTP a favorite low-end protocol for networks. The negotiation between the two ends of a PPTP connection is done in the clear. Once the negotiation is performed, the channel is encrypted. This is one of the major weaknesses of the PPTP protocol. A packet-capture device, such as a sniffer, that captures the negotiation process can potentially use that information to determine the connection type and information about how the tunnel works. Microsoft developed PPTP and supports it on most of the company's products. PPTP uses port 1723 and TCP for connections.

Layer 2 Forwarding

Layer 2 Forwarding (L2F) was created by Cisco as a method of creating tunnels primarily for dial-up connections. It's similar in capability to PPP and shouldn't be used over WANs. L2F provides authentication, but it doesn't provide encryption. L2F uses port 1701 and TCP for connections.

Layer 2 Tunneling Protocol

Relatively recently, Microsoft and Cisco agreed to combine their respective tunneling protocols into one protocol: Layer 2 Tunneling Protocol (L2TP). L2TP is a hybrid of PPTP and L2F. It's primarily a point-to-point protocol. L2TP supports multiple network protocols and can be used in networks besides TCP/IP. L2TP works over IPX, SNA, and IP, so it can be used as a bridge across many types of systems. The major problem with L2TP is that it doesn't provide data security: The information isn't encrypted. Security can be provided by protocols such as IPSec. L2TP uses port 1701 and UDP for connections.

7.6.14. Federal Information Processing Standard

The Federal Information Processing Standard (FIPS) is a set of guidelines for the United States federal government information systems. FIPS is used when an existing commercial or government system doesn't meet federal security requirements. FIPS is issued by NIST.

7.6.15. Common Criteria

Common Criteria (CC) is an internationally agreed-upon set of standards to evaluate IT security. The growing market and the need for standardized security-system ratings have created the need for a common set of definitions. CC is a combination of European, U.S., and Canadian standards compiled into a single document. Using CC, security evaluations can be consistently applied across technologies.

7.6.16. Wireless Transport Layer Security

Wireless Transport Layer Security (WTLS) provides an encrypted and authenticated connection between a wireless client and a server. WTLS is similar in function to TLS, but it uses a lower bandwidth and less processing power. It's used to support wireless devices, which don't yet have extremely powerful processors.

7.6.17. Wired Equivalent Privacy

Wired Equivalent Privacy (WEP) is a wireless protocol designed to provide privacy equivalent to that of a wired network. WEP is implemented in a number of wireless devices, including PDAs and cell phones. To make the encryption stronger, Temporal Key Integrity Protocol (TKIP) can also be employed. This places a 128-bit wrapper around the WEP encryption with a key that is based on such things as the MAC address of your machine and the serial number of the packet. Without the use of TKIP, WEP—as mentioned earlier in this chapter—is considered weak.

The Wi-Fi Protected Access (WPA) and Wi-Fi Protected Access 2 (WPA2) technologies were designed to address the core problems with WEP. These technologies implement the 802.11i standard. The difference between WPA and WPA2 is that the former implements most—but not all—of 802.11i in order to be able to communicate with older wireless cards (which may still need an update through their firmware in order to be compliant), while WPA2 implements the full standard and is not compatible with older cards.

7.6.18. ISO 17799

ISO 17799 is a 10-part security audit designed to audit virtually all aspects of your IT department. It is a comprehensive and in-depth audit/review.