Begin by first considering exactly which objects needs security. A system is a collection of components and people which accomplish a particular set of tasks, such as updating payroll or storing important data. Let's examine some different aspects of a system.
Primitives are the most basic components of a system. They perform one specific task and have a specific set of properties. For example, a system designed to protect a building might include a "locked door" as a primitive. Such a locked door opens only if the correct key is at hand. One of the most common primitives in computer security is a cryptosystem, which specifies exactly how to encrypt data with a key to produce ciphertext. Ciphertext can be thought of as data locked inside a room; the encryption makes it intractable to recover the original data from the room without the correct key.
In a symmetric cryptosystem, there is only one key used to encrypt and decrypt. That single key must always be kept secret. Another common cryptographic primitive is a public-key cryptosystem. In a public key system there are two keys, a public key and a private key. The public key is used for encryption and given to everyone. The public key works only for encryption; it cannot be used to recover data from the ciphertexts it creates. Only the corresponding private key can reverse the process and decrypt the ciphertexts to recover the message...and the private key is kept safe and secure.
The specification of how these primitives are used to accomplish some goal is called a protocol. For example, a protocol with the goal of "exchange a secure message between Alice and Bob" might use a public-key cryptosystem, and then specify such things as how Alice and Bob learn each others' public keys and how the ciphertext is transmitted. Another protocol might specify how Alice logs into her server over a network with eavesdroppers without revealing her password.
Notice the difference here between primitives and higher-level protocols. The primitive of a public key cryptosystem does not make any reference to Alice or Bob. It can be used in many different protocols for many different purposes.
Protocols are designs or specifications that eventually have to be implemented in the real world to be useful. The implementation consists of that part of the system responsible for doing what the protocol says needs to be done. Here it includes not just physical hardware, but also such things as the operating system.
Finally, pay close attention to the people involved. The users and operators of a system are the ones who have to live with whatever protective measures it has in place. They are the ones who suffer if something goes wrong. They are also the ones who suffer if a security precaution interferes with their everyday routine. If the users suffer too much, they will tend to turn off the security or try to subvert it.
Threat models also try to say something about the adversaries of the system -- the people who want to break the system, misuse it, or otherwise cause mischief.
The best information about an adversary comes from the kinds of attacks he or she uses. When the attacks succeed and are later detected, they reveal which parts of the system need work, and what is important to the adversary. Once an attack is discovered and isolated, information about it can be communicated widely.
This in turn helps build systems which are resistant to that particular attack. Unfortunately, this assumes that the next adversary will look a lot like the last one. Eventually the system ends up with too many assumptions, each coming from an experience with a previous adversary.
Making too many assumptions about your adversaries invites disaster. The classic real-world example comes in burglar alarms. An alarm system which protects doors and windows alone is of no use against a burglar who takes a chain saw and cuts a hole in the wall.
One way out is to generalize. Instead of talking about some particular adversaries, the idea is to start making statements about all adversaries. These depend on some set of assumptions. Then make as few assumptions as possible, while still saying something meaningful about what the adversary cannot do. The goal is to make a priori statements about the adversary's behavior which will include all kinds of adversaries, even those never seen.
For every primitive, such as a public-key cryptosystem, there are several different ways to implement it in practice. For every task, there are many different protocols which use these primitives to accomplish the desired goal. Choosing among these alternatives is a difficult problem.
Vigorous debate exists on the subject of which implementations of cryptographic primitives are best and why. This debate is complicated by the fact that different applications have different resource constraints and security needs. For example, a military system responsible for relaying orders may only need to keep the orders secret for hours, but may have a very limited amount of battery power and computation with which to accomplish the task. In contrast, the archives of a large company may need to be kept safe and secure for many decades.
For public-key cryptosystems, the most widely known implementations are the RSA algorithm [13], various systems related to the discrete logarithm problem such as Elgamal [7], and elliptic curve cryptography [14]. For symmetric cryptosystems, the most widely known example is the U.S. Data Encryption Standard, or DES. More recently, a contest is underway to select the Advanced Encryption Standard, or AES. An overview of various block ciphers and current information on the AES process can be found at the Block Cipher Lounge [8].Almost all of these primitives come up against a fundamental problem with our current knowledge in computer science. No one knows how to prove that anything is computationally hard (or at least, not in a way that is useful for cryptography). Every public-key cryptosystem is based on some conjecture, such as "factoring the product of two really big prime numbers is believed to be too hard for any of my adversaries to do quickly once I make the numbers big enough." The situation with symmetric cryptosystems is similar, except that often the conjecture is simply "this really messy function is too hard for anyone to break." No one knows if any of these schemes are actually any good! On the other hand, no one knows if the schemes are bad!
Most debate about cryptographic "strength" focuses on this pivotal point. No one knows how to prove anything is good. The best that can be done is to show that a primitive is bad by finding a weakness. One solution is to use only primitives which have seen years and years of analysis. In theory, if a lot of smart people have looked at it and found nothing, then the primitive is likely to be secure. An alternative approach, described by Terry Ritter [12], suggests using multiple, constantly changing ciphers to frustrate an adversary.
The situation is somewhat better in information-theoretically secure cryptography. First studied by Claude Shannon in the 1940s, these are ciphers which focus on denying the adversary enough "information" about the message to ever reconstruct it from the ciphertext. The classic example of an information-theoretically secure cryptosystem is the one-time pad. In this scheme, the sender and receiver share a random key-pad as long as the message. The key-pad is assumed completely unknown to the adversary. The ciphertext created by combining the pad and the message using a reversible operator such as "exclusive or". The point here is that the resulting ciphertext could correspond to the encryption of any message, and without knowing the pad, the adversary has no way to know which one. The adversary could even guess the right message, but without the pad the adversary has no way to verify that guess.
Information-theoretic primitives can be "proved secure." A mathematical definition of the notion of "no way to verify a guess" can be made, which captures the idea that having the ciphertext does not help the adversary determine the plaintext in any way. Then a formal proof can be given which shows that the one-time pad satisfies this definition. Unlike with most cryptography, this proof relies on no assumptions that certain problems are "too hard" or "intractable." Unfortunately, Shannon showed that all proofs of this kind require a system where the key is at least as long as the plaintext.
This means that information-theoretic primitives can be cumbersome in practice; using a one-time pad requires exchanging the entire key in advance. Reusing any part of the key not only invalidates the proof, but can make the entire scheme insecure. In addition, some of the simplifying assumptions, such as the existence of a completely unpredictable secret key, are hard to come by in practice.
Even if the primitives work, they must still be used by a protocol. What guarantee is there that the protocol uses them correctly? Some protocols come with a formal definition of security and a proof that the protocol meets the definition. When evaluating these protocols, it is critical to know what exactly is claimed by the proof, and under what assumptions. When the assumptions hold, these proofs can be powerful tools for finding problems in a protocol, and then offering assurance that no hideously subtle flaws exist.
When the assumptions do not hold, the false sense of security given by the proofs is worse than no proof at all. To stretch the burglar alarm analogy further, consider a proposed definition of security for a house as "no one can enter through any of the doors or windows." Now consider burglar alarm XYZ, which perfectly protects all doors and windows. It is provably secure because it protects all doors and all windows, just like the definition says! None of this helps when the burglar shows up with a chain saw.
Another danger comes from side-channel attacks which take advantage of some properties of the hardware not usually considered. For example, Paul Kocher has shown that by measuring the amount of time it takes to encrypt a message, information can be gained about the key used to encrypt [9]. He later showed that the amount of power consumed can leak information as well [10]. TEMPEST attacks, can also occur when an adversary eavesdrops on electromagnetic emissions emanating from the target hardware [11].
A final note: realize that the adversary has as least as much access to information about primitives, protocols, and hardware as anyone else. In fact, he or she may have more information. David Wagner has pointed out that "Hackers do basic research too, and sometimes they learn about something before any of the good guys." [18]
In light of this, it is sometimes tempting to invent a new component or modify an old one, on the theory that the adversary will not know what is going on. This is known as security through obscurity, and it is not sufficient by itself. Newly invented components tend not to be strong (especially cryptographic primitives), and then in that case a bit of reverse engineering is all that stands between the system and total failure.
On the other hand, obscurity can deter casual "kid sister" adversaries. It can also buy time in the face of other adversaries.
An example of security through obscurity in action is the A5/1 symmetric cryptosystem used in GSM mobile phones. After the cryptosystem was reverse engineered by Marc Briceno, David Wagner, and Ian Goldberg [4], it was a matter of months before Adi Shamir, Alex Biryukov, and David Wagner came up with an attack which potentially breaks the cipher in real time [17]. The system had been first used in the late 1980's - it took years until an adversary came along which was both able and willing to break the system and then publish the results. No one knows about adversaries which were able to break A5/1, but less willing to publish results.
"I trust the proofs -- they're mathematicians. I'll just find some way to get around the assumptions."
-Bruce Schneier, founder and CTO of Counterpane Internet Security, Inc.
Schneier's quotation emphasizes one major point: everything in the system must work together. This point covers everything from the choice of cryptographic primitives, to the design of protocols, to the kind of hardware used, to the training of users. Assumptions made at each point must be made explicit, and then verified across the entire system. To do otherwise is just asking for trouble.
Here are some examples of why this point is important.
Side Effects. Sometimes primitives do not have the properties expected of them. For example, suppose Alice wants to send a message to Bob so that no one can identify the sender or receiver. One way she can do this is by using the latest version of PGP, finding Bob's public key, and then creating a message encrypted to Bob. Then she posts this under some other account in a public forum which she knows Bob will read. This is fine, except that the standard used by modern versions of PGP specifies that the the message header contain the recipient's identity. Under most circumstances this is useful. In the case of posting "anonymous" messages, it is a problem. One solution is to use the "Stealth PGP" created by Adam Back, which strips headers from encrypted message, including the name of the recipient [3].
Negotiate Wisely. At the protocol level, several recent systems fell victim to negotiation attacks. Suppose the system has two protocols it can use to perform a task (such as logging in). One of them is new, modern, and reviewed by lots of people. The other was designed in 1976 by some guy on the back of a paper napkin, and was used only by the Commodore PET. This other protocol is included for backward compatibility; no one has thought about it in twenty years.
When a user connects to the system, there is a protocol negotiation step, in which the system and the user decide which protocol to use. Unfortunately, this negotiation is not protected from attack in any way. The adversary can silently step in, "take over" the negotiation step, and tell the server that the user is a Commodore PET. Then the server tells the user "I think you're a Commodore PET," and the user's software automatically swings into "Commodore PET Emulation Mode." Then the user's software and the server follow the old protocol, which easier to break than the new one. The switch happens silently and the user never notices.
This flaw was present in the first version of Microsoft's CHAP protocol for virtual private networks [16] and version 2.0 of Netscape's Secure Sockets Layer (SSL) protocol [1].
Bad Interactions. In implementations, nasty interactions are the rule, not the exception. This can be seen every time a program core dumps or a virus infects a system. Trojan horse programs like Back Orifice 2000 can also be considered in this category [6]. Then there are the "side-channel" attacks already mentioned. These can make an otherwise secure system useless.
Programming Oversights. Many languages, including C, require the programmer to handle all memory allocation. Sometimes a programmer will allocate a fixed buffer to store data such as a machine name or data coming across a network connection. When more data is shoved into the buffer than memory is available, this causes a buffer overflow . The extra data is spewed into memory, and may be executed by the host computer. With some cleverness, an adversary can use this to run arbitrary code on the host machine.
People. Finally, even the best primitives, protocols, and implementation may not protect against social engineering -- the art of tricking people into giving up their security. Social engineering takes many forms. It can be as simple as bluffing past a security guard, or as devious as taking a temporary job at a site and gaining the trust of permanent staff. Then there are other attacks, like simple eavesdropping or the practice of going through garbage, which can reveal large amounts of useful information about a system. The most famous example of social engineering in recent memory is the ILOVEYOU virus, which appealed directly to a user's desire for companionship to convince him or her to activate the virus.
Many people use the metaphor of a chain to describe a system, saying that "security is only as good as its weakest link." This metaphor does not go far enough. Security is more like a cheesecloth wrapped around data. It is full of holes, and the only hope is that the holes will be small enough to prevent the attacks actually cared about from making it through.
Making these holes smaller costs time, effort, and money. Plus implementing security measures may have a negative effect on the quality of life of the people using the system. For example, one could imagine a system which requires users to re-enter passwords every two minutes. Such a scheme would address the problem of people leaving themselves logged in while at lunch, but would also make the system nearly unusable. Another system might be secure on paper, but so expensive as to be impossible to build.
A key aspect of designing a system is recognizing these realities and the security tradeoffs involved. At some point, "the perfect is the enemy of the good," and it becomes unprofitable to try to design a system which prevents all attacks before they happen. At this point, the focus shifts to detecting attacks when they happen, and then having a plan to recover when they succeed.
Intrusion detection is the term usually applied to detecting attacks as they happen. Many different intrusion detection programs exist; the Carnegie Mellon Computer Emergency Response Team has a report which covers them in detail [2].
The best way to know if something used has been found insecure before an attack is to keep up with several sources of news on cryptography and security. The proceedings of the conferences of the International Association for Cryptologic Research are one such source [19]; another is the Bugtraq mailing list [20]. The SANS institute has also released a "top ten" list of security vulnerabilities [15].
The face of security is changing. For years, cryptography and security were dark arts, largely unknown outside the military. Then network security was a concern mainly for companies doing business over the Internet. With the rise of fast connections and increasingly complicated systems, security is on its way to becoming everyone's problem. It's time for everyone to think about solving it.
Last Modified:
Location: www.acm.org/crossroads/columns/onpatrol/june2000.html