Hello World! In the previous post, I described legacy security measures that are no longer preferred in the WiFi community, as well as WEP encryption. In this article, I detailed the operation of encryption as well as its vulnerabilities while keeping complex mathematics out of the line. Grab a cup of coffee because this is going to be another lengthy post.
But why study WEP when we now have more complex and hard to break encryption mechanisms? Let me start with a line - "Some security is better than no security": WEP is not used in the new organisation setup or your home devices, but it is still used in legacy hardware devices in the organisation or some warehouses (such as handheld devices). Because of business downtime or other internal issues, the management team frequently refuses to upgrade to the latest version of this infrastructure. This is why understanding outdated encryption techniques like WEP is crucial in such cases.
If you want a more technical explanation for why it is preferred in old embedded devices, it is due to the need for less computational power, and WEP is the best the developers could use.
Working of WEP Encryption
In the WEP, having an encryption component makes sense, as it is used to provide confidentiality in the network. The integrity checking is used to determine ensure that the data while travelling in the air is not tampered by anyone. This is accomplished by implementing a 32-bit Cyclic Redundancy Check (CRC-32) algorithm on the MSDU and then appended to it.
The encryption function is then applied on the concatenation of the MSDU + ICV(MSDU), let's called it payload for now. The key saved in the device along with random IV is used to generated the WEP seed (aka key-stream) which is then XOR'ed to get the encrypted payload.
I haven't seen the usage of keys, in my case it was always set to 0. So I will skip the discussion related to it, in this post.
Do not mix ICV with the Frame Check Sequence (FCS) – ICV is calculated only to the MSDU, but the FCS is calculated over the entire frame, including the header and payload, and is appended to the end of the frame before it is transmitted. When using WEP, the transmitter usually removes the FCS, leaving the last four bytes as the ICV value in the packet.
The encrypted data frame with headers and all the values shown above will look like this in the Wireshark panel.
Once the payload is received, following steps are used to decrypt and verify the message:
- The whole data segment is decrypted by the stream cipher derived from key and IV
- Last 4 bytes are sliced and kept in some variable
- CRC-32 is calculated on the slice data segment and compared with the value in step 2
Cryptographic Logic Behind its Working
Just one day before publishing this post, I realized that understanding "some" cryptography is required to grasp the knowledge from this post. Please keep in mind that this information does not cover RC-4 stream cipher's operation in detail, but it will give you an idea of why it is now considered "broken beyond repair".
It is a binary bit wise operation, which means that it is performed on bits rather than decimal, hex, or another number system. It, like other bit-wise operations, has a truth table: if two operands have the same value, the output is 0, otherwise it is 1. Unlike the hashing functions or other encryption functions, the length of the input is same as the output.
If this doesn't give you a hint, allow me to explain why this is used for encryption. The XOR operation has the property that if it is applied to the output again, it will produce the same result as another variable. Mathematically it is,
\[ (A \oplus B) \oplus B \implies A \]
So, if \( A \) is the plain text message and \( B \) is the shared key, the first XOR operation on the transmitter's end can be used to encrypt the message, and the second XOR operation on the receiver's end can be used to retrieve the original message.
KSA and PRGA/PRNG
RC4 algorithm uses the Key Scheduling Algorithm (KSA) and Pseudo Random Generator Algorithm (PRGA), sometimes it is also called Pseudo Random Number Generator (PRNG) to generate the random number
If you read my previous post, you would know that WEP has two configurations: a 40-bit key (5 chars) or a 104-bit key (13 chars). When it comes to MSDU length, these keys are far too short. As a result, the a key-scheduling function is used to extend the short secret key to a relatively longer length for the first XOR operation (aka encryption).
This key scheduling + XOR operation is what we known as RC-4 encryption algorithm.
Because the security of a stream cipher depends on the randomness of the generated key-stream, a random 24-bit initialization vector (IV) is passed along with the shared key to the function. And, this is why unchanged IV is sent in the wireless data frame so that it is used to generate the same key-stream for the second XOR operation (aka decryption).
Let \( K \) be a key used to encrypt two messages \( M_1 \) and \(M_2\) that produces cipher texts \( C_1 \leftarrow M_1 \oplus K \) and \( C_2 \leftarrow M_2 \oplus K \), then
\[ M_1 \oplus M_2 = C_1 \oplus C_2 \]
If a decrypted data frame does not match the embedded ICV (last four bytes) of the same frame, the frame is discarded and considered to have been sent by an unauthorized user. In this case, the access point can either continue to ignore them or send a deauthentication management frame to disconnect the station from the network, preventing additional processing of such frames.
Problem That made it Obsolete
In cryptography, the more random the algorithm used, the more secure the encryption would be. When the same key is used to encrypt the message more than once, encryption becomes simple to break. In fact, this very thing led to cracking the enigma machine.
The second problem was the repetition of the indicator, which was a serious security flaw. These security flaws enabled the Polish Cipher Bureau to break into the pre-war Enigma system as early as 1932.
Source – Wikipedia
In the case of WEP, the only parameter that changes repeatedly when encrypting the same data packet is IV. The attacker can easily exhaust it, resulting in identical cipher texts. Furthermore, the IV selection is not sequential, so the same value may be used more frequently. So it is clear that we need to capture as many unique IVs as we can to break the encryption.
IVs Capture Approach
There are two ways to get enough IVs: The passive capture is a comparatively slow one and the active capture which include packet injection is fast. But, since the the network is protected, so arbitrary packet injection will not work, and moreover can get you detected.
In this case, a clever hack would be to listen for the ARP request frame from the client and repeatedly replay it to the access point. Despite the fact that you will be sending the same frame repeatedly, the access point is bound to send unicast ARP replies with unique and randomly generated IVs.
If a client is connected but not broadcasting any ARP frames, injecting a deauthentication frame on behalf of the access point for that client will force it to rejoin the network and it will attempt to obtain environment information via DHCP and ARP requests.
Why only ARP frames used?
This is actually a nice question if you have asked to yourself (or anybody). I used to think this initially when I learnt about this technique that what is so special with the ARP frame. Well the answer lies in the size of frames and cipher text length same as of plain text property of the XOR operation.
Size of ARP request and reply is \( 28 \) bytes + \( 4 \) of append ICV and \(3 + 1\) bytes of prepended IV and key index will give length of frame body \( 36 \). So it becomes easy to capture and replay the same packet.
As a programmer, I would look for frame having body length of 36 bytes and trim the first 26 bytes of the radiotap header from it before replaying that frame on the network. If I receive a multiple responses from the access point, with body length 36 bytes, it is an out frame. The station typically broadcasts ARP request frames, and the access point unicast ARP replies to the station.
Naive Approach of Cracking the Code
Let me be honest: I'm not very good at cryptanalysis and statistics. As you can see, the sender's source IP and MAC in the request frame match the target IP and MAC in the reply frame. To crack the key, a naive approach would be
- Create a key-steam from IV and random key
- Decrypt the frames with the key-stream from step 1
- Compare the sender IP and MAC of the request frame with reply frame
I'm sure it'll take a long time, so researchers devised a more efficient method known as the PTW approach (Pyshkin, Tews, Weinmann), which is an advanced version of the FMS/KoreK method that requires less time and frames to break the encryption.
What if the access point is not present?
You're probably wondering why the packet was only sent to the access point and not to the client. This is because we need to force the generation of unique and random IVs with predictable data in the encrypted frames. No matter how many times a client sends an ARP request, the access point will always respond. Second, the same question Vivek sir asked, and boom, we got Caffe Latte Attack. In general, this attack allows you to intercept ARP packets from the probing client without association with access point.
The WEP encryption discussed in this post uses static keys, which means that the same key is shared by the access point and the station; this is known as a symmetric key in cryptography. Because WPA/TKIP, a more sophisticated algorithm, has rendered WEP obsolete, I have not discussed its other variant, Dynamic WEP.