CHAPTER 2

Cryptography 101

In this chapter you will learn about

You really have to wonder exactly when mankind started keeping secrets from one another. Was it in ancient Greece, where men in the cradle of civilization used tattoos on slaves to send messages to one another? Maybe in ancient Egypt, with messages carved into stone to protect the royals’ communications from the rest of the court? Or perhaps it was in caves in Aboriginal Australia, with one cave dweller wanting to let his friend know about the fruit tree discovery without alerting others? Regardless of who gets to claim it first, trying to keep secrets from one another has been around for a very, very long time.

From cavemen working out a succession of knocks and beats to the secure e-mail I just sent my boss a few minutes ago, we’ve been trying to keep things secret since the dawn of time. And, since the dawn of time, we’ve been trying to figure out what the other guy was saying—trying to “crack his code.” The implementation and study of this particular little fascination of the human psyche—securing communication between two or more parties—is known as cryptography. For you budding ethical hackers out there reading this book, the skill you’re looking to master, though, is cryptanalysis—the study and methods used to crack encrypted communications.

Cryptography and Encryption Overview

I debated long and hard over just how much history to put into this discussion on cryptography, but finally came to the conclusion I shouldn’t put in any—even though it’s really cool and interesting. After all, you’re probably not concerned with how the ancient Romans tried to secure their communications, or who the first purveyors of steganography—hiding messages inside an image—were (toss-up between the Greeks and the Egyptians, depending on your persuasion). What you are, and should be, concerned with is what cryptography actually is and why you should know anything about it. Excellent thoughts. Let’s discuss.

Cryptography is the science or study of protecting information, whether in transit or at rest, by using techniques to render the information unusable to anyone who does not possess the means to decrypt it. The overall process is fairly simple: Take plaintext (something you can read) data, apply a cryptographic method, and turn it into ciphertext (something you can’t read)—so long as there is some provision to allow you to bring the ciphertext back to plaintext. What is not so simple is the actual process of encrypting and decrypting. The rest of this chapter is dedicated to exploring some of the mathematical procedures, known as encryption algorithms, used to encrypt and decrypt data.

	NOTE Don’t be confused by the term plaintext. Y es, it can be used to define text data in ASCII format. However within the confines of cryptography, plaintext refers to anything that is not encrypted—whether text or not.

It’s also important to understand what functions cryptography can provide for us. In Chapter 1, we discussed the hallowed trinity of security—confidentiality, integrity, and availability. When it comes to cryptography, confidentiality is the one that most often is brought up. Encrypting data helps to provide confidentiality of the data, because only those with the “key” can see it. However, some other encryption algorithms and techniques also provide for integrity (hashes that ensure the message hasn’t been changed) as well as a new term we have yet to discuss here: non-repudiation. Non-repudiation is the means by which a recipient can ensure the identity of the sender and that neither party can deny having sent or received the message. Our discussion of PKI later will definitely touch on this. This chapter is all about defining what cryptography methods we have available so that you know what you’re up against as an ethical hacker.

Encryption Algorithms and Techniques

Cryptographic systems can be as simple as substituting one character for another (the old Caesar Cipher simply replaced characters in a string: B for A, C for B, and so on) or as complex as applying mathematical formulas to change the content entirely. Modernday systems use encryption algorithms and separate keys to accomplish the task. In its simplest definition, an algorithm is a step-by-step method of solving a problem. The problem, when it comes to the application of cryptography, is how do you render something unreadable, then provide a means to recover it? Encryption algorithms were created for just such a purpose.

	NOTE Encryption of bits takes, generally, one of two different forms: substitution or transposition. Substitution is exactly what it sounds like—bits are simply replaced by other bits. Transposition doesn’t replace bits at all; it changes their order altogether.

Encryption algorithms—mathematical formulas used to encrypt and decrypt data—are highly specialized and, sometimes, very complex. The good news for you, as a CEH candidate, is you don’t need to learn the minutiae of how these algorithms actually accomplish their task. You will need to learn, however, how they are classified and some basic information about each one. For example, a good place to start might be the understanding that modern-day systems use encryption algorithms that are dependent on a separate key—meaning that without the key, the algorithm itself should be useless in trying to decode the data. There are only two methods by which these keys can be used and shared: symmetric and asymmetric. Before we get to that, though, we need to have a quick discussion about how ciphers work.

