Use of Keys in Upper-Layer Authentication

Authentication is part of a process of creating a security context within which communications can take place. Because the process of full authentication is costly and time consuming, it is common to do full authentication occasionally and provide some token that can be used as proof of authentication in subsequent transactions. In the case of RSN, and indeed most security protocols, the proof is provided by creating secret key values as part of the authentication process.

The upper-layer authentication method is responsible for proving beyond a doubt that each party possesses some secret knowledge connected to their identity, and for providing the tokens or keys needed to support a security context. It has to do this in a way that does not leak any useful information about the shared secrets.

Before looking in detail at individual methods, let's look at the two main classes of solution: symmetric keys and asymmetric keys, sometimes known as secret and public keys, respectively.

Symmetric Keys

The concept of the symmetric secret key is simple. Each party has a copy of some secret information. Authentication occurs when each party proves to the other that they know the secret. This is like the child's method, "You can't come in unless you tell me the password." When each party has proved itself, they can both create matching session keys for use in the security context. Such keys are derived from the secret master key but may also incorporate other information, such as the time and arbitrary numbers created for the session (called nonces). The purpose of these extra items is to ensure that the session keys are usable only in the current session and cannot be reused later.

The main limitation with the secret key approach is that you have to get the secret to both parties in the first place. Sometimes that is not a problem. To communicate with your domestic partner, for example, you could agree on your secret Wi-Fi LAN key during a private moment when no one else is listening. This scenario, or at least the key exchange part, also works in corporate environments in which there is a secure place for the two parties, such as the employee and the IT manager, to meet. However, the approach doesn't scale at all for widespread use. In a huge corporation it is hard to distribute such keys and, in the case of Internet commerce, it is impossible. When you want to make a secure exchange with another party in another country whom you have never met, and never will, there is no practical way to safely agree on secret keys by informal communication.

Asymmetric Keys

To deal with the situation in which you can't easily distribute the secret key, the idea of asymmetric key encryption was invented, leading to the use of public keys. Public key encryption is supported by a set of components often referred to as PKI (public key infrastructure).

First, let's look at the encryption part of public key use. The very words "public key" sound like a contradiction in terms. If the key is public, what use can it be for privacy? However, this name is misleading because a person who uses public key encryption actually has two keys. One key is made public and the other must be kept private. Furthermore, these are not any two keys; the public and the private copies are a mathematically connected pair. The way public key encryption works is fascinating and almost counterintuitive.

As an analogy, suppose a wizard wants to send you a message. He writes the message on a piece of paper and puts it in a magic box. Now he closes the box and recites your name three times. The box is immediately sealed and cannot now be opened by anyone except you; not even the wizard can open it. When the box arrives, you recite a secret word three times and the box opens. The wizard knows your name and can seal the box with it; that is your public key. But only you know the secret word to open the box again; that is your private key.

How does this work with encryption? Many encryption systems are symmetric in that the same key is used to encrypt and then decrypt the message. However, public key systems use an asymmetrical method in which different keys are used for encryption and decryption. You encrypt with key E and decrypt with key D. Furthermore, you can't decrypt with key E, and knowing E doesn't enable you to compute D. In public key encryption, E is the spell to seal the box, or the public key. D is the spell to open the box, or the private key.

When you want to use public key encryption through programs such as PGP (Pretty Good Privacy), you first use a key-generating utility. You run this utility and usually enter some personal information to help ensure your keys are unique to you. The utility then generates two key values, a public key and a private key. The public key can be given to anyone. And the key can be used to encrypt a message using your public key and send it to you. Only you can decrypt the message because only you know the private key. It's like magic!

A subtle and important variant of this method lets you sign messages. Signing a message is like signing a document: It is intended to prove that the message came from a particular person. Message signing works in the reverse way from encryption. You use a private key to create a signature and a public key to check the signature. In a simple case, you take your name and encrypt it with your private key. The result is added to the end of your message. Anyone who receives the message (friend or foe) can decrypt the signature using your public key. If the signature successfully decrypts and reveals your name, it proves that you must have sent the message because no one else knows the secret key that was used to encrypt it. A forger could not have encrypted your name correctly because she wouldn't know your secret key. So this proves that you approved the message in the same way that signing a letter does actually, much stronger.

