Securing Communications Over an Intranet: Part 1

Providing robust security services is chief among the challenges faced by information systems teams that are building intranets. IS teams want to provide such services as single-user login, message privacy and access control for safeguarding confidential documents. These services need to be provided in a cross-platform (Windows, Macintosh, Unix, etc.) and application-independent (Web server, Web client, mail server, news server, directory server, proxy server, etc.) way.

Fortunately, industry-standard solutions to these challenges have emerged, and cryptography plays a pivotal role in these solutions. This white paper discusses the motivations and protocols for deploying cryptographic technology throughout the enterprise.

Security Challenges and Solutions

There are many challenges in building a full-service intranet that provides safe communications and collaboration. TCP/IP solves many problems in a remarkably scalable way. However, TCP/IP was not designed to offer secure communication services. Therefore, we must bring additional technology and policies to bear to solve typical security problems, such as the following:

  • How do I authenticate users to make sure they are who they claim to be? Standard Web protocols such as TCP/IP and HTTP make impersonating a person or an organization relatively simple. For example, if Alice connects to, how does she know that the site is actually operated by the well-known retailer?

  • How can I perform authentication without sending user names and passwords across the network in the clear?

  • How can I provide single-user login services to avoid costly user name and account maintenance for all the servers (Web, proxy, directory, mail, news, etc.) across the enterprise? Can I provide single-user login without compromising security or incurring high administrative costs?

  • How can I ensure that these services not only work on my intranet but also scale to the Internet? In other words, how can I avoid managing one security scheme for inside my firewall and a completely different scheme for outside the firewall?

  • How can I protect the privacy of my communications, both those in real-time (such as the data flowing between a Web client and a Web server) and those with store-and-forward applications, such as e-mail?

  • How can I can ensure that messages haven't been tampered with between the sender and the recipient?

  • How can I safeguard confidential documents to ensure that only authorized individuals have access to them?

Remarkably, there is a single technology that provides the foundation for solving all these challenges: cryptography. Cryptographic technology is embodied in industry-standard protocols such as SSL (Secure Sockets Layer), SET (Secure Electronic Transactions) and S/MIME (Secure Multipart Internet Mail Encoding). These standards provide the foundation for a wide variety of security services, including encryption, message integrity verification, authentication and digital signatures.

What Is Cryptography?

Cryptography is a surprisingly general technology that provides the foundation for each of the security challenges listed above. Cryptography includes the following elements:

  • Encryption transforms data into some unreadable form to ensure privacy. Internet communication is like sending postcards, in that anyone who is interested can read a particular message. Encryption offers the digital equivalent of a sealed envelope.

  • Decryption is the reverse of encryption; it transforms encrypted data back into its original, intelligible form.

  • Authentication identifies an entity such as an individual, a machine on the network or an organization.

  • Digital signatures bind a document to the possessor of a particular key and are the digital equivalent of paper signatures.

  • Signature verification is the inverse of a digital signature; it verifies that a particular signature is valid.

Symmetric Key and Public Key Cryptography

Symmetric key or secret key cryptography uses the same key to encrypt and decrypt messages. This is a familiar real-world phenomenon: We use the same key to unlock and lock our car doors, for instance. The problem with symmetric key cryptography is having the sender and receiver agree on a secret key without anyone else finding out. How can they do this? Over the phone, on a floppy disk, using a courier? All these are cumbersome, slow and error-prone techniques. In addition, the number of keys tends to be much larger than the number of nodes; that is, people may have multiple keys they use for different purposes.

Public key cryptography was invented in 1976 by Whitfield Diffie and Martin Hellman to solve precisely this problem. With public key cryptography, each person gets a pair of keys, a public key and a private key. Each person's public key is published, while the private key is kept secret. When Alice wants to send Bob a secure message, she encrypts it using Bob's public key. When Bob gets the message, he decrypts it using his private key. The sender and receiver no longer have to share secret information in order to communicate securely.

In practice, both symmetric key and public key techniques are used in popular security protocols such as SSL and S/MIME because symmetric key algorithms tend to be much faster than public key algorithms. Let's visit Alice and Bob again. They want to communicate securely, but they also want to communicate quickly. Here's what they do:

  1. Alice generates a random number (key) that will be used for actually encrypting her message to Bob.

  2. She encrypts the random number with Bob's public key.

  3. Bob decrypts the random number with his private key. Now Bob has a secret shared with only Alice that they can use to encrypt and decrypt messages to each other.

In reality, most security protocols are much more complicated than this, but the three-step process above gives you an idea of the fundamentals. SSL is an excellent example of a security protocol that uses these techniques to safeguard communications. This process is examined in greater detail later in the paper.

Public Key Certificates

Digital certificates, also called digital IDs, digital passports or public key certificates, are defined by an International Telecommunications Union (ITU) standard called X.509. A certificate is the digital equivalent of an employee badge, passport or driver's license.

The certificate and corresponding private key identify you to someone who needs proof of your identity. If you are pulled over by the highway patrol, you need to show your driver's license to prove that you are legally licensed to drive a car. If you want to get into a secure workplace, you might have to show a badge to prove that you are an employee of the company. If you want to make a credit card purchase, you typically have to show the credit card and demonstrate that you can produce a signature like the one on the back of the card. All these forms of identification allow you to establish your identity with someone.

Over a network, a certificate serves the same role as a driver's license, employee badge or credit card: It establishes your identity. Servers may be configured to grant access only to people with particular certificates. Similarly, clients may be configured to trust servers that present certain certificates.