Block and Stream Ciphers

All encryption algorithms on the planet have basically two methods they can use to encrypt data. If you think about it, they make perfect sense. In one method, bits of data are encrypted as a continuous stream. In other words, readable bits in their regular pattern are fed into the cipher and are encrypted one at a time, usually by an XOR operation (exclusive-or). Known as stream ciphers, these work at a very high rate of speed.

In the other method, data bits are split up into blocks and fed into the cipher. Each block of data (usually 64 bits at a time) is then encrypted with the key and algorithm. These ciphers, known as block ciphers, use methods such as substitution and transposition in their algorithms and are considered simpler, and slower, than stream ciphers.

	EXAM TIP When it comes to encryption algorithm questions on the exam, you’ll need to know two main points—what the key length is and what type of cipher (block or stream) it is.

Symmetric Encryption

Also known as single key or shared key, symmetric encryption simply means one key is used both to encrypt and decrypt the data. So long as both the sender and the receiver know/have the secret key, communication can be encrypted between the two. In keeping with the old acronym K.I.S.S. (Keep It Simple, Stupid), the simplicity of symmetric encryption is its greatest asset—as you can imagine, this makes things very easy and very fast. Bulk encryption needs? Symmetric algorithms and techniques are your best bet.

But symmetric key encryption isn’t all roses and chocolate—there are some significant drawbacks and weaknesses. For starters, key distribution and management in this type of system is difficult. How do you safely share the secret key? If you send it over the network, someone can steal it. Additionally, because everyone has to have a specific key from each partner they want to communicate with, the sheer number of keys needed presents a problem.

Suppose you had two people you wanted to safely communicate with. This creates three different lines of communication that must be secured; therefore, you’d need three keys. If you add another person to the mix, there are now six lines of communication, requiring six different keys. As you can imagine, this number jumps up exponentially the larger your network becomes. The formula for calculating how many key pairs you will need is

N (N – 1) / 2

where N is the number of nodes in the network. See Figure 2-1 for an example.

FIGURE 2-1 Key distribution in symmetric encryption systems

Here are some examples of symmetric algorithms:

And there you have it—symmetric encryption is considered fast and strong, but poses some significant weaknesses. It’s a great choice for bulk encryption, due to its speed, but key distribution is an issue because the delivery of the key for the secured channel must be done offline. Additionally, scalability is a concern because the larger the network gets, the number of keys that must be generated goes up exponentially.

Lastly, symmetric encryption does a great job with confidentiality, but does nothing to provide for another very important security measure—non-repudiation. Nonrepudiation is the method by which we can prove the sender’s identity, as well as prevent either party from denying they took part in the data exchange. These weaknesses led to the creation and implementation of the second means of encryption—asymmetric.

Asymmetric Encryption

Asymmetric encryption came about mainly because of the problem inherent in using a single key to encrypt and decrypt messages—just how do you share the key efficiently and easily without compromising the security? The answer was, of course, to simply use two keys. In this key pair system, both are generated together, with one key used to encrypt a message and the other to decrypt it. The encryption key, also known as the public key, could be sent anywhere, to anyone. The decryption key, known as the private key, is kept secured on the system.

For example, suppose two people wish to secure communications across the Internet between themselves. Using symmetric encryption, they’d need to develop some offline method to exchange the single key used for all encryption/decryption (and agree on changing it fairly often). With asymmetric encryption, they both generate a key pair. User A sends his public key to User B, and User B sends his public key to User A. Neither is concerned if anyone on the Internet steals this key because it can only be used to encrypt messages, not to decrypt them. This way, data can be encrypted by a key and sent without concern, because the only method to decrypt it is the use of the private key belonging to that pair.

	EXAM TIP Asymmetric encryption comes down to this—what one key encrypts, the other key decrypts. It’s important to remember the public key is the one used for encryption, whereas the private key is used for decryption. Either can be used for encryption or decryption within the pair (as you’ll see later in this chapter), but in general remember public = encrypt, private = decrypt.

