Encryption

[Previous] [Next]

Encryption forms the foundation of secure communication. Encryption is a huge topic, and neither this chapter nor any single book can completely cover it. The goals of this section are to provide some background on the topic and explain some key concepts and important terms.

Two or more communicating parties can use encryption to share information securely. In general terms, this is accomplished when one party modifies data in such a way that the data cannot feasibly be restored to its original state without the use of a key. A key is a digital value that is used by an encryption algorithm to encrypt data. A key is also a digital value that is used to decrypt data. The modification of data is encryption. The receiving party is able to restore the data (and therefore understand it) using the key, a process known as decryption. The study of data encryption and decryption is called cryptography.

Typically cryptography is used to ensure one or more of the three goals are met over insecure communication medium:

• Privacy Nobody but the intended party can understand the data being communicated.
• Authentication You have established with whom you are communicating.
• Integrity The data you have received has not been modified by a third party in transit.

Symmetric Key Encryption

Commonly, when people speak of encrypted communication, they are referring to a conversation between two parties that share a single secret key. The same key is used for both encryption and decryption of data. This is called symmetric key encryption.

Symmetric key encryption is appropriate only in environments where it is reasonable for two parties to share a secret. As this chapter unfolds, you will see that both the Microsoft Windows NT LAN Manager (NTLM) and Kerberos security protocols used by Windows 2000 (discussed later in this chapter) make use of symmetric key encryption.

There are, however, scenarios in which symmetric key encryption falls short. Here are some reasons:

• Two parties must hold symmetric keys, requiring the parties to communicate these keys. This communication of keys can become a security risk.
• Both parties must be trusted to use the key. What one party can do with a key, another party can do with the key. This is a concern when a known principal is communicating with an unknown principal.

These points might seem to create insurmountable problems in an environment in which many parties will need to communicate with one another in a secure manner, such as in an enterprise LAN. However, in an environment with known entities, such as a corporate network or a Windows domain, symmetric key encryption can be used to create very elegant and secure communication solutions. You will see an example of this in my discussion on Kerberos later in this chapter.

Asymmetric, or Public Key, Encryption

The Internet has created an environment in which communication must sometimes be secure, even when one or more of the communicating principals have no previous knowledge of one another. Clearly, in an environment such as the Internet, it is infeasible for each party to share a secret key. This is where asymmetric, or public key, encryption shines.

Public key encryption makes use of two keys: a public key that is intended to be shared, and a private key that must be kept secret. Data encrypted with the public key in a pair can only be decrypted using the private key. Conversely, data encrypted with the private key can only be decrypted using the public key.

You can't derive the private key in a pair from the public key. However, using brute-force techniques you can enumerate all possible private keys until a match is found for a public key. This approach, however, is computationally infeasible and becomes exponentially more difficult as the width of the keys increases.

As you can see, a system like this has a great deal of potential. It is now possible for you to publish your public key so that an agent who wishes to communicate with you can encrypt his data with your public key, knowing that only you can read the data because only you hold the private key.

Unfortunately, algorithms to encrypt and decrypt data using asymmetric (public/private) key pairs are very slow in comparison to algorithms using symmetric key encryption. Because of this, encrypting large amounts of data using asymmetric key encryption is usually unreasonable.

To get around this problem, many protocols make use of public key encryption to communicate a symmetric key. Then symmetric key encryption is used during the remainder of the conversation, or "session." This way, the advantages of public key encryption can be realized while enjoying the efficiency of symmetric key encryption.

Digital Certificates

Digital certificates, or certificates, are a means of packaging or publishing the public key in an asymmetric key pair. Digital certificates can also contain additional information such as the owner of the key pair and the allowed usage of the certificate.

NOTE

---

The private key in an asymmetric key pair is never packaged in a certificate, because it should never be published. It is tightly held by the owning entity.

If you are able to trust the validity of a certificate, you can use the public key held within the certificate to decrypt data from the owner of the certificate. In this way, you can trust the data and the source of the data. Similarly, if you trust the validity of the certificate, you can encrypt data using the public key found in the certificate, knowing that only the rightful owner of the certificate can decrypt the data. This type of technique is used when you communicate credit card information using your Web browser on a secure commercial Web site such as Amazon.com or Ebay.com.

A great deal is riding on your software's ability to trust the validity of a certificate, and therefore to trust the validity of a public key. This is where an entity known as a certificate authority, or CA, steps in.

Certificates are issued by a CA, which signs the certificate with its own public key. By signing the certificate, the CA promises that the information held in the certificate, including the public key, is correct. If you hold the public key of the CA (which I will discuss in more detail in a moment), you can assure that the signature of the certificate is intact, at least as far as this CA is concerned.

The entity you are trusting is the certificate authority, which issued the certificate in question. A client trusts a certificate authority by holding a copy of the CA's public key and using it to verify the signature of certificates that it receives. Once the client verifies the signature, it can choose to trust the information found in the certificate based on its trust relationship with the CA.

Examples of two certificate authorities include VeriSign, which can be found at www.Verisign.com, and Thawte, which can be found at www.Thawte.com. There are dozens more.

Depending on your needs, you might find it to your advantage to set up your own CA using Microsoft Certificate Services or similar software. Doing so will allow you to create and distribute certificates for use in your own enterprise or Internet environment, potentially increasing your flexibility with certificates and saving you money on certificate licensing fees.

I can't include a truly comprehensive discussion of certificates in this chapter, but it is an important technology to be aware of. Certificates will come up again later in this chapter when we discuss the Secure Sockets Layer (SSL) security protocol. For a more comprehensive discussion on the topic, I suggest you consult the Platform SDK documentation or research the topic using the World Wide Web.