Chapter 10: Encryption

The Internet is a wonderful thing. It allows knowledge to be shared with the world. But what if you want to use the Internet to share knowledge with just one person? When web pages, e-mail, and even passwords are transferred across the Internet, they are free to be seen by anyone who cares to look. You may ask, 'Who is going to be looking, anyway?' The answer, in most cases, is nobody. Anonymity can be your security. This is especially true of your Internet presence from home.

However, the situation changes when you use your credit card over the Internet, or when you are a business on the receiving end of a credit card transaction. In such cases, anonymity clearly doesn't provide enough security. Furthermore, what if you receive a sensitive document, but you are unsure if the person who sent it really is who they claim to be? How do you know that this same document wasn't tampered with between the time it was sent and the time you received it? And what if you need to protect sensitive data on your web site, or perhaps you want to protect the data in transit to the user, or authenticate the user with a stronger authentication method?

About Digital Certificates

IIS provides digital certificates to accomplish the kind of security that you may need, via the Secure Socket Layer (SSL) protocol. IIS 6 supports the SSL encryption/authentication method for web sites, and security is accomplished through the use of digital certificates.

Three types of certificates can be used:

• Server certificates Provide an encryption method for data transmitted over a network (with SSL); also provide identification methods for the server, so a client can be assured the web site they are accessing is indeed what it claims to be.

• Client certificates Provide identification for the client so the server knows the client is who they claim to be; also provide a stronger means of authentication than Basic Authentication. Client certificates do not provide data encryption.

• Code signing certificates Provide a means to digitally 'sign' your application with a digital ID that is created based on the contents of the application. If anything is modified in the application after it's signed, the ID won't match, and the user will be alerted to that fact. Code signing certificates do not encrypt the application.

Certificate Keys

Digital certificates use a technology called a key when they encrypt data. To understand how digital certificates work, you need to have an understanding of keys.

Note 

A key is a piece of data used by a cipher to encrypt plaintext into cipher text. A cipher is a mathematical algorithm that does the work of encrypting or decrypting data.

There are two forms of encrypting using keys. Often they work hand in hand.

• Symmetric-key encryption Uses the same key to encrypt the data that will be used to decrypt it. This form of encryption is efficient, resulting in little time lost for the user. It also provides some level of security because the receiving party has to know the key to decrypt the data. The major disadvantage to symmetric-key encryption occurs if someone were to learn the key; they could not only decrypt data, but also encrypt it and impersonate the sender.

• Public-key encryption Takes keys a step further. IIS gives you the choice of DH (Diffie-Hellman) and RSA (for developers Ron Rivest, Adi Shamir, and Leonard Adleman) public-key encryption. RSA is the more common form and is the focus in this chapter. With this model, when you create a key, you are actually creating a key pair that consists of a public key and a private key.

The public key is distributed freely. The data encrypted with the public key can be decrypted only with its private-key counterpart. Since the only person to have the private key would be the owner, the only person able to see the data after it is encrypted would be the person meant to see it. Not even the person who encrypted the data can decrypt it without the private key.

The private key is kept, well, private. The private key can also be used to sign data for authenticity. The public key can be used to verify that the signature is authentic and that the data has not been tampered with. When data is encrypted with the private key, not even the person who encrypted the data can decrypt it without the public key. Again, because the only person to have the private key is the owner, theoretically, the data would be authentic. When used the other way, the private-key holder is the only one who can see that data.

When compared to symmetric-key encryption, public-key encryption requires more overhead and is not as efficient. When encrypting large amounts of data, this can have a serious impact on performance. But, you can use public-key encryption to encrypt a symmetric key, and then use a more efficient symmetric key to encrypt the rest of the data. This is exactly what SSL does.

Encryption Strength

The strength of encryption relies on the length of the key and the type of cipher used to do the encryption. Messages created with a 128-bit key are 3 × 10²⁶ times more difficult to crack than a 40-bit key. This can shed some light on why the U.S. government previously did not allow technology to be exported that supports keys larger than 40 bits. For security proposes, the U.S. government relied on the fact that it can decipher encrypted data that has been intercepted. This is decidedly more difficult with 128-bit keys! The cipher used can also make a big difference. For example, data encrypted with symmetric-key encryption, such as Data Encryption Standard (DES) using a 64-bit key, is comparatively as secure as an RSA encrypted message using a 512-bit key.

Note 

Nowadays, the U.S. government allows 128-bit encryption to be exported to all non-embargoed countries.

Digital Signatures

Now that you can encrypt data, how can you be sure that it came from the source that claims to have sent it and that it has not been tampered with en route? Digital signatures are the answer to both of these problems. Digital signatures are made from two components: a one-way hash and a public-key cryptosystem.