In addition to addressing the concerns over key distribution and management, as well as scalability, asymmetric encryption also addresses the non-repudiation problem. For example, consider the following scenario. There are three people on a network—Bob, Susan, and Badguy—using asymmetric encryption. Susan wishes to send an encrypted message to Bob and asks for a copy of his public key. Bob sees this request, and so does Badguy. Both send her a public key that says “Bob’s Public Key.” Susan is now confused, because she does not know which key is the real one. So how can they prove to each other exactly who they are? How can Bob send a public key to Susan and have her, with some semblance of certainty, know it’s actually from him?

The answer, of course, is for Bob to send a message from his system encrypted with his private key. Susan can then attempt to decrypt the message using both public keys. The one that works must be Bob’s actual public key because it’s the only key in the world that could open a message encrypted with his private key. Susan, now happy with the knowledge she has the correct key, merrily encrypts the message and sends it on. Bob receives it, decrypts it with his private key, and reads the message. Meanwhile, Badguy weeps in a corner, cursing the cleverness of the asymmetric system. This scenario, along with a couple of other interesting nuggets and participants, illustrates the public key infrastructure framework we’ll be discussing later in this chapter.

	NOTE It’s important to note that although signing a message with the private key is the act required for providing a digital signature and, in effect, confidentiality and non-repudiation, this is only valid if the keys are good in the first place. This is where key management and the CA process comes into play—without their control over the entire scenario, none of this is worthwhile.

Here are some examples of asymmetric algorithms:

Asymmetric encryption provides some significant strengths in comparison to its symmetric brethren. Asymmetric encryption can provide both confidentiality and nonrepudiation, and solves the problems of key distribution and scalability. In fact, the only real downside to asymmetric—its weaknesses that you’ll be asked about on the exam—is its performance (asymmetric is slower than symmetric, especially on bulk encryption) and processing power (usually requiring a much longer key length, it’s suitable for smaller amounts of data).

Hash Algorithms

Last in our discussion of algorithms are the hashing algorithms—which really don’t encrypt anything at all. A hashing algorithm is a one-way mathematical function that takes an input and typically produces a fixed-length string (usually a number), or hash, based on the arrangement of the data bits in the input. Its sole purpose in life is to provide a means to verify the integrity of a piece of data—change a single bit in the arrangement of the original data and you’ll get a different response.

	NOTE The “one-way” portion of the hash definition is very important. Although a hash does a great job of providing for integrity checks, it’s not designed to be an encryption method. There isn’t a way for a hash to be reverse-engineered.

For example’s sake, suppose you have a small application you’ve developed and you’re getting ready to send it off. You’re concerned that it may get corrupted during transport and want to ensure the contents arrive exactly as you’ve created them. To protect it, you run the contents of the app through a hash, producing an output that reads something like this: EF1278AC6655BBDA93425FFBD28A6EA3. After e-mailing the link to download your app, you provide the hash for verification. Anyone who downloads the app can run it through the same hash program—and if the two values match, the app was downloaded successfully. If even a single bit was corrupted during transfer, the hash value would be wildly different.

Exercise 2-1: Hashing

Numerous hash programs can be downloaded for free online. This exercise is shown only as an example of one such application; many others work just as well, if not better, than this one. Here are the steps to follow:

FIGURE 2-2 MD5 Hash screen

FIGURE 2-3 Hash values

Here are some examples of hash algorithms:

	NOTE Rumors of SHA-3 being right around the corner have slowed the deployment of SHA-2. Although theoretically SHA-1 can be cracked, there haven’t been any proven cases of it. Combined with the fact that the U.S. government has stated it wants everyone on SHA-3 by 2012, businesses and contractors have been slow to change.

A note of caution here: Hashing algorithms are not impervious to hacking attempts, as is evidenced by the fact that they become outdated (cracked) and need replacing. The attack or effort used against hashing algorithms is known as a collision or a collision attack. Basically, a collision occurs when two or more files create the same output—which is not supposed to happen. When a hacker can create a second file that produces the same hash value output as the original, he may be able to pass off the fake file as the original, causing goodness knows what kinds of problems. Collisions, no matter which hash we’re discussing, are always a possibility. By definition, there are only so many combinations the hash can create given an input (MD5, for example, will only generate 2^128 possible combinations). Therefore, given the computation speed of modern computing systems, it isn’t infeasible to assume you could re-create one.

