Cryptography Standards and Protocols

Numerous standards are available to establish secure services. Some of the standards that will be presented in this section have already been discussed in greater detail in earlier chapters. Nevertheless, this section will quickly remind you of them, and it will introduce you to a few more standards.

Note

The Security+ exam does not cover all of these standards in detail. However, you should have a good understanding of the purpose and function of PKIX/ PKCS, X.509, SSL/TLS, S/MIME, PGP, HTTPS, IPS, WTLS, and WEP for the exam.

The following sections discuss a wide array of standards and protocols that are used in information systems. The movement from proprietary governmental standards toward more unified and global standards is a growing trend. This trend 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 people will try to break them.

As a security administrator, you will have to weigh the pros and cons of the different standards and weigh them against your organization's needs. This section introduces you to the major standards, discusses their focus, and describes how they were developed.

Origins of Encryption Standards

Early cryptography standards were primarily designed to secure communications for government and military communications. Many different standards groups exist today, and they often provide incompatible standards. These standards are intended to address the specific environments that these groups address.

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

Governmental Agencies

Several U.S. government agencies are involved in the creation of standards for secure systems. These agencies either directly control specific sectors of government or they provide validation, approval, and support to government agencies. This section discusses the various government agencies involved in cryptographic and information security.

NSA

The National Security Agency (NSA) is responsible for creating codes, breaking codes, and coding systems for the U.S. government. The NSA tries to keep a low profile. It is said to be the world's largest employer of mathematicians. The NSA's missions are extremely classified; the NSA's finger is in everything involving cryptography and cryptographic systems for the U.S. government, government contractors, and the military.

The NSA is responsible for obtaining foreign intelligence and supplying it to the various U.S. government agencies that need it. The NSA was chartered in 1952. For many years, the government did not publicly acknowledge its existence.

NSA/CSS

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 did not coordinate their activities well. CSS was created to help coordinate their efforts.

NIST

The National Institute of Standards and Technology (NIST) has been involved in developing and supporting standards for the U.S. government for over 100 years. NIST was formerly known as the National Bureau of Standards (NBS). NIST has become very involved in cryptography standards, systems, and technology in a variety of areas. NIST is 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 will find NIST very helpful in your battle to secure your systems.

Industry Associations and Development 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) is the mechanism used to propose a standard. It is a document-creation process with a set of practices that originated in 1969. 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 that the document meets publication standards. 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 that are adopted relating to the Internet go through this RFC process. Figure 8.1 illustrates the RFC process. The editor plays one of the key roles in the RFC process. The editor is responsible for making sure that proposals are documented properly, and he manages the discussion.

Figure 8.1: The RFC process for standards development

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.

ABA

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.

IETF

The Internet Engineering Task Force (IETF) is an international community of computer professionals, which includes network engineers, vendors, administrators, and researchers. The IETF is mainly interested in improving the Internet. It is 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.

ISOC

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

W3C

The World Wide Web Consortium (W3C) is an association concerned with the interoperability, growth, and standardization of the World Wide Web (WWW). It is 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.

CCITT

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 CCITT standards are now managed by the ITU-T committee. 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.

ITU

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 telecommunication standards. ITU-D is concerned with expanding telecommunication throughout undeveloped countries. The ITU is headquartered in Switzerland, and it operates as a sponsored agency of the United Nations. Figure 8.2 shows the overall structure of the ITU.

Figure 8.2: Organizational chart of the International Telecommunications Union

IEEE

The Institute of Electrical and Electronics Engineers (IEEE) is an international organization focused on technology and related standards. The IEEE is organized into several working groups and standards committees. IEEE is very actively involved in the development of PKC, wireless, and networking protocols standards.

Public Domain Cryptography

Public Domain Cryptography refers to the standards and protocols that emerge from individual or corporate efforts that are released to the general public for their 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.

Two common public cryptographic initiatives are discussed below:

PGP One of the most successful of these involves a system called Pretty Good Privacy (PGP). PGP 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.

Note
The U.S. government prosecuted Zimmerman for three years because he released PGP. The government claimed he violated U.S. laws prohibiting the exportation of sensitive technology. They government claimed the encryption method supported terrorism and oppression, instead of reducing it. The case was finally dropped. PGP has continued to grow in popularity worldwide.

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

PKIX/PKCS

The Public Key Infrastructure X.509 (PKIX) is the working group formed by the IETF to develop standards and models for the PKI environment.

Note

PKI was covered in detail in Chapter 7, "Cryptography Basics and Methods."

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.

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 CRL certificates. The current version of X.509 certificates is version 3, and it comes in two basic types.

The first and most common certificate is the end-entity certificate, which is a certificate issued by a certificate authority (CA) to an end entity. An end entity is a system that does not issue certificates, it merely uses them.

The second major type of certificate is the CA certificate, which is a certificate issued by one CA to another CA. The second CA can, in turn, issue certificates to an end entity.

SSL

The Secure Sockets Layer (SSL) is used to establish a secure communication connection between two TCP-based machines. This protocol uses the handshake method illustrated in Figure 8.3. When a connection request is made to the server, the server sends a message back to the client indicating a secure connection is needed. The client then 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 private key. The session is secure at the end of this process.

