WIRELESS SECURITY (ENG)

📢IMPORTANT: True growth comes from questioning, not agreeing. I invite you to challenge my views in the comments. Let's learn from debate, not from echo chambers.

This is a very broad topic, since, as we saw in previous documents, the main problem with wireless networks is security. I will try to explain it simply.

To begin, we must understand why security is so important for wireless networks.

In a wired network, all the data we send is transmitted encapsulated in a cable (copper, fiber optic, etc.) that protects our information from prying eyes. In wireless networks, information travels through the air, so having robust protection is fundamental. Over the years, security has improved (sometimes after security breaches are discovered), and, of course, this is an ongoing process.

Initially, wireless connections used open authentication, which meant there was no security, only a connection verification, but without any protection.

Later, the first protection was released: WEP (Wired Equivalent Privacy).

WEP (Wired Equivalent Privacy)

When the first wireless modems from internet service providers (ISPs) were launched, they used WEP as their security password. WEP employs a static key of 64 or 128 hexadecimal bits (10 and 26 hexadecimal characters), but here's an unexpected twist: the device connects to the network using open authentication, so any device can connect to the network even if it doesn't possess the static WEP key. So, what is this static key used for? To encrypt the traffic between connections. The process is as follows.

💡To be more precise, the IEEE 802.11 standard also defines another authentication method called SKA (Shared Key Authentication). In this method, the access point (AP) sends a plaintext challenge to the client, which encrypts it and sends it back to the AP. This method was even less secure than Open Authentication, so it quickly became obsolete.

WEP presents many problems. The first is the lack of authentication. While we can't send packets, since the encryption fails without the correct static key, we can intercept all broadcast traffic on this network. If we manage to intercept this traffic, we can perform a forensic analysis.

The second problem is that WEP uses the RC4 encryption algorithm. We won't delve too deeply into encryption algorithms, but to understand the problems, we need to know how it works. Imagine you want to send a secret message to a friend. To do this, you agree on a code with them. This code can have many variations, but in this example, the letters have a numerical value from 0 to 27, incrementing by 7. So, to send "HELLO FRIEND," the code would be similar to this.

If someone intercepts your message, they won't be able to read it, but if they know the algorithm, it's easy to decrypt.

RC4 works similarly, but it has one rule: you can never use the same key twice (in our example, the key is an increment of 7). To overcome this, WEP uses an initialization vector, which is a 24-bit random value that is combined with the static key to create a new key used to encrypt the data.

💡This is just a representation to understand the problems of WEP; RC4 is more complex.

This encryption method presents a problem: the initialization vector (IV). It's a 24-bit value, which implies around 16 million different values. Although that seems like a lot, in a modern network, a huge number of packets are sent per second, so these 16 million values are exhausted in just a few minutes, and we need to reuse some. Remember the RC4 rule? You can't use the same key twice…

Therefore, we have two major problems: anyone can read the network traffic, and we're sending packets encrypted with the same key multiple times. This is a security disaster; we can break the encryption simply by intercepting network traffic for a while.

This vulnerability allows for two main attacks:

1. IV Collision Attack: Imagine you are intercepting network traffic. Each packet is encrypted with RC4, but you don't know the static key. You capture several packets until you find a match, that is, two packets encrypted with the same IV and the same key sequence. When you find one, if you know the contents of one packet (such as an ARP packet or known headers), you can perform an XOR operation and reveal the contents of the other packet, because

This attack reveals the XOR of the plaintext, but not the WEP key itself.

2. FMS Key Recovery Attack: A much more dangerous attack is the FMS key recovery attack. This attack exploits a vulnerability in the RC4 Key Scheduling Algorithm (KSA) and allows the recovery of the complete WEP key. If the device uses weak initialization vectors (IVs) (specific IV values that cause predictable KSA behavior), the process can generate non-random key sequences, revealing parts of the WEP key. It is possible to capture a large number of these packets and combine the data (using statistical analysis and deduction) to reconstruct the WEP key.