For instance, one of the more common uses for a hash algorithm involves passwords. The original password is hashed; then the hash value is sent to the server (or whatever resource will be doing the authentication), where it is stored. When the user logs in, the password is hashed with the same algorithm and key—if the two match, then the user is allowed access. Suppose a hacker were to gain a copy of this hashed password and begin applying a collision attack to the value—that is, he compares data inputs and the hash values they present until the hashes match. Once the match is found, access is granted and the bad guy now holds the user’s credentials. Granted, this can be defined as a brute-force attack (and when we get to password attacks later on, you’ll see this), but it is included here to demonstrate the whole idea—given a hash value for an input, you can duplicate it over time using the same hash and applying it to different inputs.

Sure, this type of attack takes a lot of time, but it’s not unheard of. As a matter of fact, many of your predecessors in the hacking field have attempted to speed things up for you by creating rainbow tables for just such a use. Because hackers must lead boring lives and have loads of time on their hands, lots of unscrupulous people sat down and started running every word, phrase, and compilation of characters they could think of into a hash algorithm. The results were stored in the rainbow table for use later. Therefore, instead of having to use all those computational cycles to hash your password guesses on your machine, you can simply compare the hashed file to the rainbow table. See? Isn’t that easy?

NOTE You can find some pretty good information (and a very detailed exercise) on rainbow tables and how to use them at www.ethicalhacker.net/content/view/94/24/. We toyed with including an exercise here but avoided it for two reasons: First, it’s a very long process. Second, it’s not tested heavily on the exam. You should practice with rainbow tables for your real-world expertise, but stick with us for the exam goodies.

To protect against collision attacks and the use of rainbow tables, you can also make use of something called a salt. No, not the sodium chloride on your table in the cute little dispenser. This salt is much more virtual. A salt is a collection of random bits that are used as a key in addition to the hashing algorithm. Because the bits, and length, are random, a good salt makes a collision attack very difficult to pull off. Considering that every time a bit is added to the salt it adds a power of 2 to the complexity of the number of computation involved to derive the outcome, you can see why it’s a necessity in protecting password files.

	EXAM TIP When it comes to questions on the exam regarding hashes, remember two things. First, they’re used for integrity (any deviation in the hash value, no matter how small, indicates the original file has been corrupted). Second, even though hashes are one-way functions, a sufficient collision attack may break older versions (MD5).

Steganography

While not an encryption algorithm in and of itself, steganography is a great way to send messages back and forth without others even realizing it. Steganography is the practice of concealing a message inside another medium (such as another file or an image) in such a way that only the sender and recipient even know of its existence—let alone the manner in which to decipher it. Think about it: In every other method we’ve talked about so far, anyone monitoring the wire knows you’re trying to communicate secretly—they can see the ciphertext and know something is up. With steganography, you’re simply sending a picture of the kids fishing. Anyone watching the wire sees a cute picture and a lot of smiles, never knowing they’re looking at a message saying, for instance, “People who eavesdrop are losers.”

Steganography can be as simple as hiding the message in the text of a written correspondence or as complex as changing bits within a huge media file to carry a message. For example, you could let the recipient know that each letter starting a paragraph is relevant. Or you could simply write in code, using names of famous landmarks to indicate a message. In another example, if you had an image file you could simply change the least meaningful bit in every byte to represent data—anyone looking at it would hardly notice the difference in the slight change of color or loss of sharpness. In a sound file it may even be less noticeable.

Before you get all excited, though, and go running out to put secret messages in your cell phone pics from last Friday night’s party, you need to know that there are a variety of tools and methods in place to look for, and prevent, steganographic file usage. Although there are legitimate uses for it—digital watermarks (used by some companies to identify their applications) come to mind—most antivirus programs and spyware tools actively look for steganography. There are more “stego” tools available than we could possibly cover here in this book, and they can be downloaded from a variety of locations—just be careful.