Figure 8.3: The SSL connection process

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

Netscape originally developed the SSL method, and it has gained wide acceptance throughout the industry.

TLS

Transport Layer Security (TLS) is a security protocol that combines SSL and other security protocols. Many industry analysts predict that TLS will replace SSL in the near future. Figure 8.4 illustrates the connection process in the TLS network.

Figure 8.4: The TLS connection process

The TLS protocol is also referred to as SSL 3.1. Despite its name, it does not interoperate with SSL. The TLS standard is supported by the IETF.

Real World Scenario: Working with Credit Card Information Online

You have 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 different ways to go in this situation. Your dial-ups and Internet connections present different concerns. Because you are 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. 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 at all. It is difficult to tap a telephone line, and public access is hard to create. If your organization feels this is necessary, you will 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 that are discussed in this section.

ISAKMP

The Internet Security Association and Key Management Protocol (ISAKMP) defines a framework within which a VPN client and server can connect. ISAKMP allows the two ends to negotiate which encryption and hashing algorithms should be used between the systems. ISAKMP is used in the IPSec protocol. ISAKMP requires that the client and server use digital signatures as part of the authentication process. Figure 8.5 illustrates the ISAKMP process.

Figure 8.5: The ISAKMP Protocol negotiation and connection process

The ISAKMP provides a complete framework for exchanging authentication and key management information.

CMP

Certificate Management Protocols (CMP) is a messaging protocol between PKI entities. This protocol is not yet widely used, but it may be encountered in some PKI environments.

XML Key Management Specifications (XKMS) are 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 Committee (W3C). XKMS does not need PKI to operate, but it can interoperate with PKI systems. CMP is expected to be an area of high growth as PKI usage grows. Figure 8.6 illustrates the XKMS process. The process between the client and the CA occurs using XML, which uses XKMS. The CA is in communication with a PKI system, as shown in this example. The client would not be aware of this, nor would it need access to the PKI provider to function correctly.

Figure 8.6: Two web-enabled systems communicating via the XKMS process

S/MIME

Secure MIME (S/MIME) is a standard used for encrypting e-mail. S/MIME can also contain signature data. S/MIME provides encryption, integrity, and authentication when used in conjunction with PKI. MIME is the de facto standard for e-mail messages. S/MIME, as a standard, was originally published to the Internet by RSA. S/MIME Version 3, the current version, is supported by IETF.

S/MIME uses the PKCS #7 standard (Cryptographic Message Syntax Standard). S/MIME is the most widely supported standard used to secure e-mail communications.

SET

Secure Electronic Transaction (SET) was developed by Visa and MasterCard for secure credit-card transactions. SET is becoming an accepted standard by many companies. SET provides encryption for credit card numbers that can be transmitted over the Internet. SET is most suited to small amounts of data transmission.

SET works in conjunction with an "electronic wallet" that must be set up in advance of the transaction. Figure 8.7 illustrates the process used in an SET transaction. The consumer must establish an electronic wallet that is issued from 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.

Figure 8.7: The SET transaction in process

SSH

Secure Shell (SSH) is the tunneling protocol originally used on UNIX systems. SSH is 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. Figure 8.8 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. The second phase is a secure channel used to establish the connection.

Figure 8.8: The SSH connection-establishment process

Real World Scenario: Securing UNIX Interactive Users

You were asked to examine your existing UNIX systems and evaluate them for any 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 have a few options. You should probably 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.

PGP

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

PGP uses both symmetrical and asymmetrical systems as a part of its process. Figure 8.9 provides an overview of how the various components of a PGP process work together to provide security.

Figure 8.9: The PGP encryption system

HTTPS

Hypertext Transport Protocol Secure (HTTPS) is the secure version of HTTP. HTTP is 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 net browser.

S-HTTP

Secure Hypertext Transport Protocol (S-HTTP) is HTTP with message security. Where HTTPS creates a secure channel, S-HTTP creates a secure message. S-HTTP can use multiple protocols and mechanisms to protect the message. S-HTTP also provides data integrity and authentication.

IPSec

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

FIPS

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

Common Criteria

Common criteria 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. Common criteria are a combination of European, U.S., and Canadian standards compiled into a single document. By using common criteria, security evaluations can be consistently applied across technologies.

WTLS

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 is used to support wireless devices, which do not yet have extremely powerful processors. Figure 8.10 shows a PDA using WTLS to communicate across a WAP environment.

Figure 8.10: WTLS security between a PDA and a wireless server

WEP

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.

Note

WEP has come under a lot of fire lately. It may not be as secure as it was originally thought to be. Several demonstrations have shown that WEP is not a strong encryption system. WEP is relatively new, and these deficiencies will probably be addressed in later releases.

ISO 17799

ISO 17799 is a ten-part security audit designed to audit virtually all aspects of your IT department. It appears to be a very comprehensive and in-depth audit/review. The 10 criteria for ISO 17799 certification are listed here:

Business Continuity Planning
System Access Control
Systems Development and Maintenance
Physical and Environmental Security
Compliance
Personal Security
Security Organization
Computer and Network Management
Asset Classification and Control
Security Policy

Note
This book addresses these topics, although not at the level necessary to achieve ISO 17799 certification.