What's in a certificate? An X.509 certificate is typically a small file that contains the following information:

Field Description Examples
Subject's distinguished name (DN) A name uniquely identifying the owner of the certificate C=US, OU=Technology
Issuer's distinguished name (DN) A name uniquely identifying the certificate authority that signed the certificate C=US, O=VeriSign, CN=VeriSign Class 1 root
Subject's public key The owner's public key 512-bit RSA key
Issuer's signature The certificate authority's digital signature from which the certificate derives its authenticity RSA encryption with MD5 hash (signature itself is not human readable)
Validity period Dates between which the certificate is valid Not before Wed, Nov 4, 1997, 15:54:17 Not after Fri, Dec 31, 2001, 15:54:17
Serial number A unique number generated by the certificate authority for administrative purposes 02:41:00:00:01

How Does Cryptography Help?

With this overview of public key technology in mind, we can review the challenges described at the beginning of this paper and see how public key technology embodied in industry-standard protocols such as SSL and S/MIME offers solutions.

Requirement Public Key Technology Example of Typical Use
Authentication of users without user name and password in the clear Digital certificates (X.509) SSL handshake includes exchange of client and server certificates and corresponding signatures.
Single-user login Digital certificates (X.509) Servers may be configured to demand digital certificates rather than user name/password pairs.
Scalability to the Internet Standards-based encryption and message digest algorithms (for example, RSA, DES) negotiated using industry-standard protocols (for example, SSL) Unlike most proprietary security systems, SSL works both inside and outside the firewall.
Message privacy (real-time as well as store-and-forward applications) Public key encryption and RSA decryption (for example, RSA); often used in conjunction with symmetric key technology (for example, RC2, RC4 and DES) for higher performance SSL protects the session key used to encrypt and decrypt a data stream with public key encryption. S/MIME uses a similar technique for encrypting and signing e-mail messages in a store-and-forward paradigm.
Message integrity Message authentication codes calculated using message digest algorithms (MD5, SHA1) SSL calculates message authentication codes using a message digest algorithm and a key negotiated during the SSL handshake.
Protection of confidential documents from unauthorized access Digital certificates (X.509) and signatures This binds users listed in access control lists to certificates or requires that users present a particular certificate for access.

Secure Sockets Layer

SSL is an industry-standard protocol that makes substantial use of public key technology. It is widely deployed on intranets as well as over the public Internet in the form of SSL-capable servers. SSL provides three fundamental security services, all of which use public key techniques:

Service Underlying Technology Protection Against
Message privacy Encryption Eavesdroppers
Message integrity Message authentication codes (keyed hash functions) Vandals
Mutual authentication X.509 certificates Impostors
  • Message privacy. Message privacy is achieved through a combination of public key and symmetric key encryption, as described earlier. All traffic between an SSL server and SSL client is encrypted using a key and an encryption algorithm negotiated during the SSL handshake (described below). Encryption thwarts eavesdroppers who can capture a TCP/IP session using devices such as IP packet sniffers. Even though packet sniffers can still capture the traffic between a server and client, the encryption makes it impractical for them to actually read the message.

  • Message integrity. The message integrity service ensures that SSL session traffic does not change en route to its final destination. For the Internet to be a viable platform for electronic commerce, we must ensure that vandals do not tamper with message content as it travels between clients and servers. SSL uses a combination of a shared secret and special mathematical functions called hash functions to provide the message integrity service.

  • Mutual authentication. Mutual authentication is the process whereby the server convinces the client of its identity and (optionally) the client convinces the server of its identity. These identities are coded in the form of public key certificates, and the certificates are exchanged during the SSL handshake.

To demonstrate that the entity presenting the certificate is the legitimate certificate owner (rather than an impostor), SSL requires that the certificate presenter must digitally sign data exchanged during the handshake. The exchanged handshake data includes the entire certificate. The entities sign protocol data (which includes their certificates) to prove they are the legitimate owner of the certificate. This prevents someone from masquerading as you by presenting your certificate. The certificate itself does not authenticate; the combination of the certificate and the correct private key does.

What Happens During the SSL Handshake?

SSL is designed to make its security services as transparent as possible to the end user. Typically, users click a link or a button on a page that connects to an SSL-capable server. A typical SSL-capable Web server accepts SSL connection requests on a different port (port 443 by default) than standard HTTP requests (port 80 by default).

When the client connects to this port, it initiates a handshake that establishes the SSL session. After the handshake finishes, communication is encrypted and message integrity checks are performed until the SSL session expires. SSL creates a session during which the handshake needs to happen only once. Performing an SSL handshake for every HTTP connection would result in poor performance.

The following high-level events take place during an SSL handshake:

  1. The client and server exchange X.509 certificates to prove their identity. This exchange may optionally include an entire certificate chain, up to some root certificate. Certificates are verified by checking validity dates and verifying that the certificate bears the signature of a trusted certificate authority.

  2. The client randomly generates a set of keys that will be used for encryption and calculating message authentication codes. The keys are encrypted using the server's public key and securely communicated to the server. Separate keys are used for client-to-server and server-to-client communications, for a total of four keys.

  3. A message encryption algorithm (for encryption) and hash function (for integrity) are negotiated. In SSL implementation, the client presents a list of all the algorithms it supports, and the server selects the strongest cipher available. Server administrators may turn particular ciphers on and off.

Next Week: "Securing Communications Over an Intranet: Part 2" looks at deployment solutions and trade-offs for secure communications and collaboration.