gifshuffle [ -CQS1 ] [ -p passwd ] [ -f file | -m message ] [ infile.gif [ outfile.gif ]]

gifshuffle -C -m "I love CEH" -p "ethical" CEH.gif hacker.gif

gifshuffle -C -p "ethical" hacker.gif

PKI, the Digital Certificate, and Digital Signatures

So, we’ve spent some time discussing encryption algorithms and techniques as well as covering the theory behind it all. But what about the practical implementation? Just how does it all come together?

Well, there are a couple of things to consider in an overall encryption scheme. First is the protection of the data itself—the encryption. This is done with the key set—one for encrypting, one for decrypting. This may be a little bit of review here, but it’s critical to realize the importance of key generation in an asymmetric encryption scheme. As we’ve already covered, two keys are generated for each party within the encryption scheme, and the keys are generated as a pair. The first key, used for encrypting message, is known as the public key. The second key, used for decrypting messages, is known as the private key. Public keys are shared; private keys are not.

No pun intended here, I promise, but the key to a successful encryption system is the infrastructure in place to create and manage the encryption keys. Imagine a system with loose controls over the creation and distribution of keys—it would be near anarchy! Users wouldn’t know which key was which, older keys could be used to encrypt and decrypt messages even though the user was gone, and the storage of key copies would be a nightmare. In a classic (and the most common) asymmetric encryption scheme, a public and a private key, at a minimum, have to be created, managed, distributed, stored, and, finally, revoked.

Second, keep in mind that there’s more to it than just encrypting and decrypting messages—there’s the whole problem of non-repudiation to address. After all, if you’re not sure which public key actually belongs to the user Bill, what’s the point of having an encryption scheme in the first place? You may wind up using the wrong key and encrypting a message for Bill that the bad guy can read with impunity—and Bill can’t even open! There are multiple providers of encryption frameworks to accomplish this task, and most follow a basic template known as public key infrastructure, or PKI.

The PKI System

A friend of mine once told me that the classic PKI infrastructure is an example of “beautifully complex simplicity.” PKI is basically a structure designed to verify and authenticate the identity of individuals within the enterprise taking part in a data exchange. It consists of hardware, software, and policies that create, manage, store, distribute, and revoke keys and digital certificates (which we’ll cover in a minute). The system starts at the top, with a (usually) neutral party known as the Certificate Authority (CA). The CA acts as a third party to the organization, much like a notary public—when it stamps something as valid, you can trust, with relative assuredness, that it is. Its job is to create and issue digital certificates that can be used to verify identity. The CA also keeps track of all the certificates within the system and maintains a Certificate Revocation List (CRL), used to track which certificates have problems and which have been revoked.

	NOTE There always seems to be a lot of confusion when it comes to understanding PKI, and I think I know why. Most newcomers to the field want to think of PKI as an encryption algorithm itself. PKI is simply a framework by which keys are distributed and, most importantly, people can verify their identities through certificates.

The way the system works is fairly simple. Because the CA provides the certificate and key (public), the user can be certain the public key actually belongs to the intended recipient—after all, the CA is vouching for it. It also simplifies distribution of keys—Bill doesn’t have to go to every user in the organization to get their keys; he can just go to the CA.

For a really simple example, consider user Joe, who just joined an organization. Joe needs a key pair to encrypt and decrypt messages. He also needs a place to get the public keys for the other users on the network. With no controlling figure in place, he would simply create his own set of keys and distribute them in any way he saw fit. Other users on the network would have no real way of verifying his identity, other than, basically, to take his word for it. Additionally, Joe would have to go to each user in the enterprise to get their public key.

User Bob, on the other hand, joins an organization using a PKI structure with a local person acting as the CA. Bob goes to his security officer (the CA) and applies for encryption keys. The local security guy first verifies Bob is actually Bob (driver’s license and so on) and then asks how long Bob needs the encryption keys and for what purpose. Once he’s satisfied, the CA creates the user ID in the PKI system, generating a key pair for encryption and a digital certificate for Bob to use. Bob can now send his certificate around, and others in the organization can trust it because the CA verifies it. Additionally, anyone wanting to send a message to Bob goes to the CA to get a legitimate copy of Bob’s public key. Much cleaner, much smoother, and much more secure. As an aside, and definitely worth pointing out here, the act of the CA creating the key is important, but the fact that he signs it digitally is what validates the entire system. Therefore, protection of your CA is of utmost importance.