In reality, the above scheme doesn't prevent someone from creating a new bogus message and copying your encrypted signature from a valid message (like photocopying your signature on a letter). To protect against this, you must do more than include your name in the signature; you must include other information as well. In practice, the entire contents of the message are usually included in the signature computation to protect against tampering.

Because verifying that a message really came from the sender is very important, systems like PGP do both encryption and message signing. Remember that public key encryption by itself provides privacy but does not authenticate the sender. Suppose you receive an encrypted message saying, "Sally, come quickly, I need your help. Meet me at the bar downtown, Fred." How do you know the message is real (ignoring the fact that your name probably isn't Sally)? The message is encrypted with your public key, so anyone could have forged it. A burglar may want you to leave your house, or worse. But if Fred signed the message with his private key, you can verify that it was really him who sent it, right?

Well, maybe … it depends. Now we are back to our original key distribution problem. How do you know that Fred's public key really belongs to Fred? In this case, it's probably because you met Fred face to face and he told you the public key. Or more likely, you have had various exchanges of e-mail with Fred using his key and you trust that it really is him. But suppose you just started using public key yesterday and you received an e-mail (unencrypted) from Fred two days ago that said, "Hi. This PGP stuff is cool let's use it. My public key is: FREDSKEY." Can you be sure that Fred sent this message and not some (computer-literate) burglar? This is reminiscent of the sort of problem that we had with the distribution of symmetric secret keys.

Certificates and Certification Authorities

What is needed is a way to certify that public keys are legitimate. This issue of certifying that a public key really belongs to the expected person becomes even more important when you use the method for Internet transactions with complete strangers or corporations. Think about e-commerce. You really want to be sure that the Web site you are giving your credit card details to is who they say they are. When your order doesn't show up, and you call to inquire, you don't want to hear, "Sorry, we have no record of that transaction" because someone was impersonating the vendor. The solution comes by using a trusted third party: a certificate authority.

Essentially, a certificate authority is a trusted independent organization that certifies a set of public and private keys for use with PKI transactions. The authority handles this task by generating certificates in a standard format. A certificate is just a bunch of data. It has no physical form. However, when another party sends you a certificate, it contains enough information for you to validate who they are and establish a secure context. With most Web purchases, this is a one-way context that protects the consumer. The vendor gets protection through your credit card details!

Suppose you set up a Web company selling flags. You get a Web domain name such as www.myflagsarebest.com. You want this address to be certified to you so, when people come to your site and go to the secure purchase area, they are sure that no one is hijacking the connection. You can go to a certificate authority and purchase a certificate that binds your company and its Web site into your public and private key pair.

When someone visits your site and goes to the secure area, you send her your certificate. The browser on her PC looks at the certificate and evaluates who issued it. Assuming you went to a well-known certificate authority, the browser will likely accept the certificate as trusted (you can control this in the advanced options of the browser). If not, it notifies the user that an untrusted certificate has arrived and prompts her to decide whether to proceed.^[1] The certificate contains the public key for your site, so now the browser can start encrypting all the messages. Your Web server is able to decrypt the messages with your private key, and so the transaction is protected. The customer can feel confident that the credit card details and order information are going to the right place and not being snooped along the way.

^[1] Unfortunately at this point 99% of users don't understand the message and click "proceed" anyway.

How does the browser know that the certificate was really issued by the certificate authority and not just made up by a crook? Because the entire certificate is signed by the certificate authority using its private key, and therefore it can be proved authentic because its validity can be tested by checking the signature with the authority's public key, which is also in the certificate. Neat, huh? Note that the browser may, in any case, choose to send a message to the certificate authority to check for revocation. If someone had compromised your Web site or somehow found out your secret key, you might want to disable the certificate. This would prevent someone else issuing copies of your certificate in the event he got your secret key. To disable the certificate, you notify the certificate authority, which marks it as revoked and informs anyone who asks that this is the case. It's the same idea as canceling a stolen credit card.

This example has been simplified for the purpose of illustrating how certificates work. Full details of Internet transactions and security are outside the scope of this book. However, the example does outline the general approach taken by SSL (Secure Socket Layer) used by all the main browsers (and invented by Netscape). SSL is the basis of TLS, which is covered in more detail later in this chapter.