WPA [802.11] (Wi-Fi Protected Access)

The security shortcomings of WEP prompted the industry to create a quick solution: WPA (Wi-Fi Protected Access).

WPA was created as a patch to correct WEP's weaknesses, not as a permanent solution. This solution still uses RC4 as its encryption algorithm, but it radically changes how it works.

The first problem to solve was authentication; we need to authenticate devices before they can connect to our network. To do this, WPA introduces the four-way handshake protocol and the concept of a pre-shared key (PSK).

The four-way handshake protocol consists of four steps:

• The access point (AP) sends a key called ANONCE to the client, which creates a PTK (Pairwise temporary key).
• The client sends its own key called SNONCE to the AP and a MIC (message integrity check) that the client creates using the PTK.
• The access point (AP) creates its own PTK (Pairwise Temporary Key) using the client's data. It then uses this PTK to create a new MIC (Message Integrity Check) and compares it to the MIC received from the client. If they match, the AP indicates to the client that everything is correct, prompts them to save the PTK, and sends its own MIC.
• The client compares the received MIC with its own, installs the PTK, and sends an OK signal to the AP to begin transmitting data.

To understand this, we need to know what each term means:

• aNONCE / sNONCE: (One-time Authenticator or Supplicant Number). This is a random number generated by the device for each session. It is 256 bits long and is used to prevent repetition of the Initialization Vector (IV) in WEP.
• PSK (Pre-Shared Key): This is the key created to connect to the network; it is your Wi-Fi password.
• PMK (Pairwise Master Key): This is a key created from the PSK and the SSID, and it is used to generate the PTK.
• PTK (Pairwise Temporary Key): This is the key that RC4 uses to encrypt data. It is created from the aNONCE, the sNONCE, the access point's MAC address, the client's MAC address, and the PMK. IV (Initialization Vector): In WPA, this is a 48-bit value used for encryption, as in WEP. During the authentication process, its value is 0.

MIC (Message Integrity Check): This is a 64-bit value created from the PTK and the packet to be sent (including the IV). This value is compared at both ends to verify that the packet has not been modified during transmission.

The first task to initiate authentication is to create the PMK. This involves transforming the PSK and SSID into a PMK. This step is crucial, as it prevents inline dictionary attacks, which slow down the process and significantly increase its computational cost.

The process for creating the PMK uses a defined standard called PBKDF2 (Password-Based Key Derivation Function 2). To do this, the PSK, the network SSID, and a counter starting at 1 are sent to the HMAC-SHA1 hash algorithm, which performs 4096 iterations. This yields a 20-byte block, increments the counter by 1, and repeats the entire process, resulting in another 20-byte block.

We concatenate both blocks and take only the first 32bytes to build our PMK

THE 4-WAY HANDSHAKE

Now we are ready to start the 4-Way handshake process

Let’s check with a real-world capture

Here we can see the four messages that make up the 4-way handshake. In the first message, the access point sends the NONCE to the client, and we can see that the IV and MIC have a value of 0.

The second packet, sent by the client, includes the sNONCE and the MIC for comparison. In this step, the client confirms the TKIP encryption and the PSK as the key used.

In this step, the client creates the PTK, but does not send it to the AP; it only sends the MIC. If the PSK is the same, the MIC calculated by the AP should be the same as the one sent by the client.

The third step involves the access point (AP) calculating the PTK, creating a MIC, and comparing it to the MIC received from the client. If everything is correct, the AP installs the PTK, sends its own MIC to the client, and confirms: "The PTK is correct; use it to encrypt the connection.”

To finalize the negotiation, the client compares the MIC and, if it is correct, sends an ACK to the AP and initiates encrypted communication.

In this process, there is a final step. As we see, the initialization vector (IV) is always 0 in the four-way handshake, but when the devices complete authentication, the IV starts counting as in WEP (with many more options than in WEP), and the first packet sent is a packet called a GROUP MESSAGE.

This packet contains the GTK (Group Temporary Key), which is the encryption key used by the access point (AP) to encrypt the broadcast packets.