Digital Certificates

I know this may seem out of order, since I’ve mentioned the word “certificate” multiple times already, but it’s nearly impossible to discuss PKI without mentioning certificates, and vice versa. As you can probably tell so far, a digital certificate isn’t really involved with encryption at all. It is, instead, a measure by which entities on a network can provide identification. A digital certificate is an electronic file that is used to verify a user’s identity, providing non-repudiation throughout the system.

The certificate itself, in the PKI framework, follows a standard used worldwide. The X.509 standard, a part of a much bigger series of standards set up for directory services and such, defines what should and should not be in a digital certificate. Because of the standard, any system complying with X.509 can exchange and use digital certificates to establish authenticity.

The contents of a digital certificate are listed next. To see them in action, try the steps listed afterward to look at a certificate from McGraw-Hill Professional:

Exercise 2-2: Viewing a Digital Certificate

Any site using digital certificates will work—this one is simply used as an example. Here are the steps to follow:

FIGURE 2-4 IE address bar lock icon

FIGURE 2-5 IE View Certificates button

FIGURE 2-6 Viewing a digital certificate

	EXAM TIP Know what is in the digital certificate and what each field does. It’s especially important to remember the public key is sent with the cert.

So how does the digital certificate work within the system? For example’s sake, let’s go back to user Bob. He applied for his digital certificate through the CA and anxiously awaits an answer. The cert arrives and Bob notices two things: First, the certificate itself is encrypted. Second, the CA provided a copy of its own public key. Confused, he asks his security person what this all means.

Bob learns this method is used to deliver the cert to the individual safely and securely, and also provides a means for Bob to be absolutely certain the cert came from the CA and not from some outside bad guy. How so? The cert was encrypted by the CA before he sent it using the CA’s private key. Because the only key in existence that could possibly decrypt it is the CA’s own public key, which is readily available to anyone, Bob can rest assured he has a valid cert. Bob can now use his certificate, containing information about him that others can verify with the CA, to prove his identity.

Digital Signatures

Lastly, we come to the definition and description of the digital signature. The only real reason this is ever a confusing topic is because instructors spend a lot of time drilling into student’s heads that the public key is for encryption and that the private key is for decryption. In general, this is a true statement (and I’m willing to bet you’ll see it on your exam that way). However, remember that the keys are created in pairs—what one key does, the other undoes. If you encrypt something with the public key, the private key is the only one that can decrypt it. But that works in reverse, too—if you encrypt something with your private key, your public key is the only thing that can decrypt it.

Keeping this in mind, the digital signature is an easy thing to understand. A digital signature is nothing more than an algorithmic output that is designed to ensure the authenticity (and integrity) of the sender—basically a hash algorithm. The way it works is simple:

When it comes to PKI, asymmetric encryption, digital certificates, and digital signatures, remembering a few important facts will solve a lot of headaches for you. Keys are generated in pairs, and what one does, the other undoes. In general, the public key (shared with everyone) is used for encryption, and the private key (kept only by the owner) is used for decryption. Although the private key is created to decrypt messages sent to the owner, it is also used to prove authenticity through the digital signature (encrypting with the private key allows recipients to decrypt with the readily available public key). Key generation, distribution, and revocation is best handled within a framework, often referred to as PKI. PKI also allows for the creation and dissemination of digital certificates, which are used to prove the identity of an entity on the network and follow a standard (X.509).

Encrypted Communication and Cryptography Attacks

So we’ve learned a little bit about what cryptography is and what encryption algorithms can do for us. In this section, we need to cover the final two pieces of the CEH cryptography exam objective: how people communicate securely with one another, using these encryption techniques, and what attacks allow the ethical hacker to disrupt or steal that communication.

Data Encryption: At Rest and While Communicating