One-Way Hash Encryption A one-way hash (sometimes called a message digest) is a set of data created by an algorithm used to verify that the document you received has not been tampered with since the hash was created. When you apply a document to the one-way hash algorithm, a set of data unique to that document is created. The document is then sent along with the one-way hash that was created. When received, the document is run through the hash algorithm again. The new hash is then compared to the one received with the document. If they are different, the document has been tampered with. Even changing one character or adding one space will completely alter the hash created. There is arguably no way to create the document from only the hash. That is why it is called a one-way hash. The two most common one-way hash algorithms are MD5 message digest algorithm from MIT professor Ron Rivest (the same person who helped develop RSA), and SHA secure hash algorithm from the National Institute of Standards and Technology (NIST) and the National Security Agency (NSA). MD5 creates a 128-bit value while SHA creates a 160-bit value.

Your private key can also be used to encrypt data that only your public key can decrypt. This normally would not be a good idea, however, since anyone would be able to decrypt it-except for the fact that when you decrypt something with the public key, you are in essence verifying the sender, as only its private counterpart could have sent it, and only one person has access to it. This, of course, assumes that your private key has not been compromised. The data encrypted with your private key is your public-key cipher text.

When you encrypt the one-way hash that is unique to the data that is being sent with your private key, you have just created a digital signature. Now the digital signature can be decrypted to verify your identity, and the one-way hash can be compared to verify integrity. Two birds with one stone, so to speak.

Certificate Authorities and Trusts How can you know that the public key you are using to send encrypted data is trustworthy? When someone first creates a public/ private-key pair for use with a web site, he is actually requesting an x.509 SSL certificate (x.509 is a standard defined by RFC 2459) from a certificate authority (CA)-a server that issues certificates. A CA can also authorize any number of subordinate CAs, and those subordinate CAs can authorize more CAs, and so on. The first CA in the chain is called the root CA, and only one root CA can exist in any given chain. When an SSL certificate is issued, the issuing CA verifies that the information submitted by the requesting entity is correct. The details of the verification policies are specific to each CA.

A Client Computer's Use of Certificate Authorities

A client computer will have a certain number of default CA certificates installed; these are 'trusted' CAs. Which CA certificates are installed is specific to the software being used (such as Internet Explorer or Netscape). When presented with an SSL certificate from a web server, the client will look for the issuing CA's (as specified in the SSL certificate) certificate in its cache. If the certificate is located, the client will verify the issuing CA's signature on the SSL certificate with the public key found in the cache, thus authenticating the web server. If the issuing CA's certificate cannot be found in the cache, the client will request the certificate and then begin the process again by trying to verify that CA's certificate. If you reach the root CA and no CA's certificate can be authenticated, you will be warned that the SSL certificate could not be verified and you should not accept it. If at any time you reach a CA whose certificate is in your cache, the SSL certificate will be accepted.

Checking Your Browser's CA List You can view what CAs your browser trusts. To do this in Internet Explorer (IE 6 for this example), use the following steps:

1. In Internet Explorer, choose Tools | Internet Options.

2. Click the Content tab.

3. In the Certificates section, click Certificates.

4. In the Certificates window shown in Figure 10-1, click the Trusted Root Certification Authorities tab-your trusted root CAs are listed here.

   
   Figure 10-1: Certificates window of IE

Adding a CA to Your Browser's Trusted List If you visit a site that is trying to use a certificate for a CA that isn't trusted by your browser, your browser will let you know. You can still accept the certificate and continue with the secure communication. While you will still be encrypting your data, you have skipped one of the main functions of certificates: authentication. When you accept a certificate from a CA that isn't trusted, you are basically saying you don't care who they are, you just want to proceed with the transaction. If you have other means of verifying who they are, this may be acceptable. If you trust a CA that isn't trusted by your browser, such as your company's CA, you can add the trusted certificate to your browser so you won't have to view the warnings next time.

Here's how to add a trusted root CA to Internet Explorer:

1. Request a CA certificate from the CA you want to trust. This is specific to the company that owns the CA, so contact the administrator.

2. Place the certificate somewhere accessible by your computer, such as a local drive or a file share.

3. Open Internet Options, either from the Control Panel or by choosing Tools | Internet Options within Internet Explorer.

4. Click the Content tab.

5. Click Certificates in the Certificates section.

6. Select the Trusted Root Certification Authorities tab.

7. Click Import, and a Certificate Import Wizard will open.

8. Click Next on the welcome screen.

9. Click Browse, and then select the CA certificate you received.

10. Click Next.

11. You can leave the defaults as is in the Certificates Store screen.

12. Click Next.

13. Click Finish. You will see a message box telling you that your import was successful.