Thin Client

source link

Understanding IPsec

Excerpt:

I’ve mentioned the IPsec protocol a few times, so let’s now take a moment to discuss the role it plays. First, the name IPsec is short for IP Security, which is a suite of subprotocols (much in the same way that TCP/IP is a suite of subprotocols) that is used to protect data crossing a network. Because IPsec operates at the network layer of the OSI model, it can protect data from the transport layer and above. This means that IPsec can protect any type of TCP- or UDP-based communication. This gives IPsec a large advantage over other encryption protocols, such as SSH and SSL. These encryption protocols work at the transport layer and are restricted to specific ports. For example, SSH encrypts only TCP port 22 by default, and SSL encrypts only TCP port 443 by default. You might be wondering, “Why is IPsec a suite of protocols? Isn’t it just supposed to encrypt the data?” Excellent question. There are a couple ways to answer this. First, the makers of IPsec realized that there was far more to protecting data than just performing encryption. Encrypted packets can still be captured and used maliciously. For example, say you send some data encrypted using IPsec that transfers $1,000 to a bank account. An attacker could capture the data and resend it many times to cause multiple transfers to go through, even though the attacker cannot see the actual data in the packet. The second answer to the question is a little more complex. IPsec is considered a suite of protocols, but it is unable to provide any direct security features in and of itself. Now, if that doesn’t blow your mind, nothing will! Here’s the idea: IPsec is better described as a framework of protocols, as shown in Picture-4

Picture-4

Each of the categories shown in Picture-4 (IPsec Protocol, Encryption, Authentication, and DH) is an open hole to be filled with a standard. Think of these holes as being like an audio CD player. The CD player doesn’t choose what type of music to play; that’s the job of the CD. When you put in a jazz CD, the CD player reads the data and outputs jazz sounds to the speakers. In the same way, the IPsec protocol acts as a “player” for whatever type of security you want to add. This is extremely powerful, because it allows the IPsec protocol to continue to be used regardless of advances in cryptography. For example, 20 years from now, many of the encryption methods we use today will probably be obsolete or considered extremely weak.

With the IPsec protocol framework, we can remove those older encryption standards and plug in new ones. The IPsec protocol itself does not change! Now that we’ve discussed the IPsec protocol framework, let’s get a basic understanding of the function of each of those holes.

Encryption

Encryption is officially called data confidentiality. Its function is to make any data that you send unreadable to unauthorized devices and yet understandable to authorized devices. To fully understand how this is possible, you would need to read a book on data cryptography. (Warning: These books typically weigh more than a small car and are guaranteed to put most people to sleep within minutes.) Rather than get into advanced cryptography, let me give you the basic premise. Each device that wants to encrypt or decrypt data needs the appropriate key. A key is an extremely advanced mathematical formula that is designed to scramble data when it is sent between devices.Picture-5 illustrates this process.

Picture-5
Based on the figure, the encryption steps are as follows:

Clear-text (unencrypted) data is sent to the encryption algorithm (key). The key runs the data through a sophisticated mathematical formula that renders the data unreadable.
The encrypted data is transmitted across the potentially unsecured network and is received by the destination device.
The destination device uses the same key to decrypt the scrambled data, returning it to its original, clear-text form.
This process is technically called symmetric encryption. In this type of encryption, the same key is used to encrypt and decrypt data. It is a faster, more efficient style of encryption. Asymmetric encryption uses two keys: one to encrypt and another to decrypt. We’ll talk about asymmetric encryption in a moment. Although many symmetric encryption algorithms are available, three types of symmetric encryption commonly are used to secure data. Each one offers varying levels of encryption strength:

Data Encryption Standard (DES) algorithm: DES was one of the first encryption algorithms to be used. It was originally developed by IBM to support a 56-bit key (the longer the key, the more secure the algorithm). By today’s standards, DES is considered a relatively weak encryption method.

Triple DES (3DES) algorithm: To address the weaknesses of DES, the 3DES algorithm was produced. This algorithm did not reinvent the wheel of encryption. Instead, it ran the DES algorithm three times with different encryption keys (thus the name 3DES). This significantly improved the strength of the original DES algorithm.
Advanced Encryption Standard (AES): AES is one of the newer encryption algorithms. It was created by Rijndael (a group of two Belgian cryptographers) in response to a competition created by the National Institute of Standards and Technology (NIST)—a division of the U.S. government. It was designed to increase encryption strength beyond the DES and 3DES standards and yet be more efficient on the device’s processor. As it stands today, AES offers 128-, 192-, and 256-bit encryption.
Diffie-Hellman:

The Diffie-Hellman (DH) key exchange algorithm addresses a gigantic missing piece of the symmetric encryption systems we just talked about. Again, the symmetric encryption algorithms (including DES, 3DES, and AES) use a “shared key” approach in which the same key can encrypt and decrypt data. This is very efficient on processing cycles, but it raises a question. If the same key encrypts and decrypts data, how do both of the devices get the key? Simple! The devices just send the key to each other over the network. So, next question: If they just send the key to each other over the network, couldn’t someone intercept the key and use it to decode all the transmissions? Ah, now that is the problem, and this is where the DH key exchange algorithm comes in.

The goal of the DH algorithm is to give devices a way to securely exchange the shared key over a public network. To accomplish this, it uses an advanced process in which both endpoints exchange results to a mathematical formula over a clear network. Using these results, each VPN endpoint can determine a shared secret value that is used to generate symmetrical encryption keys (which are much easier for the devices to process) to use for the VPN session.