Data at rest (DAR) is a term being bandied about quite a bit lately in the IT Security world. Most people attribute DAR as being one of a couple of things. First, the data files and folders can be encrypted themselves. More than a few products and applications are available out there for doing just this. Microsoft builds Encrypted File Systems (EFS) into its operating systems now for data at rest encryption. Others range from free products (such as TrueCrypt) to using PKI within the system (such as Entrust products). Another method of data at rest encryption is to encrypt the entire drive at the sector level. This prevents access to the hard drive at all, except by an authorized user with the correct passphrase. You can find more information on this, along with an exercise in using TrueCrypt, in Chapter 7.

It’s one thing to protect your data at rest, but it’s another thing altogether to figure out how to transport it securely and safely. Encryption algorithms—both symmetric and asymmetric—were designed to help us do both, mainly because when all this (networking and the Internet) was being built, no one even thought security would be an issue.

Want proof? Name some application layer protocols in your head and think about how they work. SMTP? Great protocol, used to move e-mail back and forth. Secure? Heck no—it’s all in plaintext. What about Telnet and SNMP? Same thing, and maybe even worse (SNMP can do bad, bad things in the wrong hands). FTP? Please, don’t even begin to tell me that’s secure. So how can we communicate securely with one another? The list provided here isn’t all-inclusive, but it does cover the major communications avenues you’ll need a familiarity with for your exam:

FIGURE 2-7 SSL connection steps

Cryptography Attacks

For the ethical hacker, all this information has been great to know, and is very important, but it’s not enough just to know what types of encryption are available. What we need to know, what we’re really interested in, is how to crack that encryption so we can read the information being passed. A variety of methods and tools is available, and although we can’t cover all of them, we will cover many of the relevant ones:

Along with these attacks, a couple of other terms are worth discussing here. Man-in-the-middle attack is usually listed by many security professionals and study guides (depending on the test version you get, it may even be listed as such). Just keep in mind that this term simply means the attacker has positioned himself between the two communicating entities. Once there, he can launch a variety of attacks (interference, fake keys, replay, and so on). Additionally, the term brute force attack is apropos to discuss in this context. Brute force refers to an attempt to try every possible combination against a target until successful. Although this can certainly be applied to cracking encryption schemes—and most commonly is defined that way—it doesn’t belong solely in this realm (for example, it’s entirely proper to say using 500 people to test all the doors at once is a brute force attack, as is sending an open request to every known port on a single machine).

	NOTE An inference attack may not be what you think it is. Inference actually means you can derive information from the ciphertext without actually decoding it. For example, if you are monitoring the encrypted line a shipping company uses and the traffic suddenly increases, you could assume the company is getting ready for a big delivery.

What’s more, a variety of other encryption-type attack applications is waiting in the wings. Some applications, such as Carnivore and Magic Lantern (more of a keylogger than an actual attack application), were created by the U.S. government for law enforcement use in cracking codes. Some, such as L0phtcrack (used mainly on Microsoft Windows against SAM password files) or John and Ripper (a Unix/Linux tool for the same purpose), are aimed specifically at cracking password hashes. Others might be aimed at a specific type or form of encryption (for example, PGPcrack is designed to go after PGPO-encrypted systems). You’ll learn more about these applications and attacks throughout the rest of this book.

Regardless of the attack chosen or the application used to try it, it’s important to remember that, even though they may be successful, attempts to crack encryption take a very, very long time. The stronger the encryption method and the longer the key used in the algorithm, the longer the attack will take to be successful. Additionally, it’s not acceptable security practice to assign a key and never change it. No matter how long and complex the key, given a sufficient amount of time a brute force attack will crack it. However, that amount of time can be from a couple of minutes for keys shorter than 40 bits to 50 or so years for keys longer than 64 bits. Obviously, then, if you combine a long key with a commitment to changing it out within a reasonable time period, you can be relatively sure the encryption is “uncrackable.” Per the U.S. government, an algorithm using at least a 256-bit key cannot be cracked (see AES).

	NOTE A truism of hacking really applies here: Hackers are generally about the “low-hanging fruit.” The mathematics involved in cracking encryption usually make it not worthwhile.

Chapter Review

