Security Principles

1. Don't Talk to Anyone You Don't Know

In the context of security, this means you must be 100% certain about the identity of a device or person before you communicate. Security gurus point out that it is impossible to be 100% certain of anything, but it is the job of security designers to bring you as close to 100% as you need.

To understand this principle even better, consider this analogy. Imagine you are at a wild party. You are strapped to a chair in the middle of the room and blindfolded. Nobody touches you and your nose is covered so you can't smell peoples' perfume. Well, we never get invited to these sorts of parties anyway; but if you did, you would know what it feels like to be a Wi-Fi LAN.

In this scenario, you can listen and you can speak, but you have no other means to identify the people in the room. A simpler (albeit more boring) analogy is a telephone conference call. In ordinary phone conversations, during which we can hear but not see the other person on the phone, we constantly prove to ourselves that the other person is who we think he is. In most cases, we do this subconsciously. Initially we assume the caller is who he says he is; we accept his identity as stated. However, before we open our communications channels, we test that identity. If we know the caller, we recognize the voice and we go straight to open mode. If we don't, we cautiously open up as we hear information that is consistent with the person's stated identity. Throughout the call, we continue to monitor and are alert to comments that sound strange or out of context.

Conference calls are difficult because more people are involved and you need to constantly identify who is talking. Imagine that somebody makes a comment that you don't quite hear and you say, "Could you repeat that?" The comment is repeated, but can you be sure the same person repeated it, or that what was repeated is the same as the original comment?

The only reliable solution to this quandary is to require that the identities of all the call participants be proven without a doubt for every sentence they speak.

2. Accept Nothing Without a Guarantee

Like "security," the word "guarantee" means different things to different people (for instance, try taking your used car back to the dealer when things go wrong). In the context of network security, "guarantee" means a guarantee of authenticity. In other words, it is proof that the message has not been changed.

You know the sender must prove his identity before you accept his message, but you also need to be sure that what you receive is the message the sender intended to send and that the message has not been modified, delayed, or even replaced with a new message.

At first this seems like a small point and one that is essentially the same as proving the identity of the sender. After all, if the message has been altered, then surely the enemy must have intercepted and resent it.

Consider the following.

The second flaw is one of those hidden assumptions. We have assumed it is necessary for the enemy to receive and then resend the message. However, in a wireless environment, the enemy might discover a way to modify the message while the friend is transmitting it. Today, we don't know any way to do that. But you could imagine that a carefully timed burst of radio transmission from the enemy, colliding with the friendly transmission, might cause the receiver to interpret a bit to have a different value, even though the rest of the transmission came from the friend. In this case the enemy has tampered with a message without retransmitting it at all.

In practice many security protocols use a method that provides both identity proof and tamper-resistant packaging in the same algorithm. However, the rule still applies: Accept nothing without a guarantee.

3. Treat Everyone as an Enemy until Proved Otherwise

4. Don't Trust Your Friends for Long

"Make new friends but keep the old…." What does it mean to "keep" a friend? The word "keep" implies an active process, a process of affirmation. Suppose one day you are walking down the street and you meet up with your best friend from high school. This is a nice surprise because you had lost contact and you hadn't seen this person for 10 years. You grew up with this friend and shared all your secrets. After reminiscing for a while, you learn things are not going well and you hear the dreaded words, "Can you lend me some money? I absolutely promise I'll pay you back." Why do you feel uncomfortable? Ten years ago you might have forked over the money in complete confidence. Why not now? You have not reaffirmed the friendship; you don't really know who this person is anymore. You would have to take time to reestablish trust before you were comfortable again.

Applying this analogy to Wi-Fi security, friends are those devices you can communicate with and enemies are everyone else. "Friends" in a Wi-Fi LAN can be identified because they possess tokens such as a secret key that can be verified. Such tokens, whether they are keys, certificates, or passwords, need to have a limited life. You should keep reaffirming the relationship by renewing the tokens. Failure to take this step can result in unpleasant surprises.

There is a difference between policy and protocol. In simple terms, the security protocol is designed to implement the security policy. You are going to decide for your organization which people are "friends." You are also going to decide when those friends can access the network and, for multisite corporations, where they are allowed access. All these issues are part of security policy. It is then the job of the security protocol, in conjunction with hardware and software, to ensure that no one can breach the policy. For example, enemies should never get access.

In the Wi-Fi LAN context, a friend is usually a person or a computer. If you are talking to some dedicated equipment, such as a server or a network gateway, you need to establish that the equipment is considered a friend in your security policy. However, in the case of laptop or desktop computers, it might not be enough to identify the equipment. The laptop might have been stolen or left unattended. In these cases, you need to be sure the person using the computer is also legitimate. Memorizing a password is the most common way to do this.

Normally, well at least in theory, people who work for your company are friends and it is acceptable to communicate with them. In larger companies the notion of "friend" can be divided down to departments or projects. Even when you are certain of the other party's identity, you might have to check whether she has left the company or moved off the project.