💡There are two ways to deliver GTK: combined, which sends it in the third message of the four-way handshake, and separate, which, as seen in the Wireshark capture, sends it immediately after the handshake ends. This depends on the vendor.

When this process is complete, all our data travels encrypted between our devices. This is more secure than WEP (of course, now we have real authentication), but it's not without vulnerabilities. RC4 remains our core, for better or for worse.

The first problem was an attack called the "Tews-Beck attack." The details of this attack are beyond the scope of this document, but the main idea was to send a short packet, similar to an ARP request, to the client. The client responds with a standard ARP response, and the attacker can obtain the key sequence from this packet. Following this, the attacker can guess the MIC and perform an ARP spoofing attack to replace the gateway and control all traffic. This attack, along with others like denial-of-service (DoS) attacks, is WPA's main weakness.

Fortunately, WPA was created as a quick fix for WEP, and the industry was already working on a better solution: WPA2.

WPA2 (Wi-Fi Protected Access 2)

This evolution of WPA takes what works and replaces the weaknesses. The 4-Way handshake for authentication remains, but the core needs to change: RC4 has been replaced with AES (Advanced Encryption Standard) and TKIP with CCMP (Counter Mode CBC-MAC Protocol). Let's see how it works.

As mentioned before, the authentication process remains the same (4-Way handshake), but the packet encryption changes radically.

AES is a block cipher algorithm. What does this mean? First, let's see how RC4 works. RC4 creates a KeyStream using TKIP and performs an XOR operation on each bit of the data. If we have the KeyStream, we can decrypt all the data.

AES uses a different approach.