Cryptography is the science or study of protecting information, whether in transit or at rest, by using techniques to render the information unusable to anyone who does not possess the means to decrypt it. Plaintext data (something you can read) is turned into ciphertext data (something you can’t read) by the application of some form of encryption. Encrypting data provides confidentiality because only those with the “key” can see it. Integrity can also be provided by hashing algorithms. Non-repudiation is the means by which a recipient can ensure the identity of the sender and that neither party can deny having sent or received the message.

Encryption algorithms—mathematical formulas used to encrypt and decrypt data—are highly specialized and very complex. There are two methods in which the algorithms actually work, and two methods by which these keys can be used and shared. In stream ciphers, bits of data are encrypted as a continuous stream. In other words, readable bits in their regular pattern are fed into the cipher and are encrypted one at a time. These work at a very high rate of speed. Block ciphers combine data bits into blocks and feed them into the cipher. Each block of data, usually 64 bits at a time, is then encrypted with the key and algorithm. These ciphers are considered simpler, and slower, than stream ciphers.

Symmetric encryption, also known as single key or shared key, simply means one key is used both to encrypt and decrypt the data. It is considered fast and strong, but poses some significant weaknesses. It’s a great choice for bulk encryption, due to its speed, but key distribution is an issue because the delivery of the key for the secured channel must be done offline. Additionally, scalability is a concern because as the network gets larger, the number of keys that must be generated goes up exponentially. DES, 3DES, AES (Advanced Encryption Standard), IDEA (International Data Encryption Algorithm), Twofish, and RC (Rivest Cipher) are examples.

Asymmetric encryption comes down to this: What the one key encrypts, the other key decrypts. It’s important to remember the public key is the one used for encryption, whereas the private key is used for decryption. Either can be used for encryption or decryption within the pair, but in general remember public = encrypt, private = decrypt. Asymmetric encryption can provide both confidentiality and non-repudiation, and solves the problems of key distribution and scalability. The weaknesses include its performance (asymmetric is slower than symmetric, especially on bulk encryption) and processing power (asymmetric usually requires a much longer key length, so it’s suitable for smaller amounts of data). Diffie-Hellman, Elliptic Curve Cryptosystem (ECC), El Gamal, and RSA are examples.

A hashing algorithm is a one-way mathematical function that takes an input and produces a single number (integer) based on the arrangement of the data bits in the input. It provides a means to verify the integrity of a piece of data—change a single bit in the arrangement of the original data and you’ll get a different response. The attack or effort used against hashing algorithm is known as a collision or a collision attack. A collision occurs when two or more files create the same output—which is not supposed to happen. To protect against collision attacks and the use of rainbow tables, you can also make use of something called a salt. A salt is a collection of random bits used as a key in addition to the hashing algorithm. MD5, SHA-1, and SHA2 are examples of hash algorithms.

Steganography is the practice of concealing a message inside another medium (such as another file or an image) in such a way that only the sender and recipient even know of its existence—let alone the manner in which to decipher it.

PKI is a structure designed to verify and authenticate the identity of individuals within the enterprise taking part in a data exchange. It can consist of hardware, software, and policies that create, manage, store, distribute, and revoke keys and digital certificates. The system starts at the top, with a (usually) neutral party known as the Certificate Authority (CA) that creates and issues digital certificates. The CA also keeps track of all the certificates within the system, and maintains a Certificate Revocation List (CRL), used to track which certificates have problems and which have been revoked.

A digital certificate is an electronic file that is used to verify a user’s identity, providing non-repudiation throughout the system. The certificate itself typically follows the X.509 standard, which defines what should and should not be in a digital certificate. Version, Serial Number, Subject, Algorithm ID (or Signature Algorithm), Issuer, Valid From and Valid To, Key Usage, Subject’s Public Key, and Optional are all fields within a digital certificate. A digital signature is nothing more than an algorithmic output that is designed to ensure the authenticity (and integrity) of the sender.

Cipher attacks fall into a few categories and types. Known plaintext attacks, ciphertext-only attacks, and replay attacks are examples. Man in the middle is usually listed as a type of attack by many security professionals and study guides (depending on the test version you get, it may even be listed as such). Just keep in mind that man in the middle simply means the attacker has positioned himself between the two communicating entities. Brute force refers to an attempt to try every possible combination against a target until successful.

Questions

Answers