Corporations have security databases that are constantly updated with the access rights or credentials of all prospective friends. Later we will look at how Wi-Fi LAN security can be linked to those databases. However, accessing such a database often requires a significant investment in time and resources, and in some cases, the database might be temporarily inaccessible.

To reduce overhead, it is common to verify another person's credentials and then assume these credentials are OK for a limited period of time before checking again. The actual amount of time can be set by the security administrator and might vary from a few minutes to a few days.

5. Use Well-Tried Solutions

A security guru will never say that something is "totally secure." So what's the best you can do? How can you ever develop trust in a security protocol?

Part of security psychology involves developing a high level of mistrust for anything new. To see how this affects people's attitudes, let's take encryption as an example. The object of encryption is to make the encrypted data look like perfectly random noise. Suppose you take an arbitrary message, pass it through the encryption algorithm, and send it over a communications link. Then repeat the process millions of times, sending the same message over and over but encrypting it each time before sending. If the encryption algorithm is good, every transmission will be different and look totally random. If you could do this with no gaps in the transmission, no amount of analysis on the output stream would reveal any pattern—just white noise.

Now comes the hard part. If you really did convert the message to random white noise, it would not be very useful because neither the friend nor the enemy would be able to decode it. The trick is to make it look like noise to the enemy while enabling the friend to extract the original data. Many algorithms are available for achieving this goal, but how can you tell which ones really work? If the message is to be decoded by the friend, it cannot be true noise—somewhere there must be some information that allows the data to be extracted. So how can you be sure an enemy cannot eventually figure out that information and decode the message?

The answer to this question has two parts. The first involves mathematical analysis called cryptanalysis. Cryptanalysis lets you determine how hard it is to break the encryption code by conventional or well-known methods. However, weaknesses can also come from unconventional methods, such as unexpected relationships between computations in the algorithm or implicit hidden assumptions. Therefore, the second part of developing confidence in a new algorithm is the good old "test of time."

6. Watch the Ground You Are Standing on for Cracks

Every day, we make countless assumptions. From our earliest days we have learned how to look at situations and decide which ones are safe and which ones are dangerous. Over time we perform many of these skills subconsciously; we learn to trust, and for most of us, that trust is only occasionally misplaced, sometimes painfully.

Humans automatically transfer safe assumptions from conscious memory to subconscious behavior. The key word here is automatically; that is, people are not aware this transfer happens. In fact, if it didn't happen, we could not function, as our minds would be cluttered with so many checks and questions. However, this essential ability for life is the open door that has been exploited by generations of con men, pickpockets, and tricksters in performing crimes. It is also the starting point for hackers who want to attack your network.

People design software, hardware, and systems. People write and evaluate international standards. No matter how sophisticated the design tools, or what computer-aided design software is used, the designers' assumptions still come shining through. Some are valid and some false—and, more dangerously, many are applied subconsciously or implicitly.

Consider a medieval castle. The designers could specify thick walls, deep moats, and strong gates. They could require that gallons of boiling oil be kept ready at all times. But how would the castle folk fare against a modern helicopter cruising overhead, dropping boiling oil on them? They would have no defense because the designers unconsciously assumed that attacks would not come from the air. This assumption is a hidden weakness of the castle design.

How is it possible to protect against things that you can't even imagine? How can you see the implicit assumptions and bring them forward for inspection and testing? There is no certain way, but these challenges mold the way of thinking for security experts.

As a result, it can be difficult to have ordinary conversations with security experts. Here is a simple test to determine whether you are talking to a security guru: Ask him to name the security system he considers to be the strongest in the world for sending secret data by any method (wireless, wire, smoke signals, whatever). Then ask the following question, "Would I be secure if I implemented this in my system?" If the answer is "yes," you are not talking to a real security guru.

Security gurus never say, "This is completely secure." They make statements like, "Based on the assumption that attackers are limited to computational methods and processor architectures similar to today, it is computationally infeasible to mount a [certain type of attack] and no other types of attack are known to be more effective at this time." Sometimes they are prepared to say that one method is definitely as secure as another method, but the word "definite" doesn't get too many outings in the security expert's vocabulary.

Such hedging doesn't translate well to the glossy front of a product box, where customers simply look for the words "this is secure." The best approach for a customer is to understand the strengths of the security method used and, where possible, the assumptions that were made in the design. If the assumptions are reasonable, the method is well designed, and plenty of people are using it (to ensure future support), the customer can be comfortable.

