Encryption Technology

Encryption, or information scrambling, technology is an important security tool. Properly applied, it can provide a secure communication channel even when the underlying system and network infrastructure is not secure. This is particularly important when data passes through shared systems or network segments where multiple people may have access to the information. In these situations, sensitive data--and especially passwords--should be encrypted in order to protect it from unintended disclosure or modification.

Encryption is a procedure that involves a mathematical transformation of information into scrambled gobbledygook, called "cipher text." The computational process (an algorithm) uses a key--actually just a big number associated with a password or pass phrase--to compute or convert plain text into cipher text with numbers or strings of characters. The resulting encrypted text is decipherable only by the holder of the corresponding key. This deciphering process is also called decryption.

Several approaches to encryption are being explored at the UW. However, substantial barriers to widespread deployment remain. For one thing, there are many different and incompatible encryption techniques available, and not all the software we need to use implements a common approach. In the long run, effective use of encryption will require vendors to agree on which methods and standards to follow.

Private-key and Public-key Cryptography

Two different cryptographic methods are being applied to computer security problems: private-key and public-key encryption.

[Graphic: The STAR Online Web site's sign-on screen.]

STAR Online (an extension of the Student Telephone Assisted Registration) uses SSL public-key technology to provide a secure communication channel in which UW students authenticate themselves before doing tasks such as changing their address, or checking their grades or tuition balance, that they are authorized to do.

In private-key encryption, the sender and receiver of information share a secret--a key that is used for both encryption and decryption.
In public-key encryption, two different mathematically related keys (a key pair) are used to encrypt and decrypt data. Information encrypted with one key may only be decrypted by using the other half of the key pair.

One of the most common uses of public-key technology is to provide a secure communication channel between computer programs, although private-key techniques can be used for this, too. A prime example of public-key technology is the SSL protocol (see STAR Online screen), often used to protect information sent between Web browsers and Web servers. Public-key cryptography also provides the foundation for secure email, discussed at the end of this article.

When using a public-key system for personal authentication or secure messaging, you keep one key secret. The second (public) key can then be distributed to anyone. Some people put their public key on their personal Web page; it might also be stored on a public-key server.

The secret (or private) key in a public-key cryptographic system is never transmitted or shared. For example, when using this method for client-side authentication, the server sends some data to your client program. The client uses your private key to encrypt that data. Using your public key, the server will attempt to decrypt the returned data, and, if successful, know that it has established communication with "the real you."

Cryptographic Authentication

Encryption can be used to support our authentication, integrity, privacy, and non-repudiation objectives. Let's focus on authentication first.

Providing a way to authenticate yourself to a computer system without sending your password "in the clear" is an important security goal. Passwords sent without encryption may be discoverable by others if sent through or to insecure network segments or systems. Several approaches are being used to avoid the clear-text password problem:

Shared network segments are gradually being replaced by "switched" network segments. The newer, switched network technology greatly reduces the opportunity for "sniffing" or eavesdropping on people's conversations.
Methods for sending passwords through secure (encrypted) channels are beginning to be deployed.
Cryptographic authentication systems, which do not rely on transmitting passwords, are being deployed.

In this last category, there are two contenders: the Kerberos authentication system (based on private-key cryptography), and personal certificates (based on public-key cryptography). Each requires significant resources to support it campuswide.

Key Management

One of the big challenges in using cryptography on a widespread basis--especially public-key encryption--is the management of private and public keys. Private encryption keys need to be:

Backed up and recoverable
Protected against theft
Matched with encrypted data
Accessible from many systems
Accessible only to the authorized user

Another challenge for the UW will be to set policy on when and how institutional information is encrypted. In addition, public records requests and subpoenas will need to be honored regardless of whether or not records are encrypted.

Certificates

Certificates are essential ingredients in a public-key infrastructure. A certificate is a special kind of digital document that establishes a connection between you and your public key. It does this by being digitally "signed" by a trusted third party, sort of like a digital notary. If you or your software are presented with a certificate that is signed by a "certificate authority" you deem trustworthy, it is like having someone you know introduce a new acquaintance: "Susan, I'd like you to meet John."

[Graphic:
Certificate properties Web screen.]

A certificate is issued by a certificate authority, in this case Thawte Consulting.

Without establishing this kind of trust relationship, a criminal could attempt to steal your identity by distributing his or her own public key and asserting that it was yours. A digital certificate binds you to your public key.

You obtain a certificate by applying to a certificate authority (CA). Once the CA verifies you are who you say you are, it creates a certificate--a digital document--for you. The certificate contains:

A name that is unique to you
The length of time the certificate is valid
Your public key
Your key's purpose: to sign messages or to encrypt data

Trust plays an important role in any public-key technology. How much weight a certificate carries depends on the type of authentication information that was required by the CA before issuing the certificate.

Certificates are used by many Web sites to authenticate their Web server to your browser. They can also be used to authenticate the client to the server.

Web browsers are shipped with a list of trusted CAs. These include companies like Thawte Consulting (see certificate properties screen above; www.thawte.com/) and VeriSign, Inc. (www.verisign.com/).

The challenge. In order for the UW to manage certificates to be used with applications, we will have to take care of:

Production and maintenance of a very large standards-based directory
Support for a highly distributed computing environment
Methodologies supporting transparent access by applications
Private and public key storage and access issues
Incompatibility of browser vendors' certificate formats

If the UW became a certificate-issuing authority, we would have to deal with additional issues such as:

Maintenance of a certificate repository
Methodology for verifying individuals and departments
Management of certificate revocation lists (CRLs)
Renewal of key pairs and certificates
Support for trust relationships with other certificate authorities

Certificates may be used to establish the identity of an individual, or of a computer. The UW is currently using certificates for central Web servers so that they can establish secure communication links with Web clients.

How client, or personal, certificates will fit into the university's future security infrastructure remains to be seen. While there are a small number of Web servers, and therefore a modest certificate management task for them, deployment of personal certificates for everyone at the UW would be a much bigger challenge, with lots of new policy questions.

Secure messaging is the principal driver for using personal certificates. Other alternatives can be used to address security problems in online systems, including Web-based transaction systems. However, the technical, policy, and management issues mentioned previously must be resolved before any widescale deployment of a public-key infrastructure is reasonable.

Digital Signatures

Digital signatures provide a way to protect the integrity of a digital document and to verify who signed it. The document in question could be anything: an email message, a file on a floppy disk, or the information in a personal certificate.

Protecting a document's integrity is done by giving the recipient a way to determine whether or not the document has been modified since it was digitally signed. Doing this involves two cryptographic techniques: message digest algorithms and public-key encryption.

To allow a document's integrity to be verified, a mathematical function is applied to the bits that make up the digital document. The resulting number is called the "message digest." It has the property that if the document is altered, applying the same function would result in a different message digest. If a message digest computed at the time the document was signed can be compared with one computed at a later time, it is possible to know whether the document was--either accidentally or intentionally--modified at some point in between.

The diagram that follows illustrates how digital signatures can be applied to email, though the same ideas apply regardless of how a document is transmitted electronically, and regardless of whether it is thousands of pages of human-readable text or a short computer-to-computer message such as a public-key certificate.

[Graphic: Diagram of a man-in-the-middle attack to alter an email
message and how the author can safeguard it.]

(A) The author's message is altered by the man-in-the-middle attack and the recipient is not aware that the message has been changed.

(B) The author uses a message digest (MD). The recipient recalculates the MD and, because the two MDs do not match, he knows the message was altered.

(C) The man in the middle recalculates and replaces the MD on the altered message before sending it. The recipient will be fooled.

(D) The author creates her digital signature by encrypting the MD with her private signing key. The man in the middle does not have the author's private key with which to alter the original MD, so the MDs do not match.

Digital signatures work this way: The author of the document calculates a message digest by putting the data through a one-way mathematical hashing process (represented by "#" in the diagram). This binary representation ("7012" in the diagram) is like a fingerprint that can be produced only from the original message using the same hashing algorithm.

The message digest is sent along with the document so that the recipient can recalculate the message digest from the document and compare it with the digest received with the document ("B" in the diagram). If the digests are the same, then the message sent and the message received are exactly the same.

The challenge. Message digests alone are not a complete solution for ensuring that a document has not been modified. Someone might intercept a message and its digest, modify the message, recalculate a new digest, and send both on to the recipient ("C" in the diagram). This is called a "man-in-the-middle" attack.

Thus, a digital signature must be more than just a message digest value for the signed document. A digital signature wouldn't be worth its salt if it could be easily modified along with the document. So the message digest itself must somehow be protected from modification.

This is where the second cryptographic technique comes in. The message digest is encrypted using the private key of the document's author ("D" in the diagram). The recipient may then decrypt the message digest using the public key of the originator and, assuming they used the correct public key, have assurance that the message digest they decrypted has not been modified since the document was signed.

Thus, using a digital signature makes a man-in-the-middle attack more difficult to carry out because the process of digitally signing a document includes calculating the message digest and then encrypting it.

If, for example, you wish to digitally sign a document being sent to Tom, the message digest would be encrypted using your private signing key. Tom would then verify your digital signature by using your public key (the other half of your signing key pair).

What Does a Digital Signature Look Like?

A digital signature is not a graphical representation of a handwritten signature (a "John Hancock"). It is data created by encrypting a message digest with a private signing key to identify and authenticate the sender and the message. If compatible encryption software is installed on the recipient's computer, it will automatically try to verify the signature.

The State of Washington provides this example:


-------BEGIN SIGNATURE------

IQB1AwUBMVSiA5QYCuMfgNYjAQFAKgL/
ZkBfbeNEsbthba4BlrcnjaqbcKgNv+a5kr4537y8RCd+RHm
75yYh5xxA1ojELwNhhb7cltrp2V7LlOnAelws4S87UX80cL
BtBcN6AACf11qymC2h+Rb2j5SSU+rmXWru+=QFMx

-------END SIGNATURE------

Keys, Keys, and More Keys

As described previously, public-key cryptography involves two keys, a public one and a private one. But it gets better.

A public-key infrastructure that enables personal certificates for authentication, digital signatures for protecting document integrity and identity, and encryption for privacy, will undoubtedly require managing multiple key pairs for everyone using these capabilities. Different service providers may require different certificates and keys, and different functions call for using different keys.

In particular, a digital signature key pair should not be the same key pair used for encrypting messages. Digital signature keys and encryption keys need to be managed differently:

Encryption keys should be backed up and managed centrally in order to ensure the recovery of data that has been encrypted by them
Digital signature keys should not be backed up or managed centrally because they need to stay in the users' control to ensure non-repudiation

The challenge. Although digital signature technology is available today, very difficult management and policy issues stand in the way of widespread deployment. Secure messaging is the primary place we would use digital signatures, and is the application that would drive deployment of a public-key infrastructure for personal certificates.

Special Problems of Secure Messaging

An important application of public-key cryptography is secure email. When you send an encrypted message to Sue, you can encrypt it with Sue's public key and expect that only Sue can decrypt it (with her private key) because she is the only one who has her secret key.

Further, by using your own private key, you can also digitally sign the message, either in addition to encrypting it, or in lieu of encryption (in cases where the content does not require privacy protection, but authentication and integrity are needed).

As previously described, the digital signature is created by encrypting a message digest with your private signing key. This digital signature is then sent along with your message. However, signing and encrypting messages is easier said than done. The program you use to send signed and/or encrypted messages must have access to all of your recipients' public keys, to your encryption key, and to your signing key.

As mentioned, secure email is one of the few applications that requires use of a public-key cryptography infrastructure (PKI). Managing keys for a PKI is difficult to do on the scale necessary for an institution such as the UW. Some of the challenges relating to managing a PKI, for digital signatures in particular, include:

Interoperability, given that there are incompatible methods in use
Policies for accepting a digital signature and determining which applications should be required to use them
Procedures for accessing and distributing public keys
Policies relating to certificate authorities and certificate expiration

Key management is even more difficult when you would like to use your private keys from more than one computer. Almost all applications using PKI assume that your private key exists on the local hard disk of a single computer. In the future, use of "smart cards" to store these keys may mitigate this problem, but there are other challenges to deploying a public-key infrastructure that are either unique to or exacerbated by secure messaging:

Different key pairs should be used for signing and for encrypting
The keys used to sign or to encrypt a message must be available for as long as anyone needs to verify or decrypt the message
The email PKI management problem is also more complex when messages cross international boundaries, since the U.S. government does not permit export of certain forms of encryption technology (even when it is readily available outside the United States)

There are a number of incompatible methods of doing secure messaging. The two most common are S/MIME and PGP. S/MIME has the advantage that it is supported "out of the box" by Netscape's and Microsoft's email programs, though many have found it challenging to follow all the steps necessary to obtain the requisite keys and certificates.

S/MIME's leading competitor is PGP (Pretty Good Privacy). PGP is not directly supported by either Netscape or Microsoft, but add-on software is available to use it with those and many other mail programs.

More information about PGP and cryptography is available at www.pgpi.com/overview/ and, about S/MIME, at www.rsasecurity.com/standards/smime/faq.html

Although widespread deployment of a public-key infrastructure to support secure email is still a ways off at the UW, a few individuals here are successfully using secure email on a small-scale basis. This involves acquiring suitable software, because all correspondents must have a compatible encryption package, and then exchanging public keys or publishing them on public-key servers.

University of Washington Computing & Communications
Windows on Computing, No. 22, Winter 1999
newsltr@cac.washington.edu