The DH key exchange algorithm uses monstrously huge numbers (some more than 300 digits long) to accomplish its mathematical cryptographic process. Although DH is much more secure than symmetric encryption, it is much harder on the device’s processor. This is why DH cryptography is used only briefly at the start of the session to generate symmetric encryption keys.

Secure Socket Layer (SSL):

Although the Diffie-Hellman algorithm has long been used to secure symmetric encryption key exchange over a public network, SSL is a cryptographic protocol that provides secure communications over the Internet for things such as web browsing, instant messaging, and email. It is discussed here because SSL VPNs are continuing to increase in popularity.

As with Diffie-Hellman, the goal of SSL is to provide secure communications over a public network. To accomplish this, SSL uses a dual-key approach. Each device uses a public and private key system. These keys are reverse mathematical formulas to each other. In other words, anything that the public key encrypts, the private key can decrypt. Anything that the private key encrypts, the public key can decrypt. The public and private keys use mathematical algorithms that are so complex that it is impossible for someone who has one key to generate the opposite. For example, if you have a public key, it is feasibly impossible to figure out what the private key is, and vice versa. With this in mind, look at Figure 24.6, which illustrates the key exchange process.

Picture-6
The SSL key exchange goes through the following steps:

PC1 and PC2 send each other their respective public key encryption formula.

One of the devices (PC1 in this example) generates a shared-secret key (symmetric encryption) that will be used to encrypt and decrypt data for the session.

PC1 encrypts the shared-secret key using the public key of PC2 and transmits the key to PC2.

PC2 decrypts the shared-secret key using its private key. Now that both PC1 and PC2 have the same shared-secret key, it can and will be used to encrypt and decrypt all communication for the secured session.
SSL uses asymmetric encryption (public and private keys) at the start of the conversation to provide a secure exchange of a shared secret key. As soon as the devices have the shared secret key, the SSL session converts to using symmetric encryption because it is much more efficient on the device’s processors.

Authentication/Data Integrity:

When many IT people think of authentication, they equate it to entering a username and password to log on to a PC. This form of authentication is designed to verify that the person using the computer is who he says he is. Authentication as it applies to IPsec performs a similar, but not identical, job. When sending data over an unsecured network, you must ensure that the data received is exactly the same as the data sent and that the data is received from a trusted source. If the data changed somewhere between the sending and receiving devices, the security protocol should detect the change and reject the data.

Authentication is often used synonymously with the terms data integrity and hashing in the IPsec world. Technically speaking, authentication verifies that the device sending the data is the “true” device (not a fake). Data integrity ensures that the data does not change from one end to the other.

The process to accomplish data integrity is similar to encryption, but with a slightly different angle. As with encryption, hashing passes all the data contained in the packet (above Layer 3) through a mathematical algorithm. However, the job of this mathematical algorithm is not to scramble the data, but rather to come up with a result, which is known as the hash. As an example, the mathematical algorithm might say something like “Add up all the vowels in this data packet,” and the result might be 96. This result (known as the hash) is then appended to the end of the data and is sent to the receiver, as shown in Picture7.

The step-by-step hashing process goes like this:

The sending device passes the data to be transferred through a hashing algorithm and comes up with a result (the hash).

The hash is appended to the data and is sent to the receiving device.

The receiving device receives the data and runs it through the same hashing algorithm to generate a result. The result is then compared to the result that was originally appended to the data. If the hashed values are the same, the receiving device is assured that the data did not change during transmission. If the values are different, the data did change, and the receiving device discards it.

Picture-7
The hashing algorithm is obviously much more complex than simply adding up all the vowels in the data. Currently, two widely supported hashing algorithms are used:

Message Digest 5 (MD5) was created in 1991 by Ronald Rivest, an MIT professor. Uses a 128-bit hashing algorithm.

Secure Hash Algorithm 1 (SHA-1) was published in 1995 by the NIST to increase the strength of the original MD5 algorithm. Generally uses a 160-bit hashing algorithm.

As with encryption, the more bits that are used in the hashing algorithm, the stronger it becomes. You should use the strongest hashing algorithm that your VPN platform supports.

IPsec Protocols

The final “piece” of the IPsec framework is the IPsec protocol itself. As I mentioned, the individuals who created IPsec wanted it to be a protocol that would last through the ages. To make this happen, they even granted the flexibility to change the entire protocol engine! Today we use blocks such as Diffie-Hellman, encryption, and authentication, but maybe in 10 years some new security method will be added to the bundle. Perhaps biometric VPN security will be an option. Users would be required to complete a retinal scan to authenticate to the VPN (I can feel my sci-fi movie self emerging). We might need to add a “retinal block” to the IPsec protocol framework that is required for VPN establishment.

Okay, my example is a little out there, but the concept is sound. The IPsec protocol framework can be extended to support future security methods. Currently, you can use two “engines” for IPsec:

Authentication Header (AH): The AH protocol was the first IPsec engine to be released. It supported only authentication (verifying the sending and receiving devices) and data integrity (ensuring that data does not change in transmission). AH does not support any encryption.
Encapsulating Security Payload (ESP): The ESP protocol was the second IPsec engine to be released. It filled in the massive missing piece of AH: encryption. The ESP protocol supports all three pieces of the IPsec framework: authentication, data integrity, and encryption. Because of this, it is by far the more popular of the two IPsec engines.

source link