The challenge for hackers, of course, is to look for the little cracks and crevices that result from hidden assumptions. Unfortunately for the rest of us, this search is an intriguing, fascinating, and motivating challenge for hackers. Some people like to do crossword puzzles, and some people like to play sophisticated problem-solving computer games, often wrapped in a fantastical visual landscape. Hacking is another form of these mind games. When inventing a new virus or a password-cracking program, the hacker is trying to see into the mind of the designer and look for false assumptions that were made subconsciously. For example, a recent virus called "Code Red" (actually a worm) worked by exploiting the fact that when internal memory buffers overflowed in a computer, information was accidentally left in memory in a place that was accessible from outside. The system's designers made the false assumption that buffers do not overflow and that, if they do, the excess buffers are properly thrown away. Almost certainly this was a subconscious assumption; it was false and an attacker found it.

Security Terms

To set up a system in practice, we need to implement the six principles covered in the previous section using mechanisms that tend to be similar from one system to the next. It doesn't really matter whether you are implementing a system to send secret letters by pigeon or a security method for a wireless LAN. Some common processes and terms should be understood. This section briefly describes some of the main terms used in security. Sometimes words in common use have a specific meaning in security. For example, the word "encryption" tends to be used in common speech to refer to an entire security protocol, whereas in security it refers to a single specific process.

• Threat model: We need a means to measure whether a security system meets its goals. One way to understand the security goals in a given situation is to make a list of all the types of attack that are known. This "list" is used to create the threat model, which is the basis for designing and evaluating security. Having created the list, we then identify all those threats against which we plan to defend. From a practical standpoint, some of the threats on the list may be too low risk and too expensive to defend against. As an example, the threat model for protecting wired Ethernet LANs does not (usually) include the threat of being monitored via the tiny radiations coming from the wires. By contrast, unwanted monitoring of radio emissions is central to the threat model of wireless LANs.

• Security protocol: Many people use the word "encryption" in a general way to talk about security. You often hear people talking about "sending data over an encrypted link," and so on. This is dangerous because encryption is only one part of the process, albeit a very important part. Real security is provided by a set of processes and procedures that are carefully linked together. This set of procedures and processes is called the security protocol. It is important to realize that even if the most advanced encryption techniques are used, you have no security if they are used together in the wrong way.

• Keys and passwords: These terms are often used interchangeably, although there is a slight difference in meaning. Both refer to a piece of information that is intended to be secret to two or more parties. Conventionally, the term password is used to refer to keys that are chosen by humans. The term key is more often used to describe information generated by a machine that is usually not human-readable. You will often see references to the length of the key. For example, the original IEEE 802.11 had "40-bit" keys, whereas most Wi-Fi WEP systems have "128-bit keys." In general, longer keys are more difficult to crack than shorter keys, but not always—it depends on the key entropy (described next).

• Key entropy: What is important about passwords and keys is the number of different possible values a key can take. Theoretically, a 40-bit key has 2⁴⁰ or 1,000 billion possible values. However, if we restrict the values that are allowed, the effectiveness of the key goes down. For example, suppose the user enters a 40-bit key as five uppercase letter symbols (assume each letter uses 8 bits, hence 40 bits total). An example of such a password is the string "LASER." Because each symbol is limited to only 26 letters, you can have only 26⁵ (or about 12 million) different passwords. By limiting the type of password, you have reduced the number of possible passwords by a factor of 100,000. The number of possible key values determines the strength of the key and is known as the key entropy. In our earlier example, the restriction to using uppercase letters has reduced the key entropy (and hence its effectiveness) from 40 bits to 23 bits, even though the key remains 40 bits long. If we restricted ourselves to known words and names, it would be reduced even more.

• Authentication: The heart of security is the ability to distinguish the "good guys" from the "bad guys." If you can't be sure whom you are talking to, you can't protect yourself against attack. The term authentication is used at two different levels in security protocols, and this sometimes leads to confusion. The first level is user authentication and the second level is message authentication. The objective of user authentication is to prove that the other party with whom you want to communicate is who she says she is. Note that although we talk about "user" here, it could be that the other party is a computer or even a software process running on a server rather than a person. Message authentication has a different objective: to prove that a received message has not been tampered with, delayed, altered, or copied. A message is said to be authentic if it passes these tests. Typically, user authentication must be performed to identify the other party, and message authentication is done to ensure that subsequent communications come from that other party and are unaltered.

• Authorization: The process of user authentication is difficult to perform correctly. Therefore, it is discussed extensively in this book and in others. You often see statements such as,"When the mobile device is authenticated, the access point allows it to communicate with the network." This is not quite true. We saw a cartoon by Gary Larson recently in which a ghoulish specter was peeking through a partly open front door held by a security chain. The old lady inside was saying, "Ah, but how do I know you really are the angel of death?" The message is simple: the fact that you know who someone is (authenticate) doesn't mean you always want to give him access. The decision to "let him in" is called authorization and comes after authentication.

• Encryption: The process of combining a piece of data and a key to produce random-looking numbers is called encryption. It is useful only if a known key can be used to transform the random-looking numbers back to the original data. Note that we have said nothing about LANs, packets, wires, or even time. Encryption is just a computational algorithm of which there are many variants. Encryption algorithms are used to create security protocols