1. It takes the PTK and performs a key schedule to create 10 different 16-byte (128-bit) keys.
2. Then, it takes the data and divides it into 16-byte chunks. If the last chunk is incomplete, it pads it with leftover data.
3. These 16 bytes are converted into an array for processing.
4. The array undergoes a process called "Add Round Key," which consists of an XOR operation with key 0, the PTK.
5. Next, it goes through a process called "Subbytes," where each byte is replaced by its equivalent in a table defined by the standard, called an S-BOX.
6. The process continues with an operation called "Shift-Rows," which consists of moving (or rotating, as if it were a Rubik's Cube) the bytes. Row 0 remains unchanged, row 1 shifts 1 position, row 2 shifts 2 positions, and row 3 shifts 3 positions.
7. Next, a process called "MIX-Columns" is performed, using the "Galois Field (2^8)" algorithm, a complex task that modifies all the bytes.
8. Afterward, the array must go through the "Add Round Key" process again, but this time using key 1.
9. At this point, the loop starts again at step 1. subbytes and is repeated 10 times. In the last iteration, the system terminates, omitting the Mix-Columns step, and executes the Add Round Key step with the 10th key.

💡To fill the data the standard is PKCS#7 Padding and consist on fill with the number of bytes remains to fill the chunk, for example if you have 8 bytes of data, remains 8bytes to fill the chunk so all the bytes added going to be 0x08

As we can see, this encryption algorithm is much more complex than RC4, but this is not enough; we need something better than TKIP to handle this robust core, and for this, WPA2 introduces CCMP.

💡If you want to learn more about AES > https://legacy.cryptool.org/en/cto/aes-step-by-step

The primary function of CCMP is to encrypt our data, but wait a minute, that's AES's job!… Well… No.

To be more efficient, CCMP "prepares" a key stream before the data to be encrypted arrives, stores these key streams, and uses them to encrypt the data when needed. Furthermore, this process is so efficient because it can run in parallel.

To create this key stream, CCMP uses AES to encrypt a counter that it creates itself. This results in a secure 128-bit key stream that is used to encrypt the data using a simple and fast XOR operation (the data must be divided into 128-bit chunks for this, and CCMP creates a counter for each chunk). This operation is called CTR (Counter Register).

💡This process can run simultaneously, and CCMP can prevent a key stream from being available when needed.

Another function of CCMP is to create the MIC using CBC-MAC (Cipher Block Chaining-Message Authentication Code).

Before encrypting the data, we divide the packet into a stack of 128-bit "containers." Now we need to create an MIC to guarantee the integrity of our packet. Let's imagine the packet consists of four 128-bit "containers." CCMP performs the following operations:

1. It sends the first "container," performs an XOR operation on an IV of 0 to AES, and uses the PTK to encrypt this packet. AES provides CCMP with another 128-bit container, which we'll call "CONTAINER-A."
2. CCMP performs an XOR operation between the result, CONTAINER-A, and the second container. The result is sent back to AES, and the process is repeated for each container. 3. The result of the last container D is a 128-bit fragment that is split, and the first 64 bits are used as the MIC that CCMP uses to send the packet.

This process ensures that if any bit changes during transmission, a chain reaction will destroy all MICs, thus discarding the packet.

This whole process can be quite confusing, so let's create a map to understand it.

With this complex algorithm, WPA2 seems truly robust, but it's never that simple… The problem with WPA2 wasn't in its core, but in the input: the four-way handshake.

In 2016, a vulnerability in WPA2 called KRACK (Key Reinstallation Attack) was discovered. The main problem with this attack was similar to that of WEP: it could force the client to use the same key stream twice.

The attacker blocks message 4 of the handshake, so the access point (AP) never confirms whether the processing key (PTK) is installed on the client. The AP forwards message 3, and the client reinstalls the PTK and sets the nonce to the default value.

💡To execute this attack, the attacker needs to be in a Man-in-the-Middle (MitM) position based on the channel's position to block and retransmit packets.

💡You can read the original article here > https://papers.mathyvanhoef.com/ccs2017.pdf

1. After installing the PTK, the client sends message 4 to confirm, but immediately begins sending encrypted data. The first packet is a DHCP request, which uses NONCE=1.
2. Upon receiving another message 4, the client reinstalls the same PTK and resets the NONCE to 1. It then forwards another DHCP request with the same NONCE.

Let's analyze this stage of the encryption process.

What happens if we use the same nonce twice? The keystream is the same in both fragments. And if the fragment is the same? Well… the encryption breaks.

The good news is that this vulnerability was fixed on client devices with some updates, and depending on the manufacturer, there may be patches for access points and an update that addresses message retransmission. The bad news is that the 4-way handshake remains vulnerable to offline dictionary attacks. Therefore, if an attacker intercepts it, they can execute a dictionary attack using common words, and if the PSK was weak, they can decrypt it.

Of course, we have the solution: WPA3.

WPA3 (Wi-Fi Protected Access 3)

WPA3-Personal still uses AES-128 as its encryption algorithm and CCMP to generate the keys. The main change in this generation focused on authentication.

The first thing WPA3 addressed was the 4-Way Handshake, due to three main problems:

• Offline dictionary attack: An attacker can perform an offline brute-force attack and obtain the pre-shared key (PSK).
• KRACK: The attack we mentioned in the previous section.
• Perfect Forward Secrecy (PFS): If someone logs your traffic today and, in a week, obtains your password, they can decrypt all the logged data.

Therefore, it was necessary to create something better: SAE (Simultaneous Authentication of Equals), also known as the "Dragonfly Handshake."

SAE is a new concept with a new authentication process, but it still uses the 4-Way Handshake.

Building the SAE-Commit

To build the commit (and make it truly secure), our devices must follow a few steps:

• Create the PWE

Creating the PWE (Password Element) is the first step in SAE. Its main function is to protect the PSK and ensure resistance to offline dictionary attacks. We have two methods for this:

• HUNT-AND-PECK (OBSOLETE): The process begins by combining the PSK + Client MAC + AP MAC + Counter (this counter is a number between 1 and 40, incremented by 1 in each iteration) and sending them to the HMAC-SHA256 algorithm. The result of HMAC-SHA256 provides us with a candidate value. This candidate is then passed to the ECC (Elliptic Curve Cryptography) algorithm. This method, known as hash-to-curve, hunt-and-peck, or sometimes dragonfly hunting, is mathematically complex but conceptually simple. The idea is to use the candidate value as the x-coordinate in the following equation of the elliptic curve:

Imagine a map with a fixed path (this path is the elliptic curve) and a defined size. We "shoot" the point obtained from the equation onto the curve. If the result falls outside the valid area, we reset and start again from the opposite side (like in the game PAC-MAN, where you can never leave the map).

If the candidate does not fall on the curve (i.e., the equation does not have a valid value for x), the process is repeated, incrementing the counter by one each time, up to a maximum of 40 attempts. Once we find a valid point (x, y), that point becomes the PWE value.

This method became obsolete due to a known vulnerability called DRAGONBLOOD, which involves measuring response time. In short, the attacker sends a confirmation request and waits for a failure. If the response time is short, the password is not close to the correct one; but if it is long, the sent password may be similar to the real one. This allows the attacker to reduce the size of the dictionary and perform brute-force attacks with the fewest possible characters.

To address this, the standard defines a new algorithm called HASH-TO-ELEMENT (H2E).

💡Dragonblood is a set of vulnerabilities. One of the most dangerous is the "Downgrade Attack," which forces the access point and client to use the 4-Way Handshake of WPA2-PSK. For more information about Dragonblood, visit https://wpa3.mathyvanhoef.com/

• HASH-TO-ELEMENT: This algorithm uses the same ecliptic curve, but also employs a function called SSWU, which acts as a complement to the curve, regardless of the data sent to it, always returning a valid point on the curve. To do this, a seed is created, composed of the SSID, the PSK, and a domain separator "SAE-H2E" to guarantee its uniqueness. This seed is applied using SHA256 hashing. Once the seed is obtained, it is sent to the SSWU function, which always returns a point on the curve.

Now we have a valid point on the curve, but how can we tell if it's correct? Well, the AP knows the actual value the point should have, so we compare both, and if they match, the PWE is correct; if not, the PWE is incorrect.

💡The comparison process takes place afterwards, once the devices have already sent the confirmations.

• Create the Scalar: This is a random number created using a system called CSPRNG (Cryptographically Secure Pseudo-Random Number Generator). The system creates a completely random 256-bit number based on software and hardware variables. This number is private and never leaves our device in raw mode. We need to encrypt it to send it to the other device. To do this, we create another 256-bit number called a mask, which we use to encrypt the scalar.

• Create the Element: Once the Scalar is created, we need to create a secret to share with the other device; this is the Element. To create it, we use the Scalar, our previous map, and the PWE expression. To find the Element, we need to perform a "bounce" along the curve along the path n times, where n is the Mask. The formula is:

It seems simple, but let's see step by step why this method is so reliable.

First, we have the working equation (PWE) as our starting point, and for this example, we're using a scalar of 5.

Then, we first need to draw a tangent line at the point on the PWE and establish a point where the tangent intersects the curve.

After this, we draw a line parallel to the Y-axis at the point we found previously, and when the line intersects the curve again, we have the second "bounce".

We need to repeat this process, “Scalar” times and we will find our ELEMENT.

At this time, we have all the necessary components to validate our PSK with the other device; therefore, both devices send each other the "COMMIT" signal.

When we receive the Commit, we have something like this:

As you can see, we received the Scalar (masked) and the Element. These are the tools we need to compare and determine if the pre-shared key (PSK) matches on both devices.

We have the following elements:

Now both devices execute the same equations

💡The processes in these equations are the addition of points and multiplication by a scalar; it is not a matter of multiplying 2 by 2, but of operations with points of the curve.

If there are no errors and both devices have the same PSK, the K value should be the same. To verify this, the devices send K to the HMAC-SHA256, which is the PMK. A MIC (confirm) is then created from this PMK and sent back and forth to verify that the value is correct.

With the PMK created, we can continue with the 4-way handshake like on WPA2, creating the PTK, etc.

WPA3 Also introduce some important improves which, i think, worth it make a mention.

PMF (Protected Management Frames)

In my opinion, this is one of the most important security improvements. WPA3 makes Protected Management Frames (PMF) mandatory.

The problem it solves (Deauthentication Attacks): In WPA2 and earlier versions, management packets (such as "Disconnect" or "Access Point Shutdown") are sent in plain text, without encryption. A nearby attacker can easily forge a deauthentication packet and send it to a client, impersonating the access point. The client receives this forged packet and disconnects from the network. This is frequently used to harass or force a client to reconnect in order to capture a handshake.

The solution in WPA3 (Mandatory PMF): With PMF (also known as 802.11w), these crucial management frames (such as deauthentication and disassociation) are also encrypted.

If an attacker sends a forged deauthentication packet (in plaintext), the client (which expects encrypted management packets) simply ignores it.

The attacker cannot create a valid encrypted management packet because they lack the session key (PTK).

In short: PMF makes WPA3 resistant to deauthentication attacks, one of the oldest and most problematic vulnerabilities in Wi-Fi.

OWE (Opportunistic Wireless Encryption)

This solves the serious problem of public and "open" Wi-Fi networks.

The problem it solves (Wi-Fi in cafes): On an "open" Wi-Fi network (like in an airport or a coffee shop), there is no password. This means there is no encryption. Anyone on the same network can spy on your traffic and see everything you do (websites, passwords, etc.). The WPA3 solution (OWE): OWE, or "Opportunistic Wireless Encryption," provides encryption without authentication. When you connect to an open network that supports OWE, your device and the access point (AP) automatically perform a transparent Diffie-Hellman key exchange (similar to SAE).

You don't need a password, but your traffic to the AP is fully encrypted with a unique key.

In short: OWE makes public Wi-Fi networks secure. While you still don't need a password, the person next to you can no longer eavesdrop on your traffic.

6 GHz Band (Wi-Fi 6 and Wi-Fi 7)

This isn't a feature of WPA3, but a rule that solidifies it as the future.

The problem it solves (legacy protocols): The 2.4 GHz and 5 GHz bands must be backward compatible, meaning that an access point (AP) must continue to support insecure protocols like WPA2-PSK (and even WPA) so that older devices can connect.

The solution (a fresh start): The Wi-Fi Alliance has decreed that the brand-new 6 GHz band is exclusively for modern technology. WPA3 is mandatory for operating in the 6 GHz band. PMF is mandatory. Legacy protocols (WEP, WPA, WPA2) are prohibited. Open networks are prohibited (they must use OWE).

In short: The 6 GHz band forces the industry to abandon all legacy security protocols, making WPA3 (and its add-ons like OWE and PMF) the sole standard for the future of high-speed Wi-Fi.

WPA-ENTERPRISE

All the authentication methods we've seen so far are the "Personal" version, which is used (or should be used) only on our home networks. However, the business world presents different problems and requires different solutions.

Imagine you manage a huge wireless network in a company with a thousand employees. If the company fires an employee, for security reasons you would have to change the password for the entire network… This is neither efficient nor secure.

To solve this, we use a framework called WPA-Enterprise (802.1X). This framework is available from WPA and has received numerous updates over the years.

To begin, we need to understand the roles that make up the 802.1X standard:

• Supplicant: This is the client device that wants to connect to the network.
• Authenticator: This is the access point (AP), which acts as a security guard. It requests the user's credentials but doesn't know their validity and must check them with the system.
• Authentication Server: This is the brain that determines whether the user has access permission. The standard is RADIUS (Remote Authentication Dial-In User Service).

Another fundamental component of WPA-ENTERPRISE is EAP (Extensible Authentication Protocol). Unlike other protocols, EAP is more like a transport framework. It defines multiple modes for securely transporting credentials and is constantly updated (hence its "extensible" nature).

Its operation is simple:

1. The device wants to connect to the network and communicates with the access point (AP).
2. The AP responds: "Who are you?" "I need your credentials."
3. The client places its credentials in a secure envelope and sends it to the access point (AP).
4. The AP doesn't need to see the credentials; it simply sends the envelope to the system without opening it.
5. The authentication server examines the envelope and queries its database to verify if the user exists and has the necessary permissions to connect. a. If the client has permission, the server and client independently generate a Master Session Key (MSK) from the successful EAP exchange. b. If the client lacks permission, the server informs the AP that authentication failed.
6. Both parties use this MSK (Master Session Key) to generate the PMK (Pairwise Master Key). The server sends its copy of the PMK to the AP.
7. Once the AP and client have the PMK (the client creates its own PMK), the four-way handshake with the AP is initiated.

For clarity, let's divide this process into three steps:

1. ASSOCIATION: Here, the AP and client begin communicating.
2. AUTHENTICATION: In this step, the client communicates with the server through the access point (AP) as an intermediary (MitM).
3. SECURE THE CONNECTION: This is the four-way handshake.

We already analyzed steps 1 and 3 earlier in this document. These steps are the same for each standard (WPA, WPA2, and WPA3), so let's focus on step 2, as it's the foundation of WPA-Enterprise.

To begin, we have different modes (called EAP methods) that we can use in this step, but the three most common are EAP-TLS, PEAP, and EAP-TTLS.

After analyzing each one, we need to understand two concepts: Certificates and TLS.

• Certificate: It's like a passport; it's issued by a Trusted Authority (some well-known ones are Verisign, GoDaddy, etc.). This certificate verifies that the device is who it claims to be. It has an expiration date and a digital signature that cannot be forged.
• TLS: Transport Layer Security is a protocol used to protect data transmission. It creates a secure channel to ensure that communication between two devices cannot be intercepted by an unauthorized device. This involves using certificates to verify device identity, encrypting traffic with a session key, and ensuring data integrity during transmission.

Now let's look at the methods mentioned.

EAP-TLS

EAP-TLS does not use a password; it works similarly to visiting a secure website (https://).

When the server verifies that the user exists in the database and has permission to connect to the network, it sends its certificate to the client. The client verifies it and sends its own. The server verifies again and, if everything is correct, generates the MSK and then the PMK, and initiates the 4-way handshake.

This method offers high security, but it comes with some drawbacks. Maintaining hundreds of certificates on each device (renewal, revocation, and issuance) is a massive and time-consuming task. Another issue is the need for a public key infrastructure (PKI). All of this means that this method is typically used only in high-security environments. For standard environments, we can use more flexible methods such as PEAP and EAP-TTLS.

PEAP

The most common method in business environments combines the security of certificates with the convenience of passwords. We can divide it into two processes:

1. The server sends its certificate to the client, who verifies its validity and trustworthiness and initiates a secure tunnel using TLS. This allows devices to communicate securely, as the access point cannot see anything within the tunnel.

2. The second step is authentication. Inside the tunnel, the server requests the client's username and password. The client sends them using the EAP-MSCHAPv2 method, which fully encrypts them within the tunnel. The server verifies the credentials against the database, and if they are correct, both generate the MSK and PMK. The server sends an Accept-Accept RADIUS packet containing the PMK to the access point (AP). The AP sends an EAP-Success message to the client and initiates the 4-way handshake.

💡EAP-MSCHAPv2 (EAP-Microsoft Challenge-Handshake Authentication Protocol v2) is an algorithm used to verify that the client has the correct password without sending it in plaintext. This is insecure if used outside of a tunnel, as it only verifies the client.

PEAP is vulnerable to phishing attacks, password sharing, weak passwords, etc., but its benefits outweigh this weakness for the industry.

EAP-TTLS

This method is similar to PEAP: the server sends a certificate, the client verifies it, and a TLS tunnel is created. The main difference from PEAP lies in the methods allowed within the tunnel; PEAP was primarily designed for EAP-MSCHAPv2, while EAP-TTLS is more flexible and allows the use of MSCHAPv2, MSCHAP, PAP, EAP-MD5, etc.

THE MSK (Master Session Key)

The ultimate goal of these methods is the same: to authenticate the client and, if authentication is successful, to create the Master Secret (MSK). This key is like a reward for successful authentication and is necessary to create the Master Key (PMK).

• In EAP-TLS, the MSK is derived from the master secret created during the TLS handshake.
• In PEAP and EAP-TTLS, it is a cryptographic combination of the TLS tunnel secret and the internal authentication secret.

Once the client and server have the MSK, they use it to create the PMK. The server sends it to the access point (within a RADIUS packet) for installation, and the client installs it. After this, they can initiate the four-way handshake.

Another methods

The three methods we saw earlier are the most common, but others exist for specific use cases. Some examples are:

• EAP-FAST: Cisco's proprietary alternative to PEAP. It also creates a secure tunnel to protect credentials, but can use a Protected Access Credential (PAC) instead of a server certificate.
• EAP-SIM / AKA: Methods used almost exclusively by mobile carriers. They allow a device (such as a smartphone) to authenticate on a Wi-Fi network using its SIM card information.
• EAP-PWD: A modern method that uses only a password (a shared secret). Unlike older methods, it uses a secure cryptographic exchange (similar to WPA3's SAE) that protects against offline dictionary attacks, without requiring a tunnel.

There are also obsolete and insecure methods like EAP-MD5 and LEAP, which should never be used on modern networks.

GCMP (GALOIS/COUNTER MODE PROTOCOL)

To conclude this document, I want to analyze an alternative to CCMP called GCMP.

WPA3-Enterprise, the standard used in some high-security facilities, such as government and financial institutions, requires a higher level of security through the use of AES-192 in CNSA mode, GCMP, EAP-TLS, and mandatory PMF.

We've already looked at PMF and EAP-TLS, so let's look at GCMP.

First, the switch to AES-192 is easy to understand: to create the round keys, we use a 192-bit PTK, the chunk size is 128 bits, but there are 12 rounds instead of 10.

The other mandatory requirement of WPA3-Enterprise was the use of GCMP (Galois/Counter Mode Protocol) instead of CCMP. GCMP fulfilled the same function: encrypting data and protecting its integrity, but the key difference lay in the method.

Recall that CCMP has two modes: CBC-MAC, used to create the MIC, and CTR, used to encrypt the data.

In GCMP, the CTR method is similar to CCMP, with the main difference being the 192-bit PTK, although the process is virtually the same.

GCMP creates a 128-bit key sequence using a nonce and the 192-bit PTK. This key sequence can be stored, and when data needs to be encrypted, GCMP performs a simple XOR operation between the key sequence and the data to send it.

The real change lies in integrity: GCMP replaces CBC-MAC with GMAC (Galois Message Authentication Code). CBC-MAC was a chained process; it was necessary to complete block 1 before starting block 2. GMAC is a parallel method that can process all blocks simultaneously and combine the results at the end.

To achieve this, the method uses 2^128 Galois fields, which guarantees that, regardless of the operation performed, a reliable result is always obtained. Pac-Man helps me visualize this: remember the "Warp Tunnel" in the middle of the first level?

Creating a MIC requires three components:

• Encrypted data: Data created with GCMP-CTR.
• Authentication data: Packet headers. Protecting their integrity is recommended.
• Authentication key (H): A 128-bit secret key ONLY for creating the MIC.

Key H is created by encrypting a full block of 0 bits using AES-192 with the PTK as the key.

With these three components, we are ready to work with Galois Operations.

The process is complex, but it can be simplified as follows.

💡The operation, as we saw earlier, is a Galois multiplication, not a regular multiplication.

The real improvement lies in the ability to perform all these operations simultaneously, using separate threads for each one, since it's not necessary to wait for the previous fragment to finish.

Once all the results are obtained (likely simultaneously on modern CPUs), an XOR operation is applied between them to obtain a partial MIC. This is then combined with the encrypted data, and the entire sequence is re-encrypted using the key sequence from the zero counter to create the 128